Hello Charles,
>>> <Charles.Neff@xxxxxxxxxx> 2008-04-07 16:41 >>>
> Servers - located at Corporate office
> Registers - located at separate store locations
> WireShark - used to monitor at Store locations, on their LAN, using my
> laptop
How exactly are you monitoring (capturing) the various registers'
traffic "on their LAN"?
Have you "hubbed out" (put a real honest to goodness ethernet
hub --- NOT a switch--- between) the register and the upstream
LAN equipment?
Or did you monitor from a port on the upstream LAN equipment?
If the upstream LAN equipment is a real old fashioned ethernet hub,
then your system SHOULD[*] have seen everything transmitted
to and from the register (and in fact everything going into and out
of the hub).
But if the upstream LAN equipment is an ethernet switch, then you
generally have to enable some type of port mirroring (a.k.a port spanning)
to direct ethernet frames associated with one or more ports (or vlans) to
an specified analysis port (the port where you connect the monitor PC).
When setting up port mirroring you often have a choice of choosing to
see ingress data (data from the client machine connected to the port),
egress data (data from the switch being sent towards the client machine)
or both directions. If the switch supports vlans, you often also have the
choice of whether to strip the vlan tags or not.
Please note that SOME PC NIC cards are unable to successfully capture
spanned traffic IF the spanned traffic includes the vlan tags. Other PC NIC
cards will capture the spanned tagged data, but strip out the 802.1Q.
The best NIC cards for monitoring will capture and preserve the 802.1Q tags.
[*] In a problem vaguely similar (though not quite the same), I had a
coworker who had deployed a hub to troubleshoot a problem. In this
case, because he had "hubbed out", he knew he would see all packets
sent between the switch and the edge device. While he did capture all
of the egress traffic from the switch, he did NOT capture ALL of the ingress
traffic FROM the edge device. It turns out that his laptop had one of the
NIC cards that would NOT capture 802.1Q tagged frames. Now he wasn't
expecting this particular data to have any 802.1Q vlan tags. The edge port
was configured to be untagged. But it turns out that the edge device did in
fact send some frames with an 802.1Q tag, but with a vlan id of 0! The edge
device was using the 802.1Q field to convey the Layer 2 CoS (Class of Service)
bits (802.1p).
Could your upstream layer 3 device (the router at ip.addr===10.200.11.250,
eth.addr == 00:02:4b:7d:3d:40) perhaps be trying send Layer 2 prioritized
data (802.1p) and yet your monitoring system's NIC card happen to be one
the unfortunate kinds that silently drops the tagged frames? This MIGHT
explain why you can see both sides of the "telnet" (port 23) TCP data, but
only the local side of the POS (port ???) TCP data.
It's not a likely scenario but a possibility.
Regards,
Jim Y.
