[nos-bbs] XP + SwsVpkt

[Barry]

On Sat, 2 Aug 2008 10:40:43 -0400, my old friend Gene, K8EE
wrote:

> I'm trying to run JNOS2.0F on an a machine with XP PRO.  I'm
> trying use SwsVpkt driver so that I can have JNOS talk to the
> Internet.  Without gettimg into detail, things really get
> mucked up.

Yes they do.  The problem occurs when SwsVpkt is used to hook
to the same ethernet interface that is also being used by the
Windows TCP/IP stack.  Because the same MAC address is being
used for both drivers, JNOS will hear packets which are
addressed to XP and will try and route them.  You get multiple
echos of the same packet on your LAN wire that way and it
results in a pretty bad mess.

Interestingly, JNOS may be modified set a new MAC address in
the packet driver for those packet drivers that support the
SET_ADDRESS function.  Most of the older DOS packet drivers
support this function.  But of course (and very unfortunately),
SwsVpkt does not support the SET_ADDRESS function and in email
exchanges I had with the author of SwsVpkt before he stopped
supporting it, he indicated that he had never seen a need for
it.  Apparently, SwsVpkt was originally created to emulate an
IPX/SPX type of packet driver for DOS applications under
Windows and it was never intended to have TCP/IP running on
top of it.  Who besides us hams knew about a decent DOS
TCP/IP stack?  Oh well, oh well for us.

> Back in September of 2006 Barry, K2MF, discussed the problems
> with using SwsVpkt driver.  He made reference to patches that
> can be made to JNOS to get JNOS and XP to, in his words,
> "play nicely."  Can Barry or anyone else point me to where I
> can find these patches?

The first (and easiest) "patch" which requires no changes to
JNOS whatsoever is to simply install an second ethernet
interface in your computer along with the necessary hardware
driver to have Windows recognize it.  VE2PKT experimented with
this technique and has apparently perfected it.  After adding
the second ethernet interface to the Windows machine, you then
UNinstall the Windows TCP/IP driver from it and install the
SwsVpkt driver for it.  This gives SwsVpkt (and the JNOS IP
stack running on top of it) its own ethernet interface and MAC
address to use.  The hosting Windows O/S will have full IP
connectivity with JNOS through the LAN (and vice versa).

If maintaining access to services in the hosting Windows O/S
is very important to you, then your only solution is to add a
second ethernet interface.  In my particular LAN configurations,
I use SwsVpkt/NOS in multiple instances and it is precisely
because they both sit on the same physical computer that I do
NOT need actually need any IP connectivity between them and
their hosting Windows O/Ss.  I mainly use NOS as a "backdoor"
for me to get into the Windows hard disks.

The bottom line is, unless there is an application in the
hosting Windows O/S to which you need IP access for some
specific reason through the SwsVpkt IP stack (i.e. JNOS)
then you don't absolutely need to install the second
ethernet interface.  Since I personally have no such
application to which I need access through NOS it is not
an issue for me.  If it were, then I'd have no choice but
to bite the bullet and install a second ethernet interface
in the hosting Windows machine.

Make this decision *first*.  If you have decided to add a
second ethernet interface, then you can stop reading here.

But if you have decided to use only a single ethernet
interface for both the Windows O/S and SwsVpkt then it will
be necessary to apply patches to the JNOS source code in
order to stop it from hearing and trying to route XP's
packets.  HOWEVER, (and this is the very important caveat
to understand), these patches will, by definition, prevent
any IP connectivity whatsoever between the hosting Windows
O/S and the IP stack running in the SwsVpkt VDM (i.e. JNOS).
As long as you are using a single ethernet interface, you
are limited to this kind of scenario and must live with this
very important limitation.

The code to make these patches is actually relatively trivial
and I thought that at one time Maiko may have put these
additions into the JNOS code.  If not, I can make them
available to anyone who wants them with the understanding
that they were done for another NOS and that with a small
bit of editing, they can be made specific for JNOS.

To make the JNOS level 2 and ARP drivers play "nicely" with
a hosting Windows O/S that is using the same ethernet
interface and MAC address, here is the algorithmic summary
of what patches need to be made in JNOS:

1) In the ethernet receive and send subfunctions (PKTDRVR.C)
   you need to drop incoming IP packets if the source
   hardware address belongs to our interface and outgoing
   IP packets if the destination hardware address belongs
   to our interface, respectively, because either condition
   indicates that our hardware address is being shared by
   two TCP/IP stacks and both stacks are hearing packets for
   each other.  This prevents JNOS from trying to IP route
   packets for the Windows TCP/IP stack.

2) You need to add a 'struct iface *' calling argument to
   all of the *_dump() functions (TRACE.C) in the Iftypes
   list (IFACE.C) if ETHER is #defined so that dump()
   (TRACE.C) can set a flag if a packet is incoming from
   an ethernet interface and then ether_dump() can use
   that flag as a signal to determine if the source
   hardware address belongs to our interface which would
   indicate that our hardware address is being shared by
   two TCP/IP stacks and we want NOS to bypass checksum
   calculations on the packets we are hearing from the
   Windows TCP/IP stack.

3) You need to modify arp_recv() (ARP.C) to drop incoming
   ARP packets if the source hardware and IP addresses
   belong to our interface because this means that our
   hardware address is being shared by two TCP/IP stacks
   and both stacks are sending ARP replies for the same
   hardware address.  This prevents NOS from hearing its
   own ARP requests and replies and putting an entry for
   itself in its own ARP list.  While the first modifi-
   cations above will prevent NOS from talking directly
   at the IP layer with the Windows TCP/IP stack, we
   *do* permit an ARP entry for the Windows TCP/IP stack
   in NOS's ARP list so that it won't issue an ICMP Host
   Unreachable message when it cannot resolve the
   hardware address of the Windows TCP/IP stack itself
   (something that the NOS I use is programmed to do).

Does this make sense?

--
Barry
k2mf at ptd.net