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 <da...@elven.com.au>:
> 
> 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

Reply via email to