ACKed unseen segment

asked 2019-06-01 04:31:13 +0000

RickVicik
11 ●1 ●2 ●5

updated 2019-06-01 04:45:33 +0000

I'm getting a lot of "ACKed unseen segment" packets in my capture of traffic between an IP camera (AXIS M1011) and the display device which is a Furuno TZT14 marine chart-plotter. I'm using a SharkTap between the 2 devices, there is nothing else on the network, and to reduce chatter that might be causing packets to be dropped, I added capture filters of "host 172.31.200.3" (the IP cam) and "not broadcast and not multicast". My capture is TZT14M1011Filter.pcapng. A specific example is packet 11. The camera says "401, not authorized" but which packet caused that? Also, at packets 28 and 29, the chartplotter issues DESCRIBE and OPTIONS requests, but at 30, the camera says "Option not supported". From which request? When I entered this, I didn't realize I wouldn't be able to upload my capture file because I don't have 60 points. ---rick

edit retag flag offensive close merge delete

Comments

You can upload your capture file to a public file share, e.g. Google Drive, DropBox etc. and then post a link to it back here.

grahamb ( 2019-06-01 07:04:09 +0000 )edit

Thanks for the info. I uploaded the capture file to DropBox. Here is the link: https://www.dropbox.com/s/jx6vs2x0xba... ---rick

RickVicik ( 2019-06-01 20:45:33 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-06-08 03:15:36 +0000

RickVicik
11 ●1 ●2 ●5

I successfully captured all the requests and responses between the viewer and the camera (including the ones that were always missing from previous captures) by using the PC running WireShark as a bridge. The PC has 2 USB3.0 ports, so I got two RealTek GB-to-USB3.0 adapters and configured the Win10 PC as a bridge between them. WireShark could not see the bridged adapters until I uninstalled npcap (v.995) and installed winpcap (v4.1.3). ---rick

edit flag offensive delete link

Comments

To rule out the possibility that replacing npcap with winpcap was the entire solution, I tried the SharkTap with the 10/100 SMC adapter and with the GB Realtek adapter. Both cases lost packets the same as with npcap. The solution requires the bridge and winpcap.

RickVicik ( 2019-06-09 04:00:23 +0000 )edit

You should report the npcap issues with the bridged adaptors over at nmap, who manage the npcap project.

grahamb ( 2019-06-10 13:57:46 +0000 )edit

There is a long thread on the subject at https://github.com/nmap/nmap/issues/336. Apparently I could have stopped and restarted the npcap driver after creating the bridge. I'll need to switch back to try it.

RickVicik ( 2019-06-11 14:46:12 +0000 )edit

add a comment

answered 2019-06-02 10:52:41 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

The TCP analysis "error" message TCP ACKed unseen segment means Wireshark saw an ACK for a data segment that it did not see. And TCP Previous segment not captured means it sees a data segment that does not neatly come after the previously seen data segment.

As Wireshark is not one of the endpoints, there can be packets missing in the data stream towards Wireshark, even though the two endpoints do get to see all the packets. This is the case in your tracefile. You can deduct this from the fact that there are no retransmissions of the segments that are not seen by Wireshark. If one of the endpoints was missing the segments, it would send duplicate acks and the sender would retransmit.

So, something in your capture setup is not functioning well. From the capture file properties, I see no "Packet discards", this means all the packets that were received and filtered by WinPcap/Npcap were written to disk. So there was no disk IO problem that prevented part of the packet stream to be saved to disk.

Then you have a capture filter applied even though you stated there were no other systems on the network. This is a little contradictory. Why use a capture filter if there are no other systems on the network. My guess is that there were indeed other systems and the capture port might have been overloaded (please remember that mirroring one 1Gbit/s port full-duplex may result in a 2 Gbit/s data stream to the analyser port, which will start discarding packets). I see you used a SharkTap. I just lookup up their specs and there are several models. The USB model will limit data-transfers to the host to about 300-400 Mbit/s. So maybe the TAP was overloaded? Please be aware that the BPF capture filtering takes place on the capturing host, not on the TAP.

Can you please describe you capture setup, all other systems on the network, etc in more detail if the above information does not provide enough info to solve your capture issue?

edit flag offensive delete link

Comments

First, thanks very much for your detailed answers. They are much more helpful than what I get from the manufacturers of the devices I'm trying to connect.

The original setup had several devices connected by a switch but I learned that capturing from a switch port doesn't get everything so I got a SharkTap and connected just the 2 devices to it. The SharkTap is model 10/100 and the tap output goes to the PC running WireShark via an SMC 10/100 ethernet-to-USB adapter because the PC has no ethernet port. Win10 on the PC says that adapter is 100MBPS. The WireShark version is 3.0.2.

I added the capture filters because the TZT14 does a lot of broadcasting even when there are no other devices. Even more confusing is that the TZT14 uses 2 source addresses although it is the same physical device (172.31 ...(more)

RickVicik ( 2019-06-05 03:12:40 +0000 )edit

Have you checked https://wiki.wireshark.org/CaptureSetup/Ethernet? It has a lot of information on how to capture packets on ethernet networks.

Even though 100 packets/s is not that much, it might be too bursty for the SMC 10/100 adapter. The 10/100 refers to the speeds at which it is able to connect. Not necessarily the bandwidth it is able to process. My guess now is that this adapter might be dropping the frames. Have you captured data with it before? I would suggest doing an iperf test or something similar to see what it can handle before using it as a capture/measuring device.

SYN-bit ( 2019-06-05 09:27:11 +0000 )edit

add a comment