Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Looking for some help or advice with an issue

From: Hansang Bae <hbae@xxxxxxxxxx>
Date: Fri, 04 Apr 2008 23:09:35 -0400
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