MAC driver issue

[Martin, Tim]

> 
> >     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.