Mailing List Archived Message #19

From: "Lewis G Rosenthal" <> Full Headers
Undecoded message
Subject: Re: [Virtualized eCS]Accessing network shares from guest
Date: Mon, 14 Sep 2009 00:39:07 -0400
To: Virtualized eCS Users Mailing List <>

On 09/13/09 11:57 pm, Cliff Scott thus wrote :
** Reply to message from "Lewis G Rosenthal"
<> on Sun, 13 Sep 2009 19:20:58 -0400

Hi again...

On 09/13/09 06:57 pm, Cliff Scott thus wrote :
** Reply to message from Lewis G Rosenthal <> on
Sun, 13 Sep 2009 15:45:04 -0400

Hi, Cliff...

On 09/12/09 10:51 pm, Cliff Scott thus wrote :
** Reply to message from Lewis G Rosenthal <> on
Sat, 12 Sep 2009 20:17:06 -0400

Hi, Cliff...

On 09/12/09 08:59 am, Cliff Scott thus wrote :
Has anyone gotten printing to work running W2K as the guest?                              
Printing works under XP, but I'm printing to network printers and not locally. Thus, I would expect printing to work just as it would on bare metal.
I just had a thought regarding printing - You say that network printing works
for you. Are you printing via TCPIP?                
Yes, through Novell NetWare, but the printers are all talking IP.
My wife's windows machine on our local
network has the printer shared. I wonder if there is a way to connect to that
share. Do you think that should work? It says it can't see the peer network.
Guess I'll have to play with it and see what happens.

Yes, that's easy. You should be able to browse for a network printer from the Add Printer Wizard (I *hate* those dumb "wizard" things which M$ pushes). If that doesn't work, try entering the explicit share name, e.g., \\COMPUTER\PRINTER . You should be able to get to it. Make sure that the blasted Windows firewall on the host (the machine hosting the printer) is either off or allowing connections to its shares (no, the firewall isn't always modified upon enabling a shared resource...don't ask).
BTW, I thought of putting this on your Virtualization list, but there hasn't
been any traffic there so I figured no one would see it. Guess, if this
discussion goes any further we should to that.
Tried and no connection to the printer. The local peer network is on a
different net than the DHCP in VBox gives. Trying to give the VBox a fixed IP
doesn't work either. I'm using the Nat network access since the other driver
messes up networking on the host computer. The Vbox machine says it can't
access the peer network which I understand since Netbeui isn't loaded. Ideas?

Native NetBIOS is non-routable. Thus, it's not possible to have \\MYCOMPUTER on one LAN segment and \\YOURCOMPUTER on another and have them see each other. However, as long as both IP networks are routed, i.e., connected via a router, such that mycomputer.lan1 (or, can see (ping) yourcomputer.lan2 (, then accessing shares via IP is possible: \\\SHARENAME. Windows understands that the dotted notation implies IP and not NetBIOS, and *should* get the data from one place to the other.

You don't mean a physical router do you? Is there a way to software route the
two networks together since they are both on the same physical computer. I'm
afraid I'm not to savvy on the fine points of networking.
:-)  Your host machine is acting as a router in this case. Actually, OS/2 does an excellent job as a router, as do Linux and NetWare. Windows is the odd man out, though, probably due to its rather poor IP stack. But, no, I'm not talking about another piece of hardware.

Any time you have more than one logical network ( and, for example), and you need to traverse from one to the other, you need a router. Whether that's a physical box (like a LinkSys or D-Link broadband router) or simply two network interfaces in one computer, that connecting point is a router.

A bridge is a bit different. A bridge connects two physically disparate networks (wireless and wired, or coaxial and twisted pair or even fiber and twisted pair) to the same *logical* network. Thus, a "wireless broadband router" is really three things in one:

  1. A switch, as usually there are at least four wired LAN connections
     on it;
  2. A bridge, as the wireless access point must bridge the wireless
     network to the wired one; and
  3. A router, as it then routes traffic from your private LAN
     ( to the public internet (xx.xx.xx.xx)

In the case of VBox, and this situation in particular, when using host networking, we are bridging the virtual network adapter to your network via your physical adapter (via the TAP driver, under OS/2; it's different on some of the other platforms, and different with newer VBox builds). If using the "NAT" type connection, then VBox is actually routing and not bridging, as it provides a virtual DHCP server on one side (the virtual side) connecting to your physical interface on the other, and these must - by definition - be assigned to two separate, non-conflicting networks.

Sorry for the long-winded explanation; just trying to clarify a few points about the theory. :-)
I'm more curious, though, as to what your networking troubles are with the virtual machine. The only card I can't get to work with host networking is the wireless interface. Other than that, wired connections work fine, and my guest has its own virtual interface. It gets an address on the same subnet as my host machine.

How did you did you get "its own virtual interface"? DHCP gives an address
that is on a different subnet than my local network. I tried giving it a
fixed IP address on my subnet and lost internet connection and it didn't seem
to work anyway as far as accessing the peer network.

I am not using NAT networking. VBox is not assigning the address; my physical DHCP server is, which runs on another box (see Network_Settings_Host_IF.jpg, attached).

I am using a static IP on another VM, though running under a Windows host (hehehe, I virtualized my Citrix server; it's sort of like Prince Albert in a can...). The setup is exactly the same, except that the guest is set for static IP instead of DHCP.
Here's a snippet (well, greatly abbreviated, but only for clarity) from PROTOCOL.INI:




       tcpip_nif = tcpip.nif
       TAP_nif = tap.nif
       W14E4X167D_nif2 = W14E4X167D.nif


       DriverName = TCPIP$
       Bindings   = W8086X4224_nif,TAP_nif


       DriverName = TAP$
       HandleArps = 1

In CONFIG.SYS, I am loading the TAP driver, obviously.

A snippet from the xml defining my XP guest says:

        <Adapter slot="0" enabled="true" MACAddress="0800278739B6" cable="true" speed="0" type="Am79C973">
          <HostInterface TAPBridge="lan0" name="TAP$"/>
        <Adapter slot="1" enabled="false" MACAddress="0800271ECE0D" cable="true" speed="0" type="Am79C973">
        <Adapter slot="2" enabled="false" MACAddress="080027ECC3AD" cable="true" speed="0" type="Am79C973"/>
        <Adapter slot="3" enabled="false" MACAddress="080027F5508C" cable="true" speed="0" type="Am79C973"/>

The big difference is that I don't have the Tap driver loaded. I've tried,
albeit with the 1.56 version of Vbox, and it kills my normal networking and
makes the MPTS object very slow, to the point of not working at all. The only
way I could fix it was to boot to another system and the remove the driver
files so the next boot couldn't load the driver. This happened on RC7 as well
as RC4.

Hmmm... Well, none of the above will work without the TAP driver, as that's what's doing the bridging.

My TAP driver is:

1-07-08  6:21p       104,557      0 ----  prot.os2
I also have the NetBIOS loaded to get the peer network working between two
eCS computers. NetBIOS over TCPIP is loaded by default during install.

NBTCP *should* be able to route packets, as it piggy-backs on the TCP. However, it can be tricky, and is easily broken (at least in my experience). Thus, I try to stick to IP, and just use addresses or DNS names (it's handy to have your own DNS box on your network, or the ability to maintain only a handful of HOSTS files).
The only networking Vbox is using here is the NAT driver.

And that's why you're stuck on a different network.

NAT (Network Address Translation) is quite interesting, and the way in which so many of us connect to the outside world. Essentially, NAT gives you a many-to-one/one-to-many connection. You can have a dozen machines on your private network, but with the technology of NAT, they all look like one address coming out the other end of your router onto the internet (one public address). Unfortunately, this is not without consequences, as whoever is on the other end - if he must connect to you unsolicited, or rather, if he must initiate the connection - must either know that your are behind a NAT device or your NAT device must be set to handle such incoming requests and route them appropriately. This is why NAT makes such a good firewall, as it's harder to pour the water through the small end of the funnel. :-)

The NAT will forever keep you off your local LAN, so we need to figure out what's causing the network trouble when you bridge interfaces through the TAP driver.
Maybe I'm missing some key point that will make it work, but so far no go

See snippets of my Protocol.ini below:




   netbeui_nif = netbeui.nif
   tcpbeui_nif = tcpbeui.nif
   tcpip_nif = tcpip.nif
   B57_nif = B57.NIF


   DriverName = netbios$
   ADAPTER1 = netbeui$,1
   ADAPTER0 = tcpbeui$,0


   DriverName = netbeui$
   Bindings = ,B57_nif

   DriverName = tcpbeui$
   Bindings = B57_nif
   NODETYPE = "B-Node"
   SESSIONS = 130
   NCBS = 225
   NAMES = 21
   NAMECACHE = 1000
   PACKETS = 50


   DriverName = TCPIP$
   Bindings = B57_nif


   DriverName = B57$

All pretty standard stuff. All you need to add into that is the TAP stuff from my setup, above, add DEVICE={wherever}\PROT.OS2 in CONFIG.SYS, reboot, and then edit your guest networking to select Host. TAP should bind to your Broadcom card, LAN0, so your settings for the guest should look similar to the screenshot, attached (be sure to generate a MAC, if you don;t have one listed there already). As your VM is already configured for DHCP, you should be good to go. Considering what you've told me, however, you might see the problem before you get that far. I would suggest disconnecting your physical cable from the LAN prior to the reboot, even though you will be without an address upon coming back up. Assuming the system feel right (aside from not being able to connect to anything), you might snap in at that point.


Lewis G Rosenthal, CNA, CLP, CLE
Rosenthal & Rosenthal, LLC      
Need a managed Wi-Fi hotspot?      
Secure, stable, operating system


Subscribe: Feed, Digest, Index.
Mail to ListMaster