Re: dhcpcd failure
On Feb 21, 4:30pm, Roy Marples wrote: } On 21/02/2019 16:18, triaxx wrote: } > } > 3   2019/01/16 5:55:46 PM   info   udhcpd[1154]: sending OFFER to } > 255.255.255.255 with 192.168.0.11 } > } > } > 16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto } > UDP (17), length 576) } >    192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok] BOOTP/DHCP, } > Reply, length 548, xid 0x66ec8de4, Flags [none] (0x) } >      Your-IP 192.168.0.11 } >      Server-IP 192.168.0.1 } >      Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) } >      Vendor-rfc1048 Extensions } >        Magic Cookie 0x63825363 } >        DHCP-Message Option 53, length 1: Offer } >        Server-ID Option 54, length 4: 192.168.0.1 } >        Lease-Time Option 51, length 4: 86400 } >        Subnet-Mask Option 1, length 4: 255.255.255.0 } >        Default-Gateway Option 3, length 4: 192.168.0.1 } >        Domain-Name-Server Option 6, length 4: 192.168.0.1 } >        Domain-Name Option 15, length 11: "atlas.local" Can you do the tcpdump with "-e" to show the ethernet header. I'm wondering if it's sending to the layer 2 broadcast address of ff:ff:ff:ff:ff:ff? } What cisco says it's doing and what it's actually doing are different. } It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which is } correct) but in reality it's unicasting to 192.168.0.11. } } I don't see how any DHCP client can work with that. Yet, clearly it does, so there must be something else going on that we haven't figured out yet. } You might try getting dhcpcd to send the broadcast option using the -J } flag. That's non standard though and I doubt it will fix the issue. } }-- End of excerpt from Roy Marples
Re: dhcpcd failure
Le 2019-02-21 17:52, Roy Marples a écrit : On 21/02/2019 16:45, triaxx wrote: As least cisco respects -J but it doesn't fix the problem. 16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] (0x8000) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" END Option 255, length 0 PAD Option 0, length 0, occurs 261 So it's now broadcast which is good. Does dhcpcd not see that? Roy No, it does not.
Re: dhcpcd failure
On 21/02/2019 17:02, triaxx wrote: Le 2019-02-21 17:52, Roy Marples a écrit : On 21/02/2019 16:45, triaxx wrote: As least cisco respects -J but it doesn't fix the problem. 16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] (0x8000) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" END Option 255, length 0 PAD Option 0, length 0, occurs 261 So it's now broadcast which is good. Does dhcpcd not see that? Roy > No, it does not. Does it log anything about a reply with the debug flag set? -d
Re: dhcpcd failure
On 21/02/2019 16:45, triaxx wrote: As least cisco respects -J but it doesn't fix the problem. 16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] (0x8000) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" END Option 255, length 0 PAD Option 0, length 0, occurs 261 So it's now broadcast which is good. Does dhcpcd not see that? Roy
Re: dhcpcd failure
Le 2019-02-21 17:30, Roy Marples a écrit : On 21/02/2019 16:18, triaxx wrote: 3 2019/01/16 5:55:46 PM info udhcpd[1154]: sending OFFER to 255.255.255.255 with 192.168.0.11 16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0x66ec8de4, Flags [none] (0x) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" What cisco says it's doing and what it's actually doing are different. It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which is correct) but in reality it's unicasting to 192.168.0.11. I don't see how any DHCP client can work with that. You might try getting dhcpcd to send the broadcast option using the -J flag. That's non standard though and I doubt it will fix the issue. Roy As least cisco respects -J but it doesn't fix the problem. 16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] (0x8000) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" END Option 255, length 0 PAD Option 0, length 0, occurs 261
Re: dhcpcd failure
Le 2019-02-21 17:07, Roy Marples a écrit : On 21/02/2019 14:58, triaxx wrote: Le 2019-01-18 17:54, Andy Ruhl a écrit : On Fri, Jan 18, 2019 at 2:09 AM Roy Marples wrote: Hi Fred On 18/01/2019 06:05, triaxx wrote: > I experienced a dhcpcd that cannot connect to a Cisco gateway through a > fresh NetBSD 8.0. I tried dhclient which succeed. > > I didn't see relevant diff between MAIN and netbsd-8. > > I would like to send a PR but I'm interesting to know what informations > could be relevant/helping. You could try editing /etc/dhcpcd.conf and commenting out duid and using clientid. If that still fails, try commenting out both. If either work, complain to Cisco about their lack of RFC compliance. Regardless, let me know the outcome please. If it really is a Cisco compliance issue, I'd like to see a wireshark of the failing request and the successful one for my own amusement. This command seems to work on my mac, I'm guessing it will be similar on NetBSD except the interface name: tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap Andy tcpdump is like the observer of the Schrödinger's cat, it interfere in measurement. If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running service -v dhcpcd restart, it works fine... Then, I can just provide the packet trace when the request succeed: 14:56:43.981194 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 318 14:56:44.019208 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:44.019338 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 325 14:56:44.079055 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:53.955162 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 319 14:56:53.988890 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 Looks to me like the DHCP client is broadcasting for a lease (ie it doesn't have an IP address) but the DHCP server thinks it has an IP address and is unicasting to something that doesn't exist? Can you add more - to see if the client is giving any hints if it has an ip address? Roy I hope -vv is sufficient... When it failed (with tcpdump in non promiscuous mode): 1 2019/01/16 5:48:05 PM info udhcpd[1154]: sending OFFER to 255.255.255.255 with 192.168.0.11 2 2019/01/16 5:48:05 PM info udhcpd[1154]: received DISCOVER from 80:EE:73:C1:CD:36 3 2019/01/16 5:47:57 PM info udhcpd[1154]: sending OFFER to 255.255.255.255 with 192.168.0.11 4 2019/01/16 5:47:57 PM info udhcpd[1154]: received DISCOVER from 80:EE:73:C1:CD:36 16:06:03.322149 IP (tos 0x0, ttl 64, id 39057, offset 0, flags [none], proto UDP (17), length 343) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 315, xid 0x7e4dd14c, Flags [none] (0x) Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover NOAUTO Option 116, length 1: Y MSZ Option 57, length 2: 1472 Vendor-Class Option 60, length 36: "dhcpcd-7.0.6:NetBSD-8.0:amd64:x86_64" Hostname Option 12, length 6: "zealot" T145 Option 145, length 1: 1 Parameter-Request Option 55, length 13: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, Lease-Time, RN, RB Option 119 16:06:07.213394 IP (tos 0x0, ttl 64, id 14364, offset 0, flags [none], proto UDP (17), length 343) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 315, xid 0x7e4dd14c, secs 3, Flags [none] (0x) Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover NOAUTO Option 116, length 1: Y MSZ Option 57, length 2: 1472 Vendor-Class Option 60, length 36: "dhcpcd-7.0.6:NetBSD-8.0:amd64:x86_64" Hostname Option 12, length 6: "zealot" T145 Option 145, length 1: 1 Parameter-Request Option 55, length 13: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, Lease-Time, RN, RB Option 119 When it succeed (with tcpdump in promiscuous mode): 1 2019/01/16 5:55:46 PM info udhcpd[1154]: sending ACK to 255.255.255.255 2 2019/01/16 5:55:46 PM info udhcpd[1154]: received REQUEST from 80:EE:73:C1:CD:36 3 2019/01/16 5:55:46 PM info udhcpd[1154]: sending OFFER to 255.255.255.255 with
Re: dhcpcd failure
On 21/02/2019 16:18, triaxx wrote: 3 2019/01/16 5:55:46 PM info udhcpd[1154]: sending OFFER to 255.255.255.255 with 192.168.0.11 16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0x66ec8de4, Flags [none] (0x) Your-IP 192.168.0.11 Server-IP 192.168.0.1 Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.0.1 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.0.1 Domain-Name-Server Option 6, length 4: 192.168.0.1 Domain-Name Option 15, length 11: "atlas.local" What cisco says it's doing and what it's actually doing are different. It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which is correct) but in reality it's unicasting to 192.168.0.11. I don't see how any DHCP client can work with that. You might try getting dhcpcd to send the broadcast option using the -J flag. That's non standard though and I doubt it will fix the issue. Roy
Re: dhcpcd failure
On 21/02/2019 14:58, triaxx wrote: Le 2019-01-18 17:54, Andy Ruhl a écrit : On Fri, Jan 18, 2019 at 2:09 AM Roy Marples wrote: Hi Fred On 18/01/2019 06:05, triaxx wrote: > I experienced a dhcpcd that cannot connect to a Cisco gateway through a > fresh NetBSD 8.0. I tried dhclient which succeed. > > I didn't see relevant diff between MAIN and netbsd-8. > > I would like to send a PR but I'm interesting to know what informations > could be relevant/helping. You could try editing /etc/dhcpcd.conf and commenting out duid and using clientid. If that still fails, try commenting out both. If either work, complain to Cisco about their lack of RFC compliance. Regardless, let me know the outcome please. If it really is a Cisco compliance issue, I'd like to see a wireshark of the failing request and the successful one for my own amusement. This command seems to work on my mac, I'm guessing it will be similar on NetBSD except the interface name: tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap Andy tcpdump is like the observer of the Schrödinger's cat, it interfere in measurement. If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running service -v dhcpcd restart, it works fine... Then, I can just provide the packet trace when the request succeed: 14:56:43.981194 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 318 14:56:44.019208 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:44.019338 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 325 14:56:44.079055 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:53.955162 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 319 14:56:53.988890 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 Looks to me like the DHCP client is broadcasting for a lease (ie it doesn't have an IP address) but the DHCP server thinks it has an IP address and is unicasting to something that doesn't exist? Can you add more - to see if the client is giving any hints if it has an ip address? Roy
Re: dhcpcd failure
Le 2019-02-21 16:11, ignat...@cs.uni-bonn.de a écrit :
On Thu, Feb 21, 2019 at 03:58:33PM +0100, triaxx wrote:
tcpdump is like the observer of the Schrödinger's cat, it interfere in
measurement.
If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when
running
service -v dhcpcd restart, it works fine...
If you don't want it to interfere - there's the option "-p"
("Don't put the interface into promiscuous mode.")
-is
This is what I need even if tcpdump -r is now extremely slow.
Thanks \o/
Re: dhcpcd failure
On Thu, Feb 21, 2019 at 03:58:33PM +0100, triaxx wrote:
> tcpdump is like the observer of the Schrödinger's cat, it interfere in
> measurement.
>
> If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running
> service -v dhcpcd restart, it works fine...
If you don't want it to interfere - there's the option "-p"
("Don't put the interface into promiscuous mode.")
-is
Re: dhcpcd failure
Le 2019-01-18 17:54, Andy Ruhl a écrit : On Fri, Jan 18, 2019 at 2:09 AM Roy Marples wrote: Hi Fred On 18/01/2019 06:05, triaxx wrote: > I experienced a dhcpcd that cannot connect to a Cisco gateway through a > fresh NetBSD 8.0. I tried dhclient which succeed. > > I didn't see relevant diff between MAIN and netbsd-8. > > I would like to send a PR but I'm interesting to know what informations > could be relevant/helping. You could try editing /etc/dhcpcd.conf and commenting out duid and using clientid. If that still fails, try commenting out both. If either work, complain to Cisco about their lack of RFC compliance. Regardless, let me know the outcome please. If it really is a Cisco compliance issue, I'd like to see a wireshark of the failing request and the successful one for my own amusement. This command seems to work on my mac, I'm guessing it will be similar on NetBSD except the interface name: tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap Andy tcpdump is like the observer of the Schrödinger's cat, it interfere in measurement. If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running service -v dhcpcd restart, it works fine... Then, I can just provide the packet trace when the request succeed: 14:56:43.981194 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 318 14:56:44.019208 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:44.019338 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 325 14:56:44.079055 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548 14:56:53.955162 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 319 14:56:53.988890 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, Reply, length 548
Re: dhcpcd failure
On Fri, Jan 18, 2019 at 2:09 AM Roy Marples wrote: > > Hi Fred > > On 18/01/2019 06:05, triaxx wrote: > > I experienced a dhcpcd that cannot connect to a Cisco gateway through a > > fresh NetBSD 8.0. I tried dhclient which succeed. > > > > I didn't see relevant diff between MAIN and netbsd-8. > > > > I would like to send a PR but I'm interesting to know what informations > > could be relevant/helping. > > You could try editing /etc/dhcpcd.conf and commenting out duid and using > clientid. If that still fails, try commenting out both. > > If either work, complain to Cisco about their lack of RFC compliance. > Regardless, let me know the outcome please. If it really is a Cisco compliance issue, I'd like to see a wireshark of the failing request and the successful one for my own amusement. This command seems to work on my mac, I'm guessing it will be similar on NetBSD except the interface name: tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap Andy
Re: dhcpcd failure
Hi Fred On 18/01/2019 06:05, triaxx wrote: I experienced a dhcpcd that cannot connect to a Cisco gateway through a fresh NetBSD 8.0. I tried dhclient which succeed. I didn't see relevant diff between MAIN and netbsd-8. I would like to send a PR but I'm interesting to know what informations could be relevant/helping. You could try editing /etc/dhcpcd.conf and commenting out duid and using clientid. If that still fails, try commenting out both. If either work, complain to Cisco about their lack of RFC compliance. Regardless, let me know the outcome please. Roy
dhcpcd failure
Hi Roy, I experienced a dhcpcd that cannot connect to a Cisco gateway through a fresh NetBSD 8.0. I tried dhclient which succeed. I didn't see relevant diff between MAIN and netbsd-8. I would like to send a PR but I'm interesting to know what informations could be relevant/helping. Fred
