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 15 Jan 2010 14:50 On Fri, 15 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in article <AdadnduMvarTrM3WnZ2dnUVZ_o5i4p2d(a)giganews.com>, lrhorer wrote: [unruh <unruh(a)wormhole.physics.ubc.ca> wrote:] >> 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. The 45 second value is the default for chat - and is aimed at the POTS style analog modem. The timeout is meant to be "if nothing has happened in this long, declare a fault". On the other hand, if the modem returns one of the many (Hayes ATX3) error messages or codes in less than the timeout period, the value of the timeout is moot. >> 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. I'll merely state that needing multiple retries is a rather unusual design specification. Old guy
From: Moe Trin on 15 Jan 2010 14:51 On Fri, 15 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in article <AdadndiMvaqluc3WnZ2dnUVZ_o6dnZ2d(a)giganews.com>, lrhorer wrote: >Moe Trin wrote: >> Another poster suggested reloading the cdc-acm module. That probably >> requires root, but have you looked into that? >Not yet. I just got the router back this evening, and I haven't had >any time to look into the specifics of any of the failures. I'm >still running down some coding issues on one of the control modules. >One of the header files (not mine) has some issues, and so the code >won't compile. I probably won't get back to looking into the failure >modes until this weekend, if then. I did turn up yet another failure >mode, though. Oddly, the device got registered (non switched), but >wouldn't respond to ordinary system calls, so udev couldn't even >produce the device targets and the switch code could not flip it. It's looking a lot more as if this is the problem, rather than pppd. >There's no question I am going to have to shut down and restore power >to the device when some of these failure modes are encountered. It >just shouldn't be the default action. Agree. As a guess, the software in the modem isn't being set/reset to the "right" mode, and needs the power cycle to reset to sane values. From a serial data-link point of view, this probably means those init-strings aren't correct. For an analog modem, 'ATZ' generally means to reset to a _user_ specified stored configuration (that were saved using the 'AT&W0' command). This differs from 'AT&Fn' which resets the modem to ``factory'' settings. So if the user accidentally set up some weird configuration and then ran the 'AT&W0' command, the modem powers up to sane values, but gets reset to the strange condition by that 'ATZ'. That's why it's generally not a good init-string. >> 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. >'My point exactly. I have to address such eventualities, however. >That's one of the common issues with unattended devices which must >recover from unexpected issues autonomously. The power on reset does that, but I don't consider it to be the best solution. A parachute will probably save your buns when the airplane comes un-glued, but it's more desirable to not have the aircraft do that - certainly not on a regular basis. >> 'chat' was designed for this. >Well, OK. I only briefly skimmed the man page for chat, but it >certainly holds promise. If I can make some headway with the device >control (or get totally stumped) this weekend, I'll have to look into >creating a chat script to be called by the startup script. Actually, 'chat' is called by pppd using the 'connect' option. I've shown two examples in this discussion. >> That's a kernel routing problem - which is why it's a kernel >> parameter that is altered above. >I lost you, there. How is the fact the ISP does not try to maintain >its client's IP address in its DHCP server a kernel routing problem? DHCP is an Ethernet service, not PPP. The kernel routing problem occurs when the system _NORMALLY_ has a default route using a ppp interface - as either booting to a configuration where pppd is run by default and the link may yo-yo, or in a 'demand' mode. >> Not relevant to ppp. RFC1918 addresses aren't that unusual. >I never said it was relevant to ppp, and I am very well aware that >RFC1918 addresses are commonplace. If they weren't, we would have >run out of ipv4 address space long ago. All I said is that this ISP >employs NAT to supply addresses to its clients. That's what I meant. I know of several ISPs that operate that way. >It's a rather cheezy, or at least obnoxiously restrictive thing to >do. It certainly prevents the subscriber from running any sort of >internet-facing server. I'm not going to defend the ISP, but that's just another fact of business. Usually, it's a method of separating the cheap - 'client only' customer from the expensive 'allowed to run servers' customer. >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. ^^^^^^^^^^^^^^^^ >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 ^^^^^^^^^^^^^^^^^^^^ Different file. >> 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. I'll give you that. Old guy
From: unruh on 15 Jan 2010 15:26 On 2010-01-15, Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote: > On Fri, 15 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in > article <AdadndiMvaqluc3WnZ2dnUVZ_o6dnZ2d(a)giganews.com>, lrhorer wrote: > >>> That's a kernel routing problem - which is why it's a kernel >>> parameter that is altered above. > >>I lost you, there. How is the fact the ISP does not try to maintain >>its client's IP address in its DHCP server a kernel routing problem? > > DHCP is an Ethernet service, not PPP. The kernel routing problem > occurs when the system _NORMALLY_ has a default route using a ppp > interface - as either booting to a configuration where pppd is run by > default and the link may yo-yo, or in a 'demand' mode. ppp is a peer to peer service. This means that there need by no IP addresses on the line--- you send stuff to only one place, your peer. It is also not necessary that the address delivered on the ppp line is the same as the address than either side uses. However, in normal operation, the important addresses are the address the ISP sends you to refer to him ( but again he does not care, because there is only one ppp connection) and for him the important address is yours. Now the usual situation is that the ISP is asked both for his IP address and your IP address. the ISP has a certain limited number of addresses, and since on the telephone systems, many users will call up, there is a huge disincentive to assigning the same address to the same caller ( that would mean you would have to know who the caller is). Thus the ppp addresses on each connection tend to be different. Now, CDMA broadband may be different, but again there is no incentive for them to go to the trouble of giving you the same address, and it is hard to do ( how do you identify the remote caller).
From: Jerry Peters on 15 Jan 2010 16:10 lrhorer <lrhorer(a)satx.rr.com> wrote: > 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. Neither was I. I've found over may years of troubleshooting problems that *most* people simply can't debug. I've worked on projects where out of perhaps 20 or 30 people only 2 or 3 of us could debug anything. > >> 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. > No I'm not sure, hence the "I believe" part. It could also require an ioctl or some other special operation. What happens if you remove [eou]hci-hcd (the USB port driver)? Also there's additional debugging info that can be turned on for USB. I think it's a kernel config option though. >> As for "interfacing the router's control scripts with the dialing >> utility": chat. > > That seems to be the consensus. Yep, there's a good reason for that: flexibilty and control. I still use dial-up when I visit my dad in Florida. I have a bash script which builds the chat script (dependent on the modem & some options), then invokes pppd with the connect option to actually do anything. Also 2.6.26 is an old kernel (late 2008), current stable is 2.6.32.3. Jerry
From: lrhorer on 15 Jan 2010 20:07
>> 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. > > Neither was I. I've found over may years of troubleshooting problems > that *most* people simply can't debug. I've worked on projects where > out of perhaps 20 or 30 people only 2 or 3 of us could debug > anything. Yeah, including a lot of people who are paid to be able to debug an troubleshoot. 'Paid a lot, sometimes. >>> 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. >> > No I'm not sure, hence the "I believe" part. It could also require an > ioctl or some other special operation. What happens if you remove > [eou]hci-hcd (the USB port driver)? Nothing at all, I think. I believe the device has to be commanded to down the port (and I believe it is port specific). I also have to qualify the statement with "I believe", because that just what the reading I have done and the people to whom I have spoken so far has suggested. One of the USB gurus tho whom I have spoken (Alan Stern at Harvard) has suggested the best way to approach the issue is to unbind the driver and then issue the command to shut down power on the port. That makes me think unbinding the driver isn't sufficient by itself. > Also there's additional debugging info that can be turned on for USB. > I think it's a kernel config option though. > >>> As for "interfacing the router's control scripts with the dialing >>> utility": chat. >> >> That seems to be the consensus. > > Yep, there's a good reason for that: flexibilty and control. I still > use dial-up when I visit my dad in Florida. I have a bash script which > builds the chat script (dependent on the modem & some options), then > invokes pppd with the connect option to actually do anything. > > Also 2.6.26 is an old kernel (late 2008), current stable is 2.6.32.3. Debian never packages the most recent versions of software, unless the release affects security or addresses a significant bug. It is an extremely conservative distribution, which is the main reason I use it. It definitely never has all the new bells and whistles, and it isn't for someone who wants to always have support for all the latest gadgets, but it is rock solid and provides new meaning for the term "stable". I use it on all my servers, and I am using it on this router in large measure because it is stable in the extreme. Most distros have maybe two versions, Stable and Unstable. Debian has Stable, Unstable, Testing, and Experimental, in order of decreasing reliability. What most distros call, "Stable", Debian calls "Testing". If you ask me, late 2008 isn't all that "old". A lot of bugs can go undetected after only a little more than 1 year in public release. If I need anything from one of the newer kernels, I can always download and compile it, but there's nothing from any of the newer kernels that is missing in 2.6.26 and that I need for this project. Indeed, I suspect I may never upgrade the kernel, or anything else, on this machine once it is permanently online. Its job is just to sit on the shelf, route packets, generate a firewall, provide DHCP support, and provide a VPN tunnel into my file server at my house. |