Public bug reported:
Linux systems (Ubuntu 16.04) fail to connect to various hotels with wifi
as a result of the DHCPDiscover message being sent by dhclient. The
same laptop using MSWindows connects with the hotels without a problem.
This has been observed at multiple locations.
The problem was isolated by making the DHCPDiscover packet sent by
dhclient match the DHCPDiscover packet sent by MSWindows. It was found
that affecting difference was that dhclient generated a non-zero value
for the TOS UDP field. Commenting out the setting of ip.ip_tos in
packet.c so that the field remained zero fixed the problem:
dhcp-4.4.1/common:
$ diff packet.c packet.c.orig
150c150
< // ip.ip_tos = IPTOS_LOWDELAY;
---
> ip.ip_tos = IPTOS_LOWDELAY;
The hotel's router may have been misconfigured to interpret the TOS
field. However, the hotel connects to MSWindows/Apple devices. As a
result, open source systems such as Ubuntu (Linux) gain a reputation of
being unreliable. (My wife wants/needs to use MS/Apple systems as
result)
I would like to suggest that if the default DHCP message content
generated by MSWindows/Apple adheres to standards, then the default DHCP
message content from open source systems (linux) match bit for bit.
Sniff packets and compare to verify. Such practice would assure that
open source connectivity (linux) is no less reliable than commercial
device connectivity.
** Affects: isc-dhcp (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1825649
Title:
ISC DHCP client/Ubuntu fails to connect to commercial routers and code
fix suggestion
Status in isc-dhcp package in Ubuntu:
New
Bug description:
Linux systems (Ubuntu 16.04) fail to connect to various hotels with
wifi as a result of the DHCPDiscover message being sent by dhclient.
The same laptop using MSWindows connects with the hotels without a
problem. This has been observed at multiple locations.
The problem was isolated by making the DHCPDiscover packet sent by
dhclient match the DHCPDiscover packet sent by MSWindows. It was found
that affecting difference was that dhclient generated a non-zero value
for the TOS UDP field. Commenting out the setting of ip.ip_tos in
packet.c so that the field remained zero fixed the problem:
dhcp-4.4.1/common:
$ diff packet.c packet.c.orig
150c150
< // ip.ip_tos = IPTOS_LOWDELAY;
---
> ip.ip_tos = IPTOS_LOWDELAY;
The hotel's router may have been misconfigured to interpret the TOS
field. However, the hotel connects to MSWindows/Apple devices. As a
result, open source systems such as Ubuntu (Linux) gain a reputation
of being unreliable. (My wife wants/needs to use MS/Apple systems as
result)
I would like to suggest that if the default DHCP message content
generated by MSWindows/Apple adheres to standards, then the default
DHCP message content from open source systems (linux) match bit for
bit. Sniff packets and compare to verify. Such practice would assure
that open source connectivity (linux) is no less reliable than
commercial device connectivity.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1825649/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
