<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFCC" text="#000000">
A bit more thoughts, these are just thoughts, so I send them
directly.<br>
<br>
oui is not important, I use various artificial MACs, like
de:ad:be:ef:fe:ed. For this there is no known vendor, your MAC comes
back as Cisco. Also virtual machines have weird MACs, they still
work.<br>
<br>
I assume now that Your-IP is an IP, where the logger has made a
reverse DNS lookup?<br>
<br>
One other thing I think I have seen, is that the client will make a
ping before accepting the offer, so you might try to be sure that
the address is not responding to pings at the time. If it does,
check the MAC, you can then see in your system who that is and look
for the cause.<br>
<br>
<div class="moz-cite-prefix">On 17/05/13 19:08, Will Eagleton wrote:<br>
</div>
<blockquote
cite="mid:888874516.3458888.1368810486407.JavaMail.root@web-pass.com"
type="cite">
<pre wrap="">You may want to look at the actual packets to see what it is asking for and whether it is in the reply. That could be a reason to not accept an address offer. The root cause could very well be something quite different.
Sten, thank you for the input... I hope I am not asking a 'stupid' question, but what else would the root cause be? There is no wiring negotiation issue etc, so I'm at a loss to know what else there may be. Most routers provide one form or another, client-identifier, so that is the most obvious things I see.
I have looked at the Discover and Offer messages, and am trying to figure out why the Linksys is not accepting the lease. We have this problem with maybe 50 or so customers at this point, so we give them statics which we'd like to avoid (several, mostly obvious reasons)
07:58:46.298122 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 58:6d:8f:79:8c:9d (oui Unknown), length 300, xid 0x588e3b7e, secs 43, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 58:6d:8f:79:8c:9d (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 19: "Fogelmania_unit1409"
Parameter-Request Option 55, length 4:
Subnet-Mask, Default-Gateway, Domain-Name, Domain-Name-Server
07:58:46.298590 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 351) x.199.21.84.web-pass.com.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 323, xid 0x588e3b7e, secs 43, Flags [Broadcast] (0x8000)
Your-IP x.199.21.84.web-pass.com
Server-IP x.199.21.84.web-pass.com
Client-Ethernet-Address 58:6d:8f:79:8c:9d (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: x.edited-out.edited-out.edited-out.web-pass.com
Lease-Time Option 51, length 4: 28800
Subnet-Mask Option 1, length 4: 255.255.255.192
Default-Gateway Option 3, length 4: x.199.21.84.web-pass.com
Domain-Name Option 15, length 12: "web-pass.com"
Domain-Name-Server Option 6, length 12: ns6.web-pass.com,x.152.14.204.web-pass.com,ns3.web-pass.com
At this point I will likely purchase one, if it isn't the missing client-identifier then perhaps the reverse-DNS stuff is confusing the client(?)
_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>