This post got longer than I anticipated since I'm trying to give as much context to my question as possible. Hopefully the length won't dissuade too many people from reading. I'm looking for a way to create a PPP connection between a linux PC and a Windows 7 PC but the connection between them is unusual. I'm hoping folks here can tell me if my idea will work before I dive in and maybe offer some pointers.

Background: The linux box lives in a remote location. Remote as in off the grid, battery/solar powered. It logs data autonomously, then calls home periodically via satellite. The satellite connection uses RUDICS over the Iridium network via a serial modem. For those unfamiliar with RUDICS, it generates a point-to-point link between the remote device and a computer connected to the internet. The RUDICS gateway handles routing of the data between the modem connected to the remote device and an IP address and port number that you specify when setting up the service. The linux box sends standard AT commands to the Iridium modem to dial the number of the gateway. I have a custom application running on my Windows box that listens for incoming connections on the proper TCP port. When the connection is established it becomes a transparent data link. Any data sent to the modem by the linux box is received at the TCP port on the Windows box and any data sent to the TCP port on the Windows box appears at the serial port of the linux box. There's no networking protocol involved, it acts just like a very slow serial cable.

I wrote my own simple messaging protocol to send data packets back and forth across this link. It works, but is clumsy and not very robust. I'd like to modify the software to use a more robust protocol. The one I'm looking at currently is called ZeroMQ. It looks like it's well suited for my application. The only trouble is that it requires TCP networking to function.

Currently there's no networking layer involved in my communications link. The obvious way to add TCP/IP over a serial connection is to use PPP. That's easy enough to implement on the linux box but the problem is that our Iridium service doesn't include PPP functionality, only the RUDICS functionality I described above. We could open up a new Iridium account that does give us PPP functionality, but there's a $2500 setup fee and a $750/yr maintenance fee. I'd like to avoid those costs but still create a PPP connection between the two computers.

My current idea is to keep the RUDICS connection the same as it is currently, install a piece of software on the Windows box that will route data from the specified TCP port to a serial port, then connect that serial port to a 2nd serial port that will be configured as a remote access port. The pppd service on the linux machine will handle dialing of the modem and attempt to initiate the PPP link. That data will get routed to the TCP port of the Windows box, then redirected out one serial port and into another one, arriving at the Windows remote access service which should then negotiate the PPP link with the linux box.

Make sense? Any big flaws in this scheme that I'm missing? The serial ports can be virtual ports connected to each other in software, they don't need to be physical ports. I haven't looked for an application to do the redirecting of data between the TCP port and the serial port yet. There's probably something out there that will do this (any suggestions welcome). If not that's easy enough for me to create. What I'm not so sure about is how difficult it will be to configure Windows 7 to act as a PPP server, and whether there's anything special about the PPP connection that would prevent it from working with the RUDICS layer in between. There's an article on Microsoft's website that talks about accepting incoming connections:

https://technet.microsoft.com/en-us/...=ws.10%29.aspx

It doesn't specifically say that it uses PPP but I'm guessing (hoping) it must. If so that sounds pretty easy.

Any thoughts? Suggestions for an easier solution?

Thanks in advance.

But seriously OP I think this a way too special question for this forum, maybe try the Programming forum?

Yeah, kinda figured that might be the case. Lot of smart people here though so I thought it was worth a shot.

I've already posted the same question on a different forum specific to network issues but got crickets there as well. Looks like I'm on my own.

Thanks anyway.

btw what is RUDICS?

RUDICS is an awful acronym. It stands for "Router based Unrestricted Digital Internetworking Connectivity Solutions". It's a method of transferring data over the Iridium satellite network.

Most folks use the Iridium network to place satellite phone calls from remote locations where there's no cell coverage (at sea, in the mountains, etc.). You can also use the Iridium network to send data between computers. The data transfer service comes in several different flavors, roughly grouped as:

1) Short Burst Data (SBD)
2) Direct internet
3) RUDICS

SBD is sort of like sending a text message. The computer sends a message to a satellite modem that contains the phone number to send the data to and the data itself. The modem initiates the connection with the satellite network and sends the data. Easy and robust but not good for sending large amounts of data.

Direct internet connection is just like using an old-school dial-up internet account like back in the 1990's, just really slow (like 2400 bps). The computer connected to the satellite modem is connected to the internet and can do anything a "normal" computer can do, just very slowly and expensively ($0.64 a minute).

RUDICS is sort of like the direct internet connection, but instead of being connected to the whole internet you can only transfer data to a single computer, one that you specify when you set up your account. It's used for applications like mine where the remote device doesn't need to talk to computers all over the world, it just needs to communicate with a single computer. There are also some differences in how the data is transferred between the remote device and the central gateway that allow the data transfer speed to be higher using RUDICS (up to 9600 bps).

