Re: problems with wvdial
- From: lrhorer <lrhorer@xxxxxxxxxxx>
- Date: Fri, 15 Jan 2010 22:26:03 -0600
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.
I agree, although despite what unruh seems to believe, I haven't
fixated on this as a root cause, and I certaily have not even remotely
ruled out ppp problems or something bizarre that wvdial is doing as
being a proximate cause.
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.
That, or one of 10,000 other things. I'll probably figure out what,
eventually. If I come up with a solution which eliminates the symptoms
without knowing what is really happening underneath I probably won't
bother, though.
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.
Yes, but gracefully exiting the session and then dialing back in
doesn't produce a problem. If resetting the modem kills it in one
case, one might expect that resetting it in the other case would have
the same effect.
'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.
Me, either.
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.
Yeah, I see that. I'll dig into the details when I start to write the
script.
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.
Well, dial-up service typically costs about $10 a month or so, so by
comparison this service, at $40 a month, is not cheap. Indeed, it is
about the same as most landline based broadband services, cost-wise.
It is less expensive than other wireless or satellite services, but not
THAT much less expensive.
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.
OK, I see, and I see now what you were saying. 'My mistake. When I
read over that in the man page, I missed the /ppp/ and so I was
thinking pppd was writing the file.
.
- Follow-Ups:
- Re: problems with wvdial
- From: Jerry Peters
- Re: problems with wvdial
- From: Moe Trin
- Re: problems with wvdial
- References:
- problems with wvdial
- From: lrhorer
- Re: problems with wvdial
- From: unruh
- Re: problems with wvdial
- From: lrhorer
- Re: problems with wvdial
- From: lrhorer
- Re: problems with wvdial
- From: Moe Trin
- Re: problems with wvdial
- From: lrhorer
- Re: problems with wvdial
- From: Moe Trin
- Re: problems with wvdial
- From: lrhorer
- Re: problems with wvdial
- From: Moe Trin
- Re: problems with wvdial
- From: lrhorer
- Re: problems with wvdial
- From: Moe Trin
- problems with wvdial
- Prev by Date: Re: problems with wvdial
- Next by Date: Re: problems with wvdial
- Previous by thread: Re: problems with wvdial
- Next by thread: Re: problems with wvdial
- Index(es):
Relevant Pages
|