-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A quick Google found this:
http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynam ic-ports/ which appears to be relevant. AFAIK dnsmasq doesn't explicitly store the MAC address of the interface on which it's listening, but the MAC address will appear in ARP entries, so there's a possibility of a mismatch there. It might be worth following the procedure in that link and nailing the MAC address of the bridge, to see if that helps. Another possibility is this: Sep 14 22:29:05 learner dnsmasq-dhcp[1556]: DHCP, sockets bound exclusively to interface lxcbr0 Which tells you that dnsmasq called the sockopt SO_BINDTODEVICE on the socket used for DHCP. It's possible that the identify of the interface is changing enough to affect that. An easy test for this theory is to remove bind-interfaces from your dnsmasq configuration. Cheers, Simon. On 27/09/15 10:58, Ritesh Raj Sarraf wrote: > On Sat, 2015-09-26 at 22:08 +0100, Simon Kelley wrote: >> It's a fairly tall order to reproduce this, but I have one idea. >> What is the MAC address associated with lxcbr0? Is it possible >> that that is changing as a result of the suspend/resume cycle? > > Hello Simon, > > Thanks for the pointer. I never had paid attention to the MAC. > > So when nothing is in use, the status of the bridge interface is: > > rrs@learner:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc > noqueue state UNKNOWN group default link/loopback > 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host > lo valid_lft forever preferred_lft forever inet6 ::1/128 scope > host > > valid_lft forever preferred_lft forever 2: wlan0: > <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group > default qlen 1000 link/ether 2c:33:7a:8e:d6:2f brd > ff:ff:ff:ff:ff:ff > > inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic wlan0 > > valid_lft 6618sec preferred_lft 6618sec inet6 > fe80::2e33:7aff:fe8e:d62f/64 scope link valid_lft forever > preferred_lft forever 3: lxcbr0: > <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state > DOWN group default link/ether 00:00:00:00:00:00 brd > ff:ff:ff:ff:ff:ff inet 172.16.10.1/16 brd 172.16.255.255 scope > global lxcbr0 valid_lft forever preferred_lft forever inet6 > fe80::20d8:7aff:fe71:53a5/64 scope link > > valid_lft forever preferred_lft forever 2015-09-27 / 15:23:22 ♒♒♒ ☺ > > > > > And interestingly, based on which VM / Container starts, the bridge > interface gets a matching MAC address. > > When booting a Fedora Container: > > rrs@learner:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc > noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 > brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft > forever preferred_lft forever inet6 ::1/128 scope host valid_lft > forever preferred_lft forever 2: wlan0: > <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group > default qlen 1000 link/ether 2c:33:7a:8e:d6:2f brd > ff:ff:ff:ff:ff:ff inet 192.168.1.100/24 brd 192.168.1.255 scope > global dynamic wlan0 valid_lft 6730sec preferred_lft 6730sec inet6 > fe80::2e33:7aff:fe8e:d62f/64 scope link valid_lft forever > preferred_lft forever 3: lxcbr0: > <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state > DOWN group default link/ether e2:29:b7:8d:a0:4e brd > ff:ff:ff:ff:ff:ff inet 172.16.10.1/16 brd 172.16.255.255 scope > global lxcbr0 valid_lft forever preferred_lft forever inet6 > fe80::20d8:7aff:fe71:53a5/64 scope link valid_lft forever > preferred_lft forever 6: vb-fedoraTempl@if2: > <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast > master lxcbr0 state LOWERLAYERDOWN group default qlen 1000 > link/ether e2:29:b7:8d:a0:4e brd ff:ff:ff:ff:ff:ff link-netnsid 0 > 2015-09-27 / 15:21:30 ♒♒♒ ☺ > > > When booting a Debian container. > > > rrs@learner:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc > noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 > brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft > forever preferred_lft forever inet6 ::1/128 scope host valid_lft > forever preferred_lft forever 2: wlan0: > <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group > default qlen 1000 link/ether 2c:33:7a:8e:d6:2f brd > ff:ff:ff:ff:ff:ff inet 192.168.1.100/24 brd 192.168.1.255 scope > global dynamic wlan0 valid_lft 6596sec preferred_lft 6596sec inet6 > fe80::2e33:7aff:fe8e:d62f/64 scope link valid_lft forever > preferred_lft forever 3: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> > mtu 1500 qdisc noqueue state UP group default link/ether > 96:07:08:fd:b1:af brd ff:ff:ff:ff:ff:ff inet 172.16.10.1/16 brd > 172.16.255.255 scope global lxcbr0 valid_lft forever preferred_lft > forever inet6 fe80::20d8:7aff:fe71:53a5/64 scope link valid_lft > forever preferred_lft forever 7: vb-debTemplate@if2: > <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master > lxcbr0 state UP group default qlen 1000 link/ether > 96:07:08:fd:b1:af brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 > fe80::9407:8ff:fefd:b1af/64 scope link valid_lft forever > preferred_lft forever 2015-09-27 / 15:23:44 ♒♒♒ ☺ > > > > In both the cases, the bridge has the same MAC ID that was (auto) > assigned to the vif. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJWCv9TAAoJEBXN2mrhkTWiNfsP/3DAlq6/o1bCXYkk3MmLJrks PJuevOFNIONEF344/4yUb6afNwgDkHcd2M18n23LPUgFc0nspBz9Om37o+h9/8bR QPyWonqZ/tLLTn1v1k8Ik+vIBdwdbOf8yQ5wSl61fD4fk9Tyr5AQCzzxRsuqLt4S szAmmjWw9p7RL+7SI2pAEEnRZw0fAnpD7aO9XSyrmLffjnCqCCujjd5CErPKpQLU wv+L1ZjWjXfil9J9AKbtfWOJKpHR6M7Bg5acYyIciPRReJVJ4cpzSx+AMfD1YFdZ qVS/N6sREX+z7o8iKVKU7GUy1KbDRH4HSkjAqsQFS2e3w8Z3SpQ8V1YXMjnk55E4 ZhrWd4s7AwCdA6dzJRyYle6E6hWHfiQTWyTxYiZv0IDD+omhnGdcqV736QcO6oIJ XWT7vpA5RLscDtXwqSDdbEJOJRNC4QDIAv0EVneQvwphqBb4cfQqBu6ZjXj4pm5u VKYpxeE2QPcoaDBR+ysupn1+Rtz7WMiFPh7mtiNvaAOxRGKy/obcYiIy05/EV1HN pHtD9YVFyjbr2utFmPfY0d9u1rOl3dVTOopw29fCHXj9hjgAZldoFx4QiTpXCpsM WlpSyNeUdF1AgHRdXaxiugnqy4LGsR/UwUCvcapHYc+73S2X2PMBJawX3Yg29Zh8 JSzLVY7olbop59tYmr5R =V7Cs -----END PGP SIGNATURE-----
