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: unruh on 10 Jan 2010 23:53 On 2010-01-11, lrhorer <lrhorer(a)satx.rr.com> wrote: > lrhorer wrote: > >> unruh wrote: >> >>> On 2010-01-10, lrhorer <lrhorer(a)satx.rr.com> wrote: >>>> >>>> Hello, >>>> >>>> I originally posted a query about this over on alt.linux, >>>> and >>>> someone >>>> there suggested I post a query here. I am using wvdial to >>>> provide "dial up" broadband access to the Cricket >>>> wireless network using a Cal-Comp A600 GSM wireless modem on a >>>> headless >>>> router.. It's working fairly well, but there is one serious issue I >>>> need to resolve. After 12 hours online, the ISP shuts down the >>>> link. When this happens, the modem sometimes locks up, at least as >>>> far as >>>> wvdial is concerned. An attempt to dial again fails. Occasionally, >>>> the modem truly hangs, so that even a soft reboot won't recover the >>>> session. Since wvdial produces no logs, no externally readable >>>> status structure, and no exit codes, it's difficult to tell what >>>> action the router needs to take when the ppp link is down. >>>> >>>> Does anyone know of a slightly more sophisticated or >>>> better supported alternative to wvdial? I am looking at linuxconf, >>>> but there doesn't seem to be a Debian package for it, and the RPM >>>> package >>>> won't load under alien. The source code fails with a fair number of >>>> errors. I would really rather not start digging into problems with >>>> the >>>> RPM package or in the source code if I don't have to. The fact the >>>> newest version of linuxconf is from 2005 also suggests it may not be >>>> actively maintained, either >>> >>> Try looking at www.theory.physics.ubc.ca/ppp-linux.html for >>> techniques for debugging your ppp connection. >> >> The problem isn't at the ppn layer. The problem lies at the hardware >> layer, epcifically the modem locking up. > > That should have been, "...specifically..." >> > >>> One thing you could try is to kill >>> killall pppd >>> as root >>> before you try again. >> >> No, I'm not using pppd, and ppp is dead whenever the connection is >> closed. > > That's not what I meant to say. What I meant to say is that it locks > up before pppd is ever called. It loks up while the dialer is trying > to establish layer 1 connectivity. I'll double-check, though. Try using a chat sequence instead of wvdial. Sorry I cannot suggest one. I do not understand though. You said that you were connected for 12 hours when things went down. Or are you saying that after the ISP has diconnected you, then when you try to restablish the connection, things go south? >
From: lrhorer on 11 Jan 2010 13:54 unruh wrote: > On 2010-01-11, lrhorer <lrhorer(a)satx.rr.com> wrote: >> unruh wrote: >> >>> On 2010-01-10, lrhorer <lrhorer(a)satx.rr.com> wrote: >>>> >>>> Hello, >>>> >>>> I originally posted a query about this over on alt.linux, >>>> and >>>> someone >>>> there suggested I post a query here. I am using wvdial to >>>> provide "dial up" broadband access to the Cricket >>>> wireless network using a Cal-Comp A600 GSM wireless modem on a >>>> headless >>>> router.. It's working fairly well, but there is one serious issue >>>> I >>>> need to resolve. After 12 hours online, the ISP shuts down the >>>> link. When this happens, the modem sometimes locks up, at least as >>>> far as >>>> wvdial is concerned. An attempt to dial again fails. >>>> Occasionally, the modem truly hangs, so that even a soft reboot >>>> won't recover the >>>> session. Since wvdial produces no logs, no externally readable >>>> status structure, and no exit codes, it's difficult to tell what >>>> action the router needs to take when the ppp link is down. >>>> >>>> Does anyone know of a slightly more sophisticated or >>>> better supported alternative to wvdial? I am looking at linuxconf, >>>> but there doesn't seem to be a Debian package for it, and the RPM >>>> package >>>> won't load under alien. The source code fails with a fair number >>>> of >>>> errors. I would really rather not start digging into problems with >>>> the >>>> RPM package or in the source code if I don't have to. The fact the >>>> newest version of linuxconf is from 2005 also suggests it may not >>>> be actively maintained, either >>> >>> Try looking at www.theory.physics.ubc.ca/ppp-linux.html for >>> techniques for debugging your ppp connection. >> >> The problem isn't at the ppn layer. The problem lies at the hardware >> layer, epcifically the modem locking up. > > And you know this how? And if you are so sure why are you asking here > since hardware fixes do not get handled by Linux user groups. It does not appear to be a problem with the hardware, but rather the hardware layer. The modem has been replaced, and the behavior after replacement is the same as the behavior before replacement. Instead of returning coherent responses in wvdial when the modem is instructed to dial, it returns gibberish. Other commands return the "OK" response. >>> wvdial is simply a font end for the >>> thing that does the actual work, namely pppd. pppd can and does Unless I ma mistaken, pppd only does its work after layer 1 connectivity is established, is that not correct? I will double-check. She is bringing the router over this afternoon. >>> produce error messages to the daemon and local2 facilities. >> >> Yes, but there are no errors at that level, at least not until the >> modem locks up. > > Have you switched on logging for ppd? Have you set up the daemon and > local2 facilities to log to a file? No, but since the lock-up occurs before pppd is called, there doesn't seem to be much point. Again, I will double-check to make sure this is the case. > daemon.*;local2.* /var/log/daemonlog > in /etc/syslog.conf > and then do > killall -1 syslogd > > Have you looked at that file? Syslog? Of course. 'No errors. The daemon log also has bo error in it. I'll try adding the specific targets you mention, if they are not already there. >>> You need >>> to tell your system to record those and tell pppd to actually output >>> the debug messages. >>> >>> One thing you could try is to kill >>> killall pppd >>> as root >>> before you try again. >> >> No, I'm not using pppd, and ppp is dead whenever the connection is >> closed. > > ??? pppd is THE daemon for using ppp, and wvdial uses pppd > > ps auxww|grep pppd Returns nothing, as I recall. I will check again when the system gets here, if I can duplicate the problem. Troubleshooting network issues remotely is a real challenge. >>> Alternatively, have your system itself close the connection after >>> 11hr 45 min, and then restart it. >> >> That's what I am doing, or trying to do, although I use 11hr >> 17 min, in >> fact. >> >>> -- you must be paying pretty hefty >>> wireless bills to to be logged on for over 12hr a day. >> >> No, Cricket is broadband wireless. Or it is SUPPOSED to be. If it >> were > > What do you mean by wireless? GSM? In which case I am really surprized > that they are not charging you through the teeth. Actually, I believe it is CDMA, but there are a number of broadband wireless companies out there, both GSM and CDMA. In this case: http://www.mycricket.com/broadband/plans/broadband40 >> truly broadband, they would not shut down the link after 12 hours. >> Nonetheless, there are no fees for connection time. Broadband >> routers are always logged on 24/7.
From: lrhorer on 11 Jan 2010 14:07 unruh wrote: > On 2010-01-11, lrhorer <lrhorer(a)satx.rr.com> wrote: >> lrhorer wrote: >> >>> unruh wrote: >>> >>>> On 2010-01-10, lrhorer <lrhorer(a)satx.rr.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I originally posted a query about this over on alt.linux, >>>>> and >>>>> someone >>>>> there suggested I post a query here. I am using wvdial to >>>>> provide "dial up" broadband access to the Cricket >>>>> wireless network using a Cal-Comp A600 GSM wireless modem on a >>>>> headless >>>>> router.. It's working fairly well, but there is one serious issue >>>>> I >>>>> need to resolve. After 12 hours online, the ISP shuts down the >>>>> link. When this happens, the modem sometimes locks up, at least as >>>>> far as >>>>> wvdial is concerned. An attempt to dial again fails. >>>>> Occasionally, the modem truly hangs, so that even a soft reboot >>>>> won't recover the >>>>> session. Since wvdial produces no logs, no externally readable >>>>> status structure, and no exit codes, it's difficult to tell what >>>>> action the router needs to take when the ppp link is down. >>>>> >>>>> Does anyone know of a slightly more sophisticated or >>>>> better supported alternative to wvdial? I am looking at >>>>> linuxconf, but there doesn't seem to be a Debian package for it, >>>>> and the RPM package >>>>> won't load under alien. The source code fails with a fair number >>>>> of >>>>> errors. I would really rather not start digging into problems >>>>> with the >>>>> RPM package or in the source code if I don't have to. The fact >>>>> the newest version of linuxconf is from 2005 also suggests it may >>>>> not be actively maintained, either >>>> >>>> Try looking at www.theory.physics.ubc.ca/ppp-linux.html for >>>> techniques for debugging your ppp connection. >>> >>> The problem isn't at the ppn layer. The problem lies at the >>> hardware layer, epcifically the modem locking up. >> >> That should have been, "...specifically..." >>> >> >>>> One thing you could try is to kill >>>> killall pppd >>>> as root >>>> before you try again. >>> >>> No, I'm not using pppd, and ppp is dead whenever the connection is >>> closed. >> >> That's not what I meant to say. What I meant to say is that >> it locks >> up before pppd is ever called. It loks up while the dialer is trying >> to establish layer 1 connectivity. I'll double-check, though. > > Try using a chat sequence instead of wvdial. Yeah, I thought of that. Since the router lives an hour from here by car, my access to it is limited. Writing and debugging a chat script would not normally be an issue, but when I can only gain local access for an hour or so every week or two, it makes debugging difficult, especially when the issue is normally only seen after 12 hours online. > Sorry I cannot suggest > one. I do not understand though. You said that you were connected for > 12 hours when things went down. Or are you saying that after the ISP > has diconnected you, then when you try to restablish the connection, > things go south? Either the ISP disconnects or the modem does. I suppose the modem could have some sort of internal timer that shuts it down after 12 hours, but I expect it is the ISP's router which does this. And yes, the problem is only experienced after the link is dropped. I can sometimes reproduce the issue by `kill -9 <pid>` on the wvdial session. Often not, however, in which case establishing a new session works just fine.
From: unruh on 11 Jan 2010 19:10 On 2010-01-11, lrhorer <lrhorer(a)satx.rr.com> wrote: > unruh wrote: > >> On 2010-01-11, lrhorer <lrhorer(a)satx.rr.com> wrote: >>> unruh wrote: >>> >>>> On 2010-01-10, lrhorer <lrhorer(a)satx.rr.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I originally posted a query about this over on alt.linux, >>>>> and >>>>> someone >>>>> there suggested I post a query here. I am using wvdial to >>>>> provide "dial up" broadband access to the Cricket >>>>> wireless network using a Cal-Comp A600 GSM wireless modem on a >>>>> headless >>>>> router.. It's working fairly well, but there is one serious issue >>>>> I >>>>> need to resolve. After 12 hours online, the ISP shuts down the >>>>> link. When this happens, the modem sometimes locks up, at least as >>>>> far as >>>>> wvdial is concerned. An attempt to dial again fails. >>>>> Occasionally, the modem truly hangs, so that even a soft reboot >>>>> won't recover the >>>>> session. Since wvdial produces no logs, no externally readable >>>>> status structure, and no exit codes, it's difficult to tell what >>>>> action the router needs to take when the ppp link is down. >>>>> >>>>> Does anyone know of a slightly more sophisticated or >>>>> better supported alternative to wvdial? I am looking at linuxconf, >>>>> but there doesn't seem to be a Debian package for it, and the RPM >>>>> package >>>>> won't load under alien. The source code fails with a fair number >>>>> of >>>>> errors. I would really rather not start digging into problems with >>>>> the >>>>> RPM package or in the source code if I don't have to. The fact the >>>>> newest version of linuxconf is from 2005 also suggests it may not >>>>> be actively maintained, either >>>> >>>> Try looking at www.theory.physics.ubc.ca/ppp-linux.html for >>>> techniques for debugging your ppp connection. >>> >>> The problem isn't at the ppn layer. The problem lies at the hardware >>> layer, epcifically the modem locking up. >> >> And you know this how? And if you are so sure why are you asking here >> since hardware fixes do not get handled by Linux user groups. > > It does not appear to be a problem with the hardware, but rather the > hardware layer. The modem has been replaced, and the behavior after > replacement is the same as the behavior before replacement. Instead of > returning coherent responses in wvdial when the modem is instructed to > dial, it returns gibberish. Other commands return the "OK" response. Sounds like the pppd/chat layer to me. Ie, the response you are getting back is a garbled version of the negotiation. Anyway, have you tried to set up debug logging and looking at the files yet? If not, I have no idea why you came here for help, since you seem to be convinced that your theory, without testing, is right. > >>>> wvdial is simply a font end for the >>>> thing that does the actual work, namely pppd. pppd can and does > > Unless I ma mistaken, pppd only does its work after layer 1 > connectivity is established, is that not correct? I will double-check. > She is bringing the router over this afternoon. No. pppd does the whole negotiation. wvdial/chat set up the modem and dial the phone, and then hand off to pppd to do all negotiation. > >>>> produce error messages to the daemon and local2 facilities. >>> >>> Yes, but there are no errors at that level, at least not until the >>> modem locks up. >> >> Have you switched on logging for ppd? Have you set up the daemon and >> local2 facilities to log to a file? > > No, but since the lock-up occurs before pppd is called, there doesn't > seem to be much point. Again, I will double-check to make sure this is > the case. Sheesh. > >> daemon.*;local2.* /var/log/daemonlog >> in /etc/syslog.conf >> and then do >> killall -1 syslogd >> >> Have you looked at that file? > > Syslog? Of course. 'No errors. The daemon log also has bo error in > it. I'll try adding the specific targets you mention, if they are not > already there. No, the file where daemon and local2 logfacilities get written to. In the above it is /var/log/daemonlog. > >>>> You need >>>> to tell your system to record those and tell pppd to actually output >>>> the debug messages. >>>> >>>> One thing you could try is to kill >>>> killall pppd >>>> as root >>>> before you try again. >>> >>> No, I'm not using pppd, and ppp is dead whenever the connection is >>> closed. >> >> ??? pppd is THE daemon for using ppp, and wvdial uses pppd >> >> ps auxww|grep pppd > > Returns nothing, as I recall. I will check again when the system gets > here, if I can duplicate the problem. Troubleshooting network issues > remotely is a real challenge. > >>>> Alternatively, have your system itself close the connection after >>>> 11hr 45 min, and then restart it. >>> >>> That's what I am doing, or trying to do, although I use 11hr >>> 17 min, in >>> fact. >>> >>>> -- you must be paying pretty hefty >>>> wireless bills to to be logged on for over 12hr a day. >>> >>> No, Cricket is broadband wireless. Or it is SUPPOSED to be. If it >>> were >> >> What do you mean by wireless? GSM? In which case I am really surprized >> that they are not charging you through the teeth. > > Actually, I believe it is CDMA, but there are a number of broadband > wireless companies out there, both GSM and CDMA. In this case: > http://www.mycricket.com/broadband/plans/broadband40 > >>> truly broadband, they would not shut down the link after 12 hours. >>> Nonetheless, there are no fees for connection time. Broadband >>> routers are always logged on 24/7.
From: lrhorer on 12 Jan 2010 00:34
lrhorer wrote: > lrhorer wrote: > >> unruh wrote: >> >>> On 2010-01-10, lrhorer <lrhorer(a)satx.rr.com> wrote: >>>> >>>> Hello, >>>> >>>> I originally posted a query about this over on alt.linux, >>>> and >>>> someone >>>> there suggested I post a query here. I am using wvdial to >>>> provide "dial up" broadband access to the Cricket >>>> wireless network using a Cal-Comp A600 GSM wireless modem on a >>>> headless >>>> router.. It's working fairly well, but there is one serious issue >>>> I >>>> need to resolve. After 12 hours online, the ISP shuts down the >>>> link. When this happens, the modem sometimes locks up, at least as >>>> far as >>>> wvdial is concerned. An attempt to dial again fails. >>>> Occasionally, the modem truly hangs, so that even a soft reboot >>>> won't recover the >>>> session. Since wvdial produces no logs, no externally readable >>>> status structure, and no exit codes, it's difficult to tell what >>>> action the router needs to take when the ppp link is down. >>>> >>>> Does anyone know of a slightly more sophisticated or >>>> better supported alternative to wvdial? I am looking at linuxconf, >>>> but there doesn't seem to be a Debian package for it, and the RPM >>>> package >>>> won't load under alien. The source code fails with a fair number >>>> of >>>> errors. I would really rather not start digging into problems with >>>> the >>>> RPM package or in the source code if I don't have to. The fact the >>>> newest version of linuxconf is from 2005 also suggests it may not >>>> be actively maintained, either >>> >>> Try looking at www.theory.physics.ubc.ca/ppp-linux.html for >>> techniques for debugging your ppp connection. >> >> The problem isn't at the ppn layer. The problem lies at the hardware >> layer, epcifically the modem locking up. > > That should have been, "...specifically..." >> > >>> One thing you could try is to kill >>> killall pppd >>> as root >>> before you try again. >> >> No, I'm not using pppd, and ppp is dead whenever the connection is >> closed. > > That's not what I meant to say. What I meant to say is that > it locks > up before pppd is ever called. It loks up while the dialer is trying > to establish layer 1 connectivity. I'll double-check, though. I double-checked when she brought the router over, and when it dies, sometimes it is before pppd is called (and pppd never gets called), and other times the failure seems to be when pppd is called. Either way, however, pppd won't be active since pppd quits after an authentication error. Here is an example of one failure where pppd does get called: ATDT#777 CONNECT --> Carrier detected. Waiting for prompt. ~[7f]}#@!}!}!} }9}"}&} } } } }#}%B#}%}%}&a_cp}'}"}(}"[03]3~ --> PPP negotiation detected. --> Starting pppd at Mon Jan 11 21:25:39 2010 --> Pid of pppd: 10153 --> Using interface ppp0 --> pppd: ��][08]��][08] --> pppd: ��][08]��][08] --> pppd: ��][08]��][08] --> pppd: ��][08]��][08] --> pppd: ��][08]��][08] --> Disconnecting at Mon Jan 11 21:25:46 2010 --> The PPP daemon has died: Authentication error. --> We failed to authenticate ourselves to the peer. --> Maybe bad account or password? (exit code = 19) --> man pppd explains pppd error codes in more detail. --> I guess that's it for now, exiting --> The PPP daemon has died. (exit code = 19) Exit code 19 is just "We failed to authenticate ourselves to the peer." Other times it has gotten nothing but garbage after the carrier is detected, so it never calls pppd in the first place. Of course, when the failure involves a total deregsitration of the device, then /dev/ACM0 doesn't even exist, so the dialer never even sees the modem. Note in the attempt above the modem does seem to be reporting a good connection, but it never gets the authentication. The point that is being missed, however, is that I am not asking for help with troubleshooting the modem. Rather, I am looking for a communications solution that will allow me to have better granularity in interfacing the router's control scripts with the dialing utility. So far, the front runner seems to be writing a chat script. If there is a better solution, though, I'm all ears. |