-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I don't have time to do something about this at the moment, so I'll
just inform everyone here about this problem and add the debian
maintainers to the CC of this mail, so whomever has time or needs to
know about this at least knows about this issue.
In devuan/debian jessie, wicd does send the hostname and requests the
search domains in the DHCP reply, but in ascii/stretch, it no longer
does so. I believe it uses dhclient with a different dhclient.conf
than before, but I don't know what exactly changed. There is an option
to set the hostname in wicd, but using it doesn't have any effect and
it's off by default.
The hostname option is often used by dhcp servers to notify the local
dns resolver about new clients, which makes it possible to use their
hostname instead of their IP to access them. I think the default
should be for the hostname to be sent, because it used to be that way,
it may break existing setups and cause a lot of troubleshooting
otherwise, and I don't think not having it helps with anything.
The domain search option is important to get all search domains. A lot
of networks, mine too, are split into different parts. One for lan and
one for dmz for example. In that case, it's quiet common to have both
in the search domain list. My search domains are "dmz.abrecht.li
lan.abrecht.li". This way, I can access both, local clients and my
servers using just the hostname and don't have to write out the whole
domain. There are some other use cases too. I've only ever seen
Windows machines not requesting search domains before, but I alway
took for granted that they work everywhere else. They work by default
on iOS, Android, Mac, and usually Linux, except if using wicd+dhclient
in ascii/stretch. Not requesting the option also won't add any
security benefits, because in that case the domain name is used as
search domain. But that's insufficient for multiple domains.
I'm still on wicd version 1.7.4+tb2-4, which is the same in debian and
devuan, and not on the devuan version from backports, but that
shouldn't make a difference since these versions only differ in some
dependencies and nothing else.
I've used "tcpdump -vvv port 68 or port 67" on my dhcp server to
capture the DHCP requests. Here is one when using wicd:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
262144 bytes
18:46:58.202250 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none],
proto UDP (17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP,
Request from 60:36:dd:26:4a:bc (oui Unknown), length 300, xid
0x9160d35, Flags [none] (0x0000)
Client-Ethernet-Address 60:36:dd:26:4a:bc (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Requested-IP Option 50, length 4: 10.60.10.188
Hostname Option 12, length 10: "$_HOSTNAME"
Parameter-Request Option 55, length 7:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Hostname
END Option 255, length 0
PAD Option 0, length 0, occurs 29
18:46:58.202649 IP (tos 0xc0, ttl 64, id 8355, offset 0, flags [none],
proto UDP (17), length 336)
dog.bootps > 10.60.10.188.bootpc: [udp sum ok] BOOTP/DHCP, Reply,
length 308, xid 0x9160d35, Flags [none] (0x0000)
Your-IP 10.60.10.188
Server-IP dog
Client-Ethernet-Address 60:36:dd:26:4a:bc (oui Unknown)
file "legacy/pxeboot.0"[|bootp]
18:46:58.206962 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none],
proto UDP (17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP,
Request from 60:36:dd:26:4a:bc (oui Unknown), length 300, xid
0x9160d35, Flags [none] (0x0000)
Client-Ethernet-Address 60:36:dd:26:4a:bc (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Server-ID Option 54, length 4: dog
Requested-IP Option 50, length 4: 10.60.10.188
Hostname Option 12, length 10: "$_HOSTNAME"
Parameter-Request Option 55, length 7:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Hostname
END Option 255, length 0
PAD Option 0, length 0, occurs 23
18:46:58.269305 IP (tos 0xc0, ttl 64, id 8357, offset 0, flags [none],
proto UDP (17), length 336)
dog.bootps > 10.60.10.188.bootpc: [udp sum ok] BOOTP/DHCP, Reply,
length 308, xid 0x9160d35, Flags [none] (0x0000)
Your-IP 10.60.10.188
Server-IP dog
Client-Ethernet-Address 60:36:dd:26:4a:bc (oui Unknown)
file "legacy/pxeboot.0"[|bootp]
Here we see that "$_HOSTNAME" was sent as hostname, instead of the
real hostname. I think this is clearly a bug. Also Option 119 wasn't
requested, which is the option for search domain names.
And here is one using dhclient directly:
18:48:01.963362 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none],
proto UDP (17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP,
Request from 60:36:dd:26:4a:bc (oui Unknown), length 300, xid
0x357e021d, Flags [none] (0x0000)
Client-Ethernet-Address 60:36:dd:26:4a:bc (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Requested-IP Option 50, length 4: 10.60.10.188
Hostname Option 12, length 5: "mamut"
Parameter-Request Option 55, length 13:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP
END Option 255, length 0
PAD Option 0, length 0, occurs 28
18:48:02.032485 IP (tos 0xc0, ttl 64, id 8865, offset 0, flags [none],
proto UDP (17), length 373)
dog.bootps > 10.60.10.188.bootpc: [udp sum ok] BOOTP/DHCP, Reply,
length 345, xid 0x357e021d, Flags [none] (0x0000)
Your-IP 10.60.10.188
Server-IP dog
Client-Ethernet-Address 60:36:dd:26:4a:bc (oui Unknown)
file "legacy/pxeboot.0"[|bootp]
Here, the correct hostname has been sent, and Option 119 was requested.
-----BEGIN PGP SIGNATURE-----
iQFIBAEBCAAyFiEEZT8xKpcJ1eXNKSM1cASjafdLVoEFAlqlkdcUHG1lQGRhbmll
bGFicmVjaHQuY2gACgkQcASjafdLVoET4AgAq1EcX9QjA9cdtYVKpytwnAoQiHSq
RcrFuDNclAQrKDT5Prq3lC1Nf6p0/glOfiwStoLrLCUHh/SKxBWRmSCtiWdDat9m
mMMPXzt8u+XcNov/+uXiKnWnghFaN4/HILR6VWvBH2MwEYouz4E9i4eVm0S+3MIs
0Dpq8eTA1c4iAIl1bzzPoi040PNnfYYfvgW0naJgzJrytMHp9n2tsrkDx5nkV5mI
a6PJmitprh9sfGe+AyPgxWwE/fCsy0TdfCfi2KXeZJ0Z4erd5qEpMs0hgj/PVTfi
vhndtepPNOhOd8lyd8xl9iTRd9bB+mXcDSnoNCU0GDKD0UgtHQre6TGfmg==
=YF5w
-----END PGP SIGNATURE-----
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
