Kyle McDonald writes: > James Carlson wrote: > > Kyle McDonald writes: > > > >> 48ea4f19: Datagram received on network device: mgmt0(limited broadcast) > >> 48ea4f19: Malformed ICMP message received from host 172.30.171.103: len > >> 84 != 64 > >> > > > > This part means that we received a packet that was 84 bytes long (as > > reported by recvfrom) and that had an IP length of 64. I think the > > DHCP server is wrong here; that shouldn't be treated as an error. > > > > If the IP length is greater than the received length, then the packet > > has been truncated, and something's probably wrong. But if it's less, > > then that just means there's some padding we should have ignored. > > > > > Ok.
Sounds like a minor bug worth filing. It's unclear if it has anything to do with this problem, though. (I don't _think_ it does.) > > Find that guy. Someone is reponding to the address that should not > > currently be in use, because the lease is not valid. > > > > > That's the thing, the only machine on this network with that address is > the machine trying to renew that address. > > It's had that address for a while, and renewed it before. During a > renew, shouldn't the current address holder respond to the ping from the > dhcp server? Yes. But if the lease runs out, the client is required to stop using that address. I'd bet that's the problem. > > At a guess, the RHEL4u7 machine is responding to an ICMP ECHO message, > > even though it doesn't have a current lease for that address. > > > > > I thikn it does have a lease, That's the address it's trying to renew > anyway. I don't think you should see an ICMP ECHO generated by the server for a simple lease renewal. It should only be for a *new* lease. > > If that's a correct guess (a long-term snoop showing correct lease > > acquisition and eventual failure could provide more clues), then > > that's an error on their part. You can probably work around by > > specifying the ICMP_VERIFY=FALSE option in /etc/inet/dhcpsvc.conf. > > > > > I'll try to get the snoop and see what it shows. Thanks. OK. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
