Slashdot Mirror
SLiRP Project Needs Maintainer
Karl A. Krueger hopes someone might be interested in following up on this bit of info: "SLiRP is a program by Daniel Gasparovski which lets you emulate a SLIP or PPP connection over a shell dial-up connection. In other words, it's a PPP "driver" that runs entirely as a user process. Unfortunately the last official release was in 1996, and the author is apparently no longer interested in maintaining it. The license is somewhere between BSD (requires attribution) and GPL (requires freedom). I've made a few minor fixes to it so that it compiles and runs under a modern system (Debian 2.1 -- should work under others as well) but there's quite a bit that could be done with it if someone wanted to actually maintain the thing. Anyone interested? In any event, my patched version is
here. "
7 years ago, we got 20 dial-in analog lines for our userbase of 255 CIS students. Now we have 16,000 students (all students get e-mail now of course, not just CIS), but still have 20 lines.
Why? The college doesn't want to get into the ISP business. It's expensive and most students have ISP accounts of their own anyway. It's a decision I supported 100%.
But there's always the poorer students who gets screwed by policies like this. So we maintain shell access for those students to get their e-mail and -- if they can figure it out -- allow them to use SLiRP to get something approaching a PPP line.
We put up a web page explaining the steps in getting it to work, but specify that we don't support it. This way, the student who isn't burdened with a lot of cash but has half a brain can get equal access to the net at no cost.
So far, policy works fine. Most students use their own ISP, and our 20 lines don't get maxed out, but most of those that DO use it, are running slirp.
It'd be nice to see it maintained. I've seen cases where it drops the last byte of an FTP transfer and haven't been able to figure out why, for example. (We run DG/UX boxes here, might be an OS compatability issue... Also, DG/UX doesn't have a pppd that will work on a non-serial connection, ruling out that...)
Now the next slirp question I'm sure to hear is -- can it be hacked to work with Dreamcast? Beings I just bought one this morning and my first analysis of it -- answer is no. Doesn't seem to support a connection script... just PAP or CHAP I suppose... :-(
I'm the SysAdmin for the machine that hosts the "Official" SLiRP homepage at http://blitzen.canberra.edu.au/slirp/. Looking through the logs reveals that people are indeed still downloading it, despite it being several years since a proper release. Something on the order of 200 to 400 FTP downloads of SLiRP related stuff a week, and 2000 to 3500 hits on the SLiRP related web pages a week.
I can probably continue to provide hosting for SLiRP should anyone choose to continue development.
Ok, lots of posts but I haven't seen my two
favorite related slirp virtues.
1) Security. Slirp does *NOT* forward arbitrary
packets back down your phone line for you
to deal with using your firewall setup. If
you don't configure incoming connections, there
won't be any. Plus if someone portscans the
other end of the TCP connection, they will be
portscanning the server system.
I've never really felt as safe with PPP+
firewall as I did running slirp.
2) Anonymity. Sort of. All connections look like
they are coming from the server machine. (I
guess if they run ident the jig would be up).
-- cary
I wrote/maintained the FAQ for the alt.dcom.slip-emulators usenet group for
;-) adapted the then current PPP
;-)
awhile - it's been included in the release
of slirp for eons -and hasn't been updated
for just as long.
Slirp maybe one of the first Open Source
projects that helped put a company out of
business! TIA, "The Internet Adapter" has
been mentioned here a few times already.
TIA initially did Slip only, and would have
PPP Real soon now. Slirp came on the scene,
and was working pretty well after a couple
releases. We complained to Dan about PPP,and
a clever programmer in Finland(lots of those
around here
driver from Linux to Slirp! TIA didn't have
it for several months after that - at which
point they were probably too late. Slirp
just acquired a working PPP driver in a
period of a few weeks!
Ah the memories
Steve Wilson
Have you compiled your kernel today??
Hello,
:)
One of the new features getting ready for 2.4 is the so called "generic" PPP layer. This is a generic implementation of PPP which supports both modem and ISDN connections and possibly others, I'm not sure. What I'd be curious in knowing is whether it would be easy to make a module for 2.4 that exports the kernel PPP code / pppd into a nice file stream such as used by SLiRP in PPP mode. This would effectively allow Linux machines "internal" SLiRP without any additional cost. Why? I don't know.
This would not however resolve the number one reason for using SLiRP (or, at least the only reason I've ever used it): shell accounts. Most ISPs or places where you would have non-PPP shell accounts would not typically be running Linux and especially would not likely be running a recent kernel. So, there is most definately a continuing need for SLiRP but would a lot of changes and "maintenance" be needed in SLiRP to reach that goal of legacy support? I don't know that either.
So, does anyone know if the Linux 2.3/2.4 ppp layer can be munged in this manner? That could be so much fun...
Joe
Oh man! I used this neat program back in my college days (1995+). Man, I think I was the first one to discover this program and use it on my university shell account while Internet was new over there. Eventually the firewall came along. DOH!
Anyone remember TIA? Another SLIP emulator I believe.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
What'd be really nice: A signed Java applet that can access the serial port (the comm api, but I'm not sure how it interacts with signatures / applets), uses ppp to talk to the device, and then sets up a secure tunnel to a remote site. Then an appropriate web browser and a serial port could make a mostly secure VPN link for PDAs. (The serial port can be sniffed easily. A better solution would source the encrypted tunnel from within the PDA, but this is better than nothing.)
Jason, ejr@cs.berkeley.edu
Ummm....really don't know how many people from India read Slashdot but had a thought...
SLiRP could be used on a shell account in the USA (as far as I know Slirp does support telnet connections...though a bit fussy about it) in combination with a cheap shell account from VSNL (local ISP in India), a TCP/IP acc could be simulated. A bit slow but definitely worth the price ($10 for 500 hours..compared to a lot more for a TCP/IP )
Two things to note... A service called SenseNET used to provide something like this. Don't know if they used SLiRP/TiA or something else. Plus VSNL (and some other ISPs) do not provide clean 8 bit telnets (or I simply did not experiment enough with it). People might need to fiddle around with that.
It's simple.... Some of you are saying that use of this is dead. I can log onto a computer right now that probably has 30-40 slirp sessions running on it. College students are poor, or arn't allowed to get a cable/dsl modem in the doors/apartments they live in. And with some universities allowing free dialup servers like the one I goto, it is a valid solution. Granted its not gonna smoke but for the casual user that can always walk to a computer lab to do anything real, it works fine.
Is it a valid solution for most people no, mainly because we want to do more than look at a couple of simple web pages and reply to e-mails. I know now that I have a cable modem I couldn't ever go back to dialup. But for those that don't have the option slirp is a valid solution.
Twas a few weeks ago at work, whence I was determining how to solve a raft of remote access problems. Nothing was working, deadlines were coming...and then I remembered SLiRP. Oh my.
SLiRP is alot more valuable than you might think. For one thing, it provides a user-level NAT'd IP connection over any terminal link. Note, not just a modem link, but *anything*. Combined with SSH, SLiRP makes for an insanely slick VPN routable link that just *works*.
Even for dialup lines, SLiRP rocks. *Absolutely* no administrative headache getting an IP range in which to run PPP. No headaches at all.
I think you need to try to get ASPPP to work on Solaris to truly understand how painful PPP can be. Even pppd isn't too nice on Solaris. But slirp? Thunk. Work. First try.
I'm not just blowing smoke. At my work, there's a semi-decent chance we'll be deploying SLiRP *all over the place*, at *huge* companies, very soon, for precisely these reasons. It's fast, it's free, and it's astoundingly functional.
My shock at seeing my recently rediscovered PPP app of old up on Slashdot again is quite unnerving, but I can't complain. SLiRP has done me well.
One thing I'd request, if anybody's working on adding features--could somebody port in the MS-DNS code? I'm eventually going to be doing *alot* of GPL work involving SLiRP, but my stuff will end up much more high level.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Once you pull the pin, Mr. Grenade is no longer your friend.
I have a couple of guest shell accounts at the university where, as a college student, I worked at the computer center and CS dept. This university has a terrific library with some online databases that my present institution doesn't have. Access to these databases is via HTTP and restricted to IP addresses within the university.
So, what do I do?
Using ssh, I slirp up a secure ppp connection to my guest shell account. In fact I have my gateway machine (cable modem/masquerade/10-100 bridge) at home establish and maintain this connection (over my cable modem) automatically. Sort of like a poor man's vpn. It's all seamless. Packets destined for the library and a few other machines at that university always get routed over the slirp connection, which is reestablished if it's down. (This isn't surreptitious, btw.; the folks who let me have my guest account know and don't have a problem with it, so the connection is up almost always anyway -- no pesky delay when I connect to those cuspy online databases...)
I use the same trick to access resources at my graduate institution and even at my current (postdoctoral) institution (which of course doesn't recognize my cable modem address). But I don't need slirp in those cases, since I have root access to linux boxes at both places; I simply set up masquerading for my host. Same principle, though.
slirp works for me, in the limited application I have for it....
Is there any way to encapsulate SLiRP(and PPPD) within a 7 bit channel? I tried something along the lines of uudecode | slirp | uuencode, but it (obviously) didn't function as desired.
Suggestions? I have a feeling a standard 7 bit stdin/stdout wrapper might be useful all over the place.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Once you pull the pin, Mr. Grenade is no longer your friend.
Con:
For modem dial-up, it's pretty simple to use RFC1918 addresses and IP Masquerade. Last time I used it, it didn't support a lot of things (ICMP, typical reverse-connection stuff like DCC send). You lose some performance running over 7-bit ascii transports.
Pro:
There's some pretty good NAT code out there now. It outght to be possible to borrow some of that to fix some protocols that don't work. It's nice sometimes nice to pic up you connection from a machine you're not directly dialed into. As mentioned in other replies, one can combine this with SSH to make a handy VPN. It appears to be less platform specific, so is easier to port.
wow... :) Those were the days... hacking 'till 4am to get the load-balancing code to work (I only had one modem and my tester, whom I talked to on IRC (hey Ducati916!) lived in Salt Lake City), getting tons of email every day (got up to around 80-100 per day at one stage), job offers, etc. etc. Some great memories. Gosh I'm a nerd. :)
:)
It's good to see it still being used... please do email me if you have any questions on the code or anything... I wish I had the time to keep maintaining it.
Let me just clear one thing up: I see "isn't interested in maintaining it..." everywhere, which is false... I did have a 1.1 release scheduled as the "final" release with some bugfixes and some cool new functions, but I lost them in a HD crash. Then I entered the RealWorld. etc. etc.
Ahh, memories... Thanks for brightening up my (really shitty up to now) day...
Danny Gasparovski
dgs@ficsgrp.com
---
Spammed? Click here for free slack on how to fight it!
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";