Re-visiting the SUN-2 emulator: Adding SLiRP!

While I’ve covered Brad Parker (lisper)’s ‘emulator-sun-2before, booting into SunOS isn’t anything that new.

However, with the latest updates, from github, adding in a prior botched attempt, and some messing around, and finally, I got it to ping at first, then it was a matter of where to place the ‘slirp tick’. I first though putting it on the interface poll was a good spot, but for some reason the machine causes a deadlock/stall on boot before the PROM can even initialize. I’m not sure why. Searching further I found a good timer portion and injected the code. And sure enough I was greeted with the login banner:

I’ve been able to paste in about 100kb of a uuencoded tar file, and it didn’t lock the VM, and I was able to uudecode it, and actually build the source (Infotaskforce ’87 if anyone cares). So I’m at the point I think it’s stable enough to shove into the world, although I guess until I revisit it again.

You can download it on sourceforge:

Web Rendering Proxy – Full Page Scrolling

(This is a guest post by Antoni Sawicki aka Tenox)

Due to a popular demand I have added an option of generating full page height screenshot and allowing client browser to do the scrolling.

This makes the browsing experience much smoother, you have resources for it. Beware, a full page screenshot can be several MB in size encoded as gif/png and much more as a decoded raw bitmap on the client. I managed to crash Mosaic and OmniWeb a few times. Fortunately typical Wikipedia page is under 1 MB so for most part is should be fine. To activate just put 0 in page Height.

I have drafted a pre-release on github for testing. Please let me know any feedback. I’m also thinking whether enable this by default, or not.

WRP 4.0 Preview

(This is a guest post from Antoni Sawicki aka Tenox)

Welcome a completely new and absolutely insane mode of Web Rendering Proxy. ISMAP on steroids!

While v3.0 was largely just a port from Python/Webkit to GoLang/Chromedp, the new version is a whole new game. Previously WRP worked by walking the DOM and making a clickable imagemap out of <A HREF> nodes. Version 4.0 works by using x,y coordinates obtained from ISMAP to perform a simulated mouse click in Chrome browser. This way you can click on any element of the page. From annoying cookie warnings, to various drop down menus and even play some online games. Also pagination has been replaced with a clickable scroll bar.

Enough talking, you can watch this video:

Or download the new version and try it yourself!

Please report bugs on Thank you!

WRP 3.0 Beta ready for testing

(This is a guest post from Antoni Sawicki aka Tenox)

I have released WRP 3.0 for testing. It’s currently a browser-in-browser server rather than a true proxy, but that’s in the works. Please try it out and let me know. Usage instructions are on the main github project page.

Today using trickery I was able to login to my reddit account from Mosaic:

Update: just added the missing image quantizer so that the color number input box actually does something useful. Now you can browse porn even with 16 colors:

WRP Runs on Windows

(This is a guest post by Antoni Sawicki aka Tenox)

Thats right, the new beta version of Web Rendering Proxy runs natively on Windows. Single EXE, no libraries or dependencies required. Only Chrome Browser.

I took a Internet Explorer 1.5 for a spin today while WRP was running on my Windows 10 PC. Worked just fine.

I have added Prev/Next buttons so that you can easily “scroll” through long pages.

ISMAP support has been added, proof:

You can download a preview build on github.

Web Rendering Proxy – Overdue Status Update

(This is a guest post from Antoni Sawicki aka Tenox)

There hasn’t been a major update to WRP (Web Rendering Proxy) in 5 years or so. Some new features have been added thanks to efforts of Claunia but the whole project was mostly impeded with mass migration of the whole Internet to SSL/TLS/https. It does semi work somehow thanks to sslstrip but the whole stack is an unmaintainable pile of crap which I’m not going to update any more.

A new rewrite from scratch is well under way. This time written in GoLang and using Chrome DevTools Protocol. Things should be much more stable and future proof.

Far from complete but I have a fully functional prototype now working in just under 100 lines of code:

