This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Chat script From: George Cingolani <gcingo@accesscom.com> Date: Mon, 12 Apr 1999 04:53:09 -0700 (PDT) On Mon, 12 Apr 1999 NoelTinCA@aol.com wrote: > I have run into a new road block trying to dial into > the university. I have read some more documentation and > have made some headway, but I am still not able to make it > work right. I am able to dial in and connect to the > server, but I wind up getting disconnected right away. I > use the following command line to connect: > pppd connect "chat -vf /etc/ppp/chatscript" /dev/ttyS2 > 38400 -detach \crtscts modem defaultroute noauth > The file /etc/ppp/chatscript contains the following: > TIMEOUT 5 > ABORT "NO CARRIER" > ABORT "BUSY" > ABORT "NO DIALTONE" > ABORT "WAITING" > ECHO ON > "" ATZ > SAY "Dialing your ISP...\n" > OK AT&F1E0V1Q0S0=0&C1&D2&B1&A3&M4^M #modem string recommended by my modem > manufacturer > OK ATDT3464000 > TIMEOUT 45 > CONNECT "" > #TIMEOUT 5 > ogin:--BREAK--ogin: noelt #myLogonID > word: myPassWord > Does anybody see something in what I am doing that might > cause me to not be able to stay connected? I don't know > for sure, but I think that I might not be getting > authorized. try this one exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS0 38400 \ asyncmap 20A0000 escape FF kdebug 0 $LOCAL_IP:$REMOTE_IP \ noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT === Subject: Re: Modem connection speed? From: Ramon Gandia <rfg@nook.net> Date: Sat, 10 Apr 1999 10:41:23 -0800 John Mai wrote: > > Hello > > How can you tell the actual modem connection rate in RedHat Linux during > connection to ISP?? This is a trick question with a trick answer. If you want to know your ONGOING speed DURING a ppp session; ie, a speed indicator of some sort, or a program that asks what the speed is, etc. you are basically out of luck. The ppp connection will die if you access the modem register for this. Having said that, some EXTERNAL modems will report speed on the LED or LCD indicator. They do not do this via the serial ppp cable, but directly to the indicator, so the ppp link stays up. Of the inexpensive ones, the ones by Multitech do this. You can watch your speed go down, up, back down, etc as line conditions change. If all you want to know is your INITIAL connect speed; ie the speed you happen to get when you first connect to the ISP for your ppp session, then that is a lot easier. It should be reported in /var/log/messages. If not, increase the level of verbosity in pppd. Lastly, if your connection is not PPP, you can often interrupt the data stream by sending +++ top the modem to put it in command mode, then accessing the proper register to see your speed, then go back to data mode. You will need your modem manual to see what exact commands you need. Most modems, alas, do not have such a register....only the one with the initial connect speed. There are also some programs that will count bytes in and out of the modem port. This will give you an idea of the transfer speed, but is of course unrelated to the modem connect speed. === Subject: pppsetup - good program From: Mark Price <prim0001@unf.edu> Date: Tue, 13 Apr 1999 02:42:57 -0400 (EDT) This [pppsetup] is a good program for a beginner that just wants a basic ppp connection, and doesn't want to deal with composing chat scripts, and rooting around in Linuxconf. It will work with no graphics, and will help build your chatscript, is good for those that need more than just serid: and assword: in their chat script... The rpm can be found at redhat mirror sites. I learned a lot about all the technical stuff before I got it, but it is a good quick-fix. === === Subject: Re: Anyone know what this is? From: Eddie Kuns <ekuns@kilroy.chi.il.us> Date: Mon, 15 Mar 1999 08:56:56 -0600 darryl@myemail.com.au said: ] When dialing my ISP and establishing connection, My PPPD log always ] has this; ] ] Mar 14 11:29:45 gw1 pppd[9186]: Unsupported protocol (0x8207) received The remote end is offering that protocol. I received exactly the same message while dialing into my work. I also had other issues dialing into work that at the time I assumed were related to the message. That turned out to be "pilot error" on my part, whoops! I fixed those mistakes and all works, and I still get that message. When I thought it indicated a problem, I spend a couple hours trying to figure out what it was. I finally located the list of ppp protocols. The full (?) list of ppp protocol numbers can be located at: ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers The one you are curious about is: 8207 Cisco Discovery Protocol Control Thus, I'll bet a dollar the device at the other end of the phone is a Cisco device. <grin> You aren't missing anything. I'm not sure what this protocol is, exactly, or what it does. When establishing a PPP connection, the remote end offers all the protocols it knows. Linux PPP complains when it is offered a protocol it doesn't know about. Win9x PPP, on the other hand, seems to just ignore any protocols it doesn't know about. I'm not sure which behavior I prefer! Anyway, PPP's complaint is just informational. Feel free to ignore it. === Subject: Re: Re: Re: ppp connect script -Reply From: Steve Borho <sborho@ststech.com> Date: Mon, 26 Apr 1999 13:08:31 -0500 On Mon, Apr 26, 1999 at 11:51:06AM -0500, Godfried Duodu wrote: > Is there anyway I can see the expect/send format used in the ifup > command, since that works fine, so that I can repeat that in my script? /etc/sysconfig/network-scripts/chat-ppp0 ======== === === Subject: Re: ppp connect script -Reply From: Jan Carlson <janc@iname.com> Date: Mon, 26 Apr 1999 17:25:11 -0400 Godfried Duodu wrote: > > ** Reply Requested When Convenient ** > > Is there anyway I can see the expect/send format used in the ifup > command, since that works fine, so that I can repeat that in my script? Did you know that a chat script is totally unnecessary if your ISP supports PAP authentication? Also, most ISPs do use PAP these days. Try having no chat script at all, and enable PAP. You might be very happily surprised. ==== Subject: Re: ppp logs From: Ramon Gandia <rfg@nook.net> Date: Mon, 26 Apr 1999 18:51:38 -0800 Mark Anthony wrote: > > i tried your advised and it seems successful > but i still have some problems. my ISP is using > Cisco 2511 router and Radtac 3.1 for authentication. > here's my ppp logs. > > Apr 27 05:01:09 hehe pppd[421]: pppd 2.3.5 started by root, uid 0 > Apr 27 05:01:10 hehe chat[422]: send (AT^M) > Apr 27 05:01:10 hehe chat[422]: expect (OK) > Apr 27 05:01:39 hehe chat[422]: AT^M^M > Apr 27 05:01:39 hehe chat[422]: OK > Apr 27 05:01:39 hehe chat[422]: -- got it > Apr 27 05:01:39 hehe chat[422]: send (ATD2225614^M) > Apr 27 05:01:39 hehe chat[422]: expect (CONNECT) > Apr 27 05:01:39 hehe chat[422]: ^M > Apr 27 05:02:19 hehe chat[422]: ATD2225614^M^M > Apr 27 05:02:19 hehe chat[422]: CONNECT > Apr 27 05:02:19 hehe chat[422]: -- got it > Apr 27 05:02:19 hehe chat[422]: send (57600^M) > Apr 27 05:02:19 hehe chat[422]: send (ame^M) > Apr 27 05:02:19 hehe chat[422]: expect (:) > Apr 27 05:02:29 hehe chat[422]: 57600^M > Apr 27 05:02:39 hehe chat[422]: ^M > Apr 27 05:02:39 hehe chat[422]: Username : > Apr 27 05:02:39 hehe chat[422]: -- got it > Apr 27 05:02:39 hehe chat[422]: send (mark^M) > Apr 27 05:02:39 hehe chat[422]: expect (57600) > Apr 27 05:02:49 hehe chat[422]: 57600 > Apr 27 05:02:49 hehe chat[422]: -- got it > Apr 27 05:02:49 hehe chat[422]: send (word^M) > Apr 27 05:02:49 hehe chat[422]: expect (:) > Apr 27 05:02:49 hehe chat[422]: ^M > Apr 27 05:02:49 hehe chat[422]: Password : > Apr 27 05:02:49 hehe chat[422]: -- got it > Apr 27 05:02:49 hehe chat[422]: send (kram^M) > Apr 27 05:02:49 hehe pppd[421]: Serial connection established. > Apr 27 05:02:59 hehe pppd[421]: Using interface ppp0 > Apr 27 05:02:59 hehe pppd[421]: Connect: ppp0 <--> /dev/ttyS0 > Apr 27 05:02:59 hehe pppd[421]: sent [LCP ConfReq id=0x1 <magic 0xb043b9a0> > <pcomp> <accomp>] > Apr 27 05:03:29 hehe pppd[421]: LCP: timeout sending Config-Requests > Apr 27 05:03:29 hehe pppd[421]: Connection terminated. > Apr 27 05:03:29 hehe pppd[421]: Receive serial link is not 8-bit clean: > Apr 27 05:03:29 hehe pppd[421]: Problem: all had bit 7 set to 0 > Apr 27 05:03:39 hehe pppd[421]: Hangup (SIGHUP) > Apr 27 05:03:40 hehe pppd[421]: Exit. I took a look at your mail header, and see that it was sent from Eudora mail for Windows 95. Presumably, the computer you are using now on Windows 95 is the same one you are trying to make connect in Linux? If yes, I want to ask if your ISP uses a connect SCRIPT. This is a specific action on the part of Windows 95. The vast majority of users on Windows 95 simply fill in the username and password on the CONNECT window, and check the "save password" then press the connect button. Is this what you do? Or do you need to bring up a script or a "Terminal Window" in Win95 ?? If you do not need a script or a terminal window in Windows 95, then why are you forcing RedHat to execute a SCRIPT? I notice that you are doing so in your ppp log. You are expecting username :, then sending a username. Expecting Password :, then sending it. This is a script. At Nook NEt, my server will do the same thing, send you all those username and password prompts, but if you answer them it will never give you a connection. YOU MUST NOT USE A SCRIPT OR AN EXPECT-SEND SEQUENCE for you ppp to work. What 95% of all ISP's use nowadays is called PAP authentication. This does not use username and passwords in the sense that you are doing. Its a binary protocol that contains those elements and is called PAP authentication. Its automatic between you and the server. In Windows 95, the username and password that you fill in on the box that has the CONNECT button is NOT an expect-send sequence; it is rather the PAP authentication parameters. This is no end of confusion for newbies.... they log in with minicom and see a username prompt....or they look at the RedHat ppp configuration and see a place to fill in the username and password and immediately fill it in. THIS will NOT work with most ISP's and will not work with Nook Net. Instead, leave all of that junk blank. Yes, blank. Now go find the PAP authentication button, and in the PAP place go and fill in the username and password. When you finish you will notice that you have created a file called /etc/ppp/pap-secrets which contains the username and password (the password is called a "secret" in PAP parlance). Although I am not 100% sure that is your problem, I am betting that it is and that you will have a much easier time of it if you follow my advice above and get rid of the SCRIPTED logon that you are using. ======== Subject: Re: ppp-stats monitoring From: James Michael Keller <jmkeller@radix.net> Date: Sat, 01 May 1999 18:49:00 -0400 Larry Mintz wrote: > > Is there anyway I can check out if my modem is running at full speed ? > I know there is the tool pppstat, but this tool doesn't help. I am looking > for a tool similar to the Dial-Up Networking Monitor in NT. Does such a thing > exists in Linux ? An excellent little package to have at hand is iptraf. Among it's many screens, there is a detailed traffic monitor for interfaces, in this case ppp0 probably is what you would use. Will give you a meter of total k/s and packets/s. I open up a desk top with three terminal windows, one full hight showing the iptraffic monitor screen, another half high window next to it with detailed info on the ppp0 interface for the net connection, and a detailed protocol window below that that shows me what ports have trafic ( and what those ports are ie tcp/http, tcp/telnet, etc ) and how much data is moving across them. Very handy tool, and the description in the rpm when I found it on filewatcher.org was so unassuming :) ======= Subject: Diald and timeout. From: "Fathi Ben Nasr" <fathi.bennasr@sfa.com> Date: Sun, 2 May 1999 01:14:29 +0100 I set up my linux box to access Internet via a modem using diald. I used Jan Carlson post on 29/03/99 to this list, which was very clear. I added the four lines suggested in step 16: >impluse 30,0,0 >redial-timeout 10 >up-delay 5 >buffer-packets on but to the /usr/lib/diald/standard.filter instead of /var/run/pppd-diald-coors.conf as linuxconf overwrites it when activating changes and removes this four lines. Pinging from a w9x client to remote hosts gives me a line saying pinging www.remote.host.com [remote.host.ip.number] and then four lines of timed out requests. It is also impossible to browse the net or do ftp from any w95 browser or msdos command line. When pinging any host from a w95/98 client with the connection not established, the client waits until the connection is up to do the dns resolution and then gives the same timeout request messages. ============== Subject: Re: pppd problems From: Bruce Richardson <brichardson@lineone.net> Date: Sun, 2 May 1999 14:12:14 +0100 (GMT) On Sun, 2 May 1999, Paul Mezzanini wrote: > so bruce.. got any ideas on my pppd problem? :) Ok, here's an embarrassing one that tripped me up when I first set up ppp - one of the scripts (I think it was ppp-on-dialer) wasn't executable. I found out when I put debug-logging. I put this in /etc/syslog.conf: #PPP daemon,local2.debug /etc/ppp/ppp.log and added "kdebug 4" to the pppd command line. I could check it after each failure - spotted the "permission denied" problem. Whatever your problem is, having the debug messages should help. ========= Date: Sun, 27 Sep 1998 17:46:53 -0700 To: computing@kzsu.stanford.edu From: Stefan Lisowski <stefan@kzsu.stanford.edu> Subject: KZSU QPOP/ Hacker warning The LAN on my block (where I'll live for the next two weeks) was hacked from the outside again. I had "APOP" chosen in my Eudora mail client, but apparently KZSU's pop server doesn't currently support APOP, thus my password (now changed) was sniffed by my unencrypted popping. The latest QPopper supports APOP, and also: > >Another good reason to upgrade KZSU: > >"Qpopper2.41 and prior versions are vulnerable to buffer overflow. Remote >users can obtain root access on systems running these versions. Releases >of Qpopper 2.5 and later are immune from all known buffer overrun security >holes posted in bugtraq. Please upgrade your server if you are running any >qpopper older than 2.5." I'd thought that using only ssh and APOP I was set, but Eudora 3.1 doesn't warn you if your APOP is reverting to just cleartext passwords... Anyway, any chance that someone could download compile and install the latest qpopper from Qualcomm? Below are instructions to support APOP in the compile: http://eudora.qualcomm.com/freeware/qpop_faq.html >How do I setup APOP authorization? > > APOP is an alternate authentication method. It is able to >authenticate without passing the password in cleartext > over the wire. To enable this feature, you need to define the >following compiler definitions: > > APOP=\"/etc/pop.auth\" > POPUID=\"pop\" > > The first definition is the location of the database; the second >specifies the user/password entry that will own > the authorization database. When you build the qpopper with APOP, >you also get a program called popauth > which must be installed in a public location. This program must >also run SUID as the 'pop' user so that it can > make modifications to the pop.auth database. > > NOTE: Make sure the database /etc/pop.auth is owned by POPUID and >that the permissions are 600. popauth > -init creates the file with the proper owner and perms. > > The database must be initialized by root with the following command: > > popauth -init > > New users can be added by root or the 'pop' user with the following >command: > > popauth -user > > Or removed with the following command: > > popauth -delete > > Any user on the host can add themselves or change their password >with the following command: > > popauth Yuck. Dealing with hackers is a pain. ====== Subject: Re: External vs. Internal Modems From: Ramon Gandia <rfg@nook.net> Date: Tue, 18 May 1999 17:29:22 -0800 Ryan Ware wrote: > > The only way you will need isapnp is if you get an ISA modem. As for > setup, I believe all you need to do is make a link called /dev/modem to > the proper com port (/dev/ttyS0 or /dev/ttyS1), although I'm not > completely sure for an external modem. I have ISA. Good luck. You only need isapnp is your modem is internal, ISA and PnP enabled. Some, like the US Robotics Internal Sporster, have jumpers: COM1 com2 PNP etc. If you disable pnp in the jumpers then you do not need isapnp. With a modem set with jumpers to a port, you need to go into the BIOS and disable the motherboard port. Example. A USR Sporster internal. You set it for non-pnp on COM2 (cua1). Plug it in. Restart the computer and go into BIOS setup. Look for the serial port configuration. Typically you will have two serial ports on the motherboard, called A and B. Usually A will be set to COM1, and B will be set to COM2. Assuming this is the case, you go into port B setup and set it to "disable". That frees up COM2. Or you could set up the port to some different com port assignment. With an external modem, you want to ENABLE the com port that your cable attaches to, obviously. Be forewarned about COM ports. COM1 and COM3 share the same interrupt (4), and COM2 and COM4 share irq 3. The lower the number of the interrupt, the higher priority. It is best to give modems a fairly high priority as the data coming down the modem cannot be 'put on hold', it just keeps streaming in. ON a pentium, this is not too critical. COM4 (cua3) is a bad choice because video cards often use the i/o space. You never should use COM4/cua3 unless you are sure your hardware lets you with no conflicts. Some people think they are okay, and they notice strange glitches later on. If you think PnP avoids all these problems, be assured that there is nothing worse than a PnP situation that does not work properly. It can drive you to distraction because its like nailing jelly to a try. You fix THIS, and then THAT changes or freezes the computer.... Jumpers type of modem or an external are best. === Subject: Re: PPP From: John Summerfield <summer@OS2.ami.com.au> Date: Wed, 26 May 1999 08:47:20 +0800 > I have been trying without success to get my computer to dial up my ISP via > Linux 5.2. I have read all of the HOW-TO's and MAN pages on setting up > Linux, but still can't seem to get it to work. I can get minicom to dial up > and actually log-in to my ISP, but it won't hold the connection. I have > tried to set the PPP Options to make the LCD (I think that's right) to 30, > so it would not disconnect but that did not work. I really at my last straw. > I am wanting to get an Internet link to download a new XFree86 so I can use > my Matrox Millennium video card. Anyway, if there is anyone who can give me > any insight.... None of this GUI nonsense for me: I based my dialup procedure on samples in /usr/doc/ppp* To be fair, the network configuration tool attached to the control panel works well too. I've not tried linuxconf. === Subject: PPP . . . kind of . . . sort of . . . sometimes From: "Yuki Taga" <yukitaga@twics.com> Date: Mon, 31 May 1999 22:41:01 +0900 Hi Guys! Okay, I can now establish a ppp session at will. <sound of one hand clapping> The way I have to do it is hard to believe, however, and I don't think most of you would accept it. I sure can't. 1) On any boot into Linux *after* using the modem in NT or Windows, the command /sbin/ifup ppp0 will fail. The modem absolutely will not dial. 2) In the same situation, the command /usr/local/bin/wvdial will always cause the modem to dial, and connect, but the wvdial program cannot establish a ppp connection, because it is waiting for something that doesn't happen. Why this program can't finish the job is beyond me. It says it's waiting for something. But I really don't want to use this program anyway. Go to the next step. ^_^ 3) After the failure in step 2, regardless of whether step 1 was even attempted or not, the command /sbin/ifup ppp0 now successfully dials and immediately establishes a working ppp connection every single time. Moreover, a reboot into Linux that does not involve modem use in another OS means the command will work instead of failing in step 1. I am at a complete loss to explain this. I truly hope someone else can. There is one possible hint here. The program wvdial autoprobed my moden when I installed it, and it came up with an init string I never heard of and cannot find in the manual. I think there may be some magic in that init string. However, step 3 above does not use that string. === Subject: Re: PPP . . . kind of . . . sort of . . . sometimes From: "Greg W" <redhat_list@hotmail.com> Date: Mon, 31 May 1999 14:25:37 GMT I am not sure of your procedure.....but, if you boot to Linux after something has accessed your modem, always turn it off then on, you are probably aware of this... With the string, it may be worth trying &fx3 or at&fx3 , keep all characters in one case, do not mix them. In short the string tells the modem to wake up, set itself to factory default, then dial regardless (forced dial). === Subject: Re: PPP . . . kind of . . . sort of . . . sometimes From: "Yuki Taga" <yukitaga@twics.com> Date: Tue, 1 Jun 1999 07:23:45 +0900 On 31 May 99, at 10:39, Steve "Stevers!" Coile wrote: > On Mon, 31 May 1999, Yuki Taga wrote: > [...] > > 1) On any boot into Linux *after* using the modem in NT or Windows, the > > command /sbin/ifup ppp0 will fail. The modem absolutely will not dial. > > Is the modem getting different IRQ, DMA, or IO settings under Windows than > it has under Linux? Ouch. I know how to check this in M$, but not in Linux. Please teach me. > Does /etc/sysconfig/network-scripts/chat-ppp0 include any initialization > strings for your modem? Perhaps your modem isn't being properly reset. > Try adding ATZ to the chat script and see if that fixes things. Will do and will advise. Thanks. > > 2) In the same situation, the command /usr/local/bin/wvdial will... > > What is /usr/local/bin/wvdial? This is the command that fires the wvdial program. It's similar to something called xisp, the rpm for which I cannot seem to install because of a libforms.so.86 dependency. I can --nodeps the rpm, but the program won't run without the right libforms package. Wvdial is interesting. When you initialize it the first time it probes the modem and reports a lot of interesting information. It came up with an init string that isn't in my manual and I never heard of. But it works. > [...] > > 3) After the failure in step 2, regardless of whether step 1 was even > > attempted or not, the command /sbin/ifup ppp0 now successfully dials and > > immediately establishes a working ppp connection every single time. > > Moreover, a reboot into Linux that does not involve modem use in another > > OS means the command will work instead of failing in step 1. > > Sounds like the modem isn't being left in a clean state after its use > elsewhere. I'd definitely try to put some initialization settings into > the chat script in /etc/sysconfig/network-scripts. Again, too logical for me to think of first. ^^_^^ Will try, will advise. === Subject: Re: PPP . . . kind of . . . sort of . . . sometimes From: "Yuki Taga" <yukitaga@twics.com> Date: Tue, 1 Jun 1999 12:50:18 +0900 Still investigating this, Greg. But for starters the cycling of modem power didn't work. Now, I turned it off and on *between* OSes, not after I booted into Linux, but after I booted out of NT. So I'll try that next (probably won't make any difference but worth a try) and then I'll play with init strings. Quick question, though. Wvdial found an init string that apparently works on the first try, even coming from NT. Instead of the strings you have below, shouldn't I try that one first? One thing to note here: NEC is one of those companies that is extremely proprietary. They would play the M$ game in a second if they could. Had I known this about them, I would never have bought their IDSN TA/DSU, even though it's popular here in Japan. Example: They don't use standard AT commands. That's right. Try AT&W in this modem, and it returns ERROR. So, maybe that wvdail init program probed and found a good string? === Subject: Re: Can a shell script replace 'diald'? From: John Summerfield <summer@OS2.ami.com.au> Date: Tue, 01 Jun 1999 22:34:18 +0800 > I was wondering if it is possible to achieve the functionality of 'diald' > just using "stock" Linux net utils and shell scripts. Here is what I am > proposing: > > 1. Set up a script that runs in a loop, monitoring network traffic using > some network utility or log file. (Does a machine keep a log of IP address > requests somewhere?) > 2. When the script encounters an outside IP address, it just issues 'ifup > ppp0'. > 3. After a five minute interval of no Internet activity, it issues 'ifdown > ppp0'. > Recent versions of pppd do dial on demand. Read its docs, === Subject: RE: Can a shell script replace 'diald'? From: "George Lenzer" <glenzer@chuhpl.lib.oh.us> Date: Tue, 1 Jun 1999 11:39:53 -0400 Will this work with dynamic IPs? I had heard that it wouldn't, and from what I saw in the docs, it sounds like it won't either. Perhaps, I'm looking in the wrong place? /usr/doc === Subject: RE: Can a shell script replace 'diald'? From: Ryan Ware <ware@shocking.com> Date: Tue, 1 Jun 1999 09:54:40 -0700 (PDT) It'll work. Just make sure to use the ipcp-accept-local and ipcp-accept-remote options. === Subject: Re: Firewalling 101 From: "Justin Oelgoetz \(chemistry.ohio-state.edu\)" <joelgoet@chemistry.ohio-state.edu> Date: Tue, 1 Jun 1999 18:05:21 -0400 (EDT) On Wed, 2 Jun 1999, Peter Kiem wrote: > >what's in that, but it's probably ok. Definitely kill the webserver. <snip. . .> > But if the only machine allowed to accept WWW packets is the Linux > server then having web server on the firewall machine wouldn't be a > security risk? And Linuxconf can be configured that only my > workstation can connect to it? The only reason I say it's a risk is that I got the impression that we were using an NT box inside the firewall to do our Web stuff. If we need apache or a web server on the firewall for linuxconf only, it's a risk because it is an unnecessary service. It increases one's exposure to future exploits. If it's going to be used to do real web servicing then great, but otherwise it's unnecessary. (All services are potential security holes thus risks. Run only what you absolutely need on the firewall). > Yes I intend to do that but maybe I didn't explain myself enough. > Should I be putting in routing rules for *ALL* of the private address > ranges or does the routing automatically trap these? > e.g. I have a cracker at my ISP (unlikely) that is using address > 10.0.0.1 to hide his real IP address. If I don't route the 10.x.x.x > addresses to my internet network ethernet card then I would be sending > reply packets to him right? I'd go w/ the networks when you do the routes. Maintaining the files if you did the ip's individually would be painful. A hacker could always try a private IP's until one worked if they were inside your building anyways. If you set up your firewall right, you shouldn't be routing private packets to the internet. As mater of fact your upstream provider should kill them if they see them. > >> 4. PPP. THAT will be a whole can of worms in itself 8( > > > >Actually use linuxconf, and if-up ppp0 to bring the interface up, > works > >great. Don't do this file editing stuff if you don't have to. > > That sounds great 8) It seems an arcane art to get PPP running from > what I have read. Linuxconf rocks. Under redhat if you use linuxconf (which has X and ncurses interfaces) to set up ppp all you need to do to bring up the connection is type if-up ppp0 as root. if-down ppp0 brings it down. It works just like any other interface. === Subject: Re: Can a shell script replace 'diald'? From: Ryan Ware <ware@shocking.com> Date: Tue, 1 Jun 1999 22:53:11 -0700 (PDT) Hello, I've posted this before, but since the archives are of little use at the moment, it's a bit hard to find. This is an explanation of how I got the demand function of pppd working and what options I used. Hopefully this will help and maybe make the man page a bit more understandable. Ryan Ware (ware@shocking.com) To begin with, I used RedHat's netcfg program to originally connect to the internet so that's where the ppp0 device was created and also the chat-ppp0 file (amongst others.) You also need a 2.2.x kernel (or late 2.1.x.) The following is the command I use to invoke pppd: /usr/sbin/pppd -detach 204.119.204.71:204.119.204.2 ipcp-accept-local ipcp-accept-remote demand holdoff 5 idle 360 lock modem crtscts defaultroute name ware /dev/modem 115200 remotename ppp0 ipparam ppp0 connect '/usr/sbin/chat -f /etc/sysconfig/network-scripts/chat-ppp0' & > /dev/null So that it is started automatically upon boot, I put the above command in a file called /etc/rc.d/init.d/pppd and made it executable. Then I made a link called /etc/rc.d/rc3.d/S90pppd that points to the previous file. As far as I know, the demand option only works with version 2.3.5 or later. I use 2.3.5 and I think the newest version is 2.3.7. Now let me explain the options I use with the pppd command: -detach - This detaches pppd from the controling terminal so that closing the terminal has no effect upon pppd. 204.119.204.17:204.119.204.2 - This is the local_ip:remote_ip. local_ip is the IP you are assigned when you connect to your ISP. remote_ip is the ip of the machine that you connect to at your ISP. If you aren't sure what this is, connect to your ISP and issue the command 'traceroute -i ppp0 isp.domain.name'. The first line in the listing should contain the IP of the remote machine. If you do not have either one of these (i.e. dynamic allocation of IP's,) it is no problem. The following options take care of the problem. ipcp-accept-local - This option allows the local IP to be changed by the value supplied by the server at connect time. ipcp-accept-remote - This option allows the remote IP to be changed by the value supplied by the server at connect time. demand - This option turns on the demand feature so that a connection is automatically created when network traffic exists. holdoff 5 - This option specifies ho many seconds to wait before re-initiating a link after it terminates idle 360 - This option tells how many seconds to wait before disconnecting because of lack of traffic. lock - Creates a lock file for the serial device used for the modem. modem - Use the modem control lines. crtscts - Use hardware flow control. defaultroute - Have this be the default route in the routing table. name ware - This is for PAP. ware is my username that corresponds to my secret in my pap-secrets file. /dev/modem - This is the serial device to use for your modem. 115200 - This is the speed of your serial connection. remotename ppp0 - Sets the assumed name of the remote system. ipparam ppp0 - Needed for the ip-up and ip-down scripts. connect '/usr/sbin/chat -f /etc/sysconfig/network-scripts/chat-ppp0' - Tells pppd what to use to make the actual connection. & - Ensures pppd runs in the background. > /dev/null - Redirects any output away from the terminal to oblivion. On Tue, 1 Jun 1999 taj@cyber-wizard.com wrote: > On Tue, 1 Jun 1999, John Summerfield wrote: > > > Recent versions of pppd do dial on demand. Read its docs, > > Heh. But did you understand it? *I* didn't. I tried modifying the > /etc/ppp/options file as follows: > > lock # here by default > demand # dial on demand > nopersist # don't keep up a permanent connection > holdoff 30 # wait 30 seconds before redialing if dropped > idle 300 # timeout after 5 minutes of no traffic > noipdefault # I *hope* it turns off the static IP requirement > > But it just sat there when I tried dialing using /sbin/ifup ppp0. How many > french fries short of a happy meal does that make me? :) > > Have you gotten it to work? If so, mind sharing your incantation with me? === Subject: Re: PPP refuses to work as user From: Jan Carlson <janc@iname.com> Date: Mon, 31 May 1999 23:48:40 -0400 Michael Ghens wrote: [...] > chmod u+s /usr/sbin/pppd This is the wrong way to fix it on Red Hat, and it's a security hole too. Use netcfg or linuxconf to select the option that allows any user to start or stop ppp0. Linuxconf can run without X Windows also. === Subject: Re: PPP and Pacbell/Ascend Pipeline Terminal Server From: Ramon Gandia <rfg@nook.net> Date: Fri, 04 Jun 1999 08:47:43 -0800 Hal Burgiss wrote: > > On Fri, Jun 04, 1999 at 01:28:50AM -0700, Paul R. Watkins wrote: > > It seems that the serial connection is made ok but that > > the LCP times out -- how do I fix this. Also look at > > last 2 lines of file -- "Receive serial link is not > > 8-bit clean Problem: all had bit 7 set to 0 -- what > > should I do about this? > They are not talking the same lingo. Try using minicom to > set your port to '8N1', see if that clears it up. Nothing to do with it. The "all had bit 7 set to 0" means that the PPP link was not negotiated. It is one of those techno-geek error messages that gets people to think of 8N1 things or a broken UART chip, etc. You will see the same message if the scripted password fails, for instance, or any other error in the expect-send script. More often, you will see it when an expect-send script is used when the ISP is set to purposely ignore scripted logins (most Livingston based ISP'), or PAP was not used or used incorrectly. Any of those will result in non-PPP negotiation and the error message is --you guessed it-- 'bit 7 set to 0'. === Subject: Re: PPP and Pacbell/Ascend Pipeline Terminal Server From: Ramon Gandia <rfg@nook.net> Date: Sat, 05 Jun 1999 01:01:41 +0000 Hal Burgiss wrote: > > More often, you will see it when an expect-send script is used > > when the ISP is set to purposely ignore scripted logins (most > > Livingston based ISP'), or PAP was not used or used incorrectly. > > > > I get something to the effect of 'PAP Authentication failure' in this > scenario. I recently changed ISPs to one who uses PAP and does not > support linux. I eventually got it going only by trial and error, but > never got the '7 bit' message despite a lot of tinkering with the > scripts and many, many failures in the process. If PAP does not work, try CHAP. It is set up very similarly; the instructions are in the PPP=HOWTO, however, with CHAP you will be outside the limits of linuxconf. What will work is to set up with PAP, then manually add the CHAP file which is /etc/chap-secrets or something similar. CHAP is not a popular protocol, but there are a few out there that do use it. As to an "ISP that supports PAP but not Linux" is nonsense. What they mean is that they have no one on staff to answer Linux related questions. It certainly does not mean that their equipment or PAP does not work with Linux. For instance, here in Nome, I do not support Windows NT. Why? Because I only have ONE customer that uses NT, and I know nothing about it. === Subject: Re: MasqDialler or diald??? From: Jan Carlson <janc@iname.com> Date: Sat, 05 Jun 1999 15:02:32 -0400 Ken Walker wrote: [...] > > What I am wondering is which dialer people find best to use? > > So far, it looks to me like diald may be more complicated to > configure and may be hard to tame so it isn't dialing in more often > than I would like. It may also be the sort of thing where it logs > off as you read something you are browsing on the web. I am not sure > I like the idea of it deciding when it should dial rather than the > choice being made manually by the user. [...] What you say about diald is generally true, however I found the magic bullet to tame diald. It's called dctrl, and it comes with diald. . Dctrl shows me exactly what packet is triggering diald. Then I tweak the diald filter to ignore the packet type that's making it dial, or change its time-out. . The diald filter file has a readable syntax. . I can set diald so ALL its config files are in /etc/diald/ . When iconified, dctrl shows me with red, green and yellow lights whether diald is down, up or in transition. . Dctrl lets me nail the connection up, or down, or let it decide. . Diald16 is stable. . Diald16 starts and and stops nicely, controlled by ntsysv. . Dctrl helps me know what packets I receive, which is handy to keep an eye on port scans and misbehaving programs on my side. . Diald can run independently of linuxconf. . Diald16 works with all the Linux kernels from early 2.0 through 2.2.9, and all the distros I tried - Red Hat, Caldera, Slackware, Debian. . The 2.2 kernel grumbles about diald's use of routes, but diald seems to work fine anyway. . Diald does not interfere with the default RH scripts, or those used by /sbin/ifup and ifdown. Diald is very trainable. === Subject: Re: PPP permissions From: Jan Carlson <janc@iname.com> Date: Thu, 01 Jul 1999 21:47:48 -0400 Sam wrote: > > To get this working I used the following methods: > > 1. If you have a LAN, make sure your hosts, lmhosts, hosts.conf, and > resolv.conf files are setup properly. > > 2. For the PPP options (ie, put in options.ttyS0 if you're using > multiple serial ports for modem access or /etc/ppp/options if single > use) use: -detach, modem, lock, crtscts, defaultroute, mtu=576, and > mru=536 (these numbers may vary for you). > > 3. Set the permissions as follows: > > /usr/bin/pppd to SetId using chmod 4755 > /etc/ppp/ directory and files using chmod 775 > > 4. Set the Group for all the above to PPPUSERS (this group is setup by > default for RH6) using chgrp PPPUSERS > > 5. Edit the /etc/group file and add your username to the PPPUSERS group. Or, press the button in Linuxconf that allows any user to start/stop the ppp connection. === Subject: Re: modems From: Ramon Gandia <rfg@nook.net> Date: Fri, 11 Jun 1999 01:31:51 -0800 Dan Wedeking wrote: > > Then I go into the minicom program and put a number to dial. > The modem dials it, minicom says it's connected, then it disconnects right > away. > I wonder if it's because I typed my login name or password in wrong or if > it's the > PnP thing making it disconnect. Or maybe minicom is only for connecting to > BBS's > and not ISP's. But I get the same result trying to connect with PPP. Sounds like your modem is working ok. Most ISPs use PAP authentication, and not scripted or terminal. For instance, here at Nook Net, if you dial into me, you will get a welcome banner and a login: prompt. Lets say you put in your username, then get the Password: prompt, and you put that in too. Then my system will disconnect you. This is because my equipment (Livingston) is set to disconnect ALL attempts to log in via a username/password. This is the default behavior and is in use by the vast majority of ISPs. What you need to do --strange as it sounds-- is to IGNORE the login: prompt. When you see it, TERMINATE minicom but stay connected using CONTROL-A Q, then start your pppd program. Of course, you MUST have PAP authentication enabled by having the proper entries in /etc/ppp/pap-secrets. This is merely your username and password, but for PAP - not for an expect-send sequence. Unfortunately, although quite a few of us have told RedHat that the default PPP installation in RedHat is scripted, and will not work for most isp's, they persist in making this the default. Look at Windows 95. If you did not write a script, and if you do not use a "terminal window", but merely put your username and password in the "connect to" box just before you dial the isp, then you are using PAP authentication and none of that terminal or scripted junk. You must likewise do in Linux. Onions to RedHat for this newbie-eating trap. They need to reverse the thing. By making PAP the default, and the scripted expect-send thing the OPTION. === Subject: Re: trouble with ppp From: Jan Carlson <janc@iname.com> Date: Sun, 13 Jun 1999 01:21:55 -0400 Gary Neff wrote: > > I have upgraded to redhat 6.0 and everything works fine , I have one problem > I cant seem to figure out. I can connect my isdn external modem to my isp if > I utilize linuxconf and go to the ppp/slip/plip section and then click on > ppp and then use the connect button displayed. > I cannot connect using kppp or the ppp dialer in gnome which shows a > connection but no data flows. as they do not seem to see the carrier. kppp > worked fine before upgrade and I am stumped can anyone offer any advice? In Linuxconf PPP setup: Turn on PAP. Erase all expect and send blanks. Fill in your ISP username/password in the PAP tab. Linuxconf nameserver setup: Enter your ISP's nameservers IP numbers. Check "user can start/stop connection" === Subject: Re: Well I'll be damned! From: Ramon Gandia <rfg@nook.net> Date: Sun, 13 Jun 1999 00:47:30 -0800 Peter Kiem wrote: > > >What method did you use to set up PPP? PAP or chat scripts? > > I just fired up Linuxconf, selected the modem port (/dev/ttys0), put in the > phone number, put in my fixed IP address in the "Local IP address" area and > put my username and password in the PAP area. > > Told it to connect and it dialed out and connected - no fuss. This is what I have been saying all along. Leave the chat scripts BLANK, and use PAP. It will be just like a Win95 hookup then. === Subject: Re: RH6 / pppd From: Steve Borho <sborho@ststech.com> Date: Fri, 18 Jun 1999 15:57:05 -0500 On Fri, Jun 18, 1999 at 03:16:28PM -0500, Joel Golden wrote: > I have created the scripts found at > metalab.unc.edu/LPB/HOWTO/PPP-HOWTO. The scripts run fine under root. > I've chmod +s /etc/ppp/ppp(allscripts) and /usr/sbin/pppd. However, it > still denies permissions to /dev/ttyS2 to a standard user. I'm running > pppd as dial on demand. Any ideas? The chat script needs rw access to /dev/ttyS2. gauss% ls -l /dev/ttyS2 crw------- 1 root tty 4, 66 May 5 1998 /dev/ttyS2 gauss% chmod g+rw /dev/ttyS2 Now, add any user you want to allow the ability to bring PPP up to the tty group. === Subject: Re: ifdown ppp0 not always working From: Hal Burgiss <hdb@iglou.com> Date: Wed, 21 Jul 1999 18:37:40 -0400 On Wed, Jul 21, 1999 at 02:24:44PM -0400, mepr@ilnk.com wrote: > A great deal of the time, when I do "ifdown ppp0" it does not > work. What could be wrong? The only way I have found to disconnect > when that happens is to kill the pppd process manually. That is > not cool > > Mark > This doesn't really solve your problem, but this is from the ppp-down script that is included with pppd rpm: # kill the ppp daemon ... if [ -f /var/run/$DEVICE.pid ] then kill -INT `cat /var/run/$DEVICE.pid` if [ ! "$?" = "0" ]; then rm -f /var/run/$DEVICE.pid echo > "`basename $0`: ERROR, Removed stale pid file" fi fi which is just a controlled manual kill in script form. Note the "-INT" in the kill command. AFAIK, the only thing that might make this a little sticky is if you have anything in ifup-post (or similar), then this may not be resetting everything as it should. === Subject: Re: 56k CONNECTS at last but no web pages From: Hal Burgiss <hdb@iglou.com> Date: Wed, 21 Jul 1999 20:41:44 -0400 On Wed, Jul 21, 1999 at 07:38:00PM -0500, Benjamin Sher wrote: > Dear Brian and friends: > > Yes, I am sure that's the problem. But I don't know how to switch from > my ADSL modem to my 56k modem. I have been told by many that it's a > question of routing, that I have to set the routing correctly. But > that's the whole issue. I don't know quite what I should do. I know one > thing for sure: the ADSL works perfectly and the 56k modem connects to > the Internet (through Bellsouth) perfectly (at 38,000) but I cannot > connect to any Web server. Thus no web pages. I am sure the main utility > to configure all this is netcfg but I just don't know what data I should > enter and where. > Save a copy of your /etc/ppp/options, and try adding these lines. Note that this may screw with your ADSL config, but I know nothing of how that is setup. You probably can do this with netcfg, but I don't use it so not for sure. defaultroute 0.0.0.0:0.0.0.0 noipdefault netmask 255.0.0.0 === Subject: CNET 56k and ADSL Saga -- Routing SOLVED! From: Benjamin Sher <sher07@bellsouth.net> Date: Wed, 21 Jul 1999 20:44:37 -0500 Thanks to the suggestions and advice of so many wonderful people on both the Red Hat and Hedwig Lists, I have finally found the solution to the CNET 56k Routing problem. After 13 hours straight online, I was finally able to find the missing link in this puzzle. Of course, I would have never figured this out without the help of so many of you. The consensus by late afternoon was clearly that this was a routing issue, that Linux did not have the routing information for my 56k to enable it to connect to a Web server. That was right on target. Similarly, my earlier problem of an infinite loop of connecting and reconnecting was caused by setting the connection speed at 56k. When I lowered it to 38,000, my modem connected fine every time. So, what's the solution? The solution is to assign the default gateway route to the modem. Several people said so in just these words. But the place for this switch is not only in netcfg (where there is an option for this under ppp0) but also, that is, in addition to netcfg, in KDE's kppp. In kppp, under Accounts (of all places), highlight your IP (bellsouth, in my case). This brings up a whole new set of tabs, one of which is Gateway. On this tab, select Default Gateway at the top and then, the critical and key option, at the bottom, select "Assign the Default Route to this Gateway." It was this that finally made it possible for me to connect to the Web, etc. in Netscape. After using my ADSL for four months (the CNET 56k is a backup for it), I have never been so happy to see a Web page download so slowly! You should, of course, also add ppp0 to your netcfg and configure it before using KDE's kppp Setup. However, the solution is not quite perfect, as it turns out. So, there remains one final puzzle. When I turn on my dial-up modem and connect to the Internet, I find that I cannot launch ANY application, either from KDE's menu or panel. The only way it works right now is for me to bring up Netscape FIRST, then get rid of any error messages by clicking on the OK on the Error box and then dial my 56k modem. It will dial perfectly well each time (ending with "Done"), then I minimize it and go to Netscape and go to any Web site I wish and get my mail. However, if I want to launch xterm or an FTP client or any application AFTER I am already online, I can't. Hopefully, one of you gurus can help me through this last step, though I am quite relieved to get online with my dial-up modem. My thanks again to everyone who helped. It's been quite an ordeal. If anyone has any suggestions on how to overcome the last obstacle, please let me know. === From: ymg@azstarnet.com (Warrior) Date: Sat, 16 Jan 1999 21:19:05 -0700 Subject: Re: Linux PPP Interface Setup Help Newsgroups: comp.os.linux.setup In article <77rivr$iem$1@nnrp1.dejanews.com>, vdavis@nerds.com writes: > I am having trouble establishing a connection with the > XWindows PPP Interface. After dialing, the modem looks > like it is attempting to negotiate a connection, but after > 45 seconds it drops the connection. It looks like it is > unable to authenticate username and password. I have it > setup to expect "ogin:" then send my username, then > "word:" then send my password. I am using a External > USRobitics 56k X2 modem and I am using AT&F1 for an init > string. I have the Debug box checked in the Interface > setup but I never see a debug dialog. Is there another > init string I should be using? How can I see what is going > on? Add `debug' and `kdebug 7' to your /etc/ppp/options file, try to dial out, then check /var/log/messages to see what's going on. === Subject: Re: How do you dial isp via win 95 From: Jan Carlson <janc@iname.com> Date: Wed, 15 Sep 1999 22:08:52 +0000 Syd Carter wrote: > > Is there a program like dialup networking program that would initiate the > /sbin/ifup ppp0 command to the linux server? I like "modem-lights". It's small, cute and it works. Run RH6 and Gnome. Right-click task bar. Add Applet | Network | Modem-Lights. Configure it - up command = /sbin/ifup ppp0 down command = /sbin/ifdown ppp0 lockfile = blabla..ttyS0 (Use the same device ppp0 uses.) === Subject: Re: ssh From: "Todd A. Jacobs" <nospam@codegnome.org> Date: Tue, 7 Dec 1999 13:41:25 -0800 (PST) On Tue, 7 Dec 1999, Steve Lee wrote: > how do i setup ssh not to timeout at all. Remove the IdleTimeout setting in sshd_config. === Subject: Re: ssh From: Steve Lee <maillist@blitzen.net> Date: Tue, 7 Dec 1999 13:56:07 -0800 (PST) i don't have that in my sshd_config is it this instead LoginGraceTime 600 === Subject: ssh-1.2.27-7 RPMs (security update) From: Jan Kasprzak <kas@informatics.muni.cz> Date: Tue, 7 Dec 1999 11:51:07 +0100 I have built the new RPMs of secure shell. The only one fix since the previous release is the buffer overrun fix in RSAref (rsa.c), described in Core-SDI advisory from December 1. Thanks to Oystein Viggen for reporting this. RPMs are available in source form as well as the binaries for i386 (glibc2.1 and 2.0), alpha and sparc (32-bit). All packages are PGP-signed by my key <kas@fi.muni.cz> and are available at ftp://ftp.fi.muni.cz/pub/ssh/local-fi.muni.cz/linux/ and they will be available at ftp.zedz.net (used to be ftp.replay.com) soon (currently the packages are uploaded in /pub/replay/incoming). === Subject: Re: restricted shells From: Rick Moen <rick@hugin.imat.com> Date: Wed, 15 Sep 1999 10:58:36 -0700 Quoting Jerry Wilcox (jwilcox@slip.net): [http://linuxmafia.com/pub/linux/security/ssh-clients:] > In case you haven't already found out, this link, plus other links > you posted in this series of articles, gets a '404 Not Found'. My apologies: I moved my public ftp tree, late last night, and forgot to tell Apache about it. All the aforementioned URLs should be fixed, now. I was trying to find a more-secure ftpd than wu-ftpd-academ and ProFTPd, both of which have crufty design and a history of problems. I finally settled on TrollTech's free-software troll-ftp (after a bizarre misadventure with Dan Bernstein's anonftpd). === Subject: Re: cron job and ppp From: Jan Carlson <janc@iname.com> Date: Wed, 15 Sep 1999 19:15:38 +0000 David Talkington wrote: > > > The commands to connect and disconnect ppp, on rh6, are > > > > /sbin/ifup ppp0 > > /sbin/ifdown ppp0 > > > > assuming that ppp0 is the one you want. > > An aside here, but could you perhaps explain why that doesn't work on my > installation? If you use Linuxconf, netcfg or netconf to set up your ppp connections, ifup ppp0 will work. Linuxconf is the method Red Hat documents in their Installation Guide. It's the method I was talking about, since this is a Red Hat list. There are other methods that use different connect/disconnect commands. IMHO, linuxconf ppp is the one that works easiest, out of the box on Red Hat, and is quickest to learn for beginners. Old guys like you and me have learned other methods in the past, but those are harder to explain to beginners. === Subject: Re: Modem Configuration From: Steve Borho <steve@borho.myip.org> Date: Thu, 16 Sep 1999 13:59:09 -0500 On Thu, Sep 16, 1999 at 10:47:17AM -0700, James Fitzgerald wrote: > It seems that somewhere along the line the route default gets changed and I'm > not really sure where that is (or when) that is yet. After this command is > issued the connections will work well for a while, when they stop working this > command as root will fix things. What I need to figure out is how to prevent > this default route from getting messed up in the first place. I am not sure > how this effects the ethernet connections on this system, as there are none as > of yet. Anyone out there have any ideas of suggested reading material that > could enlighten me on how to understand/fix this? if pppd is given the 'defaultroute' option (either through the command line or placed in /etc/ppp/options), it will attempt to create a default route through your IP link every time it brings up an PPP connection to your ISP. This default route is deleted automatically when the IP link goes away. Linuxconf has a box you can check that will automagically add the defaultroute option to pppd for you. kppp does this by default, since it assumes that your PPP link will always be your default route to the internet. Where you run into problems is when your initscripts set up a default route through some other network device when your machine is booted. pppd cannot create a default route if one already exists. To make sure your Red Hat box doesn't do this to you, edit /etc/sysconfig/network and comment out the two GATEWAY lines. ===