<br><font size=2 face="sans-serif">I've been using Winpcap through Wireshark
(ethereal before the change) for a few years now to help track down possible
network issues, and something I've noticed through out is now becoming
a problem that I need some help with.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
When capturing POS traffic off of registers, locally at my remote locations,
I'm getting strange results as far as loss of packet info to different
degrees.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
We use FacetWin terminal emulation for our custom POS system that uses
telnet. &nbsp;When monitoring the tcp traffic from a register, I'm not
seeing the echoed responses from the POS server, only the transmitted data
from the registers. &nbsp;Also, I will lose traffic from one register completely
if another session of FacetWin is started on another register, and I will
begin to only see the data from that second register, even though the initial
register is still being used. &nbsp;This will continue to happen as new
sessions are opened on different or previous registers.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Using the same FacetWin program but changing the login info so that I am
telneted into the POS server with my username (as opposed to just logging
in as a register), I can see all traffic as I should and it will never
drop or be replaced by another session. &nbsp;As soon as the POS side of
the server is accessed for transactions, the problem occurs.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
These issues are happening with the Credit/Debit Signature pads that we
have recently attempted to rollout with issues of lock ups, and the loss
of traffic data is making it difficult to capture packets at the time of
a lockup. &nbsp;These pads are connecting to the same server as the registers.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
I'm running the sniffer locally, on a Cisco switch with port mirroring
turned on. &nbsp;I've also tried using a straight hub. &nbsp;I've monitored
the router port, and I've tried monitoring only one port for one register
at a time. &nbsp;I'm not filtering any of the data, just trying to capture
everything. &nbsp;We are using Wyse terminals for the registers, and as
I said FacetWin for terminal emulation. &nbsp;The POS server is Unix based.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Given the way this problem presents itself, and some research I've done,
I'm leaning towards the issue somehow being caused by the POS programming,
but I don't know how it would be effecting the packets, or changing them
so they wouldn't be picked up by Wireshark. &nbsp;</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Since I'm on the network side, I'm going to need some compelling information
or ideas to get anywhere with the programmers on figuring this out.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
If anyone has any suggestions or ideas, please let me know. &nbsp;At this
point I am truely greatful for any and all help.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
thank you</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
_charley</font><font size=3> </font>
<br>