William Chops Westfield wrote:
> On Aug 2, 2006, at 2:27 PM, stef mientki wrote:
>
>   
>> Sorry I made a little mistake, instead of checking the ZERO bit, I
>> checked the Length check error,
>> which is not the standard 08 00 (ARP) or 08 06 (IP),
>> but 00 2C which apparently ??? triggers the Length check error.
>>
>>     
> When ethernet was first created, the 2 byte field after the
> ethernet addresses was a "type" field.  Assorted people got
> type values assigned.  IEEE came along and in the habit of
> standards bodies everywhere, decided that they HAD to change
> SOMETHING in the existing spec, so they made it a length field.
> But then there wasn't any type field anymore, so they had to
> add some additional bytes at the beginning of the packet to
> identify the protocol (SAP, SNAP) Novell sort of showed up
> between those two steps, and is one of the few protocols that
> includes a native packet immediately following the length field,
> making it a PITA.  Meanwhile, the TYPE field was so intrenched
> that it wouldn't go away, and software implementations had to
> deal multiple encapsulations, sometimes for the same protocol
> (there were three ways that IP might have appeared, and the hacks
> to ARP to figure out which one was appropriate for each destination
> were... extensive and good for router sales.)
>
> I'm not sure why the packets would trigger the Length check error,
> though.  2C should be a fine length (44 bytes, yes?)  Perhaps
> it doesn't match the length received by the hardware (which
> ought to be OK since small ethernet frames get padded, I think (I
> don't recall whether it's supposed to actual length or padded
> length))  (Hmm.  I read the manual; looks like the error happens
> for the mismatch; but it also says the length is the unpadded
> data length, so it looks like a pretty useless error bit, unless
> you also compare to the actual min length)
>
> BillW
>
>
>   
Thank you all for your valuable contributions.
At the moment I've the ENC-chip (most of the time) running rock-stable:
5000 pings, during heavy network traffic (and lots of IPX protocols),
without any loss.
Just a few wrong returned packages (1 byte changed a little).
Because the checksum of the returned package is ok,
this is probably due to a wrong reception by the ENC-chip,
and I guess, I could have tracked that if I checked the IP-checksum of 
the received package,
although weird enough I don't get package checksum errors ???

I said "most of the time", because sometimes,
the startup or incidental reset or unplugging/replugging the cable,
doesn't give a good reset.
For what I've seen now, it seems that the transmission buffer,
(which I fill with a number of standard answers, like ARP, PING, on 
forehand,
get's not filled correctly during a reset).
I've to investigate that further,
but at least I now have a good starting point.

thanks,
Stef Mientki
>
>   
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist