Значит дело в чём-то другом. DN тут никаким боком.
Значит дело в чём-то другом. DN тут никаким боком.
Да, маршруты.
Только в ответах я их не вижу. В запросе вижу.
Ответ полностью:
PHP Code:
09:28:13.414577 IP (tos 0x0, ttl 63, id 106, offset 0, flags [DF], length: 578) 10.6.1.1.67 > 10.6.4.106.68: [udp sum ok] BOOTP/DHCP, Reply, length: 550, hops:2, xid:0x6d2cd001, secs:3, flags: [none] (0x0000)
Your IP: 10.6.4.106
Gateway IP: 10.6.1.1
Client Ethernet Address: 00:0c:6e:38:42:81
Vendor-rfc1048:
DHCP:OFFER
SID:10.100.0.11
LT:54000
SM:255.255.240.0
DG:10.6.1.1
NS:10.100.0.11
DN:"psk-net.ru"
T249:6336,43208,2566,257,6154,25600,2566,257,5130,256,2566,257,5130,512,2566,257,5130,768,2566,257,5130,1280,2566,257,5130,1792,2566,257,7690,65021,33802,1537,269,2760,2566,257,3082,53258,1537,269,2632,2566,257,5723,51424,2566,257,5824,43088,2566,257,6336,43223,2566,257,7616,43008,2058,1537,284,49320,16,2566,257,7104,43008,8202,1537,282,49320,64,2566,257,6336,43009,2566,257,6080,43010,2566,257,5824,43012,2566,257,5568,43016,2566,257,5312,43024,2566,257,6336,43209,2566,257,6336,43200,2566,257,6080,43210,2566,257,5824,43212,2566,257,5312,43216,2566,257,6339,61310,2566,257,6339,61317,2566,257
Раз раньше работало, а теперь с той же версией нет, то очевидно, что дело не в прошивке... Меня смущает именно то, что ответ не броадкастный.
Взял версию udhcpc из svn. Компильнул с дебагом.
Работает.
При этом tcpdump показывает следующее:PHP Code:
./udhcpc -i vlan1 -s /usr/local/root/showparams
udhcpc (v0.9.9-pre) started
adapter index 6
adapter hardware address 00:0c:6e:38:42:81
vforking and execle'ing /usr/local/root/showparams
deconfig
entering raw listen mode
Opening raw socket on ifindex 6
adding option 0x35
adding option 0x3d
adding option 0x3c
Sending discover...
Waiting on select...
oooooh!!! got some!
adding option 0x35
adding option 0x3d
adding option 0x3c
adding option 0x32
adding option 0x36
Sending select for 10.6.4.106...
Waiting on select...
oooooh!!! got some!
Lease of 10.6.4.106 obtained, lease time 54000
vforking and execle'ing /usr/local/root/showparams
bound
entering none listen mode
PHP Code:
tcpdump: listening on vlan1, link-type EN10MB (Ethernet), capture size 1500 bytes
16:01:12.141515 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:0c:6e:38:42:81, length: 548, xid:0x8824b449, flags: [none] (0x0000)
Client Ethernet Address: 00:0c:6e:38:42:81
Vendor-rfc1048:
DHCP:DISCOVER
CID:[ether]00:0c:6e:38:42:81
VC:"udhcp 0.9.9-pre"
PR:SM+DG+NS+HN+DN+BR+YD+YS+NTP
16:01:12.145112 IP (tos 0x0, ttl 63, id 43342, offset 0, flags [DF], length: 334) 10.6.1.1.67 > 10.6.4.106.68: [udp sum ok] BOOTP/DHCP, Reply, length: 306, hops:2, xid:0x8824b449, flags: [none] (0x0000)
Your IP: 10.6.4.106
Gateway IP: 10.6.1.1
Client Ethernet Address: 00:0c:6e:38:42:81
Vendor-rfc1048:
DHCP:OFFER
SID:10.100.0.11
LT:54000
SM:255.255.240.0
DG:10.6.1.1
NS:10.100.0.11
DN:"psk-net.ru"
16:01:12.148293 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], length: 576) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:0c:6e:38:42:81, length: 548, xid:0x8824b449, flags: [none] (0x0000)
Client Ethernet Address: 00:0c:6e:38:42:81
Vendor-rfc1048:
DHCP:REQUEST
CID:[ether]00:0c:6e:38:42:81
VC:"udhcp 0.9.9-pre"
RQ:10.6.4.106
SID:10.100.0.11
PR:SM+DG+NS+HN+DN+BR+YD+YS+NTP
16:01:12.151933 IP (tos 0x0, ttl 63, id 43346, offset 0, flags [DF], length: 334) 10.6.1.1.67 > 10.6.4.106.68: [udp sum ok] BOOTP/DHCP, Reply, length: 306, hops:2, xid:0x8824b449, flags: [none] (0x0000)
Your IP: 10.6.4.106
Gateway IP: 10.6.1.1
Client Ethernet Address: 00:0c:6e:38:42:81
Vendor-rfc1048:
DHCP:ACK
SID:10.100.0.11
LT:54000
SM:255.255.240.0
DG:10.6.1.1
NS:10.100.0.11
DN:"psk-net.ru"
Олег,
У меня тут мысль возникла. Может udhcpc из прошивки ждет пакет с не тем mac адресом?
Как это?
Про не броадкастный ответ есть в описании протокола BOOTP следущее (см. п. 2a):
В общем всё как-то странно...PHP Code:
4. Chicken / Egg Issues
How can the server send an IP datagram to the client, if the client
doesnt know its own IP address (yet)? Whenever a bootreply is being
sent, the transmitting machine performs the following operations:
1. If the client knows its own IP address ('ciaddr' field is
nonzero), then the IP can be sent 'as normal', since the client
will respond to ARPs [5].
2. If the client does not yet know its IP address (ciaddr zero),
then the client cannot respond to ARPs sent by the transmitter of
the bootreply. There are two options:
a. If the transmitter has the necessary kernel or driver hooks
Croft & Gilmore [Page 4]
RFC 951 September 1985
Bootstrap Protocol
to 'manually' construct an ARP address cache entry, then it can
fill in an entry using the 'chaddr' and 'yiaddr' fields. Of
course, this entry should have a timeout on it, just like any
other entry made by the normal ARP code itself. The
transmitter of the bootreply can then simply send the bootreply
to the client's IP address. UNIX (4.2 BSD) has this
capability.
b. If the transmitter lacks these kernel hooks, it can simply
send the bootreply to the IP broadcast address on the
appropriate interface. This is only one additional broadcast
over the previous case.
Попробуйте собрать бизибоксный udhcpc с отладкой и посмотреть в чём дело.
так вроде его и брал svn://busybox.net/trunk/udhcp
Или Вы не это имели ввиду?
ещё напрягает ругань на vlan1 прошивочного клиента:
udhcpc -i vlan1 -s /tmp/udhcpc
udhcpc (v0.9.9-pre) started
vlan1: No such process
Sending discover...
Sending discover...
Sending discover...