DHCP Option 121 Classless Static Route ignored [117544989]

WAI

Bug

[AOSP] assigned

Status Update

No update yet.

Description

ma...@gmail.com

created issue #1

Oct 10, 2018 05:08PM

Android 9 (and possibly some previous versions) do not request the Classless Static Route option when issuing DHCP requests, and ignore the option when forced in the responses.

Some previous bug reports and online articles seem to indicate that Android was previously requesting the option (which caused some issues with some networks where a misconfigured DHCP servers did not including the default route in the static route options).

Here is a capture from and Android device with the dhcp option force sent in the response:
```
2018-10-10 09:51:00.602384 40:4e:36:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 340: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 326)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 40:4e:36:xx:xx:xx, length 298, xid 0x93273b59, Flags [none] (0x0000)
Client-Ethernet-Address 40:4e:36:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 40:4e:36:xx:xx:xx
Requested-IP Option 50, length 4: 172.28.164.108
Server-ID Option 54, length 4: 172.28.160.1
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 14: "android-dhcp-9"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
PAD Option 0, length 0
2018-10-10 09:51:00.611611 f0:9f:c2:xx:xx:xx > 40:4e:36:xx:xx:xx, ethertype IPv4 (0x0800), length 366: (tos 0xc0, ttl 64, id 6644, offset 0, flags [none], proto UDP (17), length 352)
172.28.160.1.67 > 172.28.164.108.68: [bad udp cksum 0x9e04 -> 0x6f59!] BOOTP/DHCP, Reply, length 324, xid 0x93273b59, Flags [none] (0x0000)
Your-IP 172.28.164.108
Server-IP 172.28.160.1
Client-Ethernet-Address 40:4e:36:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.28.160.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.240.0
BR Option 28, length 4: 172.28.175.255
Default-Gateway Option 3, length 4: 172.28.160.1
Domain-Name-Server Option 6, length 4: 172.28.160.1
Domain-Name Option 15, length 15: "home.local"
Classless-Static-Route Option 121, length 13: (default:172.28.160.1),(

172.28.176.0/20:172.28.164.66)
END Option 255, length 0
```

Compared to a Chromebook:
```
2018-10-10 09:38:32.607370 9c:2a:70:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 372: (tos 0x0, ttl 64, id 58254, offset 0, flags [none], proto UDP (17), length 358)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 9c:2a:70:xx:xx:xx, length 330, xid 0x3631de6a, Flags [none] (0x0000)
Client-Ethernet-Address 9c:2a:70:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 9c:2a:70:xx:xx:xx
Requested-IP Option 50, length 4: 172.28.164.100
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 45: "dhcpcd-6.8.2:Linux-3.8.11:x86_64:GenuineIntel"
T145 Option 145, length 1: 1
Parameter-Request Option 55, length 15:
Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway
Domain-Name-Server, Hostname, Domain-Name, MTU
BR, Lease-Time, Server-ID, RN
RB, Option 119, Option 252
END Option 255, length 0
2018-10-10 09:38:32.618504 f0:9f:c2:xx:xx:xx > 9c:2a:70:xx:xx:xx, ethertype IPv4 (0x0800), length 385: (tos 0xc0, ttl 64, id 48271, offset 0, flags [none], proto UDP (17), length 371)
172.28.160.1.67 > 172.28.164.100.68: [bad udp cksum 0x9e0f -> 0xf671!] BOOTP/DHCP, Reply, length 343, xid 0x3631de6a, Flags [none] (0x0000)
Your-IP 172.28.164.100
Server-IP 172.28.160.1
Client-Ethernet-Address 9c:2a:70:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.28.160.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.240.0
BR Option 28, length 4: 172.28.175.255
Default-Gateway Option 3, length 4: 172.28.160.1
Domain-Name-Server Option 6, length 4: 172.28.160.1
Domain-Name Option 15, length 15: "home.local"
Hostname Option 12, length 17: "XXXXXXXChromebook"
Classless-Static-Route Option 121, length 13: (default:172.28.160.1),(

172.28.176.0/20:172.28.164.66)
END Option 255, length 0
```

Comments

ma...@google.com <ma...@google.com> #2Oct 11, 2018 07:27AM

Assigned to ma...@google.com.

Hi Josh, friendly ping for an update on progress

ma...@google.com <ma...@google.com> #3Oct 18, 2018 04:40AM

