Re: dunc pppd configuration script
Bill Leach writes: One question that I have: Is it true that ALL ISPs that use chap or pap authentication also do not require an initial login? I don't personally know of any exceptions but I also don't see any technical reason why it would not be possible to use chap following login. I've never heard of it and can think of no reason anyone would do it, but I believe it is possible. As long as the client has the right stuff in pap-secrets, it should work fine on Linux. I doubt Windows could handle it, though, which makes it *very* unlikely anyone would use it. The non-login modes are probably much more straight forward (though I note that bo examples and docs did not seem to even recognize that there was such a thing). PAP and CHAP are very simple, and rapidly becoming the most common system. I don't understand why they are not documented. Is there any chance that there is a non-authenticated ppp initiation followed by a login in use? I can't see how that would work. What would you log in to? Once the link is up you are connected directly to his kernel. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
Hi John; If windoz can't handle it then I can think of ONE reason for doing it that way! :- You certainly could be right on the possibility of a post-ppp login but I thought it was possible. best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! On 9 Dec 1997 [EMAIL PROTECTED] wrote: Bill Leach writes: One question that I have: Is it true that ALL ISPs that use chap or pap authentication also do not require an initial login? I don't personally know of any exceptions but I also don't see any technical reason why it would not be possible to use chap following login. I've never heard of it and can think of no reason anyone would do it, but I believe it is possible. As long as the client has the right stuff in pap-secrets, it should work fine on Linux. I doubt Windows could handle it, though, which makes it *very* unlikely anyone would use it. The non-login modes are probably much more straight forward (though I note that bo examples and docs did not seem to even recognize that there was such a thing). PAP and CHAP are very simple, and rapidly becoming the most common system. I don't understand why they are not documented. Is there any chance that there is a non-authenticated ppp initiation followed by a login in use? I can't see how that would work. What would you log in to? Once the link is up you are connected directly to his kernel. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
bill writes: Some ISPs using CHAP present the username/password sort of thing (of course username: might be something else like login:, account:, etc. but actually don't use them for ppp logins. If the script wakes up getty on such systems, a ppp login attempt will fail. Yes, I'm aware of that. If the user specifies pap or chap such prompts will be ignored. I personally am trying to play around with the multiple ISP problem here and while in principle it ought to be trivial it is proving to be anything but! Richard has already solved it (though at the cost of seperate config files for each user). Inasmuch as hamm seems to create the /etc/ppp/peer directory and the etc/chatscripts/provider file, I would suggest that any user configuration tool default to naming the provider files with name related to the users input thus in effect making the existing provider files example files. I intend to do something like that. pon itself seems only to lack the ability to accept either an arguement (which might be a security problem) or a choice which should not be a problem. The user can also simply type 'pppd call provider'. I also feel as though the whole process, as it currently exists (in bo), of setting up an ISP connection is horribly messy. I agree. This is partly an upstream problem. 2.3.1 improves the situation quite a bit. I don't know your own priorities but suggest that ALL connection methods be considered for eventual inclusion in your setup software, even slip. I monitor the newsgroups for questions about getting on-line. I don't recall the last time I saw one about slip. Does anyone on this list use it? I've dunc to where it deals properly with my isp. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
Hi John; One question that I have: Is it true that ALL ISPs that use chap or pap authentication also do not require an initial login? I don't personally know of any exceptions but I also don't see any technical reason why it would not be possible to use chap following login. It also seems to me that there are three ways to initiate ppp for login type ISPs. The first is that upon login, the host starts the LCP negotiation, 2) The host waits for a \n and then starts negotiation, 3) the host requires a specific command after login to start ppp. Though I have not seen or even heard of this, I presume that another possible scenerio is that the host monitors for an incomming LCP negotiation. The non-login modes are probably much more straight forward (though I note that bo examples and docs did not seem to even recognize that there was such a thing). Is there any chance that there is a non-authenticated ppp initiation followed by a login in use? Richards multiple provider solution I will have to have a look at that. I seem to have it solved now but have not yet tried under other user accounts... so I might be under the illusion that I have it working right. John, I am NOT ragging on you (or anyone else really). While Linux has the potential to meet anyone's needs better than anything else available, trying to produce packages and configuration utilities that can deal with all of the variation (or even most of the common ones) is anything but trivial. [and yes, I know that my anyone's needs claim is a bit far fetched. For example people whoes needs include always having compatibility with M$ product files will find Linux falling short often--how often depends upon how often M$ releases a new version or update] I think that anyone that even casually watches the Linux development effort just about has to be in awe of the accomplishments. The rapidity with which developers seem to deal with new information is stunning. best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] --Please note [EMAIL PROTECTED] does not work-- --nor does anyone@anyhost.wconsult.com-- ==and yes eventually I'll get the mailer figured out== from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
Richard G. Roberto writes: This was supposed to be as generally useful to as many people as possible. Yes. And the most generally useful thing to do for the most people is to make it easy for them to get a single connection working so that they can email for help and ftp files. It was originally suppose to support slip and diald as well, but I never had the chance to get that part developed. I see no urgent need to add slip support. Diald may become obsolete when demand-dialing is debugged, but I think it should have its own config utility anyway. Of course, John may be more comfortable with these elements and add them. I intend to add demand-dialling support, but probably not using diald. ...my users have dialup accounts for home, work, market data, and even sometimes private shopping networks. They currently do this on win95 themselves (multiple connections support is built in). Multiple connections aren't hard. Seperate providers for each user isn't hard either with 2.3.1. It wouldn't require taking over dunc to create a new tool with a more limited objective. I don't think that's what John's after though. I have multiple objectives, the first of which is to produce a tool that will allow new Debian users to get on the net without baffling themselves with the ppp-HOWTO. At the moment I am just trying to add enough flexibility to dunc to get it to generate scripts that will work with my isp. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
John, I am not sure that I even want to get into this flay but some comments about my own observations with the issue are: Some ISPs using CHAP present the username/password sort of thing (of course username: might be something else like login:, account:, etc. but actually don't use them for ppp logins. If the script wakes up getty on such systems, a ppp login attempt will fail. I personally am trying to play around with the multiple ISP problem here and while in principle it ought to be trivial it is proving to be anything but! I believe that in part, a problem is that it is not at all clear who is doing what with whom (and which whom) as far the files are concerned when trying to use such things as xisp or dunc and the like. Inasmuch as hamm seems to create the /etc/ppp/peer directory and the etc/chatscripts/provider file, I would suggest that any user configuration tool default to naming the provider files with name related to the users input thus in effect making the existing provider files example files. pon itself seems only to lack the ability to accept either an arguement (which might be a security problem) or a choice which should not be a problem. I am strongly in favor of the idea that pon should be setup to use named provider files and never use a file actually named provider (of course this is an issue with the maintainer of that package and not you). I believe that if the pacakge configuration for pon worked that way, it would be much more obvious to the sysadm how the system works and what changes need to be made to enable other ISPs. I also feel as though the whole process, as it currently exists (in bo), of setting up an ISP connection is horribly messy. It seems like some options and parameters are stuffed into unlikely places (and often duplicated). I am pretty sure that this is at least in part due to several different philosophies about how to establish a connection all in use at the same time as well as evolution occurring in the fundamental software used for the process (pppd changes probably being the most significant influence). In addition the existing documentation that the individual is likely to encounter that deals with setting up just ONE ISP much less multiple, conflicts on how to go about the process. It looks to me as if the latest version of ppp provides for the solution of the options file problem in a clean manner as long as the pppd developers remain consistant in their default settings for future upgrades. As I am sure that you are aware; this really is a _SERIOUS_ problem for Linux in general and is anything but a trivial one for you to solve. New user perception is likely to be that getting on-line should be a simple matter--after all to get onto AOL, Worldnet, fill in the blank is just a simple matter of answering a few simple questions and letting the software take care of everything else. I doubt that most people starting off with Linux have any idea of just how difficult it is to obtain some of the critical information that is built into these custom ISP sign up programs. I don't know your own priorities but suggest that ALL connection methods be considered for eventual inclusion in your setup software, even slip. Again, it is a bit presumptive for any of us to assume that something like slip will not be the critical factor for someone new wishing to use Debian Linux. I do agree that the priority for something like that should be lower than trying to make it nearly foolproof to connect to a main line ISP. best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] --Please note [EMAIL PROTECTED] does not work-- --nor does anyone@anyhost.wconsult.com-- ==and yes eventually I'll get the mailer figured out== from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! On 7 Dec 1997 [EMAIL PROTECTED] wrote: Richard G. Roberto writes: This was supposed to be as generally useful to as many people as possible. Yes. And the most generally useful thing to do for the most people is to make it easy for them to get a single connection working so that they can email for help and ftp files. It was originally suppose to support slip and diald as well, but I never had the chance to get that part developed. I see no urgent need to add slip support. Diald may become obsolete when demand-dialing is debugged, but I think it should have its own config utility anyway. ... [much relevent info snipped] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
On Fri, 5 Dec 1997, Robert D. Hilliard wrote: On 05 Dec 1997 16:24:10 [EMAIL PROTECTED] wrote: Richard G. Roberto writes: I also want to address this issue about standard options file locations. It is impossible to manage multiple ppp options sets in the same file unless the option requirements are identicle. ... I personally have three different connection requirements and use dunc/dppp to manage them. It should be possible to handle this with a seperate provider file for each isp (pon would need to be revised, or the user told to type 'pppd call isp'). If the object is to lead a new user through a simple ppp configuration from the base install script, I question whether it is worthwhile making it handle multiple connections. The user who requires multiple configurations is probably sophisticated enough to handle it himself. The object is to have a ppp setup utility that can set up ppp for any arbitrary user. Having one tool for novices and different tools for varying intermediate levels and yet even more tools for experts was not the objective. Who the heck really wants to go through setting up ppp with vi anyway? And what does the need to have more than one connection have to do with the level of _technical_ sophistication of the user? These were definitely not on the objective list when I wrote this. But most people are their own sysadmins. I agree that dialing out should not require root, but initial configuration of ppp is as much system administration as is setting up an ethernet connection. I don't think I'd want my users accidentally mucking around on their system as root -- especially if they're connecting from home! The last thing I need to do is start making house calls. I believe all, or almost all, networks have Internet connectivity and mail systems that have been set up by the sysadmin, so users on such systems shouldn't have to configure ppp. This tool is aimed at What does setting up a mail system have to do with someone setting up their client ppp connection? What makes you think that a setup tool can afford to make any kind of assumptions about the machine or environment anyway? This was supposed to be as generally useful to as many people as possible. It was originally suppose to support slip and diald as well, but I never had the chance to get that part developed. The next version was to add these as (or similar functionality for diald) if I got to it, but that would have been another total rewrite in perl. Of course, John may be more comfortable with these elements and add them. the new user who is migrating from DOS/Windows, and has one box with one or two users. I do this sort of thing for a living (kind of) and my users have dialup accounts for home, work, market data, and even sometimes private shopping networks. They currently do this on win95 themselves (multiple connections support is built in). What exactly is your point here? And why is it that you decided to limit the target audience all of a sudden? I wonder if Linus Torvalds would rather click a few buttons and dialup or sift through config file after config file with emacs. I'd rather click a few buttons. The object is (almost) never to get the config files setup but to just get connected. Getting the config files setup is unfortunately a prerequisite. The aim of dunc was to help simplify this so that people could more easily get on with the business of being connected (which is the point afterall.) Dont get me wrong, I think the discussion is always useful, but stepping in now and redefining the objective of almost 2 years ago isn't entirely constructive. It wouldn't require taking over dunc to create a new tool with a more limited objective. I don't think that's what John's after though. Cheers, -- Until we extend the circle of our compassion to all living things, we will not ourselves find peace -Albert Schweitzer Richard G. Roberto -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
On 05 Dec 1997 16:24:10 [EMAIL PROTECTED] wrote: Richard G. Roberto writes: I also want to address this issue about standard options file locations. It is impossible to manage multiple ppp options sets in the same file unless the option requirements are identicle. ... I personally have three different connection requirements and use dunc/dppp to manage them. It should be possible to handle this with a seperate provider file for each isp (pon would need to be revised, or the user told to type 'pppd call isp'). If the object is to lead a new user through a simple ppp configuration from the base install script, I question whether it is worthwhile making it handle multiple connections. The user who requires multiple configurations is probably sophisticated enough to handle it himself. But most people are their own sysadmins. I agree that dialing out should not require root, but initial configuration of ppp is as much system administration as is setting up an ethernet connection. I don't think I'd want my users accidentally mucking around on their system as root -- especially if they're connecting from home! The last thing I need to do is start making house calls. I believe all, or almost all, networks have Internet connectivity and mail systems that have been set up by the sysadmin, so users on such systems shouldn't have to configure ppp. This tool is aimed at the new user who is migrating from DOS/Windows, and has one box with one or two users. . . . I also need examples of working chat scripts, both for the major national isp's, and for locals that require really bizarre stuff. Attached is my working chat script. It is for a local provider that requires really plain vanilla stuff. ABORTBUSY ABORTNO CARRIER ABORTVOICE ABORT NO DIALTONE ATDT7859991 ername hilliard word \qmy_password Bob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
Just to clear up some confusion about dunc, I realize the script has shortcomings and John is looking into taking over the package so it can get properly attended to. However, its really quite useable in its current state -- even on a bo system. It's just an ash script that uses dialog, so it should depend on _any_ version of libc since the dependant packages already do. It was built with debmake which incorrectly added the libc dependency and I couldn't seem to get rid of it. Basically, since ash and dialog and ppp, etc all depend on some version of libc, dunc doesn't need to. It doesn't use the c library for anything, only the tools it uses do. As far as the core functionality goes, it should work out of the box for most situations, but it is still a bit broken when adding a deleting multpile connections. It also doesn't add defaultroute automatically, which it probably should. I'd be happy to work out any other problems in the short term while John gets up to speed on it if there is a significant demand. Else, John will surely tighten things up. PPP options ... I also want to address this issue about standard options file locations. It is impossible to manage multiple ppp options sets in the same file unless the option requirements are identicle. Since unix is a multiuser system, it only makes sense to use an organization where the system defaults are considered, and user specific options configurable. I personally have three different connection requirements and use dunc/dppp to manage them. I couldn't do that all in the same options file since the options conflict. I had thought of making a way to manage the system options file automatically, but decided that providing a hook to just edit it would be enough since the only people needing to manage this file would be sysadmins. Incidentally, win95 and NT both provide a way to manage multiple connections and the data is stored per user. If the goal is to make setting up ppp as simple as win95, then why all the hoopla about per user configuration capability? dppp ... What dppp does is parse the options file created by dunc and feed it (via xargs) to the pppd command, which automatically considers the /etc/ppp/options file when run in this manner. It does the same for the chat file, if there is one. If dunc actually worked better, had more options, and was easier to navigate, I think it would be pretty good. But I also think that managing multiple connections per user (not to mention per system!) is a big win, and forcing people into having root permissions to setup their ppp connection wouldn't sit well with many sysadmins. I don't think I'd want my users accidentally mucking around on their system as root -- especially if they're connecting from home! The last thing I need to do is start making house calls. Anyway, before I wrote dunc, I used my own options files and chat files and scripts to connect and I though dunc was a better way for me to manage my own stuff. While writing it I kept that in mind, and hoped that other people would feel the same way. I never got any real feedback on it directly, so it never went any further. John's new energy should help move it forward, but he's still going to need users to use the thing and provide feedback. The fact that it doesn't muck around in /etc/ppp at all (excpet if you run it as root and need to write to pap,chap-secrets, but then it just adds an entry to the end of the file), means that it won't break anything systemic. Because its basically safe to try out, you can add a lot of value to it by using it -- at pretty much no risk ot your system. I'm tempted to say at absolutely no risk, but I know better than that ;) Sorry for the long post. Cheers, -- Until we extend the circle of our compassion to all living things, we will not ourselves find peace -Albert Schweitzer Richard G. Roberto -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
Richard G. Roberto writes: I also want to address this issue about standard options file locations. It is impossible to manage multiple ppp options sets in the same file unless the option requirements are identicle. ... I personally have three different connection requirements and use dunc/dppp to manage them. It should be possible to handle this with a seperate provider file for each isp (pon would need to be revised, or the user told to type 'pppd call isp'). I had thought of making a way to manage the system options file automatically, but decided that providing a hook to just edit it would be enough since the only people needing to manage this file would be sysadmins. That's fine, but on the vast majority of Linux systems user==sysadmin, and they need all the help we can give them. If the goal is to make setting up ppp as simple as win95, then why all the hoopla about per user configuration capability? If we provide a 'provider' file for each isp, all that needs to go in the user's .ppprc is the name of her isp. pon or a similar script would then select the correct isp after reading the .ppprc. What dppp does is... I haven't looked closely at this yet. Sounds interesting. ...forcing people into having root permissions to setup their ppp connection wouldn't sit well with many sysadmins. But most people are their own sysadmins. I agree that dialing out should not require root, but initial configuration of ppp is as much system administration as is setting up an ethernet connection. I don't think I'd want my users accidentally mucking around on their system as root -- especially if they're connecting from home! The last thing I need to do is start making house calls. Your users are members of a very small and very lucky minority. John's new energy should help move it forward,... Thanks for the vote of confidence. I still have to scrape together the cash to fix my hardware, though, before I can become a real maintainer. ...but he's still going to need users to use the thing and provide feedback. Definitely. I also need examples of working chat scripts, both for the major national isp's, and for locals that require really bizarre stuff. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
On 3 Dec 1997 [EMAIL PROTECTED] wrote: Can anyone give me some feedback on dunc? I'm revising it and would like to hear opinions on what should be changed. Already planned are pap/chap support and use of the standard option and chat files. What version of dunc are you looking at? The last version I wrote had support for pap/chap, and it also uses the standard option file in /etc/ppp, and has the ability to create a .ppprc link to any single connection. The connections get defined in option files, and if using chat, chat files. That's pretty standard. I purposely didn't require people to have root privilage and write to /etc/ppp so that more than one user at a time could have their own dunc setup without encumbering any other user. If you're thinking of making significant amounts of changes, you might be better off rewriting it from scratch. Cheers, -- Until we extend the circle of our compassion to all living things, we will not ourselves find peace -Albert Schweitzer Richard G. Roberto -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dunc pppd configuration script
On 03 Dec 1997 15:43:13 you asked: Can anyone give me some feedback on dunc? Several weeks ago I experimented with dunc 1.5. The major bug I found was in the dialup_connect script. There is what I think is called a race condition that causes the /bin/rm -f /tmp/wchatfile to remove wchatfile before the background /usr/sbin/pppd command looks for it, so the script fails. Inserting sleep 5 between these two lines solved the problem. (5 seconds was my first try - I didn't try to optimize the sleep time.) One of the input boxes (I think it was asking for the prompt for the user id) wasn't properly setup. I deleted the default value, and replaced it with the string I would need, but the resulting chatfile had nothing entered for this value. I quit fooling with it when I saw that dunc_2.2.deb was in hamm. I have downloaded dunc_2.2.deb, but haven't installed it since I still have a libc5 system. I believe it is supposed to have pap support. Already planned are pap/chap support and use of the standard option and chat files. Good. I believe a debian package, intended to ease a new user into ppp should follow the file structure established by the debian maintainers. I have long maintained that the base installation script should call a script to configure ppp. This should reduce a lot of the ppp questions on the deb-devel list. I have started writing such a script, but haven't done much. If you are going to revise dunc to use the standard option and chat files, I will forget about it. Please keep me posted. Once the package is finished, you should start a campaign to get it called from the base installation process, since that is when it is needed desparately. Bob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dunc pppd configuration script
Can anyone give me some feedback on dunc? I'm revising it and would like to hear opinions on what should be changed. Already planned are pap/chap support and use of the standard option and chat files. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
