The client needs to access the internet!

But let’s not give them access to everything.

This is a common scenario I see, where someone needs to get updates to some magical software package on the internet.  Great.  And people just give them access to ANY site, which ends up being not only the internet (the intended destination) but the rest of their internal network.  Granted a good defense in the SDN world is inbound rules as well for each VM, but everything is never 100%.

RFC1918 defines our friends, the private address ranges:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

However the solution to this fun filled problem is to grant them HTTP/HTTPS access to the inverse of this.  Enter the netmask command.  You can give it a range, and it’ll lay out what networks to you need to add like this:
     netmask -c 0.0.0.0:9.255.255.255
     0.0.0.0/5
     8.0.0.0/7

Now I can exclude everything right up until 10.0.0.0/8 !

It’s quite the handy tool, but I didn’t see any Windows version.  So a few minutes with MinGW, and dealing with it’s weird Makefile’s way of linking things, and here you go!

This way you can permit internet access, not give them inside, access and still have a global DENY actually work.

YAY.

And if anyone is interested here are the networks:

     0.0.0.0/5
     8.0.0.0/7
    11.0.0.0/8
    12.0.0.0/6
    16.0.0.0/4
    32.0.0.0/3
    64.0.0.0/2
   128.0.0.0/3
   160.0.0.0/5
   168.0.0.0/6
  172.0.0.0/12 
 172.32.0.0/11
 172.64.0.0/10
 172.128.0.0/9
   173.0.0.0/8
   174.0.0.0/7
   176.0.0.0/4
   192.0.0.0/9
192.128.0.0/11
192.160.0.0/13
192.169.0.0/16
192.170.0.0/15
192.172.0.0/14
192.176.0.0/12
192.192.0.0/10
   193.0.0.0/8
   194.0.0.0/7
   196.0.0.0/6
   200.0.0.0/5
   208.0.0.0/4

Yes, I know it’s a LOT of typing.

One million packets served!

one million ICMP packets!

Success rate is 100 percent (1000000/1000000)!

So over in my work on porting Dynamips to MinGW, I’ve created a version of SLiRP that sends and receives data over UDP.  In retrospect, something I should have done a long time ago, as it makes troubleshooting it easier as now if it were to crash it’s a stand alone program, so it won’t crash the emulator.

The good news is that I’ve been able to copy files into the virtual router using HTTP.  I’ve even been able to access my OS/2 machine over FTP and load a file!

R1#copy ftp://10.12.0.14/README disk0:
Destination filename [README]?
Accessing ftp://10.12.0.14/README…
Loading README !
[OK – 76743/4096 bytes]

76743 bytes copied in 8.740 secs (8781 bytes/sec)

R1#dir disk0:README
Directory of disk0:/README

12 -rw- 76743 Sep 18 2015 09:01:08 +00:00 README

66875392 bytes total (41652224 bytes free)

Which is very cool!

Part of the ‘trick’ is that you should set your time out to be as long as possible to send a million packets.  I just set the maximum values.

line con 0

exec-timeout 35791 23
stopbits 1

line aux 0

stopbits 1

line vty 0 4

exec-timeout 35791 0
timeout login response 300
password cisco
login

!
end

In addition, a 7200 with idle performs MUCH better than a 1700 without idle.  There is something up with ptask, and only dispatching packets every so often.  I’m guessing it’s done that way for a reason.

Also one other cool IOS trick I learned today is that you can redirect to a file resource! Say you want that ‘show tech-support’ as a file on the disk? No problem!

show tech-support | redirect disk0:tech.txt

And of course the newer versions of IOS have a ‘do’ command that you can run from config mode to execute user commands.

R1(config)#do who
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
2 vty 0 idle 15:24:11 10.0.2.2
3 vty 1 idle 14:59:56 10.0.2.2
4 vty 2 idle 13:43:44 10.0.2.2
5 vty 3 idle 11:23:44 10.0.2.2

 Take that Junos!

For anyone interested, the binary is included in the latest binary snapshot, and using it is pretty simple:

slirp_rdr.exe 20001 127.0.0.1 20000

This will listen on port 20001, and send traffic to 127.0.0.1 on port 20000.  Easy right?

Manually interfacing from the hypervisor can be the ‘fun’ part.  I haven’t tested with any of the tools, as I don’t know if they will let you leave something ‘listening’ that isn’t connected. For my tests I end up building something with their UI, then loading up my hypervisor that logs, and seeing what it is actually doing so I can inject stuff like this:

nio create_udp nio_udp99 20000 127.0.0.1 20001
ethsw add_nio S1 nio_udp99
ethsw set_access_port S1 nio_udp99 1

This creates a udp nio, and attaches it onto the virtual etherswitch S1, and puts it on VLAN 1.  As you can see it listens on UDP port 20000, which is where slirp_rdr is setup to send it’s data to, and it’ll send to 20001 where slirp_rdr is listening.

I’ve hard coded port 42323 to telnet into 10.0.2.15.  As always SLiRP is hard coded to have the following ip address schema:

Gateway 10.0.2.2
DNS 10.0.2.3
Netmask 255.255.255.0

Be sure to set your router to 10.0.2.15/24 for this to work, and add 10.0.2.2 as your default gateway.

The ONLY address that will respond to ping is 10.0.2.2 .  This is just the way SLiRP is.  HTTP and TCP based stuff works best, things like PPTP will not.  It’s really hit and miss, but the cool thing is that it doesn’t require any device drivers, it’s all user mode code!

Dynamips on MinGW

It’s always bugged me that the only way to build Dynamips for Windows was with Cygwin.

Well fear no more, I’ve mashed an old version (I would have tried newer, but of course Cmake fails spectacularly and with zero help as always!) and not only does it compile, but it can boot a 7200 version of IOS.

Dynamips on MinGW

Dynamips on MinGW

JIT is broken.  You have to telnet into the console.  And the console is a little wonkey as I’m sure it’s doing a lot more UNIX translation vs being a Win32 program but it does work enough to login, save the config, and reload.

But it’ll crash on reload.

I’m sure it’s full of bugs actually.

https://sourceforge.net/projects/dynamips-mingw/

I started with Dynamips 0.2.8-RC7-community and started commenting out stuff to get it to compile.  Luckily I found this ezwinports that includes mairix that includes some memory mapping functions, namely mmap and munmap ported to Win32 in an early glibc port. While I was trying to integrate libuuid, I got this fun error:

mingw “error: conflicting types” “UUID”

MinGW includes UUID support, since it’s a Microsoft thing.  Unfortunately libuuid doesn’t include unique names,  so I had to rename uuid_t to uu_uuid_t

//typedef unsigned char uuid_t[16];
typedef unsigned char uu_uuid_t[16];

in the uuid.h header file, along with all instances in Dynamips.

I also borrowed sendmsg/recvmsg along with the msg structures from VLC.  inetaton.c from WSHelper, and finally telnet.h from NetBSD.

After that it was a matter of making sure Winsock starts up, and fixing some linking breakage.

For those who want to try, the binary package is here.  I’ll have to setup git on this machine and upload all the changes.  It shouldn’t require any DLL’s, although I haven’t looked at the pcap stuff, as I mentioned it’s largely untested, so I have no idea if any of it works other than the telnet console.

PCem networking update to build 335

Well after extensive testing of various CFLAGS settings it turns out that “-O2 -flto -ffast-math -mfpmath=387” gives the best overall settings for PCem.

So yeah me and leileilol went through a dozen+ iterations to arrive at this fun conclusion.

So I’ve only included 2 executables, a debug and the -O2 build.

You can download it here.

I haven’t made any changes to the networking code, and even with a LOT of fighting got OS/2 Warp 3.0 Connect to install.

Gopher

Gopher

Plus I fixed my gopher!

**EDIT

I made a mistake, and built both exe’s as debug.  I updated the archive, those who downloaded it, will want to do so again!

PCem networking update to build 334

You can download the build here: PCem-build-334-pcap-slirp.7z

This includes more different core binaries, and mostly fixes the NE2000 to no longer panic and fault out when something dumb tries to probe it, by writing the wrong values in the wrong places.

For the curious build 334 is right here.  We didn’t make the feature cut for version 10, so hopefully it’ll make 11.  I’ll provide an unofficial build once v10 is announced, along with hopefully better networking back end modules, expanding things from pcap & SLiRP.

More progress on PCem and networking

SLiRP tcp redirects now working

SLiRP tcp redirects now working

PCem is different from other emulators in that when it starts up, reboots it’ll tear itself apart, and re-kick all the components.  Normally other emulators do this once, and as a result I never noticed that slirp_exit doesn’t actually purge the socket state.  And calling the socket teardown call causes a mbuf explosion in the code.  Sadly GDB is pretty useless trying to debug it, since it’s claiming all the structure members don’t exist.  Very strange.

