Replace VPCS

[ghost]

While VPCS is a very small and fast program to simulate an end device it has a mayor drawback. For a full end device it has to implement a full TCP/IP stack in user space. VPCS currently supports only IP/ICMP/DHCP (and even that has some bugs). But something like telnet or even ssh from VPCS to a connected router is not supported and it will be a BIG task to implement that.

The alternatives:

1. Use a user mode TCP/IP library like lwIP http://savannah.nongnu.org/projects/lwip/
   This would help implementing the network protocol, nevertheless it will be a lot of work adding the command processing and the user applications (ifconfig, ping, telnet).
2. Use a router as a end device
   But what type of router? It should be something free, so it can be distributed with GNS3. But when it's not cisco like, the user has to learn a new device type.
3. Use a small linux docker image (like alpine)
   Extremely efficient and fast, solid linux TCP/IP stack and a load of useful user programs. But it requires the GNS3VM (or another linux based GNS3 server). Some interface settings are difficult for the non-linux enthusiasts, some ideas to handle that later.
4. Use a small (MicroCore) VM
   That will work even with the old QEMUs from Windows/OS X, but it needs some time for boot (25s in OS X with qemu 0.14.1, 10s with qemu in GNS3 VM).

I'm for a linux based solution, because almost everything is there, it has proven it's quality and it's efficient.

For making the IP configuration a little bit easier: A special ifconfig program implements ifconfig <interface> dhcp start|stop|status to make DHCP configuration easier and ifconfig save to make the current IP configuration persistent. All other ifconfig commands will be passed to the original ifconfig.

[AJNOURI]

I am for using docker image instead. Linux capabilities without any additional efforts.

[Raizo62]

I find that VPCS does his job : it propose minimal network commands. useful just for fast test and very low memory (or to simulate devices with no admin access) When i need more, i use VM Linux.... Complete VPCS with other, yes. But not to replace it.

[AzzyInc]

Here here!

