GNS3 1.4.4 switching instances not passing traffic (Ethernet switch or IOU) but hub does

[vader75]

I have come across a strange one. If I connect a GNS3 switch or IOU switch into a topology, then traffic between a host and a router connected to it does not work or one/two in number packets goes through but extreme loss is observed.

If I replace the switch with a GNS3 hub, all is well. It appears some internal GNS3 bridging or forwarding failure is happening or similar, but not sure.

GNS3 version 1.4.4 GNS3 VM 1.4.4 stable Platform: Windows 10 Pro VMware Workstation 12 Pro (12.1.0 build-3272444)

See my attached graphs for scenario 1 (not working) and scenario 2 (working)

Cheers,

Gordon

[julien-duponchelle]

You have only this with VMware?

[julien-duponchelle]

Probably related but: https://github.com/GNS3/gns3-server/issues/436

[vader75]

Yes probably related, even with generic hub i see increased delay but at least packets go in/out...as they say: "something's broken". Did not test with virtualbox, too much work at the moment :-).

If I don't use GNS3, and natively run networking (via monowall firewall/router) in VMWare workstation, it works perfectly, hard to troubleshoot at the moment.

[actionbastard]

I see the same behavior in Win7 with Workstation 10. 89% packet loss with the generic switch, but 0% loss using the hub. The issue with the hub is I also saw +4228 duplicates before I stopped pinging the router.

[grossmj]

More debug info: https://gns3.com/qa/gns3-1-4-0-on-esxi-can-t-connect

[grossmj]

The problem comes from uBridge and Winpcap. On at least some platforms, sending packets through pcap will, by default, cause those packets to loop back. Windows is one of them, so that applies to WinPcap. Looped back packets corrupts the MAC address table of the Ethernet switch, making it believe all packets come from the same port.

The standard libpcap API to turn this off, pcap_setdirection(), is not available in WinPcap. Supported way is to set the PCAP_OPENFLAG_NOCAPTURE_LOCAL flag when using pcap_open(). However, it seems that was broken around when Windows 7 or 8 was released: http://www.winpcap.org/pipermail/winpcap-users/2014-November/004918.html and http://www.winpcap.org/pipermail/winpcap-users/2015-November/004984.html

Initially, I have tried to use https://github.com/nmap/npcap, however it is still in beta and would not list my vmnet interfaces.

Luckily, recompiling uBridge with the latest Winpcap lib and Cygwin seems to have fixed the issue. I can only assume that the Winpcap devs fixed the PCAP_OPENFLAG_NOCAPTURE_LOCAL support.

A temporary dev version of uBridge can be downloaded from https://drive.google.com/open?id=0B558b5_SCiAHT09NVEJXVV9rLVk

Just replace ubridge.exe in your GNS3 installation directory. We will release uBridge 0.9.4 at the same time as we release a new version of GNS3.

[hsluoyz]

Hi @grossmj ,

The standard libpcap API to turn this off, pcap_setdirection(), is not available in WinPcap. Supported way is to set the PCAP_OPENFLAG_NOCAPTURE_LOCAL flag when using pcap_open(). However, it seem that was broken around when Windows 7 or 8 was released: http://www.winpcap.org/pipermail/winpcap-users/2014-November/004918.html and http://www.winpcap.org/pipermail/winpcap-users/2015-November/004984.html

Npcap supports PCAP_OPENFLAG_NOCAPTURE_LOCAL flag since 0.05 [1, 2]. You can probably set this flag using the PacketSetLoopbackBehavior() call.

however it is still in beta and would not list my vmnet interfaces.

I confirmed this issue. I will think about how to solve it.

References:

[1] http://seclists.org/nmap-dev/2015/q4/6 [2] https://github.com/nmap/npcap/releases/tag/v0.05

[grossmj]

Hi @hsluoyz,

Thanks so much for replying to this post. I will keep a look at npcap and when mature enough consider replacing winpcap by it.

[hsluoyz]

Hi @grossmj ,

Now Npcap can see VMware VMnet adapters in latest 0.06 R7.2 version: https://github.com/nmap/npcap/releases

The version number of Npcap is in beta because our community policy. It doesn't mean it's a beta quality software. The product itself has already updated many versions (which you can see in the releases).

WinPcap has no active developers currently, so there won't be much help if you encountered problems with WinPcap. And some of WinPcap developers already start the contribution to Npcap. So you can view Npcap as a semi-official replacement of WinPcap. Thanks!