The only limitation with the RUDICS system, the one I'm trying to work around, is that since it acts as a direct connection between two devices it doesn't bother with any of the networking protocols that the direct internet connection does. Specifically, the remote device is not assigned an IP address since there's no need for that kind of stuff if you're just talking to a single computer. Unfortunately the software that I want to use is designed to be used on many computers at once over the internet so it requires the use of IP addresses to tell it where to send messages. There's no way to tell it that you don't have an internet connection.

If you just have two computers sitting next to each other and connect them together using an RS-232 serial cable you can make a small local area network. One of the computers is the "server" and the other is the "client". The server can assign an IP address to the client and then the computers can talk to each other using the same protocols that they would if they were part of a larger network. What I'm trying to do is accomplish that exact same thing, but instead of the 2 computers sitting right next to each other they're separated by 1000's of miles. The RUDICS data channel is acting as my RS-232 serial cable. I think I have all of the pieces to my solution, just starting testing now.

Is the remote location in Antarctica? Just double checking that you already exhausted any cellular possibility. Also isn't there a way to use ham radio to get some extremely basic connection?

Remote location is in the middle of the ocean. Definitely no cell coverage. Never looked into using HAM for a data connection but that would definitely be a step backwards.

It's a bit early in the morning and I'm unfamiliar with RUDICS but it's not clear how there is no 'networking' involved given that your Windows machine listens on a TCP port to receive the data. This implies using TCP/IP - a port number and IP, even if its static and only to the IRIDIUM gateway.

While I brush up on RUDICS please provide some details of the application.
Is it critical to dial out based on events logged or is twice a day at pre determined intervals enough? How much data is pushed through each time, is it in KB/MB? What are you trying to achieve via a PPP link that the current RUDICS setup does not offer? Do you really need the added overhead of TCP on a high latency link? What other forms of communication are available at the remote location?

There's indeed networking involved, but only at the "non-remote" end (I forget what the actual term for the non-remote computer is. I'll just call it the Windows computer). The remote computer currently has no IP address and has no internet connectivity. As far as the remote computer is concerned, the Windows computer is just on the other end of a serial cable. It's the RUDICS gateway that adds the networking layer by taking the serial data and tunneling it over the internet to the Windows machine.

So you're correct that the Windows machine does indeed use TCP/IP for communication with the remote computer. What I would like to do is have the remote computer also be able to communicate via TCP/IP, even though it will still only be talking to the Windows computer.

Dial-out will be on a schedule. Currently the remote system initiates a connection about once every 15 minutes and transmits a short status packet to the Windows machine. Short as in less than 1kB. Once per day a largish data transfer happens during the call as well. Largish meaning a few MB.

During the short calls the remote system also checks with the Windows machine to see if there are any pending requests for additional data transfers (things that aren't normally transmitted during the once/day call). If there are pending data requests those data are transferred immediately. Those can be anywhere from a few kB to many MB.

I'd like to use ZeroMQ as my messaging protocol. It has several features that will make my communications much more robust, and should be a lot less coding. It requires both ends of the connection to have an active TCP/IP link to function. Since the RUDICS gateway won't currently act as an ISP for the remote machine I'm planning on using the Windows machine to act as the ISP. Seems like a lot of work just to use this messaging protocol, I agree. I've looked at other protocols and decided this one was the best fit.

As a practical matter, none. The remote location is in the middle of the ocean so we're stuck with satellite. Doesn't have to be Iridium but that's what we have so we're unlikely to change it.

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:

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:

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.

anyway congrats OP, that sounded like a heck of fumbling around. Did you separate the OSI layers properly?

Very curious to know wtf you're using your project for.

Sending back data collected by an oceanographic buoy. Well, technically not a buoy. It's a platform called the Wave Glider made by Liquid Robotics. It's like a big surfboard with some fins that hang way down below the surface. Electronics housed in the surfboard monitor the up-and-down wave motion and then adjust the pitch of the fins to provide propulsion to move the system to where you want it to go. Solar panels mounted on top of the surfboard and a bank of batteries provide power. Pretty neat.

We've installed some fancy sonar and GPS survey equipment inside the surfboard to do continuous monitoring of sonar beacons mounted on the seafloor for measuring tectonic motion. The satellite link sends the data back to shore periodically and allows us to check on the status of our equipment housed in the surfboard.

TL;DR: Seafloor geodesy.

That sounds very interesting actually


Neat. I wish you good luck!

I forgot about this and just read up on RUDICS because this is an awesome project. Glad to hear you got it working, do you just ppp-up as needed?

Also, this may not be an issue with 1 waverider, but if you're scaling to 10 or 100, it might be worth posting to the com0com devs what you're up to and get any tips they may have for your ultra high latency situation.
Serial connections work for real time communication, TCP does not, depending on how com0com adapts for things like packet loss, packets arriving out of order, re transmissions or congestion; you may need to tweak com0com/hub/Windows TCP to scale beyond a few units.

Since I have no idea what com0com does to work around normal TCP issues, asking the com0com devs first may be best. If it understands things like Sliding Window and SACK you just saved some bandwidth, disabling Nagle's algorithm should work well too. TCP window and maximum segment size could probably be tweaked and all these factors could reduce some of the overhead TCP brings when you're controlling more than a few units.
Windows TCP/IP Configuration Parameters

A photo of a waverider controlled via satellite is the highest level of geek porn, please post some pictures here too and all the best!

Just curious.. Why do you want to forward data from one serial port to another ? Can't you use a single serial port and use that directly to route data to your TCP/IP application ?

Not sure I understand your question, but I'm guessing you're asking about why I need two serial ports on the "local" machine? The answer is due to two things: 1) the Windows PPP server only accepts incoming connections over a serial port and 2) the data is arriving at the Windows machine on a TCP port via RUDICS. I needed a way to get the data from the TCP port to the PPP server's serial port. I accomplished this by using the software that automatically routes data from the TCP port to a 2nd serial port, which is then connected to the PPP server's serial port.

