Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GNS3 client packet capture not working correctly when remote main server is configured #2111

Closed
nextai2003 opened this issue Jun 19, 2017 · 2 comments
Labels
Milestone

Comments

@nextai2003
Copy link

Client / Server version : 2.0.3

Steps to reproduce:

  1. Configure a VMWare Workstation image (GNS3.VM.VMware.Workstation.2.0.3) as remote main server in the GNS3 Windows client Tested with Wireshark x64 2.0.x and 2.2.7

  2. Create a topology between multiple QEMU devices (e.g. Linux TinyCore).

  3. Start packet capture on the link via GUI (right-click on link, capture).

At step 3, you shall notice that Wireshark starts correctly and scrolls packets in realtime.

  1. Stop Wireshark, exit it and then stop capture from GUI via right-click "Stop capture".
    At step 4, you will receive an error in the GUI's console similar to "Can't remove file C:/Users/Emanuel/AppData/Local/Temp/GNS3.Os2808" - opening the temp dir will not reveal this file. You will however notice another GNS3.Sh2808 or similar named file which is 0 KB in length and locked by the GUI (you can't remove it). In time, you will notice that this file keeps growing, meaning that actually the packet capture is still in process in this new file.

  2. Try to start capture again. This time wireshark opens but does not scroll the capture.

  3. Repeat steps 4 and 5. Even from the first repetition you may notice that wireshark throws "invalid packet size" when trying to display the capture, so the capture gets somehow corrupted. Also, almost every time the remote main server stopped responding (timeout when accessing computes message).

Please note that this behavior does not occur when using the standard "remote servers" configuration (when the VM is configured as a "normal" remote server), with main server being standard localhost. The same Client and Server setup as above apply.

@julien-duponchelle julien-duponchelle added this to the 2.0.4 milestone Jun 22, 2017
julien-duponchelle added a commit to GNS3/gns3-server that referenced this issue Jul 27, 2017
@julien-duponchelle julien-duponchelle modified the milestones: 2.1, 2.0.4 Jul 27, 2017
@julien-duponchelle
Copy link
Contributor

I found a race condition in the startup of capture. The fix will be in 2.1.0a2

@nextai2003
Copy link
Author

Unfortunately, the issue is still reproducible in 2.1.0. Please refer to the original steps to reproduce the issue. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants