MLA TCP/IP Stack Recovering from Ethernet Error
James Cameron email (remove spam text)
On Sun, Sep 24, 2017 at 09:07:21AM -0700, Harold Hallikainen wrote:
> > I don't know the peripheral, but on ethernet both ByteCount above 1522
> > and CRCError can be a collision or interference, and device reset in
> > response seems a bit eager.
> > CRCError can also be a fault in a sending device.
> > I remember having to split networks with hubs or switches to keep
> > numbers down to what the customer wanted.
> Thanks! I have a WireShark capture from a customer site where the
> network gets flooded with TCP communications between a couple other
> devices. I don't know why my system is seeing all that traffic. It
> SEEMS like the switch should send it to the receiving device only
> based on the MAC address.
Possibly. A switch is supposed to segregate traffic by MAC address.
Consult the switch vendor. It also depends on how it was captured.
Please excuse excess detail; I'm ignorant of your knowledge.
If Wireshark was used on a host that is not your embedded system;
Ask for the MAC addresses of the host that was running Wireshark.
There may be more than one. Label this "List A".
Use Wireshark to get the foreign TCP stream MAC addresses. There
should be at least two. Label this "List B"
If any address in List B can be found in List A; i.e. the latter are a
subset of the former, then ignore the packets, as they are a
side-effect of using Wireshark on a host; packets to or from the host
are accidentally captured.
In general, I've found byte counters and packet counters to be a very
effective way to locate network misconfiguration.
-- James Cameron
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
In reply to: <firstname.lastname@example.org>
See also: www.piclist.com/techref/microchip/devices.htm?key=pic
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the