Wireshark-users: Re: [Wireshark-users] Looking for some help or advice with an issue
Charles.Neff@xxxxxxxxxx wrote:
I've been using 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.
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.
Wait, I'm confused. The POS are remote and you are capturing from a
central location?
We use FacetWin terminal emulation for our custom POS system that uses
telnet. 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.
When the telnet client connects, it will exchange what it can and can't
do. You should see them as "IAC blah" (IAC == Interpret As Command)
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. This will continue to happen
as new sessions are opened on different or previous registers.
So the original POS is still working? This is critical so we need to
konow. It almost sounds like you are behind a NAT and you *think* you
are seeing the same IP, but at the TCP level, they are different
conversations. What does "Statistics, Conversation List" say?
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. As soon as the POS side
of the server is accessed for transactions, the problem occurs.
I'm not sure what the last sentence means.
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. These pads are connecting to the same server as the registers.
I'm running the sniffer locally, on a Cisco switch with port mirroring
turned on. I've also tried using a straight hub. I've monitored the
router port, and I've tried monitoring only one port for one register at
a time. I'm not filtering any of the data, just trying to capture
everything. We are using Wyse terminals for the registers, and as I
said FacetWin for terminal emulation. The POS server is Unix based.
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.
That would be impossible *unless* the program uses its own framing.
And that's not very likely. So the question is: when the IP is
hijacked (from your perspective), do the others continue to work?
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.
If anyone has any suggestions or ideas, please let me know. At this
point I am truely greatful for any and all help.
can you upload some sample captures? You can use editcap to chop off
everything besides the headers.
--
Thanks,
Hansang