-----Original Message----- From: "Bernhard Ehlers" notifications@github.com Sent: ‎1/‎27/‎2017 10:04 To: "GNS3/gns3-gui" gns3-gui@noreply.github.com Cc: "Subscribed" subscribed@noreply.github.com Subject: [GNS3/gns3-gui] Replace VPCS? (#1823)

While VPCS is a very small and fast program to simulate an end device it has a mayor drawback. For a full end device it has to implement a full TCP/IP stack in user space. VPCS currently supports only IP/ICMP/DHCP (and even that has some bugs). But something like telnet or even ssh from VPCS to a connected router is not supported and it will be a BIG task to implement that. The alternatives: Use a user mode TCP/IP library like lwIP http://savannah.nongnu.org/projects/lwip/ This would help implementing the network protocol, nevertheless it will be a lot of work adding the command processing and the user applications (ifconfig, ping, telnet). Use a router as a end device But what type of router? It should be something free, so it can be distributed with GNS3. But when it's not cisco like, the user has to learn a new device type. Use a small linux docker image (like alpine) Extremely efficient and fast, solid linux TCP/IP stack and a load of useful user programs. But it requires the GNS3VM (or another linux based GNS3 server). Some interface settings are difficult for the non-linux enthusiasts, some ideas to handle that later. Use a small (MicroCore) VM That will work even with the old QEMUs from Windows/OS X, but it needs some time for boot (25s in OS X with qemu 0.14.1, 10s with qemu in GNS3 VM). I'm for a linux based solution, because almost everything is there, it has proven it's quality and it's efficient. For making the IP configuration a little bit easier: A special ifconfig program implements ifconfig dhcp start|stop|status to make DHCP configuration easier and ifconfig save to make the current IP configuration persistent. All other ifconfig commands will be passed to the original ifconfig. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jtorri]

Not doubt many here have are aware of alternatives for VPCS of which I know nothing. However, my vote is for the extremely lightweight VPCS for very basic connectivity testing and one of the many versions of TinyCore/Micro Core linux for additional networking functionality.

[grossmj]

I think VPCS is useful but since it gives us many problems on the development side, we have been looking to replace it by a Python version that we fully control and we can easily add new features.

Ideally, a small Linux VM would be great too but it is slow to run on Windows/OSX. One possible solution would be for us to support Hyper-V for Windows or hope that Docker containers are supported in Windows some day but I have the feeling it would give us more headaches than necessary...

[julien-duponchelle]

VPCS as some bugs we didn't manage to isolate and with recent computer it's getting worse (probably due to security feature in OS which randomize the memory address space)

Current VPCS code in C is complicated especially due to the fact VPCS can work in hypervisor mode with a single process managing multiple VPCS.

I made test few week ago to see how it's difficult to rewrite VPCS (code is broken I stopped in a middle of a test): https://gist.github.com/noplay/659bd6f0ba62186e8f7eb80a45593275

It's just connect on the UDP tunnel and reply to ping. It's use a python lib for parsing the packets.

I think we can success to make something close to VPCS with a full week of work and easier to extend. But will probably need hard debug.

In this scenario it's probably possible to leverage third party python library for implementing telnet or SSH.

[julien-duponchelle]

The alternatives:

Use a user mode TCP/IP library like lwIP http://savannah.nongnu.org/projects/lwip/ This would help implementing the network protocol, nevertheless it will be a lot of work adding the command processing and the user applications (ifconfig, ping, telnet).

This is close to my idea of using a python lib for parsing. I'm just more low level because you need to implement also the ARP cache, ICMP reply...

Using a C library seem complex and perhaps overkill for our needs we don't care about speed we want something easy to hack.

Use a router as a end device But what type of router? It should be something free, so it can be distributed with GNS3. But when it's not cisco like, the user has to learn a new device type.

If it's not a Cisco we need to run qemu and it will be slow.

Use a small linux docker image (like alpine) Extremely efficient and fast, solid linux TCP/IP stack and a load of useful user programs. But it requires the GNS3VM (or another linux based GNS3 server). Some interface settings are difficult for the non-linux enthusiasts, some ideas to handle that later.

If docker was not limited to linux that will be the way to go I think. We could easily made a shell interface à la VPCS but using under the hood the linux command ping, ip...

Use a small (MicroCore) VM That will work even with the old QEMUs from Windows/OS X, but it needs some time for boot (25s in OS X with qemu 0.14.1, 10s with qemu in GNS3 VM).

Slow for Windows and Mac :(

[ghost]

It seems, that Julien and Jeremy have this topic already on their list.

[julien-duponchelle]

I reopen because we don't have this on the roadmap on the moment and we are open to ideas.

[Raizo62]

I think that is not an good idea to disperse to other projects : we have already network devices from small (VPCS) to big (Linux/Microsoft) by passing by docker. And i think that to develop network OS is not easy to debug.

I think it is more useful to extend functionality of GNS3. For example, find an idea to add and use virtual wifi card between Virtual OS of VirtualBox or VMWare

[julien-duponchelle]

VPCS actually consume time to maintain and we are not able to recompile a working version on recent Windows and OSX it's a time bomb.

[jtorri]

You guys are doing the work, you guys know and deal with the details, you guys get to make the decisions. For what it's worth, that's my opinion.

[ghost]

Use a small (MicroCore) VM

Slow for Windows and Mac :(

I've created a stripped-down version of a MicroCore VM. On a Mac (2.5 GHz i5, slow qemu 0.14.1) that boots within 10 seconds, fully functional with all devices active. That's not super fast, but it has the advantage, that it is available and stable.

For Linux/GNS3 VM I wouldn't use that, a docker VM is instantly active.

Update: The stripped down MicroCore VM is available at https://github.com/ehlers/microcore-mininit https://git.bernhard-ehlers.de/ehlers/microcore-mininit

[julien-duponchelle]

The VM has another issue. How to convert the project that actually use VPCS?

On Thu, Feb 2, 2017 at 3:20 PM Bernhard Ehlers notifications@github.com wrote:

Use a small (MicroCore) VM

Slow for Windows and Mac :(

I've created a stripped-down version of a MicroCore VM. On a Mac (2.5 MHz i5, slow qemu 0.14.1) that boots within 10 seconds, fully functional with all devices active. That's not super fast, but it has the advantage, that it is available and stable.

For Linux/GNS3 VM I wouldn't use that, a docker VM is instantly active.

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/GNS3/gns3-gui/issues/1823#issuecomment-276970058, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVFXSqCtiN5FHrOfDvg1PqznlGYRCxTks5rYeY6gaJpZM4LwKMU .

[codeassassin]

I agree that VPCS fills a nice niche. So, we have the code. It's in C. But there are too many bugs to be able to compile and run a working version any more? Hmmm, my suggestion, if the code is open and on github, make a competition open to the community and pin the article to the community board. Whoever can debug and compile VPCS gets a badge of honor added to their GNS3 profile or something. People like a challenge.

[julien-duponchelle]

We can compile it but after we have strange issue depending how we have compile. Due to way VPCS work (multi thread) it's not easy to see what corrupt the memory.

[julien-duponchelle]

An experimentation: https://gist.github.com/noplay/659bd6f0ba62186e8f7eb80a45593275

[ghost]

Interesting!!!

But from the README of pypacker:

Q: There is problem xyz with Pypacker using Windows 3.11/XP/7/8/mobile etc. Can you fix that?

A: No. There will be no windows support. Why? Because quality matters and I won't give support for inferior systems. Think twice before chosing an operating system and deal with the consequences; don't blame others for your decision. Alternatively: give me monetary compensation and I'll see what I can do (;

[ghost]

When using pypacker only for generation / analyzing the IP packet, it's quite likely fine. I assume, that the problematic areas are sending/receiving via the OS, what's not needed with a VPCS lookalike.

[grossmj]

Do not hesitate to tell us if you find another tool that we could use to create/analyze packets etc.

Thanks :)

[julien-duponchelle]

Yeah we will not communicate with the OS, so a basic library for parsing and crafting packet should work.

[julien-duponchelle]

I have a working VPCS in vpcs_poc connected to the GNS3 with ping and save restore working now @grossmj you can do the hard work

[grossmj]

We won't have time to implement and debug this before 2.1

[grossmj]

Unfortunately recreating a VPCS-like device will take us too much time (we would have to basically recreate a small TCP/IP stack) and I am not sure it is really worth it.

I think the best approach is to keep VPCS as it is and do what @ehlers proposed in https://github.com/GNS3/gns3-gui/issues/1823#issuecomment-276970058, we could include the stripped down VM in our installers.

Also the VM boot time should be faster using HAXM support: https://github.com/GNS3/gns3-server/issues/1242

[ghost]

Just re-tested the boot times of TinyCore Linux: TinyCore normal on Linux: 10s TinyCore-mininit on Linux: 9s TinyCore normal on OS X: 25s TinyCore-mininit on OS X: 11s

The comparison is a bit unfair towards TinyCore-mininit as mininit waits on startup for all devices to register, what the normal TinyCore doesn't do. Nevertheless the benchmark shows, that the main advantage for mininit is on systems with slow software virtualization.

On system with hardware virtualization (currently only Linux) the differences are quite small, so that the extra effort to maintain TinyCore-mininit doesn't pay off. I assume similar results with HAXM. So if HAXM is coming soon, I have some doubts, that it's necessary to include TinyCore-mininit in GNS3.

[ghost]

https://github.com/GNS3/gns3-gui/issues/1823#issuecomment-277053403 The VM has another issue. How to convert the project that actually use VPCS?

I won't create an automatic change from VPCS to another solution. I would simply deprecate VPCS at a major release and stop shipping it with the next major release. The deprecation message links to a documentation webpage, that tells the user how to replace VPCS by a QEMU or Docker VM (or using a router as an end device).

So what about creating this depreciation notice with v2.2 and stop shipping it with v2.3? All what's needed is a deprecation webpage and a gns3-registry entry for TinyCore-mininit (or any other VM).

[Raizo62]

I think that VPCS does his job : it propose minimal network commands. useful just for fast test and very low memory. If you need more, you can use other VM. But VPCS in the repository of GNS3 has 3 olds pull request to fix bugs. Who is admin of this repository ?

[grossmj]

I agree with Raizo62, VPCS does fill a niche and if you need more you have the VM option. I am not really keen to deprecate VPCS, at least not until we have a really good replacement solution (native Docker support on Windows/macOS?).

We will create an registry entry for TinyCore-mininit.

[ghost]

That sounds good. Close this issue?

[grossmj]

I am going to keep it open to remember to add TinyCore-mininit to the registry. Then I will move this issue to our TBD milestone in case the situation changes long term.