dhcpd related issue - not giving up
Dánielisz László
laszlo_danielisz at yahoo.com
Sun Nov 1 18:27:49 UTC 2009
I also though that maybe the rl NIC can be wrong, I will try another branded NIC as soon as it will be possible, until than I looked for arp an socksat right after dhcp request, these are my results:
mac# $ dhcping -h 00:23:32:dc:72:19 -s 192.168.1.1
no answer
bsd# tcpdump -i rl1 -n port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl1, link-type EN10MB (Ethernet), capture size 96 bytes
19:14:38.604545 IP 192.168.1.234.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:23:32:dc:72:19, length 250
19:24:06.600131 IP 192.168.1.234.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:23:32:dc:72:19, length 250
bsd# arp -a
? (192.168.1.234) at 00:23:6c:86:41:d9 on rl1 [ethernet] <- this is my MacBook
? (192.168.1.1) at 00:13:8f:86:2f:64 on rl1 permanent [ethernet] <- this is the layer 3 switch
# sockstat -4l | grep dhcp
dhcpd dhcpd 4747 7 udp4 *:67 *:*
mac# arp -a
<public_ip>.pool.hdsnet.hu (<public_ip>) at 4a:55:88:7c:44:4f on tap0 ifscope [ethernet]
bsd (192.168.1.1) at 0:13:8f:86:2f:64 on en1 ifscope [ethernet]
________________________________
From: Michael Powell <nightrecon at hotmail.com>
To: freebsd-questions at freebsd.org
Sent: Sun, November 1, 2009 6:29:04 PM
Subject: Re: dhcpd related issue - not giving up
Dánielisz László wrote:
> I don't give it up, doing some tcpdump on my BSD I can see the dhcp
> request reaches the machine, the dhcpd is running, but why doesn't gives
> any IP?
>
> # tcpdump -i rl1 -n port 67 or port 68
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on rl1, link-type EN10MB (Ethernet), capture size 96 bytes
> 11:51:43.086597 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
> from 00:24:03:f1:bd:36, length 300 11:51:45.102260 IP 0.0.0.0.68 >
> 255.255.255.255.67: BOOTP/DHCP, Request from 00:24:03:f1:bd:36, length 300
[snip]
I only have a couple if ideas. First, is it possible to substitute some
other non rl or re NIC for rl1? I seem to recall something about these cards
having some sort of problem like this. This test would eliminate that idea.
Also, right after a client machine requests a lease examine your arp tables
on both machines. Maybe the dhcpd server is confused and sending the reply
out the wrong interface? sockstat -4l can confirm which/what interface dhcpd
is listening on, compare with arp results. Theoretically if dhcpd is bound
to and listening on rl1 there shouldn't be any replies going out rl0. Check
to eliminate.
Wrt to a managed switch blocking ports, I think you probably ruled this out
by connecting the machines to each other. Note that for GigE, or NICs that
do MDI-X properly any cable will work. However, on many older 100baseTX
cards this would need to be using a crossover cable to function correctly.
You can also broaden your tcpdump to include arp traffic. When the output
files become cumbersome to examine it's easier to look at them in Wireshark.
I have a hunch if rl1 could be replaced with some old fxp or sk card lying
around it might work. YMMV
-Mike
_______________________________________________
freebsd-questions at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions
mailing list