UPDATE 1: You can play with it if you want. Please do not submit any bug reports just yet, as this is just a development version. Note that WRP is currently not a true HTTP proxy but rather browser-in-browser. Proxy may be supported later.

UPDATE 2: As of today online setting of size, scaling and scrolling is supported. I’m specifically happy about the scrolling feature albeit it probably needs a better user input, like prev/next page.

Windows version still doesn’t work due to an upstream bug, which is probably easy to fix.

ISMAP is currently in development.

Added UDP to Qemu0.90

Yes, I know it’s kinda pointless as it’s horribly out of date, but I’m still having fun. Anyways now it’ll integrate with dynamips!

So yeah, in this example, instead of the usual “-net user” and the built in SLiRP stack, this uses UDP to talk to a stand-alone SLiRP stack. This will let you plug your Qemu into virtual Ethernet switches/hubs and interfaces of virtual routers. Even mixing and matching connections to different emulators that use UDP to exchange packets.

In this case I have a VMDK loaded with a NE2K-PCI driver, and QuakeWorld for MS-DOS. I also made the MPU401 external although it’s hanging on a secondary flag…

qemu.exe -L pc-bios -m 64 -soundhw sb16,adlib -mpu401 xx -net nic,model=ne2k_pci -net socket,udp=,remote= -hda qworld.vmdk

This has the Qemu instance listen on UDP port 4000, and connect to the same physical host on port 4001.

The recipical for the SLiRP stack from my bashed Dynamips is:

slirp_rdr.exe 4001 4000

Which in this case listens on port 4001, and connects back on port 4000.

Hopefully it makes some sense to someone.

Download it, if you want!

Download Qemu090b

Virtual Xenix & the internet pt 2

So retrohun is doing their blog thing on github of all things, and the latest entry, is of course Xenix tales. As mentioned in comments on this blog & other places they found another driver for Xenix TCP/IP!

Going back years ago, the tiny NIC driver support for the elderly Microsoft/SCO Xenix 386 v2 included 3COMA/B/C and SLIP. However it’s been recently unearthed that D-Link had drivers for their DE-100 & DE-200 models, and as it happens the DE-200 is a NE-2000 compatible card!

That means that Qemu can install/run Xenix, and it can get onto the internet* (there is a catch, there is always a catch).

You can download the driver either from github or my password protected mirror. Simply untar the floppy under Xenix (tar -xvf /dev/fd0) and do the install via ‘mkdev dlnk’

Setting up the driver is… tedious. Much like the system itself. I found Qemu 0.90 works great, and is crazy fast (in part to GCC 3) even though Qemu 0.9’s floppy emulation isn’t good enough to install or read disks. With all the updates to Qemu 3.1 use that, it’ll read the disks, and allow for networking.

To give some idea of speed I ran the age old Dhrystone test, compiled by GCC 1.37.1 and scored the following:

Dhrystone(1.1) time for 5000000 passes = 8
This machine benchmarks at 625000 dhrystones/second

When compared to the SGI Indy’s 133Mhz R4600SC score of 194,000 @ 50000 loops that makes my Xeon W3565 322 times faster, under Qemu 0.90! And that’s under Windows!

Setting up the commandline/launching is pretty much this:

qemu.exe -L pc-bios -m 16 -net nic,model=ne2k_isa -net user -redir tcp:42323::23 -hda ..\xenix.vmdk
added SLIRP
adding a [GenuineIntelC] family 5 model 4 stepping 3 CPU
added 16 megabytes of RAM
trying to load video rom pc-bios/vgabios-cirrus.bin
added parallel port 0x378 7
added NE2000(isa) 0x320 10
pci_piix3_ide_init PIIX3 IDE
ide_init2 [0] s->cylinders 203 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
ide_init2 [0] s->cylinders 2 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
added PS/2 keyboard
added PS/2 mouse
added Floppy Controller 0x3f0 irq 6 dma 2
Bus 0, device 0, function 0:
Host bridge: PCI device 8086:1237
Bus 0, device 1, function 0:
ISA bridge: PCI device 8086:7000
Bus 0, device 1, function 1:
IDE controller: PCI device 8086:7010
BAR4: I/O at 0xffffffff [0x000e].
Bus 0, device 1, function 3:
Class 0680: PCI device 8086:7113
IRQ 0.
Bus 0, device 2, function 0:
VGA controller: PCI device 1013:00b8
BAR0: 32 bit memory at 0xffffffff [0x01fffffe].
BAR1: 32 bit memory at 0xffffffff [0x00000ffe].

