[Dnsmasq-discuss] dnsmasq and lxc-net integration on fedora 33

Orabuntu-LXC gilbert at orabuntu-lxc.com
Wed Dec 23 16:00:29 GMT 2020


So now here is the tcpdump wide open traffic I see when I attach to a
container (I have two now, nsa, and nsa2) and run "dhclient" from inside
the container (for some reason they are still not getting a DHCP address
when they start up - I have to attach and run "dhclient" manually inside
the container to get a DHCP address).

[ubuntu at f33sv1 ~]$ sudo tcpdump -i lxcbr0
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lxcbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:57:30.749047 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:16:3e:33:e5:bb (oui Unknown), length 300
09:57:30.750038 ARP, Request who-has 10.0.3.162 tell f33sv1, length 28
09:57:31.758604 ARP, Request who-has 10.0.3.162 tell f33sv1, length 28
09:57:32.782601 ARP, Request who-has 10.0.3.162 tell f33sv1, length 28
09:57:33.727730 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:16:3e:33:e5:bb (oui Unknown), length 300
09:57:33.756368 IP f33sv1 > 10.0.3.162: ICMP echo request, id 64473, seq 0,
length 28
09:57:33.756675 IP f33sv1.bootps > 10.0.3.162.bootpc: BOOTP/DHCP, Reply,
length 300
09:57:33.756991 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:16:3e:33:e5:bb (oui Unknown), length 300
09:57:33.757211 IP f33sv1.bootps > 10.0.3.162.bootpc: BOOTP/DHCP, Reply,
length 300
09:57:33.768852 IP f33sv1.bootps > 10.0.3.162.bootpc: BOOTP/DHCP, Reply,
length 302
09:57:38.990702 ARP, Request who-has 10.0.3.162 tell f33sv1, length 28
09:57:38.991039 ARP, Reply 10.0.3.162 is-at 00:16:3e:33:e5:bb (oui
Unknown), length 28
09:57:39.503692 IP6 fe80::216:3eff:fe33:e5bb > ff02::2: ICMP6, router
solicitation, length 16
09:57:54.862603 IP6 fe80::216:3eff:fe13:707c > ff02::2: ICMP6, router
solicitation, length 16
09:57:57.701930 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:16:3e:13:70:7c (oui Unknown), length 300
09:57:57.719918 IP f33sv1.bootps > 10.0.3.166.bootpc: BOOTP/DHCP, Reply,
length 303
09:58:03.054856 ARP, Request who-has 10.0.3.166 tell f33sv1, length 28
09:58:03.055166 ARP, Reply 10.0.3.166 is-at 00:16:3e:13:70:7c (oui
Unknown), length 28
09:58:15.342721 IP6 fe80::216:3eff:fe33:e5bb > ff02::2: ICMP6, router
solicitation, length 16

On Wed, Dec 23, 2020 at 9:53 AM Orabuntu-LXC <gilbert at orabuntu-lxc.com>
wrote:

> SOLVED!
>
> I noticed that lxcbr0 had a mac as shown by ifconfig of 00:16:3e:00:00:00
> and suddenly realized the "00:00:00" did not look right.  So used a mac
> address random generation function to generate a valid triplet to replace
> the 00:00:00 and edited my /etc/sysconfig/lxc-net as follows and then
> restarted lxc-net and voila! the nsa2 container got a DHCP address
> immediately!
>
> ifconfig lxcbr0
>
> lxcbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 10.0.3.1  netmask 255.255.255.0  broadcast 10.0.3.255
>         ether 00:16:3e:*00:00:00*  txqueuelen 1000  (Ethernet)
>         RX packets 61  bytes 4308 (4.2 KiB)[ubuntu at f33sv1 ~]$ cat
> /etc/sysconfig/lxc-net
> # Leave USE_LXC_BRIDGE as "true" if you want to use lxcbr0 for your
> # containers.  Set to "false" if you'll use virbr0 or another existing
> # bridge, or macvlan to your host's NIC.
> USE_LXC_BRIDGE="true"
>
> # If you change the LXC_BRIDGE to something other than lxcbr0, then
> # you will also need to update your /etc/lxc/default.conf as well as the
> # configuration (/var/lib/lxc/<container>/config) for any containers
> # already created using the default config to reflect the new bridge
> # name.
> # If you have the dnsmasq daemon installed, you'll also have to update
> # /etc/dnsmasq.d/lxc and restart the system wide dnsmasq daemon.
> LXC_BRIDGE="lxcbr0"
> LXC_BRIDGE_MAC="00:16:3e:*8f:2f:ea*"  <-- changed 00:00:00 to 8f:2f:ea
> LXC_ADDR="10.0.3.1"
> LXC_NETMASK="255.255.255.0"
> LXC_NETWORK="10.0.3.0/24"
> LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
> LXC_DHCP_MAX="253"
> # Uncomment the next line if you'd like to use a conf-file for the lxcbr0
> # dnsmasq.  For instance, you can use 'dhcp-host=mail1,10.0.3.100' to have
> # container 'mail1' always get ip address 10.0.3.100.
> #LXC_DHCP_CONFILE=/etc/lxc/dnsmasq.conf
>
> # Uncomment the next line if you want lxcbr0's dnsmasq to resolve the .lxc
> # domain.  You can then add "server=/lxc/10.0.3.1' (or your actual
> $LXC_ADDR)
> # to /etc/dnsmasq.conf, after which 'container1.lxc' will resolve on your
> # host.
> LXC_DOMAIN="lxc"
>
> sudo service lxc-net restart
>
> LXC container nsa2 got an ipv4 address directly these changes were made.
>
> [ubuntu at f33sv1 ~]$ sudo lxc-ls -f
> [sudo] password for ubuntu:
> NAME STATE   AUTOSTART GROUPS IPV4       IPV6 UNPRIVILEGED
> nsa2 RUNNING 0         -      10.0.3.166 -    false
> [ubuntu at f33sv1 ~]$ sudo lxc-attach -n nsa2
> root at nsa2:/home/ubuntu# ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:16:3e:13:70:7c
>           inet addr:10.0.3.166  Bcast:10.0.3.255  Mask:255.255.255.0
>           inet6 addr: fe80::216:3eff:fe13:707c/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:8 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:727 (727.0 B)  TX bytes:1390 (1.3 KB)
>
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> root at nsa2:/home/ubuntu#
>
> Checking now to see if I can re-enable ipv6 (which I expect should be
> fine).  I re-enabled ipv6 but it still is having some problems getting an
> ipv4 address in the container.  I find that if I attach to the container
> and run "dhclient" I can get an address reliably with ipv6 enabled in
> sysctl and with a proper mac address on lxcbr0, but that the container is
> not getting an ipv4 address automatically when started (I have to attach
> and run "dhclient" inside the container).
>
> [ubuntu at f33sv1 ~]$ sudo lxc-attach -n nsa2
> root at nsa2:/home/ubuntu# ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:16:3e:13:70:7c
>           inet6 addr: fe80::216:3eff:fe13:707c/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:2 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:108 (108.0 B)  TX bytes:656 (656.0 B)
>
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> root at nsa2:/home/ubuntu# dhclient
> root at nsa2:/home/ubuntu# ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:16:3e:13:70:7c
>           inet addr:10.0.3.166  Bcast:10.0.3.255  Mask:255.255.255.0
>           inet6 addr: fe80::216:3eff:fe13:707c/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:3 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:453 (453.0 B)  TX bytes:1068 (1.0 KB)
>
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> But this is progress ... also I have the following firewalld set:
>
> [ubuntu at f33sv1 ~]$ sudo firewall-cmd --add-service=dhcp --permanent
> Warning: ALREADY_ENABLED: dhcp
> success
> [ubuntu at f33sv1 ~]$
>
> So still working out which moving parts here are actually at issue ... but
> progress made.
>
>
>
>
> On Wed, Dec 23, 2020 at 9:00 AM Orabuntu-LXC <gilbert at orabuntu-lxc.com>
> wrote:
>
>> Next I tried listening on the veth that LXC creates when the container
>> is  started.  Once it was up, I logged into the LXC container nsa2 and ran
>> the command "dhclient" at the command line of the container.  Now I see
>> some traffic on ports 67 and 68 as follows but still not understanding what
>> is happening here.
>>
>> vethLVRkjQ: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>>         inet6 fe80::fcb2:39ff:fe74:cb61  prefixlen 64  scopeid 0x20<link>
>>         ether fe:b2:39:74:cb:61  txqueuelen 1000  (Ethernet)
>>         RX packets 7  bytes 586 (586.0 B)
>>         RX errors 0  dropped 0  overruns 0  frame 0
>>         TX packets 14  bytes 1224 (1.1 KiB)
>>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> [ubuntu at f33sv1 ~]$ sudo tcpdump -i vethLVRkjQ -vvv -s 1500 '((port 67 or
>> port 68))'
>> dropped privs to tcpdump
>> tcpdump: listening on vethLVRkjQ, link-type EN10MB (Ethernet), capture
>> size 1500 bytes
>> 08:57:05.392702 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none],
>> proto UDP (17), length 328)
>>     0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP,
>> Request from 00:16:3e:13:70:7c (oui Unknown), length 300, xid 0xb7304d0f,
>> Flags [none] (0x0000)
>>  Client-Ethernet-Address 00:16:3e:13:70:7c (oui Unknown)
>>  Vendor-rfc1048 Extensions
>>    Magic Cookie 0x63825363
>>    DHCP-Message Option 53, length 1: Discover
>>    Hostname Option 12, length 4: "nsa2"
>>    Parameter-Request Option 55, length 13:
>>      Subnet-Mask, BR, Time-Zone, Default-Gateway
>>      Domain-Name, Domain-Name-Server, Option 119, Hostname
>>      Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
>>      NTP
>>    END Option 255, length 0
>>    PAD Option 0, length 0, occurs 35
>> 08:57:08.398285 IP (tos 0xc0, ttl 64, id 7927, offset 0, flags [none],
>> proto UDP (17), length 328)
>>     f33sv1.bootps > 10.0.3.166.bootpc: [bad udp cksum 0x1bec -> 0x19ab!]
>> BOOTP/DHCP, Reply, length 300, xid 0xb7304d0f, Flags [none] (0x0000)
>>  Your-IP 10.0.3.166
>>  Server-IP f33sv1
>>  Client-Ethernet-Address 00:16:3e:13:70:7c (oui Unknown)
>>  Vendor-rfc1048 Extensions
>>    Magic Cookie 0x63825363
>>    DHCP-Message Option 53, length 1: Offer
>>    Server-ID Option 54, length 4: f33sv1
>>    Lease-Time Option 51, length 4: 3600
>>    RN Option 58, length 4: 1800
>>    RB Option 59, length 4: 3150
>>    Subnet-Mask Option 1, length 4: 255.255.255.0
>>    BR Option 28, length 4: 10.0.3.255
>>    Default-Gateway Option 3, length 4: f33sv1
>>    Domain-Name-Server Option 6, length 4: f33sv1
>>    Domain-Name Option 15, length 3: "lxc"
>>    END Option 255, length 0
>>    PAD Option 0, length 0, occurs 3
>> 08:57:08.398693 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none],
>> proto UDP (17), length 328)
>>     0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP,
>> Request from 00:16:3e:13:70:7c (oui Unknown), length 300, xid 0xb7304d0f,
>> Flags [none] (0x0000)
>>  Client-Ethernet-Address 00:16:3e:13:70:7c (oui Unknown)
>>  Vendor-rfc1048 Extensions
>>    Magic Cookie 0x63825363
>>    DHCP-Message Option 53, length 1: Request
>>    Server-ID Option 54, length 4: f33sv1
>>    Requested-IP Option 50, length 4: 10.0.3.166
>>    Hostname Option 12, length 4: "nsa2"
>>    Parameter-Request Option 55, length 13:
>>      Subnet-Mask, BR, Time-Zone, Default-Gateway
>>      Domain-Name, Domain-Name-Server, Option 119, Hostname
>>      Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
>>      NTP
>>    END Option 255, length 0
>>    PAD Option 0, length 0, occurs 23
>> 08:57:08.413078 IP (tos 0xc0, ttl 64, id 7931, offset 0, flags [none],
>> proto UDP (17), length 331)
>>     f33sv1.bootps > 10.0.3.166.bootpc: [bad udp cksum 0x1bef -> 0x3afb!]
>> BOOTP/DHCP, Reply, length 303, xid 0xb7304d0f, Flags [none] (0x0000)
>>  Your-IP 10.0.3.166
>>  Server-IP f33sv1
>>  Client-Ethernet-Address 00:16:3e:13:70:7c (oui Unknown)
>>  Vendor-rfc1048 Extensions
>>    Magic Cookie 0x63825363
>>    DHCP-Message Option 53, length 1: ACK
>>    Server-ID Option 54, length 4: f33sv1
>>    Lease-Time Option 51, length 4: 3600
>>    RN Option 58, length 4: 1800
>>    RB Option 59, length 4: 3150
>>    Subnet-Mask Option 1, length 4: 255.255.255.0
>>    BR Option 28, length 4: 10.0.3.255
>>    Default-Gateway Option 3, length 4: f33sv1
>>    Domain-Name-Server Option 6, length 4: f33sv1
>>    Domain-Name Option 15, length 3: "lxc"
>>    Hostname Option 12, length 4: "nsa2"
>>    END Option 255, length 0
>>
>> On Wed, Dec 23, 2020 at 8:40 AM Orabuntu-LXC <gilbert at orabuntu-lxc.com>
>> wrote:
>>
>>> I ran tcpdump this morning wide open (when I ran it for port 67 and port
>>> 68 there was zero traffic detected when starting the lxc container nsa2).
>>> When I ran tcpdump wide open I got the following traffic detected when the
>>> lxc container starts.  I again tried turning off firewalld completely and
>>> this is still what I get as shown below.  Wondering what is going on here?
>>>
>>> [ubuntu at f33sv1 ~]$ sudo tcpdump -i lxcbr0 -vvv
>>> dropped privs to tcpdump
>>> tcpdump: listening on lxcbr0, link-type EN10MB (Ethernet), capture size
>>> 262144 bytes
>>> 08:34:39.305449 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto
>>> IGMP (2), length 40, options (RA))
>>>     f33sv1 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr
>>> 224.0.0.252 to_ex { }]
>>> 08:34:39.305469 IP6 (hlim 1, next-header Options (0) payload length: 76)
>>> f33sv1 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6,
>>> multicast listener report v2, 3 group record(s) [gaddr ff02::1:3 to_ex { }]
>>> [gaddr ff02::1:ff00:0 to_ex { }] [gaddr ff02::6a to_ex { }]
>>> 08:34:39.305542 IP6 (hlim 1, next-header Options (0) payload length: 36)
>>> :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast
>>> listener report v2, 1 group record(s) [gaddr ff02::1:ff13:707c to_ex { }]
>>> 08:34:39.397672 IP6 (hlim 1, next-header Options (0) payload length: 76)
>>> f33sv1 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6,
>>> multicast listener report v2, 3 group record(s) [gaddr ff02::1:3 to_ex { }]
>>> [gaddr ff02::1:ff00:0 to_ex { }] [gaddr ff02::6a to_ex { }]
>>> 08:34:39.445676 IP6 (hlim 1, next-header Options (0) payload length: 36)
>>> :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast
>>> listener report v2, 1 group record(s) [gaddr ff02::1:ff13:707c to_ex { }]
>>> 08:34:39.765786 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 32) :: > ff02::1:ff13:707c: [icmp6 sum ok] ICMP6, neighbor solicitation,
>>> length 32, who has fe80::216:3eff:fe13:707c
>>>  unknown option (14), length 8 (1):
>>>    0x0000:  f203 5136 6f9a
>>> 08:34:39.891089 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 32) f33sv1 > ff02::1:ff13:707c: [icmp6 sum ok] ICMP6, neighbor
>>> solicitation, length 32, who has fe80::216:3eff:fe13:707c
>>>  source link-address option (1), length 8 (1): 00:16:3e:00:00:00
>>>    0x0000:  0016 3e00 0000
>>> 08:34:40.029649 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto
>>> IGMP (2), length 40, options (RA))
>>>     f33sv1 > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr
>>> 224.0.0.252 to_ex { }]
>>> 08:34:40.797778 IP6 (hlim 1, next-header Options (0) payload length: 36)
>>> fe80::216:3eff:fe13:707c > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6
>>> sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr
>>> ff02::1:ff13:707c to_ex { }]
>>> 08:34:40.797796 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 16) fe80::216:3eff:fe13:707c > ff02::2: [icmp6 sum ok] ICMP6, router
>>> solicitation, length 16
>>>  source link-address option (1), length 8 (1): 00:16:3e:13:70:7c
>>>    0x0000:  0016 3e13 707c
>>> 08:34:40.925732 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 32) f33sv1 > ff02::1:ff13:707c: [icmp6 sum ok] ICMP6, neighbor
>>> solicitation, length 32, who has fe80::216:3eff:fe13:707c
>>>  source link-address option (1), length 8 (1): 00:16:3e:00:00:00
>>>    0x0000:  0016 3e00 0000
>>> 08:34:40.925787 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 32) fe80::216:3eff:fe13:707c > f33sv1: [icmp6 sum ok] ICMP6, neighbor
>>> advertisement, length 32, tgt is fe80::216:3eff:fe13:707c, Flags
>>> [solicited, override]
>>>  destination link-address option (2), length 8 (1): 00:16:3e:13:70:7c
>>>    0x0000:  0016 3e13 707c
>>> 08:34:40.925797 IP6 (flowlabel 0xb6a64, hlim 1, next-header TCP (6)
>>> payload length: 44) f33sv1.60688 > fe80::216:3eff:fe13:707c.hostmon: Flags
>>> [S], cksum 0xebef (incorrect -> 0xb854), seq 2709608773, win 64800, options
>>> [mss 1440,sackOK,TS val 789202957 ecr 0,nop,wscale 7,tfo
>>>  cookiereq,nop,nop], length 0
>>> 08:34:40.925818 IP6 (flowlabel 0xed86d, hlim 64, next-header TCP (6)
>>> payload length: 20) fe80::216:3eff:fe13:707c.hostmon > f33sv1.60688: Flags
>>> [R.], cksum 0xebd7 (incorrect -> 0xc74f), seq 0, ack 2709608774, win 0,
>>> length 0
>>> 08:34:41.693783 IP6 (hlim 1, next-header Options (0) payload length: 36)
>>> fe80::216:3eff:fe13:707c > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6
>>> sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr
>>> ff02::1:ff13:707c to_ex { }]
>>> 08:34:44.509930 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 16) fe80::216:3eff:fe13:707c > ff02::2: [icmp6 sum ok] ICMP6, router
>>> solicitation, length 16
>>>  source link-address option (1), length 8 (1): 00:16:3e:13:70:7c
>>>    0x0000:  0016 3e13 707c
>>> 08:34:46.045831 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 32) fe80::216:3eff:fe13:707c > f33sv1: [icmp6 sum ok] ICMP6, neighbor
>>> solicitation, length 32, who has f33sv1
>>>  source link-address option (1), length 8 (1): 00:16:3e:13:70:7c
>>>    0x0000:  0016 3e13 707c
>>> 08:34:46.045891 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
>>> 24) f33sv1 > fe80::216:3eff:fe13:707c: [icmp6 sum ok] ICMP6, neighbor
>>> advertisement, length 24, tgt is f33sv1, Flags [solicited]
>>>
>>> On Wed, Dec 23, 2020 at 12:14 AM Orabuntu-LXC <gilbert at orabuntu-lxc.com>
>>> wrote:
>>>
>>>> Hi, I cannot get dnsmasq to issue a dhcp address via lxc-net on fedora
>>>> 33.  I have compared it to a working system on Ubuntu 20.04 and what I find
>>>> is that when an lxc container starts, there is DHCPOFFER normal activity in
>>>> lxc-net status on Ubuntu 20.04, but not on Fedora 33 where the
>>>> configuration is afaik exactly the same.
>>>>
>>>> I have tried various firewalld settings in case firewalld was blocking
>>>> somehow, but nothing has worked including disabling firewalld entirely as
>>>> well as disabling selinux entirely.  Tomorrow I will try  tcpdump and see
>>>> if there are clues there.  Thanks!
>>>>
>>>> --
>>>> Gilbert Standen
>>>> Creator Orabuntu-LXC
>>>> 914-261-4594
>>>> gilbert at orabuntu-lxc.com
>>>>
>>>>
>>>
>>> --
>>> Gilbert Standen
>>> Creator Orabuntu-LXC
>>> 914-261-4594
>>> gilbert at orabuntu-lxc.com
>>>
>>>
>>
>> --
>> Gilbert Standen
>> Creator Orabuntu-LXC
>> 914-261-4594
>> gilbert at orabuntu-lxc.com
>>
>>
>
> --
> Gilbert Standen
> Creator Orabuntu-LXC
> 914-261-4594
> gilbert at orabuntu-lxc.com
>
>

-- 
Gilbert Standen
Creator Orabuntu-LXC
914-261-4594
gilbert at orabuntu-lxc.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20201223/01ae79fb/attachment-0001.html>


More information about the Dnsmasq-discuss mailing list