Grant Traynor
2017-03-16 09:36:53 UTC
Hi,
I have a few USB ethernet interfaces that can be hot plugged by users.
These are managed by NetworkManager (shared), which automatically allocates
an IP address to the interface, and starts up dnsmasq to serve any DHCP
requests on that interface.
The problem occurs with some devices which have already been assigned an IP
address come back to dnsmasq for an address. When the interface comes back
up, the device does a DHCPDISCOVER on the old subnet, but the OFFER goes
back on the new subnet. (maybe?)
06:22:50.881436 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype IPv4
(0x0800), length 390: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 1a:2b:3c:4d:16:f3 (oui Unknown), length 348
06:23:08.606107 30:37:16:55:14:51 (oui Unknown) > Broadcast, ethertype IPv4
(0x0800), length 291: 10.42.2.251.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 30:37:16:55:14:51 (oui Unknown), length 249
06:23:08.606874 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 42: Request who-has 10.42.0.251 tell 10.42.0.1, length 28
06:23:09.600302 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 42: Request who-has 10.42.0.251 tell 10.42.0.1, length 28
06:23:10.600308 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 42: Request who-has 10.42.0.251 tell 10.42.0.1, length 28
06:23:11.110214 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype IPv4
(0x0800), length 342: 10.42.0.1.bootps > 255.255.255.255.bootpc:
BOOTP/DHCP, Reply, length 300
The device seems to be looking for the old DHCP server:
06:23:34.768933 30:37:16:55:14:51 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 60: Request who-has 10.42.2.1 tell 10.42.2.251, length 46
My routing table is:
default via 192.168.1.1 dev eth0 metric 202
10.42.0.0/24 dev eth1 proto kernel scope link src 10.42.0.1
169.254.0.0/16 dev wlan0 proto kernel scope link src 169.254.214.238
metric 303
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20 metric
202
192.168.44.0/24 dev wlan0 proto kernel scope link src 192.168.44.1
There is no DHCPNACK offered by dnsmasq?
It almost seems as though it's ignoring the subnet when it offers the IP
address?
Has anyone else seen this behavior or can anyone shed some light?
Kind Regards,
Grant.
--
Grant Traynor
Chief Technology Officer
SwitchDin Pty Ltd
Mob +61.428408558 <+61%20428%20408%20558>
***@switchdin.com
http://www.switchdin.com/ <http://switchd.in/>
linkedin.com/in/grant-traynor-636b095
<https://au.linkedin.com/in/grant-traynor-636b095>
Level 2, Building B, 91 Parry Street, Newcastle West, NSW, 2302
This email and any attachments are proprietary and confidential and are
intended solely for the use of the individual to whom it is addressed. Any
views or opinions expressed are solely those of the author and do not
necessarily reflect or represent those of SwitchDin Pty Ltd. If you have
received this email in error, please let us know immediately by reply email
and delete it from your system. You may not use, disseminate, distribute or
copy this message nor disclose its contents to anyone.
SwitchDin Pty Ltd (ABN 29 154893857) PO Box 1165, Newcastle NSW 2300
Australia
I have a few USB ethernet interfaces that can be hot plugged by users.
These are managed by NetworkManager (shared), which automatically allocates
an IP address to the interface, and starts up dnsmasq to serve any DHCP
requests on that interface.
The problem occurs with some devices which have already been assigned an IP
address come back to dnsmasq for an address. When the interface comes back
up, the device does a DHCPDISCOVER on the old subnet, but the OFFER goes
back on the new subnet. (maybe?)
06:22:50.881436 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype IPv4
(0x0800), length 390: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 1a:2b:3c:4d:16:f3 (oui Unknown), length 348
06:23:08.606107 30:37:16:55:14:51 (oui Unknown) > Broadcast, ethertype IPv4
(0x0800), length 291: 10.42.2.251.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 30:37:16:55:14:51 (oui Unknown), length 249
06:23:08.606874 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 42: Request who-has 10.42.0.251 tell 10.42.0.1, length 28
06:23:09.600302 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 42: Request who-has 10.42.0.251 tell 10.42.0.1, length 28
06:23:10.600308 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 42: Request who-has 10.42.0.251 tell 10.42.0.1, length 28
06:23:11.110214 1a:2b:3c:4d:16:f3 (oui Unknown) > Broadcast, ethertype IPv4
(0x0800), length 342: 10.42.0.1.bootps > 255.255.255.255.bootpc:
BOOTP/DHCP, Reply, length 300
The device seems to be looking for the old DHCP server:
06:23:34.768933 30:37:16:55:14:51 (oui Unknown) > Broadcast, ethertype ARP
(0x0806), length 60: Request who-has 10.42.2.1 tell 10.42.2.251, length 46
My routing table is:
default via 192.168.1.1 dev eth0 metric 202
10.42.0.0/24 dev eth1 proto kernel scope link src 10.42.0.1
169.254.0.0/16 dev wlan0 proto kernel scope link src 169.254.214.238
metric 303
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20 metric
202
192.168.44.0/24 dev wlan0 proto kernel scope link src 192.168.44.1
There is no DHCPNACK offered by dnsmasq?
It almost seems as though it's ignoring the subnet when it offers the IP
address?
Has anyone else seen this behavior or can anyone shed some light?
Kind Regards,
Grant.
--
Grant Traynor
Chief Technology Officer
SwitchDin Pty Ltd
Mob +61.428408558 <+61%20428%20408%20558>
***@switchdin.com
http://www.switchdin.com/ <http://switchd.in/>
linkedin.com/in/grant-traynor-636b095
<https://au.linkedin.com/in/grant-traynor-636b095>
Level 2, Building B, 91 Parry Street, Newcastle West, NSW, 2302
This email and any attachments are proprietary and confidential and are
intended solely for the use of the individual to whom it is addressed. Any
views or opinions expressed are solely those of the author and do not
necessarily reflect or represent those of SwitchDin Pty Ltd. If you have
received this email in error, please let us know immediately by reply email
and delete it from your system. You may not use, disseminate, distribute or
copy this message nor disclose its contents to anyone.
SwitchDin Pty Ltd (ABN 29 154893857) PO Box 1165, Newcastle NSW 2300
Australia