Thanks for the packet dump. I've been after an exact dump to write a
cisco attack tool having gotten fed up of trying to get cisco to answer
emails about this paticular problem. The cisco shouldnt be going mad. The
packet shouldnt have occured in the first place but thats another story..
see below
> They say the weird things about the packet are the ethertype of 8808,
> that it's shorter than the minimum packet size of 64 bytes, and that
> it's a multicast broadcast packet. So, why my box is putting it on
> the wire (especially given that I'm not doing any multicast), and how
> do I stop it? BTW, rebuilding the kernel without multicast support
> doesn't stop these weird packets from going out.
EEPro100 with APM enabled. It seems to be some kind of SMbus problem. Intel
don't seem to want to provide info on how to lock out SMbus sent packets
(these cards support packets for stuff like case tampering, remote reboot
request [oh yes party time], and the like without the host OS intervening)
Turn off APM or switch to a card with proper docs is my first suggestion.
The other cases I've seen disabling all APM has sorted it.
> eth0: Invalid EEPROM checksum 0x60fe, check settings before activating this device!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Thats kind of an "all is not well" hint. Maybe its related.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/