On Wed, May 10, 2023 at 04:38:25PM +0200, Florian Obser wrote: > ( this is a good dhcp state diagram to follow along at home: > https://commons.wikimedia.org/wiki/File:DHCP_Client_State_Diagram_-_en.png ) > > On 2023-05-10 23:07 +10, David Diggles <da...@elven.com.au> wrote: > > I probably should have done numeric tcpdump output. Here's both again. > > > > tcpdump: WARNING: snaplen raised from 116 to 1500 > > 22:36:40.276682 0.0.0.0.68 > 255.255.255.255.67: xid:0x74253f08 > > vend-rfc1048 DHCP:REQUEST HN:"sarah" CID:1.220.159.219.40.20.191 > > PR:SM+DG+NS+HN+DN+BR+119+121 RQ:202.63.67.36 [tos 0x10] > > dhcpleased starts up and we have a lease file in /var/db/dhcpleased/, we > are in INIT-REBOOT and ask the dhcp server via broadcast if we can use > our previous IP address 202.63.67.36. We go to state REBOOTING. > > > 22:36:40.327371 202.63.66.1.67 > 255.255.255.255.68: xid:0x74253f08 > > flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf > > vend-rfc1048 DHCP:ACK SM:255.255.254.0 DG:202.63.66.1 > > NS:119.40.106.35,119.40.106.36 NTP:125.253.59.254 LT:600 SID:202.63.66.1 > > CID:1.220.159.219.40.20.191 [tos 0xc0] > > dhcp server: yeah, that's fine (DHCP:ACK). Lifetime is 600 seconds. We > configure the interface and go into state BOUND. > > some time passes > > > 22:41:40.422661 202.63.67.36.56480 > 202.63.66.1.67: (request) > > xid:0xa180ce6b C:202.63.67.36 vend-rfc1048 DHCP:REQUEST HN:"sarah" > > CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121 > > Time T1 expires, we send a unicast DHCPREQUEST to the dhcpserver: is it > OK to hold on to our IP address? We go into state RENEWING.
This looks like the thing I ran into a while ago where I had an overly broad nat-to rule for outgoing traffic that applied to traffic from the host as well as the networks behind it. This meant dhcpleased's unicast packets appeared to come from a high port, so my provider's dhcp server rejected them. It looks like David is actually using the same provider as me. If there's a pf rule like 'match out on $iface nat-to ($iface)', making that only apply to traffic received on another interface will probably help.
