Possibly answering my own question, RTFM ... *--dhcp-broadcast[=tag:<tag>[,tag:<tag>]]*(IPv4 only) When all the given tags appear in the tag set, always use broadcast to communicate with the host when it is unconfigured. It is permissible to supply no tags, in which case this is unconditional. Most DHCP clients which need broadcast replies set a flag in their requests so that this happens automatically, some old BOOTP clients do not.
Anyone with experience know that this is the case? Regards, Grant. On 19 April 2017 at 09:38, Grant Traynor <grant.tray...@switchdin.com> wrote: > Hi, > > I'm having an issue with the DHCP Server in dnsmasq. I'm using it with > NetworkManager to support sharing of internet connections between > dynamically plugged Ethernet interfaces (USB Ethernet Adaptors hotplugged / > unplugged into a RaspberryPi). > > NetworkManager sets up dnsmasq to serve on the interface when it's plugged > in. It runs multiple dnsmasq instances, one for each interface as it comes > and goes. dnsmasq is being run by NetworkManager as follows: > > /usr/sbin/dnsmasq --conf-file --no-hosts --keep-in-foreground > --bind-interfaces --except-interface=lo --clear-on-reload --strict-order > --listen-address=10.42.1.1 --dhcp-range=10.42.1.10,10.42.1.254,60m > --dhcp-option=option:router,10.42.1.1 --dhcp-lease-max=50 > --pid-file=/var/run/nm-dnsmasq-eth1.pid > > > This all seems to work fine on the FIRST time a DHCP address is offered. > But when the raspberrypi is rebooted, or ethernet devices are enabled and > disabled, the subnet for each interface can change. This doesn't seem to be > an issue until a client attempts to renew it's IP address. The client makes > a DHCP request to the server using the TCP broadcast address as expected. > > 23:26:56.002026 00:03:ac:0c:92:f9 (oui Unknown) > Broadcast, ethertype > IPv4 (0x0800), length 351: (tos 0x0, ttl 64, id 0, offset 0, flags [none], > proto UDP (17), length 337) > *0.0.0.0.bootpc > 255.255.255.255.bootps*: BOOTP/DHCP, Request from > 00:03:ac:0c:92:f9 (oui Unknown), length 309, xid 0x6ec92a2c, secs 12263, > Flags [none] > Client-Ethernet-Address 00:03:ac:0c:92:f9 (oui Unknown) > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: Discover > Client-ID Option 61, length 7: ether 00:03:ac:0c:92:f9 > Requested-IP Option 50, length 4: 10.42.1.96 > MSZ Option 57, length 2: 576 > Parameter-Request Option 55, length 7: > Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname > Domain-Name, BR, NTP > Vendor-Class Option 60, length 12: "udhcp 1.22.1" > Hostname Option 12, length 21: " > <<redacted>> > " > > But dnsmasq appears to generate a response to the requested IP, > effectively assuming that the client is listening on that address, which > doesn't necessarily seem to be the case. > > 23:26:56.002780 00:e0:4c:68:01:e4 (oui Unknown) > 00:03:ac:0c:92:f9 (oui > Unknown), ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 64, id 38232, > offset 0, flags [none], proto UDP (17), length 328) > 10.42.1.1.bootps > 10.42.1.96.bootpc: BOOTP/DHCP, Reply, length 300, > xid 0x6ec92a2c, secs 12263, Flags [none] > Your-IP 10.42.1.96 > Server-IP 10.42.1.1 > Client-Ethernet-Address 00:03:ac:0c:92:f9 (oui Unknown) > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: Offer > Server-ID Option 54, length 4: 10.42.1.1 > 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.42.1.255 > Domain-Name-Server Option 6, length 4: 10.42.1.1 > Default-Gateway Option 3, length 4: 10.42.1.1 > > Should the response not go back to 10.42.1.255 or some other broadcast > address? It appears as though the uDHCP client of TCP stack on the client > is ignoring the response as it does not assume that it's requested IP > address has in fact been allocated to it? > > I'm a relative NOOB on this stuff, so I'd appreciate any guidance anyone > can offer. > > Kind Regards, > Grant. > > -- > Grant Traynor > Chief Technology Officer > SwitchDin Pty Ltd > Mob +61.428408558 <+61%20428%20408%20558> > grant.tray...@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 > -- Grant Traynor Chief Technology Officer SwitchDin Pty Ltd Mob +61.428408558 grant.tray...@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
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
