problems with wvdial
in [Linux Networking]
|
Prev: Debian installed - Now what?
Next: Very strange, multiple IP addresses on the same Ethernet card donot route properly
From: Moe Trin on 14 Jan 2010 15:01 On Thu, 14 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in article <slrnhkul1q.3nm.unruh(a)wormhole.physics.ubc.ca>, unruh wrote: >lrhorer <lrhorer(a)satx.rr.com> wrote: Geez Bill - I _WISH_ you'd learn how to trim stuff you're not responding to off your replies. I have to use the 'tab' key to find where you are replying to stuff. >> No, it's set to be much faster than that. I think it's set to 1/2 >> second, but I don't have access to the router right now to check. >Sorry, that cannot be true. It takes much longer than that to dial >and to connect. Why do you not set up the timeout for longer. Did you notice this is GSM and not plain ole telephones? >Anyway, what is the operating system on that "router", and where >did you get that version of pppd. He's said it was Debian, and I don't think WvDial is used for other than Linux and anu ppp. >> I suppose it could be wvdial that's updating resolv.conf, but >> I'm pretty sure it's pppd. >They probably are. But I have no idea since you have a highly >non-standard pppd. No idea where you got that idea. Old guy
From: unruh on 14 Jan 2010 18:55 On 2010-01-14, Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote: > >>No, it's set to be much faster than that. I think it's set to 1/2 >>second, but I don't have access to the router right now to check. > [..] >>It's not unusual for it to attempt dialing 8 or 10 times, though. > > I'd look into that when you have time. It's hard to believe that > failing 8-10 times before happening to work is designed behavior. It is also very hard to believe that a phone could be answered in 1/2 a second. Ie, the timeout has to be longer. > >>>>--> Carrier detected. Waiting for prompt. > >>> the idiots from wvdial are still living in the past and >>> think there will be a LOGIN: prompt. > >>Or else that is just a generic status message which assumes nothing >>about what might be found at the other end. > > You really want to read the documentation for wvdial. It's designed > to log in to a getty - and over the development they discovered ISPs > are using the equivalent of autoppp mode because this is what windoze > expects. Back in the days when pppd on dialup was popular, and when I wrote that web page, one of the big problems was the difficulties people had with wvdial. If it worked fine, if it did not, it was a mess, and very difficult to debug. And wvdial made all sorts of unwarranted assumptions. It really got in the way. You can tellit not to try a login (I donot remember exaclty how anymore) but chat really really is far simpler. > >>Not everyone dials an ISP with their modem, you know. Of course in >>her case, it is, but a properly written application of this sort >>should be able to handle connections of any sort. > > What-ever > >>It also would not surprise me if there are not ISPs out there who >>still don't implement ppp. If they do not then they do not act as an ISP onto the net. ppp is the only way people have. wvdial assumes that first you log onto your service provider, and then after that you run pppd. That was their authentication scheme. Eventually the service providers discovered that there had existed for 10-15 years something called pap or chap, and eventually they all went over to that. But wvdial was started when, because many service providers read very very slowly, they had not yet gotten to the chapter discussion pap and chap. .. > > The other alternatives (besides ppp-over-something) are SLIP, CSLIP > and UUCP. Any idea when you saw one of those protocols used? I don't > think many distributions come with the 'sliplogin' package any more > (there is a 1996 tarball at sunsite) and I don't think UUCP is being > maintained (1994 tarball at sunsite). There is at least one, and > maybe more ISPs that provide a shell account (panix being the one I'm > aware of), which is basically what you used to get with a BBS setup. > For that, you use a terminal application like minicom (which seems to > be being maintained). But that doesn't offer IP connectivity. > >>I don't see how you determine that it is "belatedly". The console >>output doesn't indicate how long after it receives the ppp negotiation >>string it spawns the pppd process. It certainly should not spawn pppd Yes. it does. It waits for a login, and gets a ppp negotiation string back. It should NOT wait for a login. Noone uses that anymore ( and almost none did 10 years ago) O The problem is that his logs do NOT show the negotiation session in text form. That is NOT pppd. pppd shows the negotiations all in text form, exactly as you quote below. I have severe doubts that he is actually using pppd. > > I can see 1f28 identified as CalComp on the Linux USB list > (http://www.linux-usb.org/usb.ids), but no devices are listed. To me, > it sounds as if your problem is getting this thing to act as a modem. > Once the kernel can see it, wvdial or anything else ought to be able > to make the connection. The authentication failure you showed can > be isolated by looking at the LCP negotiations, but you'd have to get > pppd to debug mode (debug option) and set the system logging daemon to > save this output to one of the log files. Wvdial won't do this. The > logs would look something like this (canned response): > > ---------------- > PPP is like a two handed game of "Mother, may I" (popular with children > 50-100 years ago) where each player asks the other if they can do some > thing. There are three possible answers allowed: "yes", "no" and "no, > but" and the game has to be played step by step. Watch the line wraps > below - the log lines may get long, but all begin with a date/time. > > Jul 3 09:55:24 gtech pppd[924]: sent [LCP ConfReq id=0x1 <asyncmap > 0x0> <magic 0x8bab12d4> <pcomp> <accomp>] > Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfReq id=0x1 <asyncmap > 0x0> <magic 0x8bab12d4> <pcomp> <accomp>] > Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfReq id=0x1 < 00 04 00 > 00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> < mrru > 1524> <<endpoint [MAC:00:c0:7b:90:17:04]>] > > Here, this box said hello (sent LCP ConfReq) twice, before hearing from > the peer (rcvd = received from the peer). This box asks for four common > options (asyncmap = characters to escape, magic is a random 32 bit > number used to detect looped back connections, pcomp and accomp are two > header compression protocols.) The peer offers an empty Vendor > specific option (00 04 00 00), wants to have this system authenticate > with PAP (Password Authentication Protocol which shows up as > '<auth pap>'), wants to set a maximum packet size (MRU) it will accept, > wants us to 'escape' the XON/XOFF characters (asyncmap 0xa0000) and is > offering Multilink (mrru and endpoint variables). > > Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfRej id=0x1 < 00 04 00 > 00> < mrru 1524> <<endpoint [MAC:00:c0:7b:90:17:04]>] > > So, this box rejects (ConfRej = "no") the empty vendor option and the > Multilink. One rule of the game is that when something is rejected, it > can't be asked for again. > > Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfAck id=0x1 <asyncmap > 0x0> <magic 0x8bab12d4> <pcomp> <accomp>] > Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfReq id=0x2 <mru 1524> ><asyncmap 0xa0000> <auth pap> <pcomp> <accomp>] > Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfAck id=0x2 <mru 1524> ><asyncmap 0xa0000> <auth pap> <pcomp> <accomp>] > > The peer comes back and acknowledges (ConfAck = "yes") the original > 'hello' approving our requested options, and says hello again, but this > time without the unwanted stuff. This box acknowledges the peer. > > Jul 3 09:55:27 gtech pppd[924]: sent [PAP AuthReq id=0x1 user=<hidden> > password=<hidden>] > Jul 3 09:55:28 gtech pppd[924]: rcvd [PAP AuthAck id=0x1 ""] > > Because the peer asked for 'PAP' authentication (and we agreed to that), > this box sends in the username and password (here edited out), and the > peer comes back and approves the login. The (here) empty quotes in the > reply _may_ contain a greeting or some other message, but this is > optional. > --------------- > > Once the LCP (and authentication) negotiations are completed, ppp then > goes to an 'IPCP' negotiation to set up IP addresses and IP header > compression, and perhaps a 'CCP' negotiations to set up packet > compression - not really relevant here. The 'ppp' protocol is quite > versatile, and able to work with other networking besides IP (XNS, SNA, > Appletalk, IPv6, IPX, Banyan Vines... and more) depending on what the > link is needed for. > > You'd have to watch that 'auth' exchange. There would also be clues > (not shown here) if you are talking to the same peer every time, or > are talking to more than one (not unusual) perhaps with different ideas > of authentication modes. Wvdial doesn't appear to handle such > diversity, never mind handle it easily. > > Old guy
From: unruh on 14 Jan 2010 19:00 On 2010-01-14, Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote: > On Thu, 14 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in > article <slrnhkul1q.3nm.unruh(a)wormhole.physics.ubc.ca>, unruh wrote: > >>lrhorer <lrhorer(a)satx.rr.com> wrote: > > Geez Bill - I _WISH_ you'd learn how to trim stuff you're not > responding to off your replies. I have to use the 'tab' key to > find where you are replying to stuff. Ah yes, the conflict between readability and maintaining past history. I never go back into discussion to read the history, so I very much like to have the discussion available with teh answer. I detest cases where someone answers but I have no idea what the question is. On the other hand, I also hate having to search for the answers in an interminable history, but I tend to see that as the lesser of two evils. You do not. > >>> No, it's set to be much faster than that. I think it's set to 1/2 >>> second, but I don't have access to the router right now to check. > >>Sorry, that cannot be true. It takes much longer than that to dial >>and to connect. Why do you not set up the timeout for longer. > > Did you notice this is GSM and not plain ole telephones? I did, but I still do not believe 1/2 sec. response. > >>Anyway, what is the operating system on that "router", and where >>did you get that version of pppd. > > He's said it was Debian, and I don't think WvDial is used for other > than Linux and anu ppp. > >>> I suppose it could be wvdial that's updating resolv.conf, but >>> I'm pretty sure it's pppd. > >>They probably are. But I have no idea since you have a highly >>non-standard pppd. > > No idea where you got that idea. Because of the form of the pppd logs which he posted. They look nothing like the anu PPPD logs. > > Old guy
From: Moe Trin on 14 Jan 2010 21:52 On Fri, 15 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in article <slrnhkvc0c.a3o.unruh(a)wormhole.physics.ubc.ca>, unruh wrote: >Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote: >Ah yes, the conflict between readability and maintaining past history. I >never go back into discussion to read the history, so I very much like >to have the discussion available with teh answer. I detest cases where >someone answers but I have no idea what the question is. On the other >hand, I also hate having to search for the answers in an interminable >history, but I tend to see that as the lesser of two evils. You do not. You're using slrn now, not nn. Press the question mark key now, and you get key-stroke helps (press q to quit the help). The 'tab' key mentioned takes you to the next part of the article that isn't a reply. If you press the 'Esc' key then the 'p' key, it pulls up the previous article referred to. The sequence 'Esc' '1' 'Esc' 'p' will cause slrn ask the news server for all articles in the thread (and the news server _may_ provide them - you're posting from highwinds-media - I don't know if they do, giganews doesn't, but the server I normally use does). >> Did you notice this is GSM and not plain ole telephones? >I did, but I still do not believe 1/2 sec. response. I don't disbelieve it - that's a completely digital link. I wish Clifford would join in, as he has some experience with GSM links. >>> But I have no idea since you have a highly non-standard pppd. >> No idea where you got that idea. >Because of the form of the pppd logs which he posted. They look >nothing like the anu PPPD logs. True - those are the wvdial logs. Pretty useless, no? Old guy
From: Moe Trin on 14 Jan 2010 21:53
On Thu, 14 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in article <slrnhkvbnj.a3o.unruh(a)wormhole.physics.ubc.ca>, unruh wrote: >Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote: >> I'd look into that when you have time. It's hard to believe that >> failing 8-10 times before happening to work is designed behavior. >It is also very hard to believe that a phone could be answered in 1/2 >a second. Ie, the timeout has to be longer. In 'chat', that's the 'timeout' variable. WvDial doesn't seem to list anything that sets this, so it could be the phone itself deciding that no one is home. >Back in the days when pppd on dialup was popular, and when I wrote >that web page, one of the big problems was the difficulties people >had with wvdial. If it worked fine, if it did not, it was a mess, >and very difficult to debug. And wvdial made all sorts of unwarranted >assumptions. It really got in the way. It wasn't just wvdial - kppp and some of the whizzo distribution specific tools caused quite similar problems. >You can tellit not to try a login (I donot remember exaclty how >anymore) but chat really really is far simpler. Stupid Mode When wvdial is in Stupid Mode, it does not attempt to interpret any prompts from the terminal server. It starts pppd immediately after the modem connects. Apparently there are ISP's that actually give you a login prompt, but work only if you start PPP, rather than logging in. Go figure. Stupid Mode is (naturally) disabled by default. I always used to ask which of the authors the mode was named after. >wvdial assumes that first you log onto your service provider, and >then after that you run pppd. That was their authentication scheme. >Eventually the service providers discovered that there had existed >for 10-15 years something called pap or chap, and eventually they >all went over to that. Not quite. PPP goes back to 1989 (RFC1134). 'PAP' and 'CHAP' were described in RFC1334 (1992), but only PAP defined. CHAP-MD5 (RFC1994) dates from 1996, but that was after microsoft invented the telephone or the internet or something in win95. That was using PAP by default until microsoft invented MSCHAP-80 (RFC2433 in 1998) which you may recall was incompatible with CHAP-MD5. In 2000, they invented MSCHAP-81 which was incompatible with either CHAP-MD5 or MSCHAP-80. Both MSCHAP versions are supported by ANU pppd, but I think microsoft has silently dropped both versions. >But wvdial was started when, because many service providers read very >very slowly, they had not yet gotten to the chapter discussion pap >and chap. WvDial originated in late 1997, and win95 had made RFC1334 mandatory for most ISPs. There were a few holdouts - earthlink and netcom come to mind, and they supplied binaries to their windoze customers for login. >The problem is that his logs do NOT show the negotiation session in >text form. That is NOT pppd. pppd shows the negotiations all in text >form, exactly as you quote below. I have severe doubts that he is >actually using pppd. Other response - he's showing wvdial log data. Old guy |