In the file /etc/tcp the default installation does a terrible job of setting up the NIC. I changed the ifconfig line to this:

ifconfig dlink0 -trailers broadcast netmask

Which at least brings it up a bit better. I added in a gratuitous ping also in the startup script to build the arp for the gateway.

ping 32 1

Which brings us to the next point, the routing command is broken after loading the D-Link driver. I tried all the available TCP/IP drivers for Xenix (1.1.3.f 1.2.0e).

# route add default 1
add net default: gateway flags 0x3: No such device or address

So no dice there. And yes, for SLIP/no interfaces the route command works as expected, just not with the DLINK driver.

However local connections from the host machine do work, so yes, you can telnet into the VM!

Welcome to 1990!

This makes using Xenix far more usable say for managing files, control/compiling etc.

For you die hard IRC fans, all is not lost, you can simply run a local proxy (See: Teaching an old IRC dog some new tricks) on your host machine, and point the irc client to

IRCII on Xenix/Qemu

So there you go, all 20 Xenix fans out there! Not only a way to get back online, but to do it in SPEED!

Thanks to Mark for pointing out that there has been tremendous progress with version 3.1 of Qemu, and it’s TCG user speed is up to the 0.90 levels of speed (at least with dhrystone/Xenix), and it just takes a little (lot) of massaging to get up and running with Xenix with the right flags:

qemu-system-i386.exe -net none -L . -m 16 -hda xenix.vmdk -device ne2k_isa,mac=00:2e:3c:92:11:01,netdev=lan,irq=10,iobase=0x320 -netdev user,id=lan,hostfwd=tcp::42323-:23

This is based off my old post, Running Netware 3.12 on Qemu / KVM 2.8.0 although with a few more flags to assert the user mode tcp redirect.

I’m using Stefan Weil’s build of the x64 native i386 Qemu.

What is a VLAN (part 6)

WIth Windows NT installed, it’s time to look at it on the network side.

The killer feature of GNS3 is that we can inspect traffic everywhere we draw a connection.  So simply right click on the connection from the Qemu VM to the Hub, and you can start a packet capture.

GNS3 will then prompt what the link type media is, in this case it’s Ethernet, and what the link name is.  After hitting OK, it’ll then start WireShark on the virtual link.

And in no time we can see the NT machine broadcasting on the network.  OK everything is looking fine.

As you can see our packet is an 802.3 Ethernet packet, with a LLC header, and a NetBIOS packet.  This is what we are expecting as the connection to the hub is ‘raw’.

Now that we have verified that we can connect to the network and capture, we can close Wireshark.

We then should right click on the link, and tell it to stop capturing.

OK, now what about VLANs?  Let’s start with a simple lab.  We are going to get rid of the Hub for now, and add in two switches.  One switch will be our ‘core’ switch, the other will be our access switch.  We will then put our PC onto the access switch, and then setup an 802.1q trunk between the two switches, and then observer the NT broadcase traffic in the trunk so we can see the VLAN tag in action.

Right click on the hub, and delete it.

Yes we do want to delete it

Drag out a switch, and then right click and rename it to core.

Now we are going to configure the core switch.

Right click on the core switch, and choose configure.

By default every port is on VLAN 1, and is a port type of ‘access’.  You would typically connect end devices like servers to access ports.  I probably should have deleted them all, but since we are going from my session I deleted ports 0 & 1.

Now I’m going to add port 0 with a native VLAN of 1, but a type of dot1q. This port will be used to connect to the access switch.

And then port 1 will be an access port on VLAN 2.  Hit OK and it’ll close the window.

And we are good to go.

*HOWEVER* this is a source of some confusion at least for me.  Go back and right click on the core switch, and look at the ports.  GNS3 for me changed the port numbers so it did not preserve my port choices, however there is still an access port on VLAN 2, and an 802.1q port.

As you can see on the core switch, port 6 is now the dot1q trunk port, and port 7 is the VLAN 2 access port.

Add in a second switch, and change it’s hostname to access

Now let’s configure this switch the same way we configured the core.

Same steps, in that we delete some ports first

Add in an access port for the Qemu PC on VLAN 2

And then add in a port with a type of dot1q, and a native VLAN of VLAN 1.

And our access switch is configured, so you can hit OK.

As you can see GNS3 has changed our trunk port to port 7, and our Qemu access port is now port 6.  This should be a bug…

So with this confusion in mind we connect port 7 of the access switch to port 6 of the core switch, by selecting the cable tool, and the appropriate ports.

And we will now have connected the two switches.  Now to connect the Qemu PC.

Again using the cable tool, it’s the only port on the Qemu VM

And to port 6 of the access switch.

Now we can start a capture on the connection between the two switches.  Right click on the link and start the capture.  It’ll be the same as last time, the default options are fine, and it’ll start Wireshark.

Now when the NT server sends a packet on the network, the access port is in VLAN 2.  Broadcast packets will be sent to all the other member ports on the network, in this case we do have an access port on the core switch in VLAN 2.  But while the packet is going between switches it needs a way to identify what VLAN the traffic came from, so as you can see from the capture There is now another protocol layer going on.  In this case we have an Ethernet II packet, but now the next layer is the 802.1Q frame, that gives the priority level, along with the VLAN number.  Then the NetBIOS packet is under that.  As you can see it is *NOT* TCP/IP only, but rather any Ethernet frame can be encapsulated in a VLAN, and then across 802.1q links they can be transmitted by encapsulating the packet in an 802.1q header to keep track of which VLAN the traffic was bound to.

But how about data egressing on the other side?

Let’s take a HUB and drag it out to the infrastructure pane.

Now we are going to connect that hub on any port to the core switch.

In this case, port 7 was our access port on VLAN 2.

And now we can start a capture on the connection from the core switch to the hub.

And as you can see the NetBIOS arrives on the other side without any 802.1q header, and any machine on the other side wouldn’t even know it’s been through an 802.1q trunk, or that it’s even on a VLAN.

So why use VLANs?  Isn’t it easy enough to add infrastructure for every network as needed?  Sure you *could* but it becomes very costly.  And you end up supporting quite a number of devices.  Then it never fails that you have one user or device in part of the network that doesn’t warrent a good network connection, but when it breaks, like it always does they generate a lot of heat about it.  Just as LAN segmentation is a popular way corporations restrict internal access as they can have firewalls to control traffic entering and leaving each network.  But doing this the old way means that every tiny move add and change will require someone to do something physically making it very expensive to maintain.  VLANS solve these issues by letting you deploy good infrastructure everywhere that everyone can benefit from as they can share the hardware, however with things like QOS, you can ensure that they do not stomp on each-other for the uplinks, but they are isolated in their own VLANs.

And what is the big deal with 802.1q?  Well going back to our VLANs vs using physical switches, if we had 1,000 VLANS on a switch, and we wanted to connect 300 of those VLANs to a single server without 802.1q you would need 300 network cards.  Just as adding another switch would require you to use 1,000 ports to carry all those VLANs from one switch to another.  By using 802.1q to tag each VLAN through the trunk port it lets you use a single physical connection, and appear on each network.

Hopefully this is enough to get you started, both in terms of how to set things up, but what to look for.