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 21:54 On Thu, 14 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in article <uhtuk59611a9it4smrb98uah7uglo78l24(a)4ax.com>, Andrew Schulman wrote: >Old guy, you sure know your modems. Thank you - but no, the real modem expert was Rob Clark who had the 'Winmodems are not Modems" web site referenced in the Modem-HOWTO. >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. Recall Robert Hart's original 'PPP-HOWTO'? That document drove me nuts because the second or third system I set up in ~1995 was trying to dial in to an ISP who had advanced to the RFC1334 authentication method, but whose hell-desk staff could spell PPP (or DNS) no matter what you did and thus were unable to provide the hint I needed. It took most of a week to get things running. Thing that bothered me the most was that the week was my vacation and I was unable to access the Internet and "was on my own". Once you realize how the game is meant to be played (end chat when the modem reports CONNECT and don't even send a carriage return), it becomes extremely easy to get a ppp connection running. Most ``helper'' tools are written by those who haven't bothered to investigate how ppp is used, and as a result are less than optimum. Most also hide any ppp debug data, which makes it all the harder to figure out what went wrong. >But it's good that there are some Old Guys out there who still know >how to work 'em. I don't see that much for dialin questions any more. In 2003, we used to average about four articles a day in the Usenet newsgroup comp.protocols.ppp, and one of the authors of the current package was a regular poster. Last year, it was around one article per week. The group comp.dcom.modems went from ten a day to ten a month, and most of those are spam now. Old guy
From: lrhorer on 15 Jan 2010 04:11 >> 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. The modem has been replaced under warranty. The replacement behaves precisely the same way. Retail cost is $119. This and one other very similar modem are the only ones they support. Note the modem doesn't typically die and then disconnect. It's the other way around. >>> 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. I'm not sure why you think that. This isn't a PSTN modem. PRI and BRI connections are ALWAYS made in less than 1/2 second, for example. I'm not intimately familiar with CDMA protocols, but I am fairly intimately familiar with the equipment which handles it, and there is no reason why a connect cannot be failed or accepted in less than a second. > Why do you not set up the timeout for longer. Well, first of all because there is no timeout parameter for wvdial, so it isn't possible. Secondly, because it clearly is not necessary. The modem never fails to get a connection, and in far less time than your 45 second suggestion, at that. >> 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. I'll look into it when I implement chat (or whatever), but it's not a high priority. >>> 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. To what, exactly, were you responding? What "is not"? Moe and I were speaking about the line which says, "--> Carrier detected. Waiting for prompt." That is most certainly not 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. It's not a "router". It's a router, specifically a Linux router. It's running Debian "Lenny" under kernel 2.6.26-2-686. The version of pppd is 2.4.4 Rel 10.1, and of course it is from the Debian Stable repository. >>> 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. The fact it connects in less than 10 seconds every time, consistently takes very nearly the same amount of time to connect, takes no more time to connect under Linux than under Windows, and consistently undergoes 6 - 8 retires rather than random numbers of attempts strongly suggests you are incorrect. >> 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. And you have personally connected to every one of the 10,000+ dial-up ISPs out there to verify this? >>>>--> 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. You can ask Marco d'Itri <md(a)linux.it>, he's the maintainer. >>> 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. This is supposed to be a broadband operation. Of course, it emulates a dial-up operation, which is I suppose their excuse.
From: lrhorer on 15 Jan 2010 04:33 Moe Trin wrote: > On Fri, 15 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, > in article <slrnhkvc0c.a3o.unruh(a)wormhole.physics.ubc.ca>, unruh >>> 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. Exactly. There's no interface to the PSTN, and either the spectrum is available or it isn't. There's no actual dialing involved, either, although as I mentioned earlier, ISDN systems (which may tie into the very same class 5 switch as your POTS line) always connect in less than 1/2 second. >>>> 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 It's not really a log, per se. It's stdout redirected to a file. This is an example of the pppd logs: Jan 9 09:48:59 Cricket pppd[13333]: Connect time 68.2 minutes. Jan 9 09:48:59 Cricket pppd[13333]: Sent 125726 bytes, received 214681 bytes. Jan 9 09:49:00 Cricket pppd[13333]: CHAP authentication succeeded Jan 9 09:49:00 Cricket pppd[13333]: CHAP authentication succeeded Jan 9 09:49:00 Cricket pppd[13333]: local IP address 10.100.18.173 Jan 9 09:49:00 Cricket pppd[13333]: remote IP address 172.29.122.162 Jan 9 09:49:00 Cricket pppd[13333]: primary DNS address 172.28.221.53 Jan 9 09:49:00 Cricket pppd[13333]: secondary DNS address 172.28.221.54 Jan 9 11:26:48 Cricket pppd[2544]: pppd 2.4.4 started by root, uid 0 Jan 9 11:26:48 Cricket pppd[2544]: Using interface ppp0 Jan 9 11:26:48 Cricket pppd[2544]: Connect: ppp0 <--> /dev/ttyACM0 Jan 9 11:26:51 Cricket pppd[2544]: CHAP authentication succeeded Jan 9 11:26:51 Cricket pppd[2544]: CHAP authentication succeeded Jan 9 11:26:52 Cricket pppd[2544]: local IP address 10.100.23.215 Jan 9 11:26:52 Cricket pppd[2544]: remote IP address 172.29.122.162 Jan 9 11:26:52 Cricket pppd[2544]: primary DNS address 172.28.221.53 Jan 9 11:26:52 Cricket pppd[2544]: secondary DNS address 172.28.221.54
From: lrhorer on 15 Jan 2010 04:48 Jerry Peters wrote: > 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. Yes, but that doesn't mean I require assistance troubleshooting it. I appreciate people wanting to be helpful, but I'm not new at dealing with electronics down to the component level. I wasn't new at it when the IBM PC was first introduced. > Have you tried removing and re-inserting the cdc-acm > module? That *might* be enough to re-initialize the modem to a usable > state. I'll give it a shot when I get the chance. > 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. Are you sure about that? I've looked, and I can't find any documentation to that effect. I'm working on writing a userspace binary to allow me to control the port, but if there is already a solution out there, I would be thrilled to use it. Of course, many USB ports do not have the capability in the first place, but if necessary I can use an external hub that does support power management. > As for "interfacing the router's control scripts with the dialing > utility": chat. That seems to be the consensus.
From: unruh on 15 Jan 2010 11:04
On 2010-01-15, lrhorer <lrhorer(a)satx.rr.com> wrote: > Moe Trin wrote: > >>>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. > > You lost me, again. Completely. Wvdial is calling pppd with the > usepeerdns option, which by every reading I have done in the pppd man > page tells me it is pppd which is updating /etc/resolv.conf. pppd updates /etc/ppp/resolv.conf It is up to the user's programs to transfer that information into /etc/resolv.conf. The writers of pppd did not feel that it was their business to be altering system files. > Admittedly, I am not as familiar with ppp as I should be, since I > rarely every use it for anything, but the man page for pppd > specifically says, "usepeerdns - Ask the peer for up to 2 DNS server > addresses. The addresses supplied by the peer (if any) are passed to > the /etc/ppp/ip-up script in the environment variables DNS1 and DNS2, > and the environment variable USEPEERDNS will be set to 1. In > addition, pppd will create an /etc/ppp/resolv.conf file containing one ^^^^^^^^^^^^^^^^^^^^ Please read the underlined carefully. > or two nameserver lines with the address(es) supplied by the peer." > > So how is it my understanding of the security features of pppd are > flawed, or that I am mistaken in believing pppd is > updating /etc/resolv.conf? You are mistaken. Please read that paragraph you quoted again. > >> >> 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. > > 'More like keeping it acting like a modem. Getting it to do so in the > first place is easy. Can you really not buy your sister a decent cdma modem? .... >> ---------------- >> PPP is like a two handed game of "Mother, may I" (popular with > > Did I mention I am a professional telecommunications engineer? I've > been doing this for over 30 years. I really, really don't need > hand-holding. I'm relatively new to Linux, so I don't know a lot of > what's available for it, but I don't need any primers. Again, no > offense intended, but I'm looking for advice on what applications are > available, not how to troubleshoot issues. See above. |