RE: MAC driver issue

=20

quoted

    I have no doubt it is with the driver.  I am somewhat=20

fortunate in=20

quoted

this instance that I have a nearly identical setup - this=20

is an FPGA=20

quoted

based system
    I can swap the FPGA firmware, get an almost identical=20

kernel with=20

quoted

a slightly different NIC, and everything works - same=20

cables, same IP's,

quoted

    Same switch, The only things different are the NIC and=20

its driver.=20

quoted

Even the Linux kernels are identical - except the NIC driver.
  =20
    BUT so is the data received and passed on to the kernel=20

(outside=20

quoted

random differences in the padding of the ARP packet)

Why is the ARP packet padding random?  I would think it would be fixed,
since the ARP packet itself is a fixed length (for IPv4<->Ethernet ARPs)
and the minimum Ethernet frame is 64 bytes...

quoted

    One works the other doesn't.
=20

=20
Well ethernet device drivers contain multiple arp supporting=20
methods, e.g. header_cache, header_cache_update,=20
hard_header_parse, etc etc.
Generally driver writers don't need to concern themselves=20
about these as they are assigned to generic handlers by=20
ether_setup().  However, your problematic driver may do=20
something different.
=20
Given this problem appears to be driver specific rather than=20
PPC specific your best bet is to try and contact the author. =20
BTW, I don't think you've said which driver you are using, a=20
key piece of info....
=20

Might I suggest putting static ARP entries in the kernel (use the "arp"
command from a prompt) and some other packet traffic - UDP perhaps.  See
if the problem is specifically with the way your network driver handles
ARP packets, or if it's a more fundamental problem of how the driver
hands any type of Ethernet packet off to the upper kernel stack layers.