Cool :-) Your solution is cleverer than mine, in that it uses LD_PRELOAD (I had anticipated some sort of userspace-tunnelling thingy based on tun/tap) but less clever in that you don't have any of the packet-selective-dropping cleverness I proposed...

Yet another person discovers "TCP over UDP" ... yay! Previous castles that have sunk into the swamp:

• iproxy: "As iproxy allows arbitraty TCP services to be carried over Broadcast, Unicast and Multicast UDP it potenitally has many applications beyond the scope of network device configuration."
• utunnel: "utunnel allows you to tunnel ip traffic (tcp, icmp, etc) over udp. utunnel is written and c using libpcap and libnet."
• atou: "Almost TCP over UDP" -- not a usable implementation as far as I can tell, but these guys sure did a lot of research and metrics collection. Could let you make a rounder wheel, if you choose to reinvent one.

Whatever you do, Brad, for the love of God, don't go LD_PRELOAD'ing Perl. :-)

After 3 castles sink into the swamp, isn't that the point that the 4th one has firm enough ground to build on? :-)

But uh, my aspirations seem considerably smaller than any of those 3 projects.

If you do get motivated to hack on this, I wish you lots of luck.

Luckily for me, my WiFi at home is stable enough to use SSH very reliably with great interactive response.

Now, if SSH from my Treo 650 were "interactive" enough to be useful, that'd be something. You SSH from your Treo 650 yet? Got any ideas on how to make that interactivity more responsive? :-)

What's the conf file for? What configuration is needed?

I'd do it like bradwifipreload --args-i-don't-understand ssh --ssh-args host. Then it doesn't need to understand ssh at all.

Ease of typing. But yeah, only destination host is in config.

er, instead of fixing the retransmit timer in uesrspace udp, why not fix it in the stack as I suggested?

Because userspace hacking is easier? And then more people could use it easily?

To be honest, my first thought upon coming across something like this *would* be "why didn't they do it in the stack? this must be crack." But then I'd see you wrote it and figure it wasn't too much crack. And yeah, I'd imagine considerably easier. :)

Yay for LD_PRELOAD! I wrote my first hack a few months ago, which intercepts TCP connect()ions and sends them out on my cable modem instead of the DSL.

Is it possible for the kernel packet filtering layer to be the intercept point? I.e. if port 22 TCP outgoing, send packets to userspace service xyz. Where xyz encapsulates everything over UDP for the wireless hop.

The clever bit about this is that a single command could actually remove the packet filter command, and everything would fall back to the old way. And established connections would stay alive. Not sure that it matters, though.

It would be nice if the whole thing looked transparent, sort of like a VPN interface.

Could you please share with us if enabling Westwood TCP congestion control helped or not?

Also there is an academic project (very old, 1999): http://timely.crhc.uiuc.edu/Projects/wtcp/wtcp.html
I could not find source code there, but you may want to read their papers at least.
--
Artem (http://www.artemfrolov.com/)

I'm not quite sure I understand what you're trying to do all this for. Changing from BIC to Westwood worked for me... but I assume you need additional functionality. Good luck!

I imagine Westwood will work for me too. I haven't tried yet. (Had a laptop harddrive failure.....)