[nos-bbs] XP + SwsVpkt

[Gene Mayler]

Hi Barry,

As usual, you have given what seems to be a very thorough
answer.  I haven't looked at the source code yet, so I can't
tell you whether it "makes sense" yet.  I'll let you know if it
doesn't.

Thanks for the time you've spent on this.

73, Gene - K8EE

----- Original Message ----- 
From: "Barry" <k2mf at ptd.net>
To: "TAPR xNOS Mailing List" <nos-bbs at lists.tapr.org>
Sent: Monday, August 04, 2008 10:09 AM
Subject: Re: [nos-bbs] XP + SwsVpkt


> 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
> 
> 
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs