Doubt anyone is still watching this thread, but in case someone searches for it in the future here's my update.
It works! I used the open source software package com0com to create a pair of virtual serial ports on my "non-remote" Windows 7 computer. Call them COM3 and COM4. Those ports are connected together in software by the driver so anything received on COM3 is transmitted to COM4 and vice versa. I then installed the companion software package hub4com. This is a very versatile piece of software. It allows you to, among other things, route traffic between a serial port and a TCP port.
I defined a "modem" in Windows 7 using the driver "Communications cable between two computers". This is a legacy driver that is not normally installed in Windows 7. The only way to install it is to go to the Device Manager, select any item on the list, then go to the Action menu and select Add Legacy Hardware->Select From List->Show All Devices, click on the (Standard Modem Types) category and it's the first item in that list. Told the modem setup to use COM4.
I configured COM3 to route traffic to/from the TCP port that I designated for my RUDICS account. I then configured Windows 7 to accept incoming dial-in connections using the modem defined above. To do this you need to open the Network and Sharing Center, go to Change Adapter Settings, press the Alt key to activate the menus, then under the File menu you'll find New Incoming Connection. I added a user account here and set a password but then unchecked the box that says "require all users to password protect files", or something like that. Not the most secure setup but the dial-in network doesn't have access to much on the computer.
So now COM3 is connected to the correct TCP port, COM4 is connected to COM3 in software, and Windows is listening for incoming connections on COM4.
The remote linux machine uses the standard pppd program to initiate the PPP connection over a serial port. The part that took the longest to figure out was the magic sequence of commands that need to be exchanged between the client and server before they begin exchanging PPP configuration packets. The answer is: The client machine needs to send the string CLIENTCLIENTCLIENT, then the server responds with CLIENTSERVER. Once that exchange takes place the PPP link is ready to be initiated.
The command I used on the linux side to initiate the link is:
Code:
pppd /dev/ttyX 19200 noauth defaultroute connect "/usr/sbin/chat -f /etc/ppp/windows.chat
That tells pppd to execute the contents of the chat script located in /etc/ppp/windows.chat before setting up the PPP link. The contents of that file are:
Code:
TIMEOUT 10
"" CLIENTCLIENTCLIENT
CLIENTSERVER ""
That's it in a (large, confusing) nutshell. I need to tweak the chat script some to include the modem dialing command and add in a longer timeout to allow for the satellite link to be established. I've been doing that manually so far. But it works, and I can now exchange TCP/IP traffic over the sat link without having to set up a new account just for that purpose.