i think the TL;DR is that this is stuck behind investigating the current lab outages, which are more urgent.

pending CL is https://android-review.googlesource.com/c/platform/system/core/+/1250677.

ma...@google.com <ma...@google.com> #4Oct 25, 2018 06:48AM

Status: Won't Fix (Infeasible)

Have you consider snappy or zstd? From my experience snappy compresses at around 200~300MB/s with reasonable compression rate ~30%.

ma...@gmail.com <ma...@gmail.com> #5Oct 25, 2018 06:55AM

For brotli, try quality level 1, this can give around 150-200MB/s with a much better compression ration than snappy of over 60%. Brotli quality 0 is even faster for still over 50% compression.

ma...@google.com <ma...@google.com> #6Oct 25, 2018 09:14AM

Status: Assigned (reopened)

Hmm, gerrit-watcher didn't post the CLs on this bug, so I guess I'll do so manually:

https://android.googlesource.com/platform/system/core/+/939fc19aee7f6a19ce0f4fa91557bbbe9cd974f5 added brotli support (with quality level 1)

https://android.googlesource.com/platform/system/core/+/ec44d35fde60d20d9ab1c6fb9ac7ee844335f1eb added LZ4

Throughput numbers from a device:

           none    brotli    lz4
USB 3.0     120       110    190
USB 2.0      38        75     63

I'm seeing identical throughput with brotli quality 0 and 1 (110MB/s end to end), although there's some giant low hanging fruit to compress multiple files at once.

zstd isn't in the tree yet (I started the ball rolling on that, but no idea when it'll end up getting merged), but I'll take a look at it eventually, probably when I get around to implementing compression for generic streams in adb (b/153901735).

This is probably good enough to call this fixed for now.

ma...@google.com <ma...@google.com> #7Nov 1, 2018 06:36AM

Please share the above requested details, in

comment #6

ma...@gmail.com <ma...@gmail.com> #8Nov 1, 2018 06:41AM

How exactly do you want me to create that bug report?
I mean the only reproducible step is to connect to a WiFi network that offers the option, and observe at the network level that the option is not requested. Since Android doesn't request the option, there is literally nothing special that will show up in logs/report compared to a WiFi network that doesn't offer the option.

ma...@gmail.com <ma...@gmail.com> #9Jan 14, 2019 11:00PM

Any update here? My router keeps complaining that my Pixel2 device doesn't listen to redirect messages, which is expected when the device doesn't listen to pushed routes.
My Chromebook behaves perfectly fine.

is...@google.com <is...@google.com> May 9, 2019 07:08AM

Status: New

vi...@google.com <vi...@google.com> #10May 10, 2019 10:34AM

Assigned to vi...@google.com.

For capturing bugreport you may refer to

https://developer.android.com/studio/debug/bug-report.

ma...@gmail.com <ma...@gmail.com> #11May 15, 2019 04:15AM

As I mentioned before, there is nothing to capture in a bug report because android simply doesn't request the dhcp option.

vi...@google.com <vi...@google.com> #12Jan 13, 2020 11:15AM

Status: Won't Fix (Obsolete)

Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here

https://goo.gl/TbMiIO.

ma...@gmail.com <ma...@gmail.com> #13Jan 14, 2020 05:21AM

Can you explain how the issue is being addressed? The problem is still present in the latest public Android version (QQ1A.200105.002) so this issue is not obsolete.

bl...@gmail.com <bl...@gmail.com> #14Jun 17, 2020 05:38PM

I can't believe this issue still hasn't been resolved, AND has been closed as "won't fix/obsolete".
Classless routes are an RFC standard. Why would we just ignore the problem?
Also, why does the problem even exist? Linux's network stack has always properly supported classless routes.

The issue exists on any network where you need to set a static route that is anywhere other than the default route. Windows does not support any other method of routing (from DHCP options) other than DHCP option 121, and consequently, many routers don't either. 121 is the standard method.

What does Google recommend Android users (or network administrators) do to resolve this?

ni...@gmail.com <ni...@gmail.com> #15Dec 27, 2022 04:36AM

Resubmitted as

https://issuetracker.google.com/issues/263721377

This issue is a real pain on some small business and corporate networks.

vi...@google.com <vi...@google.com> Oct 14, 2024 05:37PM

Status: Won't Fix (Intended Behavior)