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: Jerry Peters on 12 Jan 2010 16:31 lrhorer <lrhorer(a)satx.rr.com> wrote: > > 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. You should be; it sounds like the modem gets confused and drops off the USB bus. Have you tried removing and re-inserting the cdc-acm module? That *might* be enough to re-initialize the modem to a usable state. There are also ways to control the power to a USB port via sysfs I believe. This would allow you to fully reset the modem. As for "interfacing the router's control scripts with the dialing utility": chat. Jerry
From: lrhorer on 14 Jan 2010 03:24 Moe Trin wrote: > On Mon, 11 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, > in article <M7KdnSnIsJsXmdHWnZ2dnUVZ_v1i4p2d(a)giganews.com>, lrhorer > wrote: > >>Moe Trin wrote: > >>> And what is the exact indication that dialing failed? The >>> soft-reboot is also suggesting the modem initiation string is wrong. > >> Well, when the modem is well and truly hung, it disappears >>altogether. The computer no longer recognizes that it is attached to >>the USB port - lsusb shows nothing at all - and of course udev >>de-registers the /dev/ttyACM0 device, so no string of any sort is >>going to help at that point. > > The fact that the device is disappearing would seem to be the problem. > In Message-ID: <M7KdnS7IsJt869bWnZ2dnUVZ_v3_fwAA(a)giganews.com>, you > say: > > ] 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. > > I'd want to find out why it's disappearing from lsusb - never mind > /dev/ttyACM0. Well, ultimately I do, too, of course. In the mean time, however, I need to account for and handle the possibility, even if it rarely (or hopefully never) occurs in daily useage. > I think you know that stuff doesn't happen randomly, No, of course not. Most of this is happening because I am forcing the issue setting up failure scenarios. Nonetheless, more than one of these failure modes has occurred during simple testing, rather than during stress testing. > and something wvdial is doing (perhaps because of those init-strings) > is randomly hosing the device file. It's certainly possible, but I don't think that is the case, at least not for most of the failure modes. I could be wrong, of course. Further testing will tell. but before I can really do any failure testing, I need to come up with an ironclad means of automatic recovery under the worst case scenario. The router is 50 miles away from me, in the possession of someone who can barely use a mouse and finds browsing the web a daunting proposition. >>Well of *COURSE* it's called from the command line. I believe I >>mentioned more than once this is a headless router. > > I first saw the word headless in yesterday's alt.linux post, which I > read _after_ reading c.o.l.n. > >>The commands are all called from a startup script in /etc/init.d. > > In my response yesterday in alt.linux, I showed a pair of scripts to > operate the connection directly rather than using a less than helpful > helper program like 'wvdial'. Even simpler, > > [galileo ~]$ cat /etc/ppp/options | column > lock crtscts nodetach defaultroute persist > /dev/modem modem 115200 noipdefault > [galileo ~]$ ls -l /etc/ppp/*ap-secrets /etc/resolv.conf > -rw------- 1 root root 99 Jun 16 2008 > /etc/ppp/chap-secrets > -rw------- 1 root root 94 Jun 16 2008 > /etc/ppp/pap-secrets > -rw-r--r-- 1 root root 49 Jun 16 2008 /etc/resolv.conf > [galileo ~]$ cat /usr/local/bin/dialin.example > exec /usr/sbin/pppd user ibuprofin(a)example.com connect > "/usr/sbin/chat ABORT BUSY \"\" AT\&F1 OK ATDT2662902 CONNECT > \"\d\c\"" > [galileo ~]$ Thanks. I've looked briefly into chat as a solution. I may use it, or perhaps minicom + expect. > If your IP address is going to be changing, you > probably want to stick a '1' into /proc/sys/net/ipv4/ip_dynaddr It does, with every single call. What's more, they are using NAT, because they provide the user with non-routable addresses in the 10.100 range, as you can see above. They also block TCP port 25, which many ISPs do to help cut down spam, but then they don't bother to provide an e-mail server themselves, which is incumbent on any ISP who blocks port 25. Setting up mail for her was a real pain. I finally resorted to setting up a gmail account with an SSL SMTP server and hosting her POP mail over a VPN to an IMAP daemon on one of my servers here at my house. Oh, by the way, they also block any VPN using PPTP or IPSec. I set up openvpn over SSL. The minimum latency on any connection is 180ms, and the best my sister can do is about 400ms. If one uses any significant amount of bandwidth, they throttle the link by artificially increasing the latency over a period of time. When working remotely using VNC to help my sister with basic Windows tutoring, I've encountered latencies consistently as high as 14 seconds! Glacial doesn't begin to describe window updates over a 14 second link, even with only an 8 bit colormap. It's definitely a low rent operation, but OTOH they are inexpensive ($40 flat rate a month), and they do have service coverage at my sister's house. Verizon and Sprint do not. > There is also the Debian 'pppconf' program which creates the needed > connection setup/teardown scripts, and the author of that ap does > read these newsgroups. Yeah, I looked at that. I haven't settled fully on any option, yet. >>I might try that. The bigger issue, however, is that logging to a log >>file - especially an output as verbose as that produced by wvdial - >>and then parsing it with a pseudo-linguistic recognition script is not >>the best way to try to programmatically determine the status of a >>running application. > > There shouldn't be that much logging. With full debugging, the script > above would produce around 40 lines of ASCII in total - bringing up > the link and tearing it down. Um, no. I have to determine if the device is registered on the USB bus, and restart it if not. Then I have to determine if it is properly "fipped" into modem mode, and force it to switch modes if not. Then of course I have to make sure it is responding on the pseudo tty port (/dev/ttyACM0), and once again restart it if not. Then of course I have to make sure it gets a carrier, and finally turn it over to pppd. If that fails, I have to start over again. >>Secondly, this is a router, so everything it does must be done >>automatically. Nothing interactive can be employed to facilitate >>systems operations, unless of course I write an expect script or >>some such to interact with the system. Nothing like `less` would >>fill that bill. > > You have no shell access to read log files? What do you mean by "me"? If by "me", you mean me, personally, then I don't have any sort of access at all until the router can successfully dial out, establish networking, and finally establish the VPN tunnel to my server. If any of that fails, I'm perfectly blind. If by "me" you mean the router itself, then of course it can parse logs under the control of my scripts or compiled programs, but an automated / embedded system needs to limit the number of responses it is expected to encounter. Exit codes work great, as do signals, semaphores, and simple status files such as those in /proc and /sys. If by "me" you mean, "can I read the logs to see what went wrong for troubleshooting purposes", then of course I can - after networking is up and running again, but once more I am not really at the troubleshooting stage of the project, yet - at least not in-depth troubleshooting. To be sure, I want to eliminate as many of the more common causes of failure as I can, but it is more important at this point to build the system to be fault tolerant, allowing it to recover from whatever problem - expected or otherwise - that might occur than it is to stamp out as many gremlins as I can find. >>When it is working properly, the output from wvdial looks like >>this: > > I'd hardly consider it working properly, but anyway: > >>--> WvDial: Internet dialer version 1.60 >>--> Cannot get information for serial port. > > Trying to read the UART, and failing. That's likely due to this being > a USB port. > >>--> Initializing modem. >>--> Sending: ATZ >>ATZ >>OK > > So it sends a "reset to an unknown saved configuration", and receives > an OK - it can talk to the modem. > >>--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 >>ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 >>OK > > Sent some useless stuff not applicable to a USB device, and got > another OK response I haven't delved into the command codes, yet, but the standard AT commands are evidently implemented by the modem, albeit differently than a regular PSTN modem. The string was given to me by someone else who got his A600 working. How much is superfluous, I don't yet know. >>--> Sending: ATDT#777 >>--> Waiting for carrier. >>ATDT#777 >>NO CARRIER >>--> No Carrier! Trying again. > > Supposedly dialed a number, but no modem answered within the timeout > period - that's normally 45 seconds. 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. The example I posted took less than 10 seconds to connect. Unless it fails altogether, it has never taken more than 90 seconds to do everything, including clearing the firewall, shutting down the Ethernet port, switching the modem, dialing, establishing ppp, turning the Ethernet port back on, establishing the VPN tunnel, clearing the firewall again, verifying connectivity, establishing DNS, establishing NAT, putting the (correct) firewall back in place, and setting up the routes. It's not unusual for it to attempt dialing 8 or 10 times, though. > [repeats snipped] > >>--> Sending: ATDT#777 >>--> Waiting for carrier. >>ATDT#777 >>CONNECT >>--> Carrier detected. Waiting for prompt. > > This time, a modem was detected on the other end of the line. As I > mentioned, the idiots from wvdial are still living in the past and > think there will be a LOGIN: prompt. > >>~[7f]}#@!}!}!} }9}"}&} } } } }#}%B#}%}%}&X[05]@[16]}'}"}(}"}9y~ Or else that is just a generic status message which assumes nothing about what might be found at the other end. 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. > Instead, the peer sends a ppp frame, like every ISP has been doing > for the past 15 plus years. > >>--> PPP negotiation detected. And obviously it responds appropriately. I haven't looked into the guts of wvdial, and it might indeed be buggy and klunky, but the fact they employ a response you don't like and support older and less commonly used protocols isn't a valid criticism, when it clearly does support a more universal one. It also would not surprise me if there are not ISPs out there who still don't implement ppp. >>--> Starting pppd at Mon Jan 11 21:30:54 2010 >>--> Pid of pppd: 14384 > > and wvdial belatedly starts pppd. 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 until it is certain the other end actually is pppd, unless it is specifically told to do so by it's configuration file or a command line option. >>--> pppd: <EF><BF><BD>'<EF><BF><BD>[08]<EF><BF><BD>%<EF><BF><BD>[08] > > This should be 8 bit ppp frames - hard to say what it actually is. I agree with you, here. It certainly should be better able to translate the protocols into something more intelligible. That's one reason I asked for alternatives. > [remainder of ``log'' snipped] > > and it's getting RFC1918 addresses for local, remote/peer, and two > DNS servers. My ISPs don't play Musical IP Addresses with the DNS, > so I've got those written directly into /etc/resolv.conf. Most of your better ISPs try to avoid shuffling their clients' IP addresses. This is not one of your better ISPs. They are inexpensive, though, and my sister is retired and living on a very fixed income. > There is a > 'usepeerdns' option to pppd to cause it to ask the peer for these > addresses, but pppd puts them into /etc/ppp/resolv.conf rather than > screwing with a system configuration file - you could soft-link the > two if needed. It's in the pppd man page. It already does. I suppose it could be wvdial that's updating resolv.conf, but I'm pretty sure it's pppd. >>> If you're using Debian, the normal tool is pppconf which creates >>> 'pon' and 'poff'. > >> Since the failure doesn't usually seem to be in pppd, I'm not sure >>these will be helpful. I'll take a look, though. > > The failure _seems_ to be caused by the modem disappearing. Why that > happens is anyone's guess, but my guess would be due to those plain > old generic telephone modem init-strings used by wvdial. Well, it's possible, of course. I wouldn't expect it to be the case, however, or else I would expect the modem to never connect at all. I'll certainly run it down once I have recovery working solidly. >>> Concur - also look carefully through any documentation for your >>> modem, > >> You're kidding me, right? The modem documentation is a single sheet >>of paper about the size of a credit card. I've found nothing online, >>either specific to the modem. > > Must be hell - did this modem come with a windoze disk? No, it's worse than that. The box it comes in would not fit an ordinary mouse. The modem starts up in storage mode with an executable which runs automatically and checks to see if the system is already configured with their canned application. If not, it loads itself into Windows and installs the device drivers and the canned application, along with a volatile initialization application, run only once to initialize the modem and then never again. Windows then issues a switch command which "flips" the modem from storage mode into modem mode, and the modem disappears as device 1f28:0021 on its initial USB address and reappears as 1f28:0020 on its original USB address +1. The initialization routine initializes the modem for access and terminates, resetting the modem. Thereafter, it will respond to AT commands. Of course, in Linux, none of this happens automagically. Instead, I use a little utility produced by a 3rd party developer to handle just such modems under Linux which switches the device into modem mode. It works very well on a wide variety of such devices. Thereafter, it acts like any other CDMA modem, responding on /dev/ttyACMx. > There will > be a windoze file that contains the modem init strings. Uh-uh. Binaries only. 'All canned applications with no user readable files, including no documentation. Indeed, under Windows it isn't even possible to read the files at all, since the modem is immediately flipped out of storage mode the moment it is recognized by Windows. > I don't do windoze, I try not to, but unfortunately my job requires it. > so I don't know which file it is, but greping for "AT" > should turn it up. Probably one of the smaller files (the bigger > ones are often bitmap icons for the desktop). Good luck It might be embedded as text in one of the binaries. My sister is bringing the router over tomorrow. I'll try taking a look then. It can't hurt.
From: unruh on 14 Jan 2010 12:28 On 2010-01-14, lrhorer <lrhorer(a)satx.rr.com> wrote: > Moe Trin wrote: > >> On Mon, 11 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, >> in article <M7KdnSnIsJsXmdHWnZ2dnUVZ_v1i4p2d(a)giganews.com>, lrhorer >> wrote: >> >>>Moe Trin wrote: >> >>>> And what is the exact indication that dialing failed? The >>>> soft-reboot is also suggesting the modem initiation string is wrong. >> >>> Well, when the modem is well and truly hung, it disappears >>>altogether. The computer no longer recognizes that it is attached to >>>the USB port - lsusb shows nothing at all - and of course udev >>>de-registers the /dev/ttyACM0 device, so no string of any sort is >>>going to help at that point. >> >> The fact that the device is disappearing would seem to be the problem. >> In Message-ID: <M7KdnS7IsJt869bWnZ2dnUVZ_v3_fwAA(a)giganews.com>, you >> say: >> >> ] 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. >> >> I'd want to find out why it's disappearing from lsusb - never mind >> /dev/ttyACM0. > > Well, ultimately I do, too, of course. In the mean time, however, I > need to account for and handle the possibility, even if it rarely (or > hopefully never) occurs in daily useage. > >> I think you know that stuff doesn't happen randomly, > > No, of course not. Most of this is happening because I am forcing the > issue setting up failure scenarios. Nonetheless, more than one of > these failure modes has occurred during simple testing, rather than > during stress testing. > >> and something wvdial is doing (perhaps because of those init-strings) >> is randomly hosing the device file. > > It's certainly possible, but I don't think that is the case, at least > not for most of the failure modes. I could be wrong, of course. > Further testing will tell. but before I can really do any failure > testing, I need to come up with an ironclad means of automatic recovery > under the worst case scenario. The router is 50 miles away from me, in > the possession of someone who can barely use a mouse and finds browsing > the web a daunting proposition. > >>>Well of *COURSE* it's called from the command line. I believe I >>>mentioned more than once this is a headless router. >> >> I first saw the word headless in yesterday's alt.linux post, which I >> read _after_ reading c.o.l.n. >> >>>The commands are all called from a startup script in /etc/init.d. >> >> In my response yesterday in alt.linux, I showed a pair of scripts to >> operate the connection directly rather than using a less than helpful >> helper program like 'wvdial'. Even simpler, >> >> [galileo ~]$ cat /etc/ppp/options | column >> lock crtscts nodetach defaultroute persist >> /dev/modem modem 115200 noipdefault >> [galileo ~]$ ls -l /etc/ppp/*ap-secrets /etc/resolv.conf >> -rw------- 1 root root 99 Jun 16 2008 >> /etc/ppp/chap-secrets >> -rw------- 1 root root 94 Jun 16 2008 >> /etc/ppp/pap-secrets >> -rw-r--r-- 1 root root 49 Jun 16 2008 /etc/resolv.conf >> [galileo ~]$ cat /usr/local/bin/dialin.example >> exec /usr/sbin/pppd user ibuprofin(a)example.com connect >> "/usr/sbin/chat ABORT BUSY \"\" AT\&F1 OK ATDT2662902 CONNECT >> \"\d\c\"" >> [galileo ~]$ > > Thanks. I've looked briefly into chat as a solution. I may use it, or > perhaps minicom + expect. Use chat. > >> If your IP address is going to be changing, you >> probably want to stick a '1' into /proc/sys/net/ipv4/ip_dynaddr > > It does, with every single call. What's more, they are using NAT, > because they provide the user with non-routable addresses in the 10.100 > range, as you can see above. They also block TCP port 25, which many > ISPs do to help cut down spam, but then they don't bother to provide an > e-mail server themselves, which is incumbent on any ISP who blocks port > 25. Setting up mail for her was a real pain. I finally resorted to > setting up a gmail account with an SSL SMTP server and hosting her POP > mail over a VPN to an IMAP daemon on one of my servers here at my > house. Oh, by the way, they also block any VPN using PPTP or IPSec. I > set up openvpn over SSL. The minimum latency on any connection is > 180ms, and the best my sister can do is about 400ms. If one uses any > significant amount of bandwidth, they throttle the link by artificially > increasing the latency over a period of time. When working remotely > using VNC to help my sister with basic Windows tutoring, I've > encountered latencies consistently as high as 14 seconds! Glacial > doesn't begin to describe window updates over a 14 second link, even > with only an 8 bit colormap. Lunatic. I assume it is they who supplied you with that usb modem as well. I would say it is defective and you should be requesting a new one. For you to waste as much time as you have on a device which cost lets say $50 is silly. Their modem should not be dieing and disconnecting. As for another one, or buy another one. > > It's definitely a low rent operation, but OTOH they are inexpensive > ($40 flat rate a month), and they do have service coverage at my > sister's house. Verizon and Sprint do not. > >> There is also the Debian 'pppconf' program which creates the needed >> connection setup/teardown scripts, and the author of that ap does >> read these newsgroups. > > Yeah, I looked at that. I haven't settled fully on any option, yet. > >>>I might try that. The bigger issue, however, is that logging to a log >>>file - especially an output as verbose as that produced by wvdial - >>>and then parsing it with a pseudo-linguistic recognition script is not >>>the best way to try to programmatically determine the status of a >>>running application. >> >> There shouldn't be that much logging. With full debugging, the script >> above would produce around 40 lines of ASCII in total - bringing up >> the link and tearing it down. > > Um, no. I have to determine if the device is registered on the USB > bus, and restart it if not. Then I have to determine if it is > properly "fipped" into modem mode, and force it to switch modes if not. > Then of course I have to make sure it is responding on the pseudo tty > port (/dev/ttyACM0), and once again restart it if not. Then of course > I have to make sure it gets a carrier, and finally turn it over to > pppd. If that fails, I have to start over again. > >>>Secondly, this is a router, so everything it does must be done >>>automatically. Nothing interactive can be employed to facilitate >>>systems operations, unless of course I write an expect script or >>>some such to interact with the system. Nothing like `less` would >>>fill that bill. >> >> You have no shell access to read log files? > > What do you mean by "me"? If by "me", you mean me, personally, then I > don't have any sort of access at all until the router can successfully > dial out, establish networking, and finally establish the VPN tunnel to > my server. If any of that fails, I'm perfectly blind. If by "me" you > mean the router itself, then of course it can parse logs under the > control of my scripts or compiled programs, but an automated / embedded > system needs to limit the number of responses it is expected to > encounter. Exit codes work great, as do signals, semaphores, and > simple status files such as those in /proc and /sys. If by "me" you > mean, "can I read the logs to see what went wrong for troubleshooting > purposes", then of course I can - after networking is up and running > again, but once more I am not really at the troubleshooting stage of > the project, yet - at least not in-depth troubleshooting. To be sure, > I want to eliminate as many of the more common causes of failure as I > can, but it is more important at this point to build the system to be > fault tolerant, allowing it to recover from whatever problem - expected > or otherwise - that might occur than it is to stamp out as many > gremlins as I can find. > >>>When it is working properly, the output from wvdial looks like >>>this: >> >> I'd hardly consider it working properly, but anyway: >> >>>--> WvDial: Internet dialer version 1.60 >>>--> Cannot get information for serial port. >> >> Trying to read the UART, and failing. That's likely due to this being >> a USB port. >> >>>--> Initializing modem. >>>--> Sending: ATZ >>>ATZ >>>OK >> >> So it sends a "reset to an unknown saved configuration", and receives >> an OK - it can talk to the modem. >> >>>--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 >>>ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 >>>OK >> >> Sent some useless stuff not applicable to a USB device, and got >> another OK response > > I haven't delved into the command codes, yet, but the standard AT > commands are evidently implemented by the modem, albeit differently > than a regular PSTN modem. The string was given to me by someone else > who got his A600 working. How much is superfluous, I don't yet know. > >>>--> Sending: ATDT#777 >>>--> Waiting for carrier. >>>ATDT#777 >>>NO CARRIER >>>--> No Carrier! Trying again. >> >> Supposedly dialed a number, but no modem answered within the timeout >> period - that's normally 45 seconds. > > 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. The 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. > example I posted took less than 10 seconds to connect. Unless it fails > altogether, it has never taken more than 90 seconds to do everything, > including clearing the firewall, shutting down the Ethernet port, > switching the modem, dialing, establishing ppp, turning the Ethernet > port back on, establishing the VPN tunnel, clearing the firewall again, > verifying connectivity, establishing DNS, establishing NAT, putting the > (correct) firewall back in place, and setting up the routes. It's not > unusual for it to attempt dialing 8 or 10 times, though. If that is because of a highly inappropriate timeout, then you should fix that. > >> [repeats snipped] >> >>>--> Sending: ATDT#777 >>>--> Waiting for carrier. >>>ATDT#777 >>>CONNECT >>>--> Carrier detected. Waiting for prompt. >> >> This time, a modem was detected on the other end of the line. As I >> mentioned, the idiots from wvdial are still living in the past and >> think there will be a LOGIN: prompt. >> >>>~[7f]}#@!}!}!} }9}"}&} } } } }#}%B#}%}%}&X[05]@[16]}'}"}(}"}9y~ > > Or else that is just a generic status message which assumes nothing > about what might be found at the other end. 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. No, it is not. It is the remote side sending a ppp negotiation frame. wvdial is well known for inappropriately waiting for a login prompt. That is just wrong. Again, I strongly suggest that web page for setting up an appropriate response. On the other hand, I have no idea what sort of ppp you have. The return messages it is giving you are just bizarre. They should be text messages. Anyway, what is the operating system on that "router", and where did y ou get that version of pppd. > >> Instead, the peer sends a ppp frame, like every ISP has been doing >> for the past 15 plus years. >> >>>--> PPP negotiation detected. > > And obviously it responds appropriately. I haven't looked into the No it obviously does NOT respond properly. That by chance once in 8 times it connects is a fluke rather than proper operation. > guts of wvdial, and it might indeed be buggy and klunky, but the fact > they employ a response you don't like and support older and less > commonly used protocols isn't a valid criticism, when it clearly does > support a more universal one. It also would not surprise me if there Oh yes it is. I have dealt with complaints about wvdial for 10 years. > are not ISPs out there who still don't implement ppp. No, there are not. ppp is how it works. > >>>--> Starting pppd at Mon Jan 11 21:30:54 2010 >>>--> Pid of pppd: 14384 >> >> and wvdial belatedly starts pppd. > > 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 > until it is certain the other end actually is pppd, unless it is > specifically told to do so by it's configuration file or a command line > option. > >>>--> pppd: <EF><BF><BD>'<EF><BF><BD>[08]<EF><BF><BD>%<EF><BF><BD>[08] >> >> This should be 8 bit ppp frames - hard to say what it actually is. > > I agree with you, here. It certainly should be better able to > translate the protocols into something more intelligible. That's one > reason I asked for alternatives. I have no idea what kind of pppd you have on your system. > > >> [remainder of ``log'' snipped] >> >> and it's getting RFC1918 addresses for local, remote/peer, and two >> DNS servers. My ISPs don't play Musical IP Addresses with the DNS, >> so I've got those written directly into /etc/resolv.conf. > > Most of your better ISPs try to avoid shuffling their clients' IP > addresses. This is not one of your better ISPs. They are inexpensive, > though, and my sister is retired and living on a very fixed income. No, ISPs hand out IP addresses at random if it is a dialup operation. Almost none give static IPs. > >> There is a >> 'usepeerdns' option to pppd to cause it to ask the peer for these >> addresses, but pppd puts them into /etc/ppp/resolv.conf rather than >> screwing with a system configuration file - you could soft-link the >> two if needed. It's in the pppd man page. > > It already does. 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. > > >>>> If you're using Debian, the normal tool is pppconf which creates >>>> 'pon' and 'poff'. >> >>> Since the failure doesn't usually seem to be in pppd, I'm not sure >>>these will be helpful. I'll take a look, though. >> >> The failure _seems_ to be caused by the modem disappearing. Why that >> happens is anyone's guess, but my guess would be due to those plain >> old generic telephone modem init-strings used by wvdial. > > Well, it's possible, of course. I wouldn't expect it to be the case, > however, or else I would expect the modem to never connect at all. > I'll certainly run it down once I have recovery working solidly. Nope, they could just put it into an unstable state. > >>>> Concur - also look carefully through any documentation for your >>>> modem, >> >>> You're kidding me, right? The modem documentation is a single sheet >>>of paper about the size of a credit card. I've found nothing online, >>>either specific to the modem. >> >> Must be hell - did this modem come with a windoze disk? > > No, it's worse than that. The box it comes in would not fit an > ordinary mouse. The modem starts up in storage mode with an executable > which runs automatically and checks to see if the system is already > configured with their canned application. If not, it loads itself into > Windows and installs the device drivers and the canned application, > along with a volatile initialization application, run only once to > initialize the modem and then never again. Windows then issues a > switch command which "flips" the modem from storage mode into modem > mode, and the modem disappears as device 1f28:0021 on its initial USB > address and reappears as 1f28:0020 on its original USB address +1. The > initialization routine initializes the modem for access and terminates, > resetting the modem. Thereafter, it will respond to AT commands. Of > course, in Linux, none of this happens automagically. Instead, I use a > little utility produced by a 3rd party developer to handle just such > modems under Linux which switches the device into modem mode. It works > very well on a wide variety of such devices. Thereafter, it acts like > any other CDMA modem, responding on /dev/ttyACMx. > >> There will >> be a windoze file that contains the modem init strings. > > Uh-uh. Binaries only. 'All canned applications with no user readable > files, including no documentation. Indeed, under Windows it isn't even > possible to read the files at all, since the modem is immediately > flipped out of storage mode the moment it is recognized by Windows. > >> I don't do windoze, > > I try not to, but unfortunately my job requires it. > >> so I don't know which file it is, but greping for "AT" >> should turn it up. Probably one of the smaller files (the bigger >> ones are often bitmap icons for the desktop). Good luck > > It might be embedded as text in one of the binaries. My sister is > bringing the router over tomorrow. I'll try taking a look then. It > can't hurt.
From: Moe Trin on 14 Jan 2010 14:35 On Thu, 14 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in article <tKadnZgERulUSdPWnZ2dnUVZ_tdi4p2d(a)giganews.com>, lrhorer wrote: >Moe Trin wrote: >> I'd want to find out why it's disappearing from lsusb - never mind >> /dev/ttyACM0. >Well, ultimately I do, too, of course. In the mean time, however, I >need to account for and handle the possibility, even if it rarely (or >hopefully never) occurs in daily useage. Another poster suggested reloading the cdc-acm module. That probably requires root, but have you looked into that? >It's certainly possible, but I don't think that is the case, at least >not for most of the failure modes. I could be wrong, of course. >Further testing will tell. but before I can really do any failure >testing, I need to come up with an ironclad means of automatic recovery >under the worst case scenario. Automatic - that may be the problem, as you don't know what the actual failure is. That the device disappears from lsusb has to be attacked. If the device doesn't exist, there's not much an application like minicom, pppd/chat, or wvdial can do. >Thanks. I've looked briefly into chat as a solution. I may use it, or >perhaps minicom + expect. 'chat' was designed for this. There _used_ to be a "PPP-over-Minicom" mini-howto, but I haven't seen it mentioned in over ten years. Few have bothered to use it, as it's unduly complex to setup/use. The pppd wants a "working" serial link (tty option to pppd) and this is normally setup using the 'connect' option. You can use what-ever you like - I've seen it done with 'echo', 'read' and redirection if you want to be crude about it. >> If your IP address is going to be changing, you probably want to >> stick a '1' into /proc/sys/net/ipv4/ip_dynaddr >It does, with every single call. That's a kernel routing problem - which is why it's a kernel parameter that is altered above. >What's more, they are using NAT, because they provide the user with >non-routable addresses in the 10.100 range, as you can see above. Not relevant to ppp. RFC1918 addresses aren't that unusual. >> Sent some useless stuff not applicable to a USB device, and got >> another OK response >I haven't delved into the command codes, yet, but the standard AT >commands are evidently implemented by the modem, albeit differently >than a regular PSTN modem. The string was given to me by someone else >who got his A600 working. How much is superfluous, I don't yet know. Blindly sending codes and hoping they're OK isn't always the best solution. By the way, there is no such thing as 'standard AT commands'. Those are Hayes commands, and even Hayes didn't implement or use the commands consistently. What WvDial is using are a combination of Hayes standard command, Hayes extended commands, and a Rockwell command. Standards??? What are those? >> Supposedly dialed a number, but no modem answered within the timeout >> period - that's normally 45 seconds. >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. >>>--> 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. >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. 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 >until it is certain the other end actually is pppd, What other purpose do you think there could be? WvDial really isn't able to handle UUCP, SLIP, or a text shell session. It also doesn't handle ppp-over-whatever. >> There is a 'usepeerdns' option to pppd to cause it to ask the peer >> for these addresses, but pppd puts them into /etc/ppp/resolv.conf >> rather than screwing with a system configuration file - you could >> soft-link the two if needed. It's in the pppd man page. >It already does. I suppose it could be wvdial that's updating >resolv.conf, but I'm pretty sure it's pppd. Read the man page - pppd is written by people with security in mind. >The modem starts up in storage mode with an executable which runs >automatically and checks to see if the system is already configured >with their canned application. If not, it loads itself into >Windows and installs the device drivers and the canned application, >along with a volatile initialization application, run only once to >initialize the modem and then never again. Windows then issues a >switch command which "flips" the modem from storage mode into modem >mode, and the modem disappears as device 1f28:0021 on its initial USB >address and reappears as 1f28:0020 on its original USB address +1. The >initialization routine initializes the modem for access and terminates, >resetting the modem. Thereafter, it will respond to AT commands. Of >course, in Linux, none of this happens automagically. Instead, I use >a little utility produced by a 3rd party developer to handle just such >modems under Linux which switches the device into modem mode. It works >very well on a wide variety of such devices. 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: Andrew Schulman on 14 Jan 2010 14:57
> Old guy Old guy, you sure know your modems. I've read this discussion all the way through, partly because I'm learning a bunch of stuff I never knew about modems, ppp, wvdial, & friends; and partly because I'm remembering how much I used to struggle with and hate modems, and how glad I am that I don't have to do that any more. But it's good that there are some Old Guys out there who still know how to work 'em. Andrew. -- To reply by email, change "deadspam.com" to "alumni.utexas.net" |