I run Ubuntu 20.04.2 LTS and have both TekSavvy 50/10 DSL Internet
and Distributel 300/20 Cable Internet here in Ottawa's Little Italy.
(TekSavvy uses Bell for the last mile; Distributel uses Rogers.)
I have a SmartRG 516 modem/router that handles the DHCP for TekSavvy
DSL, so I don't see the DHCP traffic when the modem tries to get an
address from TekSavvy, but for Distributel Cable I only have a modem
(technicolor TC4350) so my Linux machine has to run dhclient to get a
DHCP address from Distributel/Rogers. I get to see all the DHCP traffic.
And, as far as I can tell, Distributel/Rogers doesn't do DHCP by the book.
At boot time, when my computer requests a DHCP address from
Distributel/Rogers, this is the correct sequence I see in my log file
(edited for clarity):
dhclient: DHCPDISCOVER on eth2 to 255.255.255.255
dhclient: DHCPREQUEST of 216.48.162.78 on eth2 to 255.255.255.255
dhclient: DHCPOFFER of 216.48.162.78 from 209.148.134.201
dhclient: DHCPACK of 216.48.162.78 from 209.148.134.201
Note that right after a DHCPDISCOVER the DHCPREQUEST goes to the
broadcast address 255.255.255.255, and the DHCPOFFER came from DHCP
server at 209.148.134.201, which happens to be a Rogers IP address.
The actual DHCP address information received from the Distributel/Rogers
209.148.134.201 DHCP server and stored on my computer contains this
information in the lease file /var/lib/dhcp/dhclient.eth2.leases:
lease {
interface "eth2";
fixed-address 216.48.162.78;
option subnet-mask 255.255.255.224;
option routers 216.48.162.65;
option dhcp-lease-time 172706;
option dhcp-message-type 5;
option dhcp-server-identifier 7.127.0.166;
option interface-mtu 576;
option dhcp-renewal-time 86353;
option broadcast-address 255.255.255.255;
renew 4 2020/04/09 03:23:25;
rebind 5 2020/04/10 01:37:18;
expire 5 2020/04/10 07:37:07;
}
Note that the "dhcp-server-identifier" is incorrectly set to 7.127.0.166
when it should be the actual DHCP server at 209.148.134.201. The actual
DHCP server address 209.148.134.201 that gave me my lease is not listed
anywhere in the lease information.
DHCP server address 7.127.0.166 is listed by whois as belonging to the
USA "DoD Network Information Center", but further investigation suggests
that Rogers is using some non-routable addresses inside the 7.0.0.0/8
network for Rogers internal IP addresses, and perhaps that is why that
address is being sent to me:
https://www.dslreports.com/forum/r25679029-Why-is-my-first-hop-to-a-DoD-assigned-IP-address
Note that neither DHCP server IP address 7.127.0.166 nor 209.148.134.201
are in the network address 216.48.162.78/255.255.255.224 given to my
computer eth2 interface, so if eth2 is not my default route I would
have to add explicit routes on my machine for unicast packets sent to
these two DHCP servers addresses to go out eth2. It's a bad move to
assume that I only have one network interface and that of course the
DHCP unicast packets will use it.
Note also that the Interface-MTU is incorrectly set to 576 instead
of 1500. (I've confirmed 1500 using traceroute's "--mtu" option.)
That's all wrong, but that's not what I want to talk about today.
After some time, my computer wants to renew the DHCP lease before it
expires, and things get worse.
This one-paragraph summary explains how a DHCP lease renewal is supposed
to work:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/f946ab4a-e5d5-4044-87a7-e9efb47706a8/whats-happen-if-client-cant-renew-his-ip-from-the-dhcp
The DHCP client first attempts to renew its lease when 50 percent of
the original lease time, known as T1, has passed. At this point the
DHCP client sends a unicast DHCPRequest message to the DHCP server that
originally granted its lease. If the server is available, and the lease
is still available, the server responds with a unicast DHCPAck message
and the lease is renewed. [...]
If there is no response from the DHCP server, the client waits until
87.5 percent of the lease time has passed (known as T2). At T2, the
client enters the rebinding state, and broadcasts a DHCPRequest message
to attempt to renew the lease from any available DHCP server.
A more detailed summary of the DHCP lease renewal protocol behaviour is here:
http://www.tcpipguide.com/free/t_DHCPLeaseRenewalandRebindingProcesses-2.htm
When my computer needs to renew its DHCP lease at time "T1", it correctly
sends a unicast DHCPREQUEST to the DHCP server at 7.127.0.166 that was
supplied in the DHCP lease file. My log file correctly shows this:
dhclient: DHCPREQUEST of 216.48.162.78 on eth2 to 7.127.0.166
A tcpdump confirms that this is a unicast (not broadcast) packet sent
from my current IP address to the 7.127.0.166 DHCP server, and because
eth2 is my default route the unicast packet correctly goes out eth2.
(If eth2 were not my default route, the packet would go out my default
route, not out eth2, and be ignored. Not good.)
This unicast DHCPREQUEST to the DHCP server at 7.127.0.166 gets no
reply from Distributel/Rogers. Because my dhclient uses the default
"backoff-cutoff" setting of fifteen seconds, my computer repeats the
DHCPREQUEST unicast over and over approximately every 9-23 seconds, and it
never gets a reply. It repeats many thousands of times, until eventually
DHCP protocol time "T2" is reached. At time "T2" my computer abandons
the unicast and does a broadcast DHCPREQUEST. My computer immediately
gets a reply from the "other" DHCP server that gave it the DHCP address
in the first place:
dhclient: DHCPREQUEST of 216.48.162.78 on eth2 to 255.255.255.255
dhclient: DHCPACK of 216.48.162.78 from 209.148.134.201
This reply also contains the wrong DHCP Server Identifier 7.127.0.166,
and wrong MTU, just as it did before. This lease lasts until it is again
time for renewal, at which point thousands of unicast DHCPREQUEST packets
are again generated and ignored until eventually time "T2" arrives and
the broadcast address is used successfully. Repeat, repeat, repeat.
Just as an experiment, I over-rode the incorrectly supplied DHCP
server 7.127.0.166 and made my computer send a unicast DHCPREQUEST
to the DHCP server actually doing the offering at 209.148.134.201.
That had no effect; the unicast DHCPREQUEST of 216.48.162.78 on eth2 to
209.148.134.201 is also ignored and produces no response. After thousands
of failed unicast DHCPREQUESTs, my computer abandons the unicast and
switches to use the broadcast address, which immediately works, with
the DHCPACK coming from 209.148.134.201 but still containing the invalid
server-id 7.127.0.166 and invalid MTU 576. A packet from tcpdump:
08:42:37.499402 00:17:10:93:5d:91 > 70:88:6b:85:ab:81, ethertype IPv4
(0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto
UDP (17), length 328) 209.148.134.201.67 > 216.48.162.85.68: [udp sum ok]
BOOTP/DHCP, Reply, length 300, xid 0x5a87300e, Flags [none] (0x0000)
Your-IP 216.48.162.85
Gateway-IP 7.127.0.166
Client-Ethernet-Address 70:88:6b:85:ab:81
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 7.127.0.166
Lease-Time Option 51, length 4: 150722
Subnet-Mask Option 1, length 4: 255.255.255.224
RN Option 58, length 4: 75361
BR Option 28, length 4: 255.255.255.255
MTU Option 26, length 2: 576
Default-Gateway Option 3, length 4: 216.48.162.65
There are multiple problems here:
1. Do not assume that I have only one network interface. The DHCP
server must have an address on the network assigned to my interface so
that unicast DHCPREQUEST packets are correctly routed out that interface
and not out some other default interface. (Lucky for me, I use eth2 as
my default interface so the unicast packets do go out correctly.)
2. Fix the DHCP server to respond to unicast DHCPREQUEST packets, as
documented in the DHCP protocol. (As a work-around to avoid thousands
of ignored DHCPREQUEST unicast packets being sent between T1 and T2,
I changed the "backoff-cutoff" setting in /etc/dhcp/dhclient.conf to
3600 seconds instead of the default 15. Now only a few dozen unicast
DHCPREQUEST packets are generated and ignored, instead of thousands.)
3. Fix the MTU to be 1500, not 576. (My machine apparently ignores the
MTU supplied by DHCP, so in practice this isn't a problem.)
Is anyone else seeing this behaviour on their ISP?
Rumour has it that Windows machines never send unicast DHCPREQUEST
packets; they only use the broadcast version, so they never see this
"ignore unicast" problem. Can someone with Windows confirm this?
--
| Ian! D. Allen, BA, MMath - idallen [ at ] idallen [ dot ] ca - Ottawa, Ontario, Canada
| Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca
| Former college professor (Free/Libre GNU+Linux) at: teaching.idallen.com
| Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/
To unsubscribe send a blank message to linux+unsubscribe [ at ] linux-ottawa [ dot ] org
To get help send a blank message to linux+help [ at ] linux-ottawa [ dot ] org
To visit the archives: https://lists.linux-ottawa.org