Luckily I could duplicate the debug feature to go though current socket redirects, and close the sockets on the Windows side with a simple closesocket.

In this version I’ve setup the following TCP port redirects:

ExternalPORT    Internal Port
42322                 22
42323                 23
42380                 80
42443                 443

I still haven’t messed with the rc file, so there is no GUI config, instead you have to do it in the text files.  I have some notes on the whole thing on the pcem forum here.

Download the executables and source here:

http://vpsland.superglobalmegacorp.com/install/pcem/PCem-0657320820ab-pcap-slirp.7z

And for those interested, the diff against mainline 328 is here.

Adding SLiRP to PCem

So PCem is an incredible emulator for the IBM PC platform.  One thing that has been missing, and really missed has been networking.  So a while ago, SA1988 came up with a patch that incorporated the BOCHS ne2k.cc into PCem.

So as requested, I took the copy of SLiRP I’ve used in SIMH, Cockatrice and Previous, and got it working in PCem.

Telnet

Telnet from MS-DOS

This has to be one of the easier ports since PCem doesn’t use threads.  But yes, it appears to work, although I haven’t done any major testing.

For those who want to experiment, here is a binary/source blob of the project.  Right now we are just past the OMG it compiled phase to OMG it SENT and RECEIVED data phase.

If anyone wants to play, the NE2000 is set to 0x300 IRQ 10.

And you need to manually add the following to your pcem.cfg file:

netinterface = 1
netcard = 1

And you should be good to go. I think.

QuakeWorld

QuakeWorld

And yes, it’ll run QuakeWorld!

Random links

No I’m not dead, just been busy.

But here is some interesting things I’ve seen the last while:

Infer: static code analysis from facebook of all people.  Supports C, Objective-C and Java.

Dr Jack Whitham’s blog, with some interesting stuff related to compiler optimizations and how they alter floating point results, along with ‘bug 323‘, and some DOOM fun!  Plus he has his updated source repositories online here.

And finally, Building A 10BASE5 “Thick ethernet” network.  A fun look at the first gen ethernet cabling on ‘slightly’ newer machines.

Porting Quake II to MS-DOS pt2

Continuing in this series on porting Quake II to MS-DOS, we get to touch some of the fun stuff.  The first big ‘fun’ thing is networking.

Now in my prior work with the MS-DOS version of Quake, I had used the WATTCP library to bring networking to the otherwise Windows/UNIX specific fun of network deathmatch back to MS-DOS.  Quake by default had support for the Beame & Whiteside’s TCP/IP stack which for all intents and purposes has vanished from the face of the Earth (does anyone have a copy?!).  So at the time, I thought it’d be cool to try to interface WATTCP with Quake, and it worked on the first attempt as WATTCP is a very competent TCP/IP stack.

So I took the Linux networking file net_udp, and compiled it, and I got an executable!

When it comes to testing WATTCP though, I prefer to use Qemu instead of DOSBox as it can not only emulate various network cards to which I can find packet drivers (yes even the evil PCI NE2000!) but it has a built in SLiRP network stack that let’s me NAT on my desktop without any crazy network configs.

And for the sake of testing, I setup a ‘null’ text mode server, figured out some flags, and I was able to connect!

Quake II for MS-DOS running on Qemu connected to a dedicated OS X server.

Quake II for MS-DOS running on Qemu connected to a dedicated OS X server.

Very exciting stuff indeed!

Now for some interesting stuff.  First I noticed that MS-DOS 5.00 with himem.sys is almost unplayable because it is so slow.  MS-DOS 4.01 without himem.sys is actually faster.  No, I’m not kidding.

Next is that some levels LOVE to gobble up RAM.  Maps like city1 will need at least 192MB of ram.  I haven’t even tried playing with the virtual memory of DJGPP, and I really don’t want to.  And let’s face if, if you even try to load Quake II on a MS-DOS machine, it better be a ‘big’ one.  This means you should be using the ‘dos’ from Windows 98, or perhaps FreeDOS, although I haven’t tested that at all.

So far from our limited testing the networking seems to be pretty good.   And at least that is one function we didn’t have to really pour a lot of effort into.  Although the payoff of being able to connect to servers on the LAN and even the internet is a good thing.

Continued in pt3, pt4, and part 5.