grouch53 commented 1 year ago

I am trying to connect uplink to an Android based hotspot using dhcpcd.

My testbed consists of

Alix board with 256MB memory and 2 radio cards.
An off the shelf access point which serves as the uplink network node.
An android phone with Wifi Hotspot enabled.
An android tablet to log into webconf to be able to choose the uplink SSID easily and to test internet connectivity.

The dhcp client is based on LEAF http://leaf.sourceforge.net and is running dhcpcd 8.1.5

Dec 15 10:53:36 SALT syslog[7160]: wlan0: carrier lost Dec 15 10:54:04 SALT kernel: [ 2062.390076] wlan0: authenticate with f8:1a:67:56:42:96 Dec 15 10:54:04 SALT kernel: [ 2062.390076] wlan0: authenticate with f8:1a:67:56:42:96 Dec 15 10:54:04 SALT kernel: [ 2062.400051] wlan0: send auth to f8:1a:67:56:42:96 (try 1/3) Dec 15 10:54:04 SALT kernel: [ 2062.403615] wlan0: authenticated Dec 15 10:54:04 SALT kernel: [ 2062.400051] wlan0: send auth to f8:1a:67:56:42:96 (try 1/3) Dec 15 10:54:04 SALT kernel: [ 2062.403615] wlan0: authenticated Dec 15 10:54:04 SALT kernel: [ 2062.414075] wlan0: associate with f8:1a:67:56:42:96 (try 1/3) Dec 15 10:54:04 SALT kernel: [ 2062.416690] wlan0: RX AssocResp from f8:1a:67:56:42:96 (capab=0x431 status=0 aid=1) Dec 15 10:54:04 SALT kernel: [ 2062.416900] wlan0: associated Dec 15 10:54:04 SALT kernel: [ 2062.414075] wlan0: associate with f8:1a:67:56:42:96 (try 1/3) Dec 15 10:54:04 SALT kernel: [ 2062.416690] wlan0: RX AssocResp from f8:1a:67:56:42:96 (capab=0x431 status=0 aid=1) Dec 15 10:54:04 SALT kernel: [ 2062.416900] wlan0: associated Dec 15 10:54:04 SALT syslog[7160]: wlan0: carrier acquired Dec 15 10:54:04 SALT syslog[7160]: wlan0: connected to Access Point `scoobly' Dec 15 10:54:05 SALT syslog[7160]: wlan0: rebinding lease of 194.124.158.82 Dec 15 10:54:05 SALT syslog[7160]: wlan0: probing address 194.124.158.82/24 Dec 15 10:54:09 SALT syslog[7160]: wlan0: leased 194.124.158.82 for 216000 seconds Dec 15 10:54:09 SALT syslog[7160]: wlan0: adding route to 194.124.158.0/24 Dec 15 10:54:09 SALT syslog[7160]: wlan0: adding default route via 194.124.158.1 Dec 15 10:55:14 SALT kernel: [ 2132.235721] wlan0: deauthenticating from f8:1a:67:56:42:96 by local choice (Reason: 3=DEAUTH_LEAVING) Dec 15 10:55:14 SALT kernel: [ 2132.235721] wlan0: deauthenticating from f8:1a:67:56:42:96 by local choice (Reason: 3=DEAUTH_LEAVING) Dec 15 10:55:14 SALT syslog[7160]: wlan0: carrier lost Dec 15 10:55:14 SALT syslog[7160]: wlan0: deleting route to 194.124.158.0/24 Dec 15 10:55:14 SALT syslog[7160]: wlan0: deleting default route via 194.124.158.1

Here everything looks fine (and is)

However, trying to connect to the WiFi Hotspot on the Android phone results in the following

Dec 15 10:56:00 SALT kernel: [ 2178.125545] wlan0: authenticate with 5a:e9:b2:a6:20:7b Dec 15 10:56:00 SALT kernel: [ 2178.125545] wlan0: authenticate with 5a:e9:b2:a6:20:7b Dec 15 10:56:00 SALT kernel: [ 2178.135677] wlan0: send auth to 5a:e9:b2:a6:20:7b (try 1/3) Dec 15 10:56:00 SALT kernel: [ 2178.135677] wlan0: send auth to 5a:e9:b2:a6:20:7b (try 1/3) Dec 15 10:56:00 SALT kernel: [ 2178.216124] wlan0: authenticated Dec 15 10:56:00 SALT kernel: [ 2178.216124] wlan0: authenticated Dec 15 10:56:00 SALT kernel: [ 2178.220230] wlan0: associate with 5a:e9:b2:a6:20:7b (try 1/3) Dec 15 10:56:00 SALT kernel: [ 2178.220230] wlan0: associate with 5a:e9:b2:a6:20:7b (try 1/3) Dec 15 10:56:00 SALT kernel: [ 2178.237796] wlan0: RX AssocResp from 5a:e9:b2:a6:20:7b (capab=0x431 status=0 aid=3) Dec 15 10:56:00 SALT kernel: [ 2178.238017] wlan0: associated Dec 15 10:56:00 SALT kernel: [ 2178.237796] wlan0: RX AssocResp from 5a:e9:b2:a6:20:7b (capab=0x431 status=0 aid=3) Dec 15 10:56:00 SALT kernel: [ 2178.238017] wlan0: associated Dec 15 10:56:00 SALT syslog[7160]: wlan0: carrier acquired Dec 15 10:56:00 SALT syslog[7160]: wlan0: connected to Access Point `Mega' Dec 15 10:56:01 SALT syslog[7160]: wlan0: soliciting a DHCP lease

