> > > I have no doubt it is with the driver. I am somewhat > fortunate in > > this instance that I have a nearly identical setup - this > is an FPGA > > based system > > I can swap the FPGA firmware, get an almost identical > kernel with > > a slightly different NIC, and everything works - same > cables, same IP's, > > Same switch, The only things different are the NIC and > its driver. > > Even the Linux kernels are identical - except the NIC driver. > > > > BUT so is the data received and passed on to the kernel > (outside > > 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... > > One works the other doesn't. > > > > Well ethernet device drivers contain multiple arp supporting > methods, e.g. header_cache, header_cache_update, > hard_header_parse, etc etc. > Generally driver writers don't need to concern themselves > about these as they are assigned to generic handlers by > ether_setup(). However, your problematic driver may do > something different. > > Given this problem appears to be driver specific rather than > PPC specific your best bet is to try and contact the author. > BTW, I don't think you've said which driver you are using, a > key piece of info.... > 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.
