[Fwd: wvdial bug report and patch (fwd)]
William Lachance
seems right to me, but I'm inclined to be extremely cautious on applying
fixes to wvdial, not being modem-enabled myself.
--
William Lachance <wrl...@gmail.com>
Avery Pennarun
> Would anyone care to comment on this? I looked over the patch and it
> seems right to me, but I'm inclined to be extremely cautious on applying
> fixes to wvdial, not being modem-enabled myself.
Hmm, I don't think I've seen this before. Perhaps it scrolled past my
ever-expanding inbox.
I've examined the patch and it looks correct. The current behaviour
is indeed a bug.
Avery
Antonio Olivares
am using wvdial-1.60 and I tried to patch it, it appeared to work the
first time, I try to do it again second time, it fails to work :(
switch( received )
{
case -1:
modem->print( "ATQ0\r" );
log( "Sending: ATQ0\n" );
received = wait_for_modem( init_responses, 500, true );
modem->print( "%s\r", *this_str );
log( "Re-Sending: %s\n", *this_str );
received = wait_for_modem( init_responses, 5000, true );
switch( received )
{
case -1:
err( "Modem not responding.\n" );
return( false );
case 1:
err( "Bad init string.\n" );
return( false );
}
goto end_outer; <----- I changed this one to
break; Line 786
case 1:
err( "Bad init string.\n" );
goto end_outer;
}
}
I was connected for a while, but then disconnected to try to connect
again and it fails :(
root@slax:~# wvdial
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 X3 &C1 &D2 +MS=90
ATQ0 V1 E1 S0=0 X3 &C1 &D2 +MS=90
OK
--> Modem initialized.
--> Sending: ATDT7072000
--> Waiting for carrier.
ATDT7072000
CONNECT 49333
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Mon May 4 22:21:43 2009
--> Pid of pppd: 28437
--> Using interface ppp0
--> pppd: `¸[07][08]Á[07][08]
--> pppd: `¸[07][08]Á[07][08]
--> pppd: `¸[07][08]Á[07][08]
--> pppd: `¸[07][08]Á[07][08]
--> local IP address 66.201.8.70
--> pppd: `¸[07][08]Á[07][08]
--> remote IP address 66.201.8.6
--> pppd: `¸[07][08]Á[07][08]
--> primary DNS address 66.201.0.203
--> pppd: `¸[07][08]Á[07][08]
--> secondary DNS address 66.94.120.9
--> pppd: `¸[07][08]Á[07][08]
^CCaught signal 2: Attempting to exit gracefully...
--> Terminating on signal 15
--> pppd: `¸[07][08]Á[07][08]
--> Connect time 4.3 minutes.
--> pppd: `¸[07][08]Á[07][08]
--> pppd: `¸[07][08]Á[07][08]
--> Disconnecting at Mon May 4 22:26:01 2009
root@slax:~# wvdial
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
--> Sending: ATQ0
--> Re-Sending: ATZ
--> Modem not responding.
root@slax:~# /etc/rc.d/rc.slmodemd restart
then I can connect again after doing above command :
root@slax:~# /etc/rc.d/rc.slmodemd restart
Shutting down SmartLink modem daemon
Starting SmartLink modem daemon: /usr/sbin/slmodemd
root@slax:~# wvd
wvdial wvdialconf
root@slax:~# wvdial
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 X3 &C1 &D2 +MS=90
ATQ0 V1 E1 S0=0 X3 &C1 &D2 +MS=90
OK
--> Modem initialized.
--> Sending: ATDT7072000
--> Waiting for carrier.
ATDT7072000
CONNECT 44000
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Mon May 4 22:27:31 2009
--> Pid of pppd: 29512
--> Using interface ppp0
--> pppd: `¸[07][08]Á[07][08]
--> pppd: `¸[07][08]Á[07][08]
--> pppd: `¸[07][08]Á[07][08]
--> pppd: `¸[07][08]Á[07][08]
--> local IP address 66.201.8.74
--> pppd: `¸[07][08]Á[07][08]
--> remote IP address 66.201.8.6
--> pppd: `¸[07][08]Á[07][08]
--> primary DNS address 66.201.0.203
--> pppd: `¸[07][08]Á[07][08]
--> secondary DNS address 66.94.120.9
--> pppd: `¸[07][08]Á[07][08]
Now do both have to be break; or only top one?
This behavior is only exhibited in smartlink modem /dev/ttySL0 and not
in LTModem supported by martian driver /dev/ttySM0. How can I fix it?
I got it to work one time, and I try to make the changes and save
them, but it does not work anymore.
Thanks,
Antonio
Avery Pennarun
> root@slax:~# wvdial
> --> WvDial: Internet dialer version 1.60
> --> Cannot get information for serial port.
> --> Initializing modem.
> --> Sending: ATZ
> --> Sending: ATQ0
> --> Re-Sending: ATZ
> --> Modem not responding.
> root@slax:~# /etc/rc.d/rc.slmodemd restart
I don't think the patch under discussion here will fix this problem:
the fact that it's printing "Modem not responding" after the second
ATZ means that modem really *isn't* responding. It doesn't sound like
your problem is caused by a bug in wvdial.
> then I can connect again after doing above command :
>
> root@slax:~# /etc/rc.d/rc.slmodemd restart
> Shutting down SmartLink modem daemon
> Starting SmartLink modem daemon: /usr/sbin/slmodemd
If the above fixes it, then your problem is likely a bug in slmodemd -
it seems to lock up after a connection gets disconnected. Have you
contacted the slmodemd people about it?
One option would be to just *always* restart slmodemd every time you
start wvdial, eg. using a shell script. It's not pretty, but it would
probably help.
Good luck,
Avery
Antonio Olivares
does respond. Why does it do so with KPPP? I also use another
winmodem supported by martian modem drivers and modem port is
/dev/ttySM0 and I can use wvdial, disconnect and connect again with
wvdial. However, I applied the changes, at one point using Slax live
cd, and recompiled wvdial-1.60.tar.gz and it worked at that point. I
tried to recreate slax modules by modifying the code, changing line
786 using sed and the Makefile to satisfy Slax module requirements:
sed -i '786 s/goto end_outer/break/g' wvdialer.cc
# fix prefix to be /usr instead of default /usr/local
sed -i 's|prefix=/usr/local|prefix=/usr|g' Makefile
and the resultant module still gives me back errors. At one point it
apparently worked?
Well, thank you for the info, in the meantime I shutdown slmodemd and
then restart it so that I can use wvdial. If I don't want to
stop|start|restart slmodemd service I can use KPPP. But I prefer
wvdial.
Regards,
Antonio
Avery Pennarun
<olivar...@gmail.com> wrote:
> I do believe something is wrong, because if I use KPPP, it(the modem)
> does respond. Why does it do so with KPPP? I also use another
> winmodem supported by martian modem drivers and modem port is
> /dev/ttySM0 and I can use wvdial, disconnect and connect again with
> wvdial.
Well, what's really going on is probably a bad interaction between
wvdial and the kernel driver. KPPP probably does something slightly
different from wvdial, which is usually harmless but in this case the
kernel driver doesn't like it. (Perhaps the driver was tested only
with kppp and not wvdial.)
If you could track down what the difference is between how kppp treats
the modem and how wvdial does, we could perhaps see if it's worth
changing wvdial to avoid the problem. But it's really tricky for us
to do without the failing hardware. You might want to play with
'strace' and see if you can figure it out.
Also, like I said, you might want to email the people who make the
driver. Maybe wvdial will fail reliably for them like it does for
you? If so, it would be easy for them to isolate the problem and, if
it really is wvdial's fault, tell us what to do to avoid it.
Fundamentally, the kernel driver is supposed to reset when you close
the connection to the /dev/tty* device, so if it doesn't, there's
*some* kind of bug in the driver.
Have fun,
Avery
Peter McCurdy
how to make my laptop's modem ignore the first init string, nor do I
have a dial-up account to connect to, nor a phone line to connect
with. I can tell you it still compiles and dials, at least.
You can get it from http://github.com/pmccurdy/wvdial , or just apply
the patch yourself I guess.
--
Peter McCurdy
Co-founder, The Navarra Group
http://navarra.ca
> From: Sergey Ostashenko <o...@kiae.su>
> To: wrl...@gmail.com
> Date: Mon, 4 May 2009 20:19:29 +0400 (MSD)
> Subject: wvdial bug report and patch (fwd)
> Hello William,
>
> I did submit a patch for WvDial in the past, but it did not get into the
> source. I am still in hope the change could be accepted, so I am sending
> the patch to you, because you seem to be indicated as the WvDial source
> maintainer on http://alumnit.ca/wiki/?WvDial.
>
> Sergey
>
> ---------- Forwarded message ----------
> Date: Fri, 11 May 2007 00:53:23 +0400 (MSD)
> From: Sergey Ostashenko <o...@relcom.ru>
> To: <wvdia...@nit.ca>
> Subject: wvdial bug report and patch
>
> Hello Wvdial team,
>
> I did uncover trivial bug which is probably rather a typo in the
> wvdialer.cc code. The bug is in the modem init strings sending code below:
> modem->print( "%s\r", *this_str );
> received = wait_for_modem( init_responses, 5000, true );
> switch( received )
> {
> case -1:
> modem->print( "ATQ0\r" );
> log( "Sending: ATQ0\n" );
> received = wait_for_modem( init_responses, 500, true
> );
> modem->print( "%s\r", *this_str );
> log( "Re-Sending: %s\n", *this_str );
> received = wait_for_modem( init_responses, 5000, true
> );
> switch( received )
> {
> case -1:
> err( "Modem not responding.\n" );
> return( false );
> case 1:
> err( "Bad init string.\n" );
> return( false );
> }
> goto end_outer;
>
> beginning of the dialer session. As you see the code tries to resend an
> init string in case the was no response from the modem on the first try.
> The problem with the bug is the re-sending does not help even if the
> sending succeeds on the second try. This is due to "goto end_outer;"
> statement at the end of the above fragment. The statement makes the
> wvdial leave the init strings sending loop even after the re-sending
> succeeds. I guess it was a typo and the author's intention was to place
> "break;" statement here to proceed with sending the init strings.
>
> I did find this bug rather annoying due to my modem has a bad habit of
> not responding randomly on the first init string sent to it. It does
> respond when the string is resent, but the bug fails the wvdialer session
> anyway. I was forced to restart wvdial again and again until the modem's
> response to the first init string was catched from the first try. Finally
> I did find the bug and I am happy now thanks to the open source.
> Hopefully the fix will be in the next release. The patch for 1.56 is
> attached.
>
> Sergey
>
>
>
Avery Pennarun
<peterm...@alumni.uwaterloo.ca> wrote:
>
> Well, I gave this patch a quick test. Nothing extensive: I don't know
> how to make my laptop's modem ignore the first init string, nor do I
> have a dial-up account to connect to, nor a phone line to connect
> with. I can tell you it still compiles and dials, at least.
>
> You can get it from http://github.com/pmccurdy/wvdial , or just apply
> the patch yourself I guess.
Just to confirm: wlach, are you going to merge this into the next
release, then, or do you need something else first?
Thanks,
Avery
William Lachance
I'm pretty satisfied at this point that the patch won't break anything
so yes, I'll merge it into my tree and make it part of the next
release of wvdial (probably to be released along with the next version
of wvstreams, unless someone wants to volunteer to make a new release
earlier).
--
William Lachance
wrl...@gmail.com
Patrick Patterson
I'm pretty satisfied at this point that the patch won't break anything
so yes, I'll merge it into my tree and make it part of the next
release of wvdial (probably to be released along with the next version
of wvstreams, unless someone wants to volunteer to make a new release
earlier).
BTW: While we're on the topic - is there a planned "new release", now that the dbus folks have accepted the change that means that WvStreams doesn't need to statically link with libdbus.a?
--
Personal Mail from Patrick Patterson
No company affiliation
William Lachance
> On Wed, May 6, 2009 at 12:24 PM, William Lachance <wrl...@gmail.com> wrote:
>>
>> I'm pretty satisfied at this point that the patch won't break anything
>> so yes, I'll merge it into my tree and make it part of the next
>> release of wvdial (probably to be released along with the next version
>> of wvstreams, unless someone wants to volunteer to make a new release
>> earlier).
>
> BTW: While we're on the topic - is there a planned "new release", now that
> the dbus folks have accepted the change that means that WvStreams doesn't
> need to statically link with libdbus.a?
The change has been applied to their git repository, but an actual
release of dbus has not been made. I plan to release a new version of
WvStreams as soon as that happens, which I assume will be within the
next few months.
--
William Lachance
wrl...@gmail.com