It would have been nice if I could have just routed the data from the TCP port directly to the PPP server's serial port but you can't do that. Only one application can access a serial port at any given time. The PPP server grabs control of its serial port so the routing software is unable to access it. That's what the 2nd serial port is for.

Let me know if that's not what you were asking about.

I guess this is a good time to post an update on this project if anyone else is still listening. The system was deployed for about 6 weeks in the middle of the Pacific Ocean over the summer and worked very well. There were a few hiccups along the way but those were due to other programming bugs unrelated to the communications.

There is, however, one big hassle to the system I put together that I don't have a good solution for yet. When the remote system is done transferring data it disconnects from the local system and hangs up the satellite modem. Unfortunately the PPP server on the local system doesn't recognize this disconnection and keeps the connection alive on its end, preventing future connections. It eventually times out and disconnects but the time required for the disconnect seems to vary a lot, I'm not sure why. I had to increase the interval between connections to allow for this. Not a deal breaker but pretty annoying.

I haven't had time to dig into what it would take to get the local system to disconnect when the call is through. I suspect the cause of this behavior is that the PPP server monitors the carrier detect signal on its serial port and uses that to determine when the call has been disconnected. If so I should be able to get the virtual serial port software to toggle this signal appropriately when the call is disconnected. If that doesn't work I'll have to think of something ugly as a work around.

Hi,

I am trying to connect my remote system to internet using iridium PPP connection due to the lack of any other infrastructure as that of yours and transfer few files. The data transfer seems to be extremely slow and the net throughput comes to 1.5 KBPS. I am using 9522B modem. Is this the maximum speed that I can expect from this ppp connection ? How much do you get? Is there any way to increase the bandwidth ? Can we open multiple PPP connections using the same modem ?. Is this even possible ?

Thanks
Anand

That speed is a little slow but not unheard of. I think I typically get between 2-3 kbps but it depends heavily on the quality of your satellite link. Out on the open ocean the connection is usually pretty good. If I try to do testing at home I have to position the Iridium antenna carefully to get a good view of the sky and avoid interference from nearby buildings and trees. And since the constellation of Iridium satellites is constantly changing the connection quality can change from good to bad in a matter of minutes.

There are a few things you can play with in the setup of the Iridium modem that might improve your throughput. For instance, I found that enabling hardware handshaking between the modem and whatever it's connected to helps a lot. I had handshaking disabled initially since the data rate was so low I figured it wasn't necessary, but as the quality of the satellite link changes the modem can throttle the flow of data if necessary. There are other settings in the modem that might help some but I don't really remember what they are.

Opening multiple PPP connections over a single modem won't help since it's the satellite communications part that's so slow. In fact, that would make things worse since there's a fair amount of overhead involved in handling each PPP connection. What you can do though is use multiple modems if the thing they're connected to is a computer and you have enough serial ports to connect them. Most PPP implementations support "bonded" connections, which means you can use multiple modems and the software automatically splits your data transfer between them. Each modem should get about the same data rate so you can double or triple your throughput using 2 or 3 modems. I've never actually done this but it's supposed to work just fine. That might not be an option for you though.

Thanks for your suggestions.

I've been researching using Iridum RUDICS for out-of-band console management of network devices located in remote areas. I found this thread via google, and I created an account here just to say thanks for the thorough details and multiple follow-ups. There are so few well-documented cases of using Iridum RUDICS, so finding this was a pleasant surprise.

Glad to have helped. Funny you should revive this thread now as I'm working on this project again for the first time since it was deployed last summer.

Hi there,
Not sure if this is still active but I'm taking on a project almost exactly like this except fetching acoustical data,not geophysical. I'm new to this kind of thing but if you're available I might be posting here for help in the next little while as it seems to be a fairly niche subject

Hello

I love reading about things like this.
I would just like to add some information on a other way to send/receive data over low speed connections.

Kermit.
http://www.columbia.edu/kermit/
https://en.wikipedia.org/wiki/Kermit_(protocol)

It works on most systems and have a very good error checking.

Still missing a picture of your setup.

Espen

Bump

OP have you considered installing an OPC UA server on your Linux box?