Re: dhcpleased losing route
On 2023 May 12 (Fri) at 00:10:33 +1000 (+1000), David Diggles wrote: :Here's a longer tcpdump that should have a couple of rounds. :The ISP does offer ipv6 but I'm not ready to give up on dhcp yet. : You can run both in parallel, no problems with that. -- Expect the worst. It's the least you can do.
Re: dhcpleased losing route
Yes this is now fixed. Thanks everyone! Stuart's suggestion of "received-on" is indeed excellent and is what I've used. On Thu, May 11, 2023 at 04:13:34PM +0200, Florian Obser wrote: > On 2023-05-11 08:08 +10, David Diggles wrote: > > On Thu, May 11, 2023 at 07:27:22AM +1000, Jonathan Matthew wrote: > >> > >> 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. > > > > The nat rule I have > > > > match out on egress nat-to (egress) > > > > Yes, pretty sure this is causing your issue, like Jonathan was > describing. > > -- > In my defence, I have been left unsupervised. >
Re: dhcpleased losing route
On 2023-05-11 08:08 +10, David Diggles wrote: > On Thu, May 11, 2023 at 07:27:22AM +1000, Jonathan Matthew wrote: >> >> 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. > > The nat rule I have > > match out on egress nat-to (egress) > Yes, pretty sure this is causing your issue, like Jonathan was describing. -- In my defence, I have been left unsupervised.
Re: dhcpleased losing route
Here's a longer tcpdump that should have a couple of rounds. The ISP does offer ipv6 but I'm not ready to give up on dhcp yet. tcpdump: WARNING: snaplen raised from 116 to 1500 22:54:27.011337 202.63.67.36.68 > 202.63.66.1.67: xid:0x10040a18 C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 22:54:27.059554 202.63.66.1.67 > 202.63.67.36.68: xid:0x10040a18 C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 22:58:25.011341 202.63.67.36.68 > 202.63.66.1.67: xid:0x10040a18 C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 22:58:25.062762 202.63.66.1.67 > 202.63.67.36.68: xid:0x10040a18 C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:03:01.011350 202.63.67.36.68 > 202.63.66.1.67: xid:0x10040a18 C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 23:03:01.059384 202.63.66.1.67 > 202.63.67.36.68: xid:0x10040a18 C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:07:49.011348 202.63.67.36.68 > 202.63.66.1.67: xid:0x10040a18 C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 23:07:49.058859 202.63.66.1.67 > 202.63.67.36.68: xid:0x10040a18 C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:12:05.011350 202.63.67.36.68 > 202.63.66.1.67: xid:0x10040a18 C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 23:12:05.061192 202.63.66.1.67 > 202.63.67.36.68: xid:0x10040a18 C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:16:40.229532 0.0.0.0.68 > 255.255.255.255.67: xid:0xede3396c vend-rfc1048 DHCP:REQUEST LT:86400 RQ:202.63.67.36 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 23:16:46.011758 0.0.0.0.68 > 255.255.255.255.67: xid:0xede3396c secs:6 vend-rfc1048 DHCP:REQUEST LT:86400 RQ:202.63.67.36 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 23:16:46.061397 202.63.66.1.67 > 255.255.255.255.68: xid:0xede3396c flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether 20:c9:d0:15:3c:a3 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:21:03.011372 202.63.67.36.68 > 202.63.66.1.67: xid:0xede3396c C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 23:21:03.061077 202.63.66.1.67 > 202.63.67.36.68: xid:0xede3396c C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:26:00.011350 202.63.67.36.68 > 202.63.66.1.67: xid:0xede3396c C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 23:26:00.061670 202.63.66.1.67 > 202.63.67.36.68: xid:0xede3396c C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:29:56.011353 202.63.67.36.68 > 202.63.66.1.67: xid:0xede3396c C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 23:29:56.060547 202.63.66.1.67 > 202.63.67.36.68: xid:0xede3396c C:202.63.67.36 Y:202.63.67.36 S:172.21.116.42 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 23:34:54.011347 202.63.67.36.68 > 202.63.66.1.67: xid:0xede3396c C:202.63.67.36 vend-rfc1048 DHCP:REQUEST LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 23:34:54.068231 202.63.66.1.67 > 202.63.67.36.68: xid:0xede3396c C:202.63.67.36 Y:202.63.67.36
Re: dhcpleased losing route
You are still getting a 5 minute lease. So that seems to be normal for your provider? (Maybe they only have a very limited pool of IPv4 addresses and want to be able to reuse them ASAP? Might explain why the initial DHCP:OFFER took so long as well.) But you don’t show what happens when the lease is to be renewed in your dump. That is where you received the NAK on OpenBSD which caused your machine to temporarily loose the IP, the gateway and the name servers. Does your provider offer IPv6? You may be better off using that. > Am 11.05.2023 um 05:08 schrieb David Diggles : > > Ok here's the Apple pcap for a working implementation. > > tcpdump -r airport.dhcp.pcap > > tcpdump: WARNING: snaplen raised from 116 to 1500 > 12:26:04.010316 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5fc12750 > secs:28 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] > 12:26:27.806275 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xb4e0b61a > vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 > CID:1.32.201.208.21.60.163 [tos 0x10] > 12:26:33.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xb4e0b61a > secs:6 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] > 12:26:44.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xb4e0b61a > secs:17 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] > 12:26:49.707196 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 > vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 > CID:1.32.201.208.21.60.163 [tos 0x10] > 12:26:55.010311 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 > secs:6 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] > 12:27:03.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 > secs:14 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] > 12:27:12.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 > secs:23 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] > 12:27:57.010496 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x34861165 > vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 > CID:1.32.201.208.21.60.163 [tos 0x10] > 12:27:57.227277 202.63.66.1.bootps > 255.255.255.255.bootpc: xid:0x34861165 > flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether 20:c9:d0:15:3c:a3 > vend-rfc1048 DHCP:OFFER 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 > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] > 12:27:57.228177 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x34861165 > vend-rfc1048 DHCP:REQUEST SID:202.63.66.1 LT:86400 RQ:202.63.67.36 HN:"x" > PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] > 12:27:58.075046 202.63.66.1.bootps > 255.255.255.255.bootpc: xid:0x34861165 > flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether 20:c9:d0:15:3c:a3 > 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 > MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] > > On Thu, May 11, 2023 at 12:20:48AM +0200, Sebastian Benoit wrote: >> i think that putput does not help mmuch because it does not show the DHCP >> packet contents. >> >> You could write the capture to a file with "-w filename" and then copy the >> file to the OpenBSD box for printing with "-r filename". Or send the raw >> pcap file. >> >> /B. -- Mike Fischer fisc...@lavielle.com
Re: dhcpleased losing route
Ok here's the Apple pcap for a working implementation. tcpdump -r airport.dhcp.pcap tcpdump: WARNING: snaplen raised from 116 to 1500 12:26:04.010316 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5fc12750 secs:28 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:26:27.806275 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xb4e0b61a vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:26:33.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xb4e0b61a secs:6 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:26:44.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xb4e0b61a secs:17 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:26:49.707196 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:26:55.010311 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 secs:6 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:27:03.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 secs:14 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:27:12.010312 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5886fe16 secs:23 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:27:57.010496 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x34861165 vend-rfc1048 DHCP:DISCOVER LT:86400 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:27:57.227277 202.63.66.1.bootps > 255.255.255.255.bootpc: xid:0x34861165 flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether 20:c9:d0:15:3c:a3 vend-rfc1048 DHCP:OFFER 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] 12:27:57.228177 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x34861165 vend-rfc1048 DHCP:REQUEST SID:202.63.66.1 LT:86400 RQ:202.63.67.36 HN:"x" PR:SM+TZ+DG+DN+NS+HN+WNS MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0x10] 12:27:58.075046 202.63.66.1.bootps > 255.255.255.255.bootpc: xid:0x34861165 flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether 20:c9:d0:15:3c:a3 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 MSZ:1500 CID:1.32.201.208.21.60.163 [tos 0xc0] On Thu, May 11, 2023 at 12:20:48AM +0200, Sebastian Benoit wrote: > i think that putput does not help mmuch because it does not show the DHCP > packet contents. > > You could write the capture to a file with "-w filename" and then copy the > file to the OpenBSD box for printing with "-r filename". Or send the raw > pcap file. > > /B.
Re: dhcpleased losing route
On 2023-05-10, Jonathan Matthew wrote: > 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. "received-on" is excellent for making rules only apply to packets coming from some specific interface. in particular, "!received-on any" will prevent a rule (e.g. a match...nat-to) from applying to locally-generated packets.
Re: dhcpleased losing route
David Diggles(da...@elven.com.au) on 2023.05.11 08:09:54 +1000: > Thanks Florian, here's a tcpdump from the Apple (NetBSD) router. > This implementatin isn't losing the default route. > > tcpdump -n -i mgi1 -s1500 -vv port 67 or 68 > tcpdump: listening on mgi1, link-type EN10MB (Ethernet), capture size 1500 > bytes > 07:15:36.010329 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: > 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 > 07:15:40.326961 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: > 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 > 07:15:47.010316 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: > 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 > 07:15:47.065803 IP (tos 0xc0, ttl 128, id 47543, offset 0, flags [none], > length: 328) 202.63.66.1.67 > 255.255.255.255.68: [udp sum ok] UDP, length: > 300 > 07:15:47.066581 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: > 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 > 07:15:47.281209 IP (tos 0xc0, ttl 128, id 59063, offset 0, flags [none], > length: 328) 202.63.66.1.67 > 255.255.255.255.68: [udp sum ok] UDP, length: > 300 > 07:20:42.239765 IP (tos 0x0, ttl 64, id 31050, offset 0, flags [none], > length: 328, bad cksum 0 (->e6b6)!) 202.63.67.36.68 > 202.63.66.1.67: [bad > udp cksum 8b57!] UDP, length: 300 > 07:20:42.288197 IP (tos 0xc0, ttl 128, id 45441, offset 0, flags [none], > length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300 > 07:25:07.019747 IP (tos 0x0, ttl 64, id 18503, offset 0, flags [none], > length: 328, bad cksum 0 (->17ba)!) 202.63.67.36.68 > 202.63.66.1.67: [bad > udp cksum 8b57!] UDP, length: 300 > 07:25:07.085454 IP (tos 0xc0, ttl 128, id 28472, offset 0, flags [none], > length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300 > 07:30:08.019746 IP (tos 0x0, ttl 64, id 46516, offset 0, flags [none], > length: 328, bad cksum 0 (->aa4c)!) 202.63.67.36.68 > 202.63.66.1.67: [bad > udp cksum 8b57!] UDP, length: 300 > 07:30:08.068323 IP (tos 0xc0, ttl 128, id 21000, offset 0, flags [none], > length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300 Hi, i think that putput does not help mmuch because it does not show the DHCP packet contents. You could write the capture to a file with "-w filename" and then copy the file to the OpenBSD box for printing with "-r filename". Or send the raw pcap file. /B. > 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 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. > > > > > 22:41:40.434534 202.63.66.1.67 > 202.63.67.36.68: xid:0xa180ce6b > > > C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 > > > CID:1.220.159.219.40.20.191 [tos 0xc0] > > > > dhcp server: Absolutely not! DHCP:NACK. > > > > RFC 2131 has this: > > > > If the client receives a DHCPNAK message, it cannot reuse its > > remembered network address. It must instead request a new > > address by restarting the configuration process, this time > > using the (non-abbreviated) procedure described in section > > 3.1. This action also corresponds to the client moving to > > the INIT state in the DHCP state diagram. > > > > There is not a lot of wiggle room, we MUST remove our address. We go to > >
Re: dhcpleased losing route
Thanks Florian, here's a tcpdump from the Apple (NetBSD) router. This implementatin isn't losing the default route. tcpdump -n -i mgi1 -s1500 -vv port 67 or 68 tcpdump: listening on mgi1, link-type EN10MB (Ethernet), capture size 1500 bytes 07:15:36.010329 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 07:15:40.326961 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 07:15:47.010316 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 07:15:47.065803 IP (tos 0xc0, ttl 128, id 47543, offset 0, flags [none], length: 328) 202.63.66.1.67 > 255.255.255.255.68: [udp sum ok] UDP, length: 300 07:15:47.066581 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300 07:15:47.281209 IP (tos 0xc0, ttl 128, id 59063, offset 0, flags [none], length: 328) 202.63.66.1.67 > 255.255.255.255.68: [udp sum ok] UDP, length: 300 07:20:42.239765 IP (tos 0x0, ttl 64, id 31050, offset 0, flags [none], length: 328, bad cksum 0 (->e6b6)!) 202.63.67.36.68 > 202.63.66.1.67: [bad udp cksum 8b57!] UDP, length: 300 07:20:42.288197 IP (tos 0xc0, ttl 128, id 45441, offset 0, flags [none], length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300 07:25:07.019747 IP (tos 0x0, ttl 64, id 18503, offset 0, flags [none], length: 328, bad cksum 0 (->17ba)!) 202.63.67.36.68 > 202.63.66.1.67: [bad udp cksum 8b57!] UDP, length: 300 07:25:07.085454 IP (tos 0xc0, ttl 128, id 28472, offset 0, flags [none], length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300 07:30:08.019746 IP (tos 0x0, ttl 64, id 46516, offset 0, flags [none], length: 328, bad cksum 0 (->aa4c)!) 202.63.67.36.68 > 202.63.66.1.67: [bad udp cksum 8b57!] UDP, length: 300 07:30:08.068323 IP (tos 0xc0, ttl 128, id 21000, offset 0, flags [none], length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300 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 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. > > > 22:41:40.434534 202.63.66.1.67 > 202.63.67.36.68: xid:0xa180ce6b > > C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 > > CID:1.220.159.219.40.20.191 [tos 0xc0] > > dhcp server: Absolutely not! DHCP:NACK. > > RFC 2131 has this: > > If the client receives a DHCPNAK message, it cannot reuse its > remembered network address. It must instead request a new > address by restarting the configuration process, this time > using the (non-abbreviated) procedure described in section > 3.1. This action also corresponds to the client moving to > the INIT state in the DHCP state diagram. > > There is not a lot of wiggle room, we MUST remove our address. We go to > state INIT. > > > 22:41:40.442012 0.0.0.0.68 > 255.255.255.255.67: xid:0x6a13ec33 > > vend-rfc1048 DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 > > PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] > > dhcpleased, broadcast: could I please have a lease? go to state SELECTING > > > 22:41:41.532272 0.0.0.0.68 > 255.255.255.255.67: xid:0x6a13ec33 > > vend-rfc1048 DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 > > PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] > > dhcpleased, broadcast: could I
Re: dhcpleased losing route
On Thu, May 11, 2023 at 07:27:22AM +1000, Jonathan Matthew wrote: > > 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. The nat rule I have match out on egress nat-to (egress)
Re: dhcpleased losing route
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 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.
Re: dhcpleased losing route
( 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 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. > 22:41:40.434534 202.63.66.1.67 > 202.63.67.36.68: xid:0xa180ce6b > C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 > CID:1.220.159.219.40.20.191 [tos 0xc0] dhcp server: Absolutely not! DHCP:NACK. RFC 2131 has this: If the client receives a DHCPNAK message, it cannot reuse its remembered network address. It must instead request a new address by restarting the configuration process, this time using the (non-abbreviated) procedure described in section 3.1. This action also corresponds to the client moving to the INIT state in the DHCP state diagram. There is not a lot of wiggle room, we MUST remove our address. We go to state INIT. > 22:41:40.442012 0.0.0.0.68 > 255.255.255.255.67: xid:0x6a13ec33 vend-rfc1048 > DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 > PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] dhcpleased, broadcast: could I please have a lease? go to state SELECTING > 22:41:41.532272 0.0.0.0.68 > 255.255.255.255.67: xid:0x6a13ec33 vend-rfc1048 > DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 > PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] dhcpleased, broadcast: could I please have a lease? pretty please? with sugar on top? stay in state SELECTING > 22:41:41.653804 202.63.66.1.67 > 255.255.255.255.68: xid:0x6a13ec33 > flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf > vend-rfc1048 DHCP:OFFER 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] server: ok fine, do you like this one? > 22:41:41.658881 0.0.0.0.68 > 255.255.255.255.67: xid:0xdafa3da4 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 SID:202.63.66.1 [tos 0x10] dhcpleased: looks, good, is it ok if I use this one? go to state REQUESTING > 22:41:42.414218 202.63.66.1.67 > 255.255.255.255.68: xid:0xdafa3da4 > 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: yes, that's fine. dhcpleased: configure address, go to state BOUND. This process repeats every 5 minutes. To me it looks like the server just NACKS all unicast requests. As far as I remember our broadcast DHCPREQUESTs are exactly the same as our unicast DHCPREQUESTs, so it's not the contents of the packet. You were saying this works with other implementations? I would be interested in seeing a tcpdump for those. > 22:46:42.512451 202.63.67.36.63976 > 202.63.66.1.67: (request) xid:0x953f83f1 > 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 > 22:46:42.525222 202.63.66.1.67 > 202.63.67.36.68: xid:0x953f83f1 > C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 > CID:1.220.159.219.40.20.191 [tos 0xc0] > 22:46:42.531574 0.0.0.0.68 > 255.255.255.255.67: xid:0x66009a6e vend-rfc1048 > DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 > PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] > 22:46:43.622162 0.0.0.0.68 > 255.255.255.255.67: xid:0x66009a6e vend-rfc1048 > DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 > PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] > 22:46:43.762685 202.63.66.1.67 > 255.255.255.255.68: xid:0x66009a6e > flags:0x8000 Y:202.63.67.36
Re: dhcpleased losing route
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] 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] 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 22:41:40.434534 202.63.66.1.67 > 202.63.67.36.68: xid:0xa180ce6b C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 CID:1.220.159.219.40.20.191 [tos 0xc0] 22:41:40.442012 0.0.0.0.68 > 255.255.255.255.67: xid:0x6a13ec33 vend-rfc1048 DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] 22:41:41.532272 0.0.0.0.68 > 255.255.255.255.67: xid:0x6a13ec33 vend-rfc1048 DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] 22:41:41.653804 202.63.66.1.67 > 255.255.255.255.68: xid:0x6a13ec33 flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf vend-rfc1048 DHCP:OFFER 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] 22:41:41.658881 0.0.0.0.68 > 255.255.255.255.67: xid:0xdafa3da4 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 SID:202.63.66.1 [tos 0x10] 22:41:42.414218 202.63.66.1.67 > 255.255.255.255.68: xid:0xdafa3da4 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] 22:46:42.512451 202.63.67.36.63976 > 202.63.66.1.67: (request) xid:0x953f83f1 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 22:46:42.525222 202.63.66.1.67 > 202.63.67.36.68: xid:0x953f83f1 C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 CID:1.220.159.219.40.20.191 [tos 0xc0] 22:46:42.531574 0.0.0.0.68 > 255.255.255.255.67: xid:0x66009a6e vend-rfc1048 DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] 22:46:43.622162 0.0.0.0.68 > 255.255.255.255.67: xid:0x66009a6e vend-rfc1048 DHCP:DISCOVER HN:"sarah" CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121 [tos 0x10] 22:46:43.762685 202.63.66.1.67 > 255.255.255.255.68: xid:0x66009a6e flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf vend-rfc1048 DHCP:OFFER 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] 22:46:43.768051 0.0.0.0.68 > 255.255.255.255.67: xid:0xfe3d764f 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 SID:202.63.66.1 [tos 0x10] 22:46:44.526556 202.63.66.1.67 > 255.255.255.255.68: xid:0xfe3d764f 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] state_transition[cnmac2] Down -> Rebooting, timo: 1 DHCPREQUEST on cnmac2 parse_dhcp, from: 0e:a2:00:04:00:03, to: ff:ff:ff:ff:ff:ff parse_dhcp: 202.63.66.1:67 -> 255.255.255.255:68 dhcp_hdr op: Boot Reply (2) dhcp_hdr htype: Ethernet (1) dhcp_hdr hlen: 6 dhcp_hdr hops: 0 dhcp_hdr xid: 0x74253f08 dhcp_hdr secs: 0 dhcp_hdr flags: 0x8000 dhcp_hdr ciaddr: 0.0.0.0 dhcp_hdr yiaddr: 202.63.67.36 dhcp_hdr siaddr: 172.21.116.42 dhcp_hdr giaddr: 0.0.0.0 dhcp_hdr chaddr: dc:9f:db:28:14:bf () DHO_DHCP_MESSAGE_TYPE: DHCPACK DHO_SUBNET_MASK: 255.255.254.0 DHO_ROUTER: 202.63.66.1 DHO_DOMAIN_NAME_SERVERS: 119.40.106.35 (1/2) DHO_DOMAIN_NAME_SERVERS: 119.40.106.36 (2/2) DHO_42, len: 4 DHO_DHCP_LEASE_TIME 600s DHO_DHCP_SERVER_IDENTIFIER: 202.63.66.1 DHO_END DHCPACK on cnmac2 from 0e:a2:00:04:00:03/202.63.66.1 to ff:ff:ff:ff:ff:ff/255.255.255.255 adding 202.63.67.36 to cnmac2 (lease from 202.63.66.1) adding nameservers 119.40.106.35 119.40.106.36 (lease from 202.63.66.1 on cnmac2) state_transition[cnmac2] Rebooting -> Bound, timo: 300 configure_interface cnmac2 iface_timeout[3]: Bound state_transition[cnmac2] Bound -> Renewing, timo: 112 DHCPREQUEST on cnmac2 parse_dhcp, from: 0e:a2:00:04:00:03, to: dc:9f:db:28:14:bf parse_dhcp: 202.63.66.1:67 -> 202.63.67.36:68 dhcp_hdr op: Boot Reply (2)
Re: dhcpleased losing route
On Wed, May 10, 2023 at 05:55:28AM -, Stuart Henderson wrote:
> On 2023-05-10, David Diggles wrote:
> > My ISP provides connection via DHCP.
> >
> > Every 5 minutes or so when dhcpleased is renewing the lease,
> > my default route disappears for a few seconds.
>
> That isn't supposed to happen. I just checked on a machine which has
> 10 minute leases and I don't see that problem or those log messages.
>
> I'd run dhcpleased in the foreground with debug logging and collect a
> couple of cycle's worth to see if that gives any clues. Saving a
> packet capture might be useful too ("tcpdump -i cnmac2 -s1500 -w
> /tmp/dhcp.pcap port 67 or 68").
>
> > Definitely I'll be looking at requesting a longer lease by
> > putting a setting in /etc/dhclient.conf but is there any way
> > I can stop the default route disappearing with each renew event?
>
> dhcpleased doesn't support this yet though it would certainly be a
> feature that's useful to have.
Ok Stuart, here's a couple of rounds of dhcpleased -vvv with the tcpdump.
root@sarah log:130# rcctl stop dhcpleased
dhcpleased(ok)
root@sarah log:0# which dhcpleased
/sbin/dhcpleased
root@sarah log:0# /sbin/dhcpleased -d -vvv
state_transition[cnmac2] Down -> Rebooting, timo: 1
DHCPREQUEST on cnmac2
parse_dhcp, from: 0e:a2:00:04:00:03, to: ff:ff:ff:ff:ff:ff
parse_dhcp: 202.63.66.1:67 -> 255.255.255.255:68
dhcp_hdr op: Boot Reply (2)
dhcp_hdr htype: Ethernet (1)
dhcp_hdr hlen: 6
dhcp_hdr hops: 0
dhcp_hdr xid: 0x74253f08
dhcp_hdr secs: 0
dhcp_hdr flags: 0x8000
dhcp_hdr ciaddr: 0.0.0.0
dhcp_hdr yiaddr: 202.63.67.36
dhcp_hdr siaddr: 172.21.116.42
dhcp_hdr giaddr: 0.0.0.0
dhcp_hdr chaddr: dc:9f:db:28:14:bf ()
DHO_DHCP_MESSAGE_TYPE: DHCPACK
DHO_SUBNET_MASK: 255.255.254.0
DHO_ROUTER: 202.63.66.1
DHO_DOMAIN_NAME_SERVERS: 119.40.106.35 (1/2)
DHO_DOMAIN_NAME_SERVERS: 119.40.106.36 (2/2)
DHO_42, len: 4
DHO_DHCP_LEASE_TIME 600s
DHO_DHCP_SERVER_IDENTIFIER: 202.63.66.1
DHO_END
DHCPACK on cnmac2 from 0e:a2:00:04:00:03/202.63.66.1 to
ff:ff:ff:ff:ff:ff/255.255.255.255
adding 202.63.67.36 to cnmac2 (lease from 202.63.66.1)
adding nameservers 119.40.106.35 119.40.106.36 (lease from 202.63.66.1 on
cnmac2)
state_transition[cnmac2] Rebooting -> Bound, timo: 300
configure_interface cnmac2
iface_timeout[3]: Bound
state_transition[cnmac2] Bound -> Renewing, timo: 112
DHCPREQUEST on cnmac2
parse_dhcp, from: 0e:a2:00:04:00:03, to: dc:9f:db:28:14:bf
parse_dhcp: 202.63.66.1:67 -> 202.63.67.36:68
dhcp_hdr op: Boot Reply (2)
dhcp_hdr htype: Ethernet (1)
dhcp_hdr hlen: 6
dhcp_hdr hops: 0
dhcp_hdr xid: 0xa180ce6b
dhcp_hdr secs: 0
dhcp_hdr flags: 0x0
dhcp_hdr ciaddr: 202.63.67.36
dhcp_hdr yiaddr: 0.0.0.0
dhcp_hdr siaddr: 172.21.116.42
dhcp_hdr giaddr: 0.0.0.0
dhcp_hdr chaddr: dc:9f:db:28:14:bf ()
DHO_DHCP_MESSAGE_TYPE: DHCPNAK
DHO_DHCP_SERVER_IDENTIFIER: 202.63.66.1
DHO_END
DHCPNAK on cnmac2 from 0e:a2:00:04:00:03/202.63.66.1 to
dc:9f:db:28:14:bf/202.63.67.36
deleting nameservers 119.40.106.35 119.40.106.36 (lease from 202.63.66.1 on
cnmac2)
deleting 202.63.67.36 from cnmac2 (lease from 202.63.66.1)
state_transition[cnmac2] Renewing -> Init, timo: 1
DHCPDISCOVER on cnmac2
deconfigure_interface cnmac2
iface_timeout[3]: Init
state_transition[cnmac2] Init -> Init, timo: 2
DHCPDISCOVER on cnmac2
parse_dhcp, from: 0e:a2:00:04:00:03, to: ff:ff:ff:ff:ff:ff
parse_dhcp: 202.63.66.1:67 -> 255.255.255.255:68
dhcp_hdr op: Boot Reply (2)
dhcp_hdr htype: Ethernet (1)
dhcp_hdr hlen: 6
dhcp_hdr hops: 0
dhcp_hdr xid: 0x6a13ec33
dhcp_hdr secs: 0
dhcp_hdr flags: 0x8000
dhcp_hdr ciaddr: 0.0.0.0
dhcp_hdr yiaddr: 202.63.67.36
dhcp_hdr siaddr: 172.21.116.42
dhcp_hdr giaddr: 0.0.0.0
dhcp_hdr chaddr: dc:9f:db:28:14:bf ()
DHO_DHCP_MESSAGE_TYPE: DHCPOFFER
DHO_SUBNET_MASK: 255.255.254.0
DHO_ROUTER: 202.63.66.1
DHO_DOMAIN_NAME_SERVERS: 119.40.106.35 (1/2)
DHO_DOMAIN_NAME_SERVERS: 119.40.106.36 (2/2)
DHO_42, len: 4
DHO_DHCP_LEASE_TIME 600s
DHO_DHCP_SERVER_IDENTIFIER: 202.63.66.1
DHO_END
DHCPOFFER on cnmac2 from 0e:a2:00:04:00:03/202.63.66.1 to
ff:ff:ff:ff:ff:ff/255.255.255.255
state_transition[cnmac2] Init -> Requesting, timo: 1
DHCPREQUEST on cnmac2
parse_dhcp, from: 0e:a2:00:04:00:03, to: ff:ff:ff:ff:ff:ff
parse_dhcp: 202.63.66.1:67 -> 255.255.255.255:68
dhcp_hdr op: Boot Reply (2)
dhcp_hdr htype: Ethernet (1)
dhcp_hdr hlen: 6
dhcp_hdr hops: 0
dhcp_hdr xid: 0xdafa3da4
dhcp_hdr secs: 0
dhcp_hdr flags: 0x8000
dhcp_hdr ciaddr: 0.0.0.0
dhcp_hdr yiaddr: 202.63.67.36
dhcp_hdr siaddr: 172.21.116.42
dhcp_hdr giaddr: 0.0.0.0
dhcp_hdr chaddr: dc:9f:db:28:14:bf ()
DHO_DHCP_MESSAGE_TYPE: DHCPACK
DHO_SUBNET_MASK: 255.255.254.0
DHO_ROUTER: 202.63.66.1
DHO_DOMAIN_NAME_SERVERS: 119.40.106.35 (1/2)
DHO_DOMAIN_NAME_SERVERS: 119.40.106.36 (2/2)
DHO_42, len: 4
DHO_DHCP_LEASE_TIME 600s
DHO_DHCP_SERVER_IDENTIFIER: 202.63.66.1
DHO_END
DHCPACK on cnmac2 from 0e:a2:00:04:00:03/202.63.66.1 to
ff:ff:ff:ff:ff:ff/255.255.255.255
adding 202.63.67.36 to cnmac2 (lease from
Re: dhcpleased losing route
On Wed, May 10, 2023 at 08:56:10PM +1000, David Diggles wrote: > dhcpleasectl -l cnmac2 > > cnmac2 [Bound] > inet x.x.x.x netmask x.x.x.x > default gateway x.x.x.1 > nameservers x.x.x.x x.x.x.x > lease 6 minutes > dhcp server x.x.x.1 > > I've gone on to try isc-dhcp-client from ports and it gets exactly the same > problem. > > It's almost as though I have an arch issue - I've tried on another identical > device > with identical install - same problem. > > I've tried plugging in with Apple Airport Extreme (NetBSD 4.0 ARM) does not > have the problem. > I've tried plugging in with Linux/NetworkManger - does not have the problem. > > I might try swapping the egress interface from cnmac2 to cnmac1,cnmac0 and > try my luck there. You might find better luck by following Stuart's directions: collect logging information and packet dumps. That will allow developers to see what is going on, very likely. -Otto > > [ using 762392 bytes of bsd ELF symbol table ] > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 7.3 (GENERIC.MP) #1242: Sat Mar 25 18:04:31 MDT 2023 > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > real mem = 536870912 (512MB) > avail mem = 521093120 (496MB) > random: good seed from bootblocks > mainbus0 at root: board 20002 rev 2.12, model CN3xxx/CN5xxx > cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation > cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way > clock0 at mainbus0: int 5 > octcrypto0 at mainbus0 > iobus0 at mainbus0 > simplebus0 at iobus0: "soc" > octciu0 at simplebus0 > octsmi0 at simplebus0 > octpip0 at simplebus0 > octgmx0 at octpip0 interface 0 > cnmac0 at octgmx0: port 0 RGMII, address dc:9f:db:28:14:bd > atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 > cnmac1 at octgmx0: port 1 RGMII, address dc:9f:db:28:14:be > atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 > cnmac2 at octgmx0: port 2 RGMII, address dc:9f:db:28:14:bf > atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 > com0 at simplebus0: ns16550a, 64 byte fifo > com0: console > dwctwo0 at iobus0 base 0x118006800 irq 56 > usb0 at dwctwo0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev > 2.00/1.00 addr 1 > octrng0 at iobus0 base 0x14000 irq 0 > umass0 at uhub0 port 1 configuration 1 interface 0 "Imation Atom USB Device" > rev 2.00/1.00 addr 2 > umass0: using SCSI over Bulk-Only > scsibus0 at umass0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: removable > serial.071805340503380BB56D > sd0: 7644MB, 512 bytes/sector, 15654912 sectors > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > root on sd0a (1e748e9c1a25cfa3.a) swap on sd0b dump on sd0b > > On Wed, May 10, 2023 at 08:09:17AM +0200, Mike Fischer wrote: > > What does `# dhcpleasectl -l cnmac2` output on the machine you are using? > > > > Mine (OpenBSD 7.3 amd64 vm on the LAN) looks like this (anonymised): > > root@vm2:~# dhcpleasectl -l vio0 > > vio0 [Bound] > > inet 192.168.x.220 netmask 255.255.255.0 > > default gateway 192.168.x.1 > > nameservers 192.168.x.1 > > lease 24 hours < what is your lease time? > > dhcp server 192.168.x.1 > > root@vm2:~# > > > > I suspect your lease time is much higher than 5 min. An ISP issuing leases > > as short as 5 min. would be highly unusual. > > > > You could try running dhcpleased manually like this to see details about > > what is going on: > > # dhcpleased -vv -d > > > > (But you???d need to stop the processes started by rc(8) first. E.g.: `# > > rcctl stop dhcpleased`. Don???t forget to `# rcctl start dhcpleased` when > > you are done with the testing.) > > > > > > Does the interface go down and up for some reason every 5 minutes? That > > might cause dhcpleased(8) to renew the lease. > > > > > > HTH > > Mike > > > > > Am 10.05.2023 um 07:28 schrieb Otto Moerbeek : > > > > > > On Wed, May 10, 2023 at 01:17:05PM +1000, David Diggles wrote: > > > > > >> > > >> Just to update, I've added the following to dhclient.conf but > > >> it's still renewing every 5 minutes (approximately) and the > > >> default route is disappearing for a couple of seconds. :( > > >> > > >> send dhcp-lease-time 86400; > > > > > > dhcpleased does not use dhclient.conf, it used dhcpleased.conf, which > > > does not have a way to influence the lease time requested (if that is a > > > thing). > > > > > > -Otto > > >> > > >> On Wed, May 10, 2023 at 01:00:00PM +1000, David Diggles wrote: > >
Re: dhcpleased losing route
dhcpleasectl -l cnmac2 cnmac2 [Bound] inet x.x.x.x netmask x.x.x.x default gateway x.x.x.1 nameservers x.x.x.x x.x.x.x lease 6 minutes dhcp server x.x.x.1 I've gone on to try isc-dhcp-client from ports and it gets exactly the same problem. It's almost as though I have an arch issue - I've tried on another identical device with identical install - same problem. I've tried plugging in with Apple Airport Extreme (NetBSD 4.0 ARM) does not have the problem. I've tried plugging in with Linux/NetworkManger - does not have the problem. I might try swapping the egress interface from cnmac2 to cnmac1,cnmac0 and try my luck there. [ using 762392 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3 (GENERIC.MP) #1242: Sat Mar 25 18:04:31 MDT 2023 dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP real mem = 536870912 (512MB) avail mem = 521093120 (496MB) random: good seed from bootblocks mainbus0 at root: board 20002 rev 2.12, model CN3xxx/CN5xxx cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way clock0 at mainbus0: int 5 octcrypto0 at mainbus0 iobus0 at mainbus0 simplebus0 at iobus0: "soc" octciu0 at simplebus0 octsmi0 at simplebus0 octpip0 at simplebus0 octgmx0 at octpip0 interface 0 cnmac0 at octgmx0: port 0 RGMII, address dc:9f:db:28:14:bd atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2 cnmac1 at octgmx0: port 1 RGMII, address dc:9f:db:28:14:be atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2 cnmac2 at octgmx0: port 2 RGMII, address dc:9f:db:28:14:bf atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2 com0 at simplebus0: ns16550a, 64 byte fifo com0: console dwctwo0 at iobus0 base 0x118006800 irq 56 usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1 octrng0 at iobus0 base 0x14000 irq 0 umass0 at uhub0 port 1 configuration 1 interface 0 "Imation Atom USB Device" rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable serial.071805340503380BB56D sd0: 7644MB, 512 bytes/sector, 15654912 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (1e748e9c1a25cfa3.a) swap on sd0b dump on sd0b On Wed, May 10, 2023 at 08:09:17AM +0200, Mike Fischer wrote: > What does `# dhcpleasectl -l cnmac2` output on the machine you are using? > > Mine (OpenBSD 7.3 amd64 vm on the LAN) looks like this (anonymised): > root@vm2:~# dhcpleasectl -l vio0 > vio0 [Bound] > inet 192.168.x.220 netmask 255.255.255.0 > default gateway 192.168.x.1 > nameservers 192.168.x.1 > lease 24 hours < what is your lease time? > dhcp server 192.168.x.1 > root@vm2:~# > > I suspect your lease time is much higher than 5 min. An ISP issuing leases as > short as 5 min. would be highly unusual. > > You could try running dhcpleased manually like this to see details about what > is going on: > # dhcpleased -vv -d > > (But you???d need to stop the processes started by rc(8) first. E.g.: `# > rcctl stop dhcpleased`. Don???t forget to `# rcctl start dhcpleased` when you > are done with the testing.) > > > Does the interface go down and up for some reason every 5 minutes? That might > cause dhcpleased(8) to renew the lease. > > > HTH > Mike > > > Am 10.05.2023 um 07:28 schrieb Otto Moerbeek : > > > > On Wed, May 10, 2023 at 01:17:05PM +1000, David Diggles wrote: > > > >> > >> Just to update, I've added the following to dhclient.conf but > >> it's still renewing every 5 minutes (approximately) and the > >> default route is disappearing for a couple of seconds. :( > >> > >> send dhcp-lease-time 86400; > > > > dhcpleased does not use dhclient.conf, it used dhcpleased.conf, which > > does not have a way to influence the lease time requested (if that is a > > thing). > > > > -Otto > >> > >> On Wed, May 10, 2023 at 01:00:00PM +1000, David Diggles wrote: > >>> My ISP provides connection via DHCP. > >>> > >>> Every 5 minutes or so when dhcpleased is renewing the lease, > >>> my default route disappears for a few seconds. > >>> > >>> Definitely I'll be looking at requesting a longer lease by > >>> putting a setting in /etc/dhclient.conf but is there any way > >>> I can stop the default route disappearing with each renew event? > >>> > >>> The route didn't disappear when I tested with NetBSD and Linux. > >>> > >>> This seems like I'm
Re: dhcpleased losing route
What does `# dhcpleasectl -l cnmac2` output on the machine you are using? Mine (OpenBSD 7.3 amd64 vm on the LAN) looks like this (anonymised): root@vm2:~# dhcpleasectl -l vio0 vio0 [Bound] inet 192.168.x.220 netmask 255.255.255.0 default gateway 192.168.x.1 nameservers 192.168.x.1 lease 24 hours < what is your lease time? dhcp server 192.168.x.1 root@vm2:~# I suspect your lease time is much higher than 5 min. An ISP issuing leases as short as 5 min. would be highly unusual. You could try running dhcpleased manually like this to see details about what is going on: # dhcpleased -vv -d (But you’d need to stop the processes started by rc(8) first. E.g.: `# rcctl stop dhcpleased`. Don’t forget to `# rcctl start dhcpleased` when you are done with the testing.) Does the interface go down and up for some reason every 5 minutes? That might cause dhcpleased(8) to renew the lease. HTH Mike > Am 10.05.2023 um 07:28 schrieb Otto Moerbeek : > > On Wed, May 10, 2023 at 01:17:05PM +1000, David Diggles wrote: > >> >> Just to update, I've added the following to dhclient.conf but >> it's still renewing every 5 minutes (approximately) and the >> default route is disappearing for a couple of seconds. :( >> >> send dhcp-lease-time 86400; > > dhcpleased does not use dhclient.conf, it used dhcpleased.conf, which > does not have a way to influence the lease time requested (if that is a > thing). > > -Otto >> >> On Wed, May 10, 2023 at 01:00:00PM +1000, David Diggles wrote: >>> My ISP provides connection via DHCP. >>> >>> Every 5 minutes or so when dhcpleased is renewing the lease, >>> my default route disappears for a few seconds. >>> >>> Definitely I'll be looking at requesting a longer lease by >>> putting a setting in /etc/dhclient.conf but is there any way >>> I can stop the default route disappearing with each renew event? >>> >>> The route didn't disappear when I tested with NetBSD and Linux. >>> >>> This seems like I'm missing a setting in dhclient.conf to make >>> the default route sticky? I can't see any obvious answers in >>> the man page for dhclient.conf unfortunately. >>> >>> (IP fudged log snippet below) >>> >>> May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to >>> cnmac2 (lease from x.x.x.1) >>> May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding nameservers >>> x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) >>> >> -- Mike Fischer fisc...@lavielle.com
Re: dhcpleased losing route
On 2023-05-10, David Diggles wrote:
> My ISP provides connection via DHCP.
>
> Every 5 minutes or so when dhcpleased is renewing the lease,
> my default route disappears for a few seconds.
That isn't supposed to happen. I just checked on a machine which has
10 minute leases and I don't see that problem or those log messages.
I'd run dhcpleased in the foreground with debug logging and collect a
couple of cycle's worth to see if that gives any clues. Saving a
packet capture might be useful too ("tcpdump -i cnmac2 -s1500 -w
/tmp/dhcp.pcap port 67 or 68").
> Definitely I'll be looking at requesting a longer lease by
> putting a setting in /etc/dhclient.conf but is there any way
> I can stop the default route disappearing with each renew event?
dhcpleased doesn't support this yet though it would certainly be a
feature that's useful to have.
Re: dhcpleased losing route
On Wed, May 10, 2023 at 01:17:05PM +1000, David Diggles wrote: > > Just to update, I've added the following to dhclient.conf but > it's still renewing every 5 minutes (approximately) and the > default route is disappearing for a couple of seconds. :( > > send dhcp-lease-time 86400; dhcpleased does not use dhclient.conf, it used dhcpleased.conf, which does not have a way to influence the lease time requested (if that is a thing). -Otto > > On Wed, May 10, 2023 at 01:00:00PM +1000, David Diggles wrote: > > My ISP provides connection via DHCP. > > > > Every 5 minutes or so when dhcpleased is renewing the lease, > > my default route disappears for a few seconds. > > > > Definitely I'll be looking at requesting a longer lease by > > putting a setting in /etc/dhclient.conf but is there any way > > I can stop the default route disappearing with each renew event? > > > > The route didn't disappear when I tested with NetBSD and Linux. > > > > This seems like I'm missing a setting in dhclient.conf to make > > the default route sticky? I can't see any obvious answers in > > the man page for dhclient.conf unfortunately. > > > > (IP fudged log snippet below) > > > > May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > > cnmac2 (lease from x.x.x.1) > > May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to > > cnmac2 (lease from x.x.x.1) > > May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > > cnmac2 (lease from x.x.x.1) > > May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to > > cnmac2 (lease from x.x.x.1) > > May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > > cnmac2 (lease from x.x.x.1) > > May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to > > cnmac2 (lease from x.x.x.1) > > May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > > cnmac2 (lease from x.x.x.1) > > May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to > > cnmac2 (lease from x.x.x.1) > > May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding nameservers > > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > > >
Re: dhcpleased losing route
Just to update, I've added the following to dhclient.conf but it's still renewing every 5 minutes (approximately) and the default route is disappearing for a couple of seconds. :( send dhcp-lease-time 86400; On Wed, May 10, 2023 at 01:00:00PM +1000, David Diggles wrote: > My ISP provides connection via DHCP. > > Every 5 minutes or so when dhcpleased is renewing the lease, > my default route disappears for a few seconds. > > Definitely I'll be looking at requesting a longer lease by > putting a setting in /etc/dhclient.conf but is there any way > I can stop the default route disappearing with each renew event? > > The route didn't disappear when I tested with NetBSD and Linux. > > This seems like I'm missing a setting in dhclient.conf to make > the default route sticky? I can't see any obvious answers in > the man page for dhclient.conf unfortunately. > > (IP fudged log snippet below) > > May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting nameservers > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > cnmac2 (lease from x.x.x.1) > May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 > (lease from x.x.x.1) > May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x > x.x.x.x (lease from x.x.x.1 on cnmac2) > May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting nameservers > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > cnmac2 (lease from x.x.x.1) > May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 > (lease from x.x.x.1) > May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x > x.x.x.x (lease from x.x.x.1 on cnmac2) > May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting nameservers > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > cnmac2 (lease from x.x.x.1) > May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 > (lease from x.x.x.1) > May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x > x.x.x.x (lease from x.x.x.1 on cnmac2) > May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting nameservers > x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) > May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from > cnmac2 (lease from x.x.x.1) > May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 > (lease from x.x.x.1) > May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x > x.x.x.x (lease from x.x.x.1 on cnmac2) >
dhcpleased losing route
My ISP provides connection via DHCP. Every 5 minutes or so when dhcpleased is renewing the lease, my default route disappears for a few seconds. Definitely I'll be looking at requesting a longer lease by putting a setting in /etc/dhclient.conf but is there any way I can stop the default route disappearing with each renew event? The route didn't disappear when I tested with NetBSD and Linux. This seems like I'm missing a setting in dhclient.conf to make the default route sticky? I can't see any obvious answers in the man page for dhclient.conf unfortunately. (IP fudged log snippet below) May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) May 10 12:23:21 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from cnmac2 (lease from x.x.x.1) May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 (lease from x.x.x.1) May 10 12:23:23 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) May 10 12:28:23 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from cnmac2 (lease from x.x.x.1) May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 (lease from x.x.x.1) May 10 12:28:25 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) May 10 12:33:26 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from cnmac2 (lease from x.x.x.1) May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 (lease from x.x.x.1) May 10 12:33:28 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2) May 10 12:38:28 openbsd-gateway dhcpleased[77979]: deleting x.x.x.30 from cnmac2 (lease from x.x.x.1) May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding x.x.x.30 to cnmac2 (lease from x.x.x.1) May 10 12:38:30 openbsd-gateway dhcpleased[77979]: adding nameservers x.x.x.x x.x.x.x (lease from x.x.x.1 on cnmac2)