So wpa_supplicant connects to the access point but dhcpcd fails to get an address as can be seen here

SALT# tcpdump -i wlan0 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 11:03:33.616568 EAPOL key (3) v2, len 95 11:03:33.617874 EAPOL key (3) v1, len 117 11:03:33.624471 EAPOL key (3) v2, len 151 11:03:33.625364 EAPOL key (3) v1, len 95 11:03:34.027803 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:b1:b1:4d:25 (oui Unknown), length 326 11:03:39.021148 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:b1:b1:4d:25 (oui Unknown), length 326 11:03:46.888539 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:b1:b1:4d:25 (oui Unknown), length 326 11:04:03.848012 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:b1:b1:4d:25 (oui Unknown), length 326 11:04:35.084820 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:b1:b1:4d:25 (oui Unknown), length 326 11:05:39.156389 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:b1:b1:4d:25 (oui Unknown), length 326 11:06:42.718712 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:b1:b1:4d:25 (oui Unknown), length 326 ^C 11 packets captured 11 packets received by filter 0 packets dropped by kernel

However, connecting to the Android based hotspot works fine using the Android tablet or a Winblows laptop.

Ideas anyone?

Thanks

ET

rsmarples commented 1 year ago

Does any other DHCP client connect? If you have an IPv6 link local address, can you ping another IPv6 link local address on the other side?

Chances are this isn't a dhcpcd problem as according to your tcpdump a dhcp client is sending requests but no reply is coming.

grouch53 commented 1 year ago

Hello

Am 23.12.2022 um 14:39 schrieb Roy Marples:

Does any other DHCP client connect? If you have an IPv6 link local address, can you ping another IPv6 link

It is IPv4 only and yes other dhcp clients e.g. Winblows and Adroid connect seamlessly.

local address on the other side?

Chances are this isn't a dhcpcd problem as according to your tcpdump a dhcp client is sending requests but no reply is coming.

Indeed that is what happens. It appears that the dhcp server on the Andriod phone chokes on our discover packet. Now the question is the famous 'why'.

Also the dhcpcd daemon connects seamlessly to another dhcp server running on a NAS. So I guess you are right the problem is the behaviour of the dhcp server on the Android Phone. I tried to understand the internals of the discover message by comparing a successful connection and the dump of the unsuccessful one. Not having access to the dchp server code makes this of course pure guessing.

Is there a way to strip down dhcpcd to the pure minimal functionality to see if then the server at least tries to reply?

Thanks

Erich Titl

rsmarples commented 1 year ago

Hello Am 23.12.2022 um 14:39 schrieb Roy Marples: Does any other DHCP client connect? If you have an IPv6 link local address, can you ping another IPv6 link It is IPv4 only and yes other dhcp clients e.g. Winblows and Adroid connect seamlessly.

No, I mean another DHCP client on the same host running dhcpcd? Like say ISC dhclient

Is there a way to strip down dhcpcd to the pure minimal functionality to see if then the server at least tries to reply?

Yes. You can remove clientid, duid, option rapid_commit, require dhcp_server_identifier and slaac private from the default /etc/dhcpcd.conf. If you've customised it, you should still get the idea - dhcpcd works fine without dhcpcd.conf as well. You can verify what dhcpcd sends using tcpdump -vvvvv.

grouch53 commented 1 year ago

Am 23.12.2022 um 19:51 schrieb Roy Marples:

Hello Am 23.12.2022 um 14:39 schrieb Roy Marples:
Does any other DHCP client connect? If you have an IPv6 link local
address, can you ping another IPv6 link
It is IPv4 only and yes other dhcp clients e.g. Winblows and Adroid
connect seamlessly.

No, I mean another DHCP client on the same host running dhcpcd? Like say ISC dhclient

I tried pump, a very old dhcp client, it just resulted in a 169.x.x.x address and no routing, so it was probably just discarded and configured itself.

I have wireshark dumps from the windows client and tcpdumps from various attempts from the small embeded linux box. Those are the two attempts I was able to record. Unfortunately there appears to be no tool to record traffic on the Android phone without rooting the device.

Is there a way to strip down dhcpcd to the pure minimal
functionality to see if then the server at least tries to reply?
Yes. You can remove |clientid|, |duid|, |option rapid_commit|, |require dhcp_server_identifier| and |slaac private| from the default |/etc/dhcpcd.conf|. If you've customised it, you should still get the idea - dhcpcd works fine without dhcpcd.conf as well.

I did of course customize it. The thing that hit my eyes as the biggest difference in the dhcpdiscover message was option 145 which (among others) was not used on the Winblows packet.

I can trey with an empty dhcpcd.conf and see what is happening.

here is my current dhcpcd.conf

A sample configuration for dhcpcd.

See dhcpcd.conf(5) for details.

Allow users of this group to interact with dhcpcd via the control socket.

controlgroup wheel

Inform the DHCP server of our hostname for DDNS.

hostname SALT

Use the hardware address of the interface for the Client ID.

clientid

or

Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per

RFC4361.

Some non-RFC compliant DHCP servers do not reply with this set.

In this case, comment out duid and enable clientid above.

duid

Persist interface configuration when dhcpcd exits.

persistent

vendorclassid is set to blank to avoid sending the default of

dhcpcd-:::

vendorclassid

A list of options to request from the DHCP server.

option domain_name_servers, domain_name, domain_search option classless_static_routes

Respect the network MTU. This is applied to DHCP routes.

option interface_mtu

Request a hostname from the network

option host_name

Most distributions have NTP support.

option ntp_servers

Rapid commit support.

Safe to enable by default because it requires the equivalent option set

on the server to actually work.

option rapid_commit

A ServerID is required by RFC2131.

require dhcp_server_identifier

Generate SLAAC address using the Hardware Address of the interface

slaac hwaddr

OR generate Stable Private IPv6 Addresses based from the DUID

slaac private

background

noipv4ll

broadcast

end of dhcpcd.conf

Thanks

ET

grouch53 commented 1 year ago

Hello

Am 23.12.2022 um 19:51 schrieb Roy Marples:

Hello Am 23.12.2022 um 14:39 schrieb Roy Marples:
Does any other DHCP client connect? If you have an IPv6 link local
address, can you ping another IPv6 link
It is IPv4 only and yes other dhcp clients e.g. Winblows and Adroid
connect seamlessly.
No, I mean another DHCP client on the same host running dhcpcd? Like say ISC dhclient
Is there a way to strip down dhcpcd to the pure minimal
functionality to see if then the server at least tries to reply?
Yes. You can remove |clientid|, |duid|, |option rapid_commit|, |require dhcp_server_identifier| and |slaac private| from the default |/etc/dhcpcd.conf|. If you've customised it, you should still get the idea - dhcpcd works fine without dhcpcd.conf as well.

I did as you suggested, stripped down dhcpcd.conf unfortunately without success.

Using an empty dhcpcd.conf resulted in registering an IPv4LL address which is not of much use in this environment.

Using a completely stripped down dhcpcd.conf did not get me nowhere neither. Still a valid WiFi connection but no IP address.

SALT# wpa_cli status Selected interface 'wlan0' bssid=90:ee:c7:a7:02:9d freq=2412 ssid=Mega id=1 mode=station pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=WPA2-PSK wpa_state=COMPLETED address=00:1b:b1:b1:4d:1b

SALT# cat /etc/dhcpcd.conf background

noipv4ll

broadcast

cheers

ET

grouch53 commented 1 year ago

Hello

here the wpa_cli status of two different stations, one successful one failed

SALT# wpa_cli status Selected interface 'wlan0' bssid=f8:1a:67:56:42:96 freq=2422 ssid=scoobly id=0 mode=station pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=WPA2-PSK wpa_state=COMPLETED address=00:1b:b1:b1:4d:1b

and here without an IP address

SALT# wpa_cli status Selected interface 'wlan0' bssid=90:ee:c7:a7:02:9d freq=2412 ssid=Mega id=1 mode=station pairwise_cipher=CCMP group_cipher=CCMP key_mgmt=WPA2-PSK wpa_state=COMPLETED address=00:1b:b1:b1:4d:1b

cheers

ET

NetworkConfiguration / dhcpcd

dhcp request from dhcpd is not handled by Android based hotspot #158

A sample configuration for dhcpcd.

See dhcpcd.conf(5) for details.

Allow users of this group to interact with dhcpcd via the control socket.

controlgroup wheel

Inform the DHCP server of our hostname for DDNS.

Use the hardware address of the interface for the Client ID.

or

Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per

Some non-RFC compliant DHCP servers do not reply with this set.

In this case, comment out duid and enable clientid above.

duid

Persist interface configuration when dhcpcd exits.

vendorclassid is set to blank to avoid sending the default of

dhcpcd-:::

A list of options to request from the DHCP server.

Respect the network MTU. This is applied to DHCP routes.

Request a hostname from the network

Most distributions have NTP support.

option ntp_servers

Rapid commit support.

Safe to enable by default because it requires the equivalent option set

on the server to actually work.

A ServerID is required by RFC2131.

Generate SLAAC address using the Hardware Address of the interface

slaac hwaddr

OR generate Stable Private IPv6 Addresses based from the DUID

end of dhcpcd.conf