No DHCP in WIFI_AP mode?

[the-maldridge]

I'm trying to work out if the problem is in my code or in the library support. There seems to be no DHCP when running the wifi in access point mode, even when using one of the provided examples such as the captive portal. Have I missed something obvious?

[earlephilhower]

DHCP should definitely be running.

What exactly do you mean by no DCHP? That you never get and IP address when you associate with it, or that you can't look up other connected devices' addresses? Fort that you'd need to use MDNS or something, the AP doesn't have it's own DNS server unless you make it using the DNSServer class.

[the-maldridge]

What I am observing is that after approximately 10 seconds my computer abandons the attempt to get an address via DHCP and self-assigns and address in the 169.254 range. I am not using DNS or other mdns style options, only trying to get connectivity via a computer and the Pico directly via IP.

…

On Tue, Oct 3, 2023, 8:37 AM Earle F. Philhower, III < ***@***.***> wrote: DHCP should definitely be running. What exactly do you mean by no DCHP? That you never get and IP address when you associate with it, or that you can't look up other connected devices' addresses? Fort that you'd need to use MDNS or something, the AP doesn't have it's own DNS server unless you make it using the DNSServer class. — Reply to this email directly, view it on GitHub <#1747 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARW3FR73XM7ODUMJZQWHCDX5QIKTAVCNFSM6AAAAAA5QMPXACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TCNZVHEYTK> . You are receiving this because you authored the thread.Message ID: ***@***.*** .com>

[earlephilhower]

I don't think tcpdump will give much since you don't have a TCP address if there's no DHCP. Wireshark works at the lowest Ethernet packet level so should be able to capture DHCP request and ACK packet request...

[earlephilhower]

Rebooted the Win box into Ubuntu 22.40, no problems getting an IP from the same sketch (note the PicoW gave the same IP as the Windows run since it was the same MAC address, which is expected):

3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 20:1e:88:29:82:18 brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.17/24 brd 192.168.42.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 86396sec preferred_lft 86396sec
    inet6 fe80::a922:bf1d:bc10:1634/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

[the-maldridge]

Not quite correct. tcpdump and Wireshark are both frontends onto libpcap which (at least on linux) is what does the low level interface tap to snoop on the traffic.

Dumping traffic though, this appears to be a clear problem on my end, because here's tcpdump:

maldridge@deepblue:~$ sudo tcpdump -i wlp5s0 port 67 or port 68 -vv 
tcpdump: listening on wlp5s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:28:21.192698 IP (tos 0x0, ttl 64, id 19782, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 10:63:c8:62:63:81 (oui Unknown), length 300, xid 0xb5b6d1f2, Flags [none] (0x0000)
	  Client-Ethernet-Address 10:63:c8:62:63:81 (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Discover
	    Parameter-Request (55), length 14: 
	      Subnet-Mask (1), Classless-Static-Route (121), Default-Gateway (3), Domain-Name-Server (6)
	      Hostname (12), Domain-Name (15), MTU (26), BR (28)
	      Static-Route (33), Lease-Time (51), Server-ID (54), RN (58)
	      RB (59), Unknown (119)
	    MSZ (57), length 2: 1472
	    Client-ID (61), length 19: hardware-type 255, c8:62:63:81:00:01:00:01:2c:59:2a:52:10:63:c8:62:63:81
	    SLP-NA (80), length 0""
	    NOAUTO (116), length 1: Y
	    Unknown (145), length 1: 1
23:28:21.197481 IP (tos 0x0, ttl 255, id 19, offset 0, flags [none], proto UDP (17), length 302)
    192.168.42.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 274, xid 0xb5b6d1f2, Flags [none] (0x0000)
	  Your-IP 192.168.42.16
	  Client-Ethernet-Address 10:63:c8:62:63:81 (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Offer
	    Server-ID (54), length 4: 192.168.42.1
	    Subnet-Mask (1), length 4: 255.255.255.0
	    Default-Gateway (3), length 4: 192.168.42.1
	    Domain-Name-Server (6), length 4: 192.168.42.1
	    Lease-Time (51), length 4: 86400

And the corresponding dhcpcd log shows that it was offered a lease, which is not then being taken up:

wlp5s0: carrier acquired
wlp5s0: config file changed, expiring leases
wlp5s0: IAID c8:62:63:81
wlp5s0: soliciting an IPv6 router
wlp5s0: soliciting a DHCP lease
wlp5s0: offered 192.168.42.16 from 192.168.42.1
wlp5s0: probing for an IPv4LL address
wlp5s0: using IPv4LL address 169.254.64.54
wlp5s0: adding route to 169.254.0.0/16
wlp5s0: no IPv6 Routers available

At this point it looks like I need to dig through the dhcp client and figure out why it doesn't like the lease, as one is clearly being offered.

[the-maldridge]

Yeah this is for sure a problem at my end. Changing the wireless configuration on my laptop from using wpa_supplicant+dhcpcd to just iwd makes everything happy.