
But i have a router which is connected to active link from which internet is accessable but i don't want to flash this one because my isp has done ip/mac binding so it long proccess ( I am asking this becouz my mentor in the college has asked me to replicates this thing on a real router aside vm now two thing i have a router which is nt in use.

If you have gns "talking" with virtualbox ( are you running on win? ) then that is really the hardest part of the process. I spend an hour or few banging my head against the wall trying to get gns to play nice with virtualbox ( vboxwrapper.py ) but it wouldn't play ball on my system. so it might be something i have to delve into soon. as i mentioned it had been years since i'd used gns so it was kinda cool firing it up and seeing just how far it's come! 90% of solving a problem is defining it correctly. substitute aspects of the topology and see if it works.

I reckon try it with something you find more comfortable. say "QEMU guest" or "VIRTUALBOX guest interface" or "Host Interface" etc. chances are it's just a matter of breaking the components down and testing each aspect.īe more specific about what is not working and dont use the word vm. If the machine fires up and you have no connectivity. but the main issue I had was getting the qemu command, not the tap0. I will need to poke around my filesystem to find a working one if you need it. The ifup / down scripts just make sure the underlying tap0 and br0 etc exist and are up. net nic -net tap,ifname=tap0,script=no,downscript=no #-append "root=/dev/vda1 debug=4 console=tty0 addtty" \ #-append "initrd=/bin/sh init=/bin/sh addtty" \ Here is the wrapper script I used to power on the vm. Manually add the tap / tun interface to which the QEMU guest would bind to.

It was necissary for me to shift my Debian interface into a bridge. You have to break down each component to it's bare essentials and troubleshoot from there.įrom the QEMU->Physical bridging. Well, without knowing the totality of your setup.
