| View previous topic :: View next topic |
| Author |
Message |
bookwood
Tux's lil' helper
Joined: 06 Oct 2005
Posts: 128
Location: Dortmund
|
 Posted: Mon Jan 19, 2009 3:03 pm Post subject: Strange dhcpcd behavior and it overlooks ntp server setting |
 |
|
Since 3 month (timestamp of my /etc/ntpd.conf is 2007-11-15) dhcpd is ignoring "option ntp-servers " and my ntpd server isn't set. I use an dhcpd server on my Gentoo router with the entry "option ntp-servers 10.x.x.x" since three years without any problems, since last november.
The second problem is with the dhcp server of Micro$oft 2003 server at the office. Micro$oft ignores very often standards and implements them with a hot glowing nail on there own. An example is rfc1497, this rfc describe the DHCP Options. The "domain name" option has token 15 followed by the lenght of the domainname and then by the domain name. The lenght is defined as the number of letters of the domain name. Micro$oft sends number of letters + 1 followed by the domainname and a 0x00, thats there own interpretation of the rfc 1497.
A quote of RFC 1497:
| Quote: | Domain Name (Tag: 15, Data: N bytes of domain name)
Specifies the domain name of the client for Domain Name
Server (DNS) resolution [RFC-1034].
|
The linux dhcpd sends the number of letters followed by the domain name without a tailing garbage 0x00.
Now the problem, here is the generated resolv.conf by the Micro$oft bullshit:
| Code: | # Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
search ads.xxxxxxx.deÿ
nameserver 192.168.xx.103 |
The problem is the "ÿ" char ending domainname. A Hexdump of my /var/lib/dhcpcd/dhcpcd-eth0.lease
| Code: | hexdump -C /var/lib/dhcpcd/dhcpcd-eth0.lease
00000000 02 01 06 00 a6 bd a9 2a 00 00 00 00 00 00 00 00 |.......*........|
00000010 xx xx xx 8e 00 00 00 00 00 00 00 00 00 0d 60 af |..............`.|
00000020 27 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |'...............|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 |............c.Sc|
000000f0 35 01 05 3a 04 00 04 9d 40 3b 04 00 08 13 30 33 |5..:....@;....03|
00000100 04 00 09 3a 80 36 04 c0 a8 2f 67 01 04 ff ff fe |...:.6.../g.....|
00000110 00 03 04 xx xx xx fe 06 08 xx xx xx 67 xx xx xx |...../...../g../|
00000120 6b 0f 0f 61 64 73 2e xx xx xx xx xx xx xx 2e 64 |k..ads.xxxxxxx.d|
00000130 65 ff 05 dc 3c 0c 64 68 63 70 63 64 20 34 2e 30 |e...<.dhcpcd 4.0|
00000140 2e 37 0c 09 73 6b 79 77 61 6c 6b 65 72 37 0f 01 |.7..skywalker7..|
00000150 79 21 03 06 0c 0f 1c 28 29 2a 33 3a 3b 77 ff 00 |y!.....()*3:;w..|
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000005b0 |
shows a 0xff at position 131. My packetdump of the dhcp offer packet from the micro$oft 2003 server shows a 0x00 after the domain name.
My Hotfix in the /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf is a simple sed line:
| Code: | | new_domain_name="`echo ${new_domain_name} | sed 's/\\\\[0-9]\+$//g'`" |
where the new domain name is setted. I just replace the contence of the ${new_domain_name} variable "ads.xxxxxxx.de\377" to "ads.xxxxxxx.de".
I hope that help others, but the best solution is to find the bug that put the 0xff into the /var/lib/dhcpcd/dhcpcd-eth0.lease file. |
|
| Back to top |
|
 |
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
|
Networking & Security
