Hi,
Thanks for the tip.
I tried now but it didn't help :/
I also logged local7.debug but the DHCPd doesn't seem to see anything
from eth0.5.
However I noticed a difference in the paquets on the receiver/dhcpd
side:
- from eth0.5:
00:04:30.931442 vlan 5, p 0, IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:40:ca:d5:1c:57 (oui Unknown), length: 300, xid:0x5150aa6e, flags: [none] (0x0000)
Client Ethernet Address: 00:40:ca:d5:1c:57 (oui Unknown) [|bootp]
- from eth0:
00:05:03.930970 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:40:ca:d5:1c:57 (oui Unknown), length: 300, xid:0x5e2db216, flags: [none] (0x0000)
Client Ethernet Address: 00:40:ca:d5:1c:57 (oui Unknown) [|bootp]
eth0.5 sends this "vlan 5, p 0" additional information. Is that
normal? Maybe I need to configure something on the receiver side as
well?
Thanks for your help!
--
Sylvain
On Sat, Sep 16, 2006 at 02:57:01PM -0400, Enrico Demarin (home) wrote:
> Hi Sylvain,
>
> if you are using ISC DHCP try to recompile it to use sockets and not LPF :
>
> +++ dhcp-3.0pl2-enri/includes/cf/linux.h Fri Jan 17 22:02:28 2003
> @@ -122,7 +122,7 @@
> #if (LINUX_MAJOR >= 2)
> # if (LINUX_MINOR >= 1)
> # if defined (USE_DEFAULT_NETWORK)
> -# define USE_LPF
> +# undef USE_LPF
> # endif
> # if !defined (__sparc__) /* XXX hopefully this will be fixed
> someday */
> # define SIOCGIFCONF_ZERO_PROBE
>
> Sylvain Beucler wrote:
> >Hi,
> >
> >On Thu, Sep 14, 2006 at 05:17:28PM +0200, Peter Stuge wrote:
> >
> >>On Thu, Sep 14, 2006 at 12:25:43PM +0200, Sylvain Beucler wrote:
> >>
> >>>Shouldn't it work?
> >>>
> >>I think it should.
> >>
> >>I would check what is actually on the wire, to confirm that nothing
> >>is really leaving the box. (Use a hub.)
> >>
> >>I would also investigate what dhclient actually does by running it
> >>under strace.
> >>
> >>I would also try other DHCP clients. Personally I like dhcpcd but
> >>there's also pump and udhcpc.
> >>
> >
> >Thanks for the advice.
> >
> >
> >It turns out that something goes out of the wire, the DHCP server
> >machine receives it, yet does not reply (I doubt the DHCP server
> >daemon itself sees it). Or, the reply does not show on tcpdump.
> >
> >
> >This is strange really: tcpdump -vv shows that the initial broadcast
> >paquet is nearly identical for eth0 and eth0.5. Only a 'xid' field
> >differs, which is one-char shorter on the vlan:
> >* pump -i eth0.5
> >22:14:24.039510 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
> >length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request
> >from 00:40:ca:d5:1c:57, length: 548, xid:0xb4c6a13, flags: [none] (0x0000)
> > Client Ethernet Address: 00:40:ca:d5:1c:57 [|bootp]
> >[nothing]
> >
> >* pump -i eth0
> >22:14:26.495647 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none],
> >length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request
> >from 00:40:ca:d5:1c:57, length: 548, xid:0xd54c6b50, flags: [none] (0x0000)
> > Client Ethernet Address: 00:40:ca:d5:1c:57 [|bootp]
> >[DHCP offer/request follows]
> >
> >
> >The behavior is the same with all DHCP clients I tries (dhclient,
> >dhclient3, pump, dhcpcd). I also tried dhcp3-server and udhcpd (and my
> >ISP's box's) :/
> >
> >
> >As for the strace, dhclient3 times out on a select:
> >
> >time([1158267744]) = 1158267744
> >time([1158267744]) = 1158267744
> >rt_sigaction(SIGPIPE, {0xa7ea57e0, [], 0}, {SIG_DFL}, 8) = 0
> >send(3, "<30>Sep 14 23:02:24 dhclient: DH"..., 91, 0) = 91
> >rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
> >write(2, "DHCPDISCOVER on eth0.5 to 255.25"..., 61DHCPDISCOVER on eth0.5
> >to 255.255.255.255 port 67 interval 10) = 61
> >write(2, "\n", 1
> >) = 1
> >sendto(8, "\377\377\377\377\377\377\0@\312\325\34W\10\0E\20\1H\0\0"...,
> >342, 0, {sa_family=AF_PACKET, proto=0x6574, if892219496,
> >pkttype=PACKET_HOST, addr(0)={0, }, 16) = 342
> >select(9, [7 8], [], [], {10, 0}) = 0 (Timeout)
> >
> >time([1158267754]) = 1158267754
> >time([1158267754]) = 1158267754
> >[...]
> >
> >
> >A (newbie) question though: theoretically how could the eth0.5 grab a
> >DHCP offer? Doesn't 'eth0' steal it first?
> >
> >Thanks,
