PPP over ssh: solving problems with indirection

August 13, 2010

There is an old aphorism in Computer Science that any problem can be solved by another level of indirection (Wikipedia credits it to David Wheeler). Today I have an illustration of this.

I mentioned that I was having problems with USB serial ports on my just upgraded to Fedora 13 machine. Specifically, starting up PPP on such a port would hang the pppd process (and then any other process that touched the serial port). Since my DSL link is still down, this is a problem. It turns out that the specific issue is that on my machine, trying to switch to the PPP line discipline on a USB serial port hangs the process; I suspect locking issues between the kernel's TTY layer and USB layer. Reasonably, the PPP daemon switches its tty to the PPP line discipline pretty much the moment it starts, and there goes my connection attempt (and my dialup connection).

(I suspect that this happens on all SMP x86_64 Linux machines with a recent enough kernel, and possibly all SMP machines. It doesn't happen on a uniprocessor x86 machine. Interested parties can see the Fedora bug report.)

This is not a general bug with the TTY layer's handling of the PPP line discipline, or it would have been noticed well before now. In particular, you can switch to the PPP line discipline on a pseudo-tty without problems.

(I wound up testing this sort of by accident. My PPP account has a somewhat weird setup, and the most convenient way to test that it had survived the Fedora 13 upgrade was to just ssh in to it in a terminal window and see if it spewed a PPP connection initiation at me or printed errors. After the upgrade I tried this and had it work, and I thought nothing of it until later.)

So I solved my problem with indirection; I arranged to run pppd on a pty instead of on the serial port itself, transparently passing all IO back and forth between the serial port and the pty. This needed something to do this work, and the simple program for this is ssh in its transparent mode. So now my connect script doesn't directly log in to my PPP account; instead it logs in to a regular account and immediately does an 'ssh -e none pppme@localhost'.

(I could have written a program to do this without the SSH overhead, but ssh has the great virtue of already existing and working and this is an expedient hack that I sincerely hope is not living on for too long.)

Sidebar: the logical extension of this hack

Suppose that you have two machines; one machine with a dialin modem and a regular account but no PPP setup, and another machine where you can actually run PPP but you don't have a (working) dialin modem. We can solve the problem of getting a PPP link up in this situation in exactly the same way; since we're using ssh, we can perfectly well ssh off to another machine entirely instead of localhost. It may not have great latency and performance, but as the wise man once observed, working at all is better performance than not working.

(Extensions to the situation where the first machine can't directly talk to the second machine are left as an exercise for the reader.)

Written on 13 August 2010.
« Many programs should provide an easy way to change font size
What I want in a caching nameserver »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Aug 13 01:09:53 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.