Using the (X)Net TCP/IP Stack under Windows 9x/NT/ME/2000 1. Problem ---------- (X)Net has it's own TCP/IP stack, complete with ARP resolution, IP routing and TCP layers. It uses that stack to support the built-in TCP applications such as the Telnet Server, FTP server, SMTP Server, POP3 Server, etc. On the Linux setup (linuxnet) a SLIP connection has to be created with the Linux kernel TCP/IP stack; once proper routes are established on both sides both stacks could interact (i.e. Telnet from the Linux kernel into the Telnet server of (X)Net and viceversa. This arrangement, however, isn't possible to be implemented on the NT setup (NTNET) since a SLIP connection with the MS TCP/IP stack isn't possible. Thus, under Windows the TCP/IP stack of (X)Net is mostly isolated and the built-in applications could not be accessed (other than trivially from inside XNet itself). 2. Alternatives --------------- The problem itself lies in the radically different way the MS TCP/IP stack works compared with the Linux TCP/IP stack, so same solutions could not be applied. In order for this to be overcomed several solutions might be possible, many of them would require programming inside NTNET to be implemented, some of the solutions might be: a) To develop a Win Network Adapter, then TCP/IP frames heard over radio interfaces could be feed into the MS TCP/IP stack for it's processing. Applications inside XNet should then use WinSocks to operate over TCP/IP instead of the internal XNet TCP/IP stack (which would be of no use). In case IP routing is needed Windows has to be configured for that. b) To develop an NDIS driver which by-passing completely the MS TCP/IP stack could allow the XNet stack to co-exist with it (it would be the most accurate equivalent to the Linux solution). c) Use an external TCP/IP adapter and feed the results thru the currently supported XNet Interfaces. Obviously options (a) and (b) could not be implemented without modifications on (X)Net (NTNET). Option (c) could, however, be implemented with NTNET as it is. External TCP/IP Adapter Solution -------------------------------- I wrote an external "driver" to allow XNet to be run with (or on top, or under, you pick) the AGW Packet Engine by SV2AGW. AGWPE is a Layer 2 Manager capable to operate with an impressive range of hardware to produce AX.25, from TNCs, most types of well known special boards, some types of relatively unknown special boards, most cheap Baycom modems and even Soundcards. This is very interesting because spans the possibilities of NTNET to operate with hardware devices not natively supported by it. The principle that driver (named XGLUE) operates is rather simple; it sits in between of AGWPE and XNet. For AGWPE it behaves as a client application and for XNet looks as a remote AXUDP destination; frames heard by AGWPE are feed into XNet thru the appropriate AXUDP interface (one interface has to be defined per AGWPE port) with a small "massage" of the content while all frames sent by XNet are feed into AGWPE also with a minimal massage. The driver works transparently over any generic frame passed from one side to the other, and that includes TCP/IP over AX.25 frames. AGWPE also includes a TCP/IP Adaptor which plugs into the MS TCP/IP stack and feeds it with TCP/IP frames heard over radio ports (and generates them). This TCP/IP adaptor could then be used to plug XNet (NTNET) and to interact with the MS TCP/IP stack. High Level View of the Solution ------------------------------- Let's view how the XNet->MS TCP/IP works. XNet sends an AX.25 frame encapsulating a IP frame over some of the interfaces which are being served by XGlue. XGlue feeds AGWPE with them and being a TCP/IP frame feeds MS TCP/IP with that frame; based on the proper routing to be established the answer from the MS TCP/IP stack will be delivered to the AGWPE TCP/IP stack which in turn will "transmit" it thru the appropriate port, that frame been picked by XGlue and feed into XNet. Of course proper routing is essential, but that's is an implementation detail. Key here is that if the TCP/IP frame generated by XNet is feed into the AGWPE loopback port it's absolutely non differenced from any other TCP/IP frame generated by any other TCP/IP node over radio. Low Level Implementation Details -------------------------------- Let's assume the following configuration. AGW TCP/IP Adapter IP 44.153.48.3 NetMask 255.255.255.0 Gateway None AGW Ports Port 1 - Radio Port 145.15 Mhz 1K2 Port 2 - Radio Port 431.20 Mhz 9K6 Port 3 - Radio Port 145.03 Mhz 1K2 Port 4 - Loopback Port On AGW's TCP/IP Over Radio Setup - Enable TCPIP checked. - Default radio port -> Any radio port (Don't select ALL PORTS USED) - MyCall : LU7DID-5 (to be used as HW Address for ARP). - Pass All IP Traffic to MS TCPIP Stack -> UNCHECKED (!) - Allow Broadcast Messages -> CHECKED Setup Routes 44.153.48.32 -> Port 4 (point XNet's IP Address to LoopBack port) As it is obvious YOU MUST HAVE a LoopBack port defined!! XNet Configuration AUTOEXEC.NET att ip0 axudp 0 1 l93 d9300 127.0.0.1 att ip1 axudp 1 1 l94 d9400 127.0.0.1 att ip2 axudp 2 1 l95 d9500 127.0.0.1 att ip3 axudp 3 1 l96 d9600 127.0.0.1 ..... MY CALL LU7DID-4 .... IP.NET My IP 44.153.48.32 SubNet 44.153.48.32 ARP Port 1 arp add 44.153.48.3 AX25DG LU7DID-5 ipr add 44.153.48.3 AX25DG 44.153.48.3 XGLUE Configuration [XNET.PORT] p0=1,93,9300 p1=2,94,9400 p2=3,95,9500 p3=4,96,9600 Windows Configuration The insertion of the AGW Adapter automatically creates the routes for 44.153.48.* into the AGW TCP/IP Adapter An ARP routing (the program AGWARP could be used to ease the process) must be done executing in Windows (once at start-up) arp -s 44.153.48.33 98-AA-21-39-4E-38 (Please note the "pseudo-address" is LU7DID-4 spelled in the AX.25 shifted format). And that is pretty much it..... If you do on Windows PING -n 1 -w 20000 44.153.48.32 You'll receive the ICMP answer from XNet and viceversa doing on XNet ping 44.153.48.3 Will receive the ICMP answer from the AGW Adapter. You could then start a Telnet client on Windows and access the Telnet server of XNet or viceversa with any other service available on your windows machine. More complex Routing schemes... ------------------------------- Extensions on the above scheme could be made just adding the proper ARP and routing statements on both Windows and XNet. i.e. Suppose the Windows MS TCP/IP stack is also connected to a LAN with IP Addresses in the C-Class subnet 192.168.0.0/16 and also radio TCP/IP destinations on the A-Class subnet 44.0.0.0/8 are required to be accessed. Windows already knews how to route things with the C-Class subnet, so it's only a matter to teach to XNet that, and this is done with a statement like ipr add 192.168.0.0/16 AX25DG 44.153.48.3 Windows doesn't need to know about TCP/IP nodes reachable thru radio links, XNet could handle directly them, assume such a radio destination is LU9DGN-5 at 44.153.48.18, you could make XNet route things directly to it by means of arp add 44.153.48.18 ax25dg LU9dgn-5 ipr add 44.153.48.18 ax25dg 44.153.48.18 and so on.... Hope it helps. 73 de Pedro.