|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Among many other bugs, Android 5.x seems to have a DHCPv4 bug that prevents it from getting addresses from some embedded systems. For me, this includes the Wi-Fi functions on the GoPro HERO3 and Canon EOS 70D.
We all remember DORA from our networking 101 classes, right?
Unfortunately, with Android 5.x this turns into DORN when talking to some DHCP servers.
That's right, the server sends a NAK for the DHCP request, which usually indicates the requested address is invalid or in use.
I realized this while on my honeymoon earlier this year and was not pleased at all. I routinely use the Wi-Fi capabilities of my GoPro HERO3 camera with a "selfie stick" to shoot accurate photos. The HERO3 turns itself into a Wi-Fi access point and allows a single client to connect in order to use the GoPro application, which is used to control & view live video on camera. Usually this works without a hitch, but not this time. When connecting to the camera the Wi-Fi status hung in the "Obtaining IP address..." phase. After debugging a bit I realized that the server was sending NAKs for the DHCP request from my phone and I had upgraded my OnePlus One to CyanogenMod 12.0 (Android 5.0) a few weeks earlier. Here's what logcat says:
I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9 I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9 I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9 I/dhcpcd (25750): wlan0: broadcasting for a lease I/dhcpcd (25750): wlan0: offered 10.5.5.109 from 10.5.5.9 W/dhcpcd (25750): wlan0: NAK: via 10.5.5.9
(the HERO3 uses 10.5.5/24 with the camera 10.5.5.9 and the clients starting around 10.5.5.109 or so)
The entry that's missing is the DHCP request debug entry, where Android should be sending a message to the DHCP server asking for 10.5.5.109. This is actually happening and can be seen via a packet capture:
20:48:52.890280 IP (tos 0x0, ttl 64, id 21568, offset 0, flags [none], proto UDP (17), length 330)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c0:ee:fb:24:8c:59 (oui Unknown), length 302, xid 0x1d11a2f4, Flags [none]
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255, fb:24:8c:59:00:01:00:01:1c:c4:48:b1:c0:ee:fb:24:8c:59
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 12: "dhcpcd-5.5.6"
Hostname Option 12, length 5: "omega"
Parameter-Request Option 55, length 10:
Subnet-Mask, Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, MTU, BR, Lease-Time
RN, RB
20:48:52.896211 IP (tos 0x0, ttl 64, id 81, offset 0, flags [none], proto UDP (17), length 326)
10.5.5.9.bootps > 10.5.5.109.bootpc: BOOTP/DHCP, Reply, length 298, xid 0x1d11a2f4, Flags [none]
Your-IP 10.5.5.109
Server-IP 10.5.5.9
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.5.5.9
Subnet-Mask Option 1, length 4: 255.255.255.0
Lease-Time Option 51, length 4: 10368000
TTL Option 23, length 1: 64
MTU Option 26, length 2: 1500
RN Option 58, length 4: 10368000
RB Option 59, length 4: 10371600
Domain-Name Option 15, length 3: "lan"
BR Option 28, length 4: 10.5.5.255
Default-Gateway Option 3, length 4: 10.5.5.9
20:48:52.897006 IP (tos 0x0, ttl 64, id 41212, offset 0, flags [none], proto UDP (17), length 342)
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c0:ee:fb:24:8c:59 (oui Unknown), length 314, xid 0x1d11a2f4, Flags [none]
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 19: hardware-type 255, fb:24:8c:59:00:01:00:01:1c:c4:48:b1:c0:ee:fb:24:8c:59
Requested-IP Option 50, length 4: 10.5.5.109
Server-ID Option 54, length 4: 10.5.5.9
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 12: "dhcpcd-5.5.6"
Hostname Option 12, length 5: "omega"
Parameter-Request Option 55, length 10:
Subnet-Mask, Static-Route, Default-Gateway, Domain-Name-Server
Domain-Name, MTU, BR, Lease-Time
RN, RB
20:48:52.902836 IP (tos 0x0, ttl 64, id 82, offset 0, flags [none], proto UDP (17), length 272)
10.5.5.9.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 244, xid 0x1d11a2f4, Flags [none]
Client-Ethernet-Address c0:ee:fb:24:8c:59 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Except for some absurdly high lease times, there's nothing invalid I see in the DHCP request above. So, why is the HERO3 sending a NAK? Here's what I know:
Since the 70D and HERO3's DHCP servers are closed, I can't look at their debug log to see what's happening. The only workaround I have so far is to assign a static IPv4 address to my OPO when connecting to the HERO3, which is 10.5.5.109/24 with a default gateway of 10.5.5.9. I don't believe the default gateway is used for the application functionality, but provides some fake HTTP responses that cause Android and iOS' Internet connection quality tests to succeed.
I'd submit a bug for this but I'm worried it'll go nowhere or be tagged WONTFIX like this request for DHCPv6 support.
New comments are currently disabled for this entry.
     |
This HTML for this page was generated in 0.002 seconds. |