opensuse v42.1 linux 4.1.15-8-default x86_64 wireshark 1.12.9 virtualbox 5.0.14 Wireshark is running on the linux side. I have been having difficulty with netbios and tcp writes from an ancient OS/2 system running in VirtualBox. Sometimes the writes perform as expected; other times they stall. I have some PCAPs that capture both success and failure to write to the network. In one case it is a netbios send; in another it is a TCP connection from SVN. I do not know (yet) what is expected in this forum for displaying packet info. In both cases it proceeds normally until, well, something, happens. Instead of proceeding with the data transfer, the resulting packet proclaims "[TCP Previous segment not captured] NBSS" rather than the expected data packet. 11 2016-02-21 12:40:28.433429 192.168.69.236 192.168.69.245 NBSS [TCP Previous segment not captured] NBSS Continuation Message Shortly thereafter is a packet indicating "[TCP Dup ACK 10#1] 139→51555 [ACK] Seq=389". Sometimes there is another DUP packet. By this time the session is a mess, and eventually times out. The SVN failure packet is 19 2016-02-21 14:50:10.913572 192.168.69.236 74.101.171.114 TCP [TCP Previous segment not captured] 51560→3690 [PSH, ACK] Seq=3342 Ack=401 Win=33580 Len=1176 Does this imply a fault on the sender's side (OS/2), trying to recover from a dropped packet? And failing? Or is it a Wireshark error, failing to capture the packet? Or ...? asked 21 Feb '16, 13:57  jimoe |
One Answer:
I can't say for certain, but, in this case, given the networking problems you're describing, "NBSS Continuation Message" probably means that the "previous segment" wasn't captured because it didn't make it to the machine running Wireshark, i.e. a packet got lost in transit between 192.168.69.236 and 192.168.69.245. Wireshark couldn't reassemble the message (NetBIOS Session Service, "NBSS", over TCP - port 139 - which is used to transport SMB in older systems such as OS/2) because the chunk was missing, but it inferred from port 139 that it's NBSS, so it assumed it was a continuation of an earlier message as it didn't begin with an SMB header. It probably was a continuation, but there was a piece missing before it. I suspect that if you look at the TCP layer of those packets, there will be some TCP analysis information indicating a missing packet. Is Linux the host and OS/2 the guest? Or are they both guests on the same host talking to each other? Or is there actual communication over a physical network? If it's host <-> guest or guest <-> guest, there's no physical network, so packet drops at the "physical" layer are just VirtualBox issues. However, there might instead be a problem with one of the TCP layers.
We'd probably have to see the full dissection of the packets in question, but I suspect from the duplicate ACKs that something's going on at the TCP layer.
It's probably best to upload the raw capture to some online storage service and post the URL here, if you're willing and able to make the capture public; that way, we can see all the details without having to deal with a big text dump or screenshot. answered 22 Feb '16, 17:19  Guy Harris ♦♦ |
Here is a link to two PCAPs for a file transfer, a write from local os/2 to the remote system. One is the successful transfer, the other when it failed.
https://www.dropbox.com/sh/b6t28azor5x6swv/AACwEycyRdj5I27KDkztVZ1aa?dl=0
linux is hosting VirtualBox; os/2 is a guest. As a side note, we have 4 other similar installations that are also displaying this issue. And one that does not: an OSX host with a os/2 guest; it runs fine.
The connection is very short: os/2 to host to destination (a linux-based NAS unit). Because the OSX setup functions normally, it has made me suspect something about the vbox network interface. Which is why I am investigating this with wireshark.
Wireshark is running on the host, linux OS. I would presume, then, that the packet is somehow being lost from the destination to the host. It would seem almost impossible given how little hardware is in between.
It looks as if, in the failing case, the first two TCP segments of an SMB Write are getting lost, and the server is sending two duplicate ACKs to try to trigger a "fast retransmit".
So Wireshark is running on the machine in the middle (the host), and it's not seeing the packets, so they're probably getting out somewhere between the OS/2 box and the host. Whether that's an OS/2 problem or a VirtualBox problem - or a Linux problem, or a VirtualBox-on-Linux problem, as it's not happening with an OS X host - I don't know.