...making Linux just a little more fun!
Amit Saha [amitsaha.in at gmail.com]
Hi!
I use PPP to use a GPRS and/or CDMA modem. The 'pppd' often dies abruptly, blurting out "modem has hung up".
I am not suspecting a network issue as it doesn't happen on Windows. Any idea how can I find out the reason and may be then correct it ?
Thanks!
-Amit
-- Journal: http://amitksaha.wordpress.com, Micro-blog: http://twitter.com/amitsaha Freenode: cornucopic in #scheme, #lisp, #math,#linux, #python
Paul Sephton [paul at inet.co.za]
On Thu, 2009-07-09 at 14:07 +0530, Amit Saha wrote:
> Hi! > > I use PPP to use a GPRS and/or CDMA modem. The 'pppd' often dies > abruptly, blurting out "modem has hung up". > > I am not suspecting a network issue as it doesn't happen on Windows. > Any idea how can I find out the reason and may be then correct it ? > > Thanks! > -Amit
Could be a cable fault. If the DCD (data carrier detect) signal is dropped, the assumption is that the modem has hung up. One might play arround with the 'stty' app against the port, eg. 'stty < /dev/tty0' or whatever to check the port settings for the serial connection.
Paul
René Pfeiffer [lynx at luchs.at]
On Jul 09, 2009 at 1407 +0530, Amit Saha appeared and said:
> Hi! > I use PPP to use a GPRS and/or CDMA modem. The 'pppd' often dies > abruptly, blurting out "modem has hung up". > I am not suspecting a network issue as it doesn't happen on Windows. > Any idea how can I find out the reason and may be then correct it ?
You can turn on debugging by setting the debug and kdebug options. You can also increase the thresholds for the lcp-... options since pppd monitors the connection and terminates it if the peer doesn't respond with LCP Echo packets.
Best, René.
Amit Saha [amitsaha.in at gmail.com]
On Thu, Jul 9, 2009 at 4:50 PM, René Pfeiffer <[email protected]> wrote:
> > On Jul 09, 2009 at 1407 +0530, Amit Saha appeared and said: > > Hi! > > > > I use PPP to use a GPRS and/or CDMA modem. The 'pppd' often dies > > abruptly, blurting out "modem has hung up". > > > > I am not suspecting a network issue as it doesn't happen on Windows. > > Any idea how can I find out the reason and may be then correct it ? > > You can turn on debugging by setting the debug and kdebug options. You > can also increase the thresholds for the lcp-... options since pppd > monitors the connection and terminates it if the peer doesn't respond > with LCP Echo packets.
I have tried increasing the value of 'lcp'. Doesn't help. Will try the 'kdebug' option.
Thanks -Amit
-- Journal: http://amitksaha.wordpress.com, Micro-blog: http://twitter.com/amitsaha Freenode: cornucopic in #scheme, #lisp, #math,#linux, #python
Amit Saha [amitsaha.in at gmail.com]
On Thu, Jul 9, 2009 at 5:24 PM, Amit Saha<[email protected]> wrote:
> On Thu, Jul 9, 2009 at 4:50 PM, René Pfeiffer <[email protected]> wrote: >> >> On Jul 09, 2009 at 1407 +0530, Amit Saha appeared and said: >> > Hi! >> > >> > I use PPP to use a GPRS and/or CDMA modem. The 'pppd' often dies >> > abruptly, blurting out "modem has hung up". >> > >> > I am not suspecting a network issue as it doesn't happen on Windows. >> > Any idea how can I find out the reason and may be then correct it ? >> >> You can turn on debugging by setting the debug and kdebug options. You >> can also increase the thresholds for the lcp-... options since pppd >> monitors the connection and terminates it if the peer doesn't respond >> with LCP Echo packets. > > I have tried increasing the value of 'lcp'. Doesn;t help. Will try the > 'kdebug' option.
My situation is like this: I am using 'wvdial' which in turns spawns 'pppd'. Any body would know how I can pass the '--kdebug' option to 'pppd' in this scenario ?
Thanks! -Amit
Steve Brown [steve.stevebrown at gmail.com]
Hi Amit,
On Fri, Jul 10, 2009 at 9:49 AM, Amit Saha<[email protected]> wrote: > > On Thu, Jul 9, 2009 at 5:24 PM, Amit Saha<[email protected]> wrote: >> >> On Thu, Jul 9, 2009 at 4:50 PM, René Pfeiffer <[email protected]> wrote: >>> >>> >>> >>> On Jul 09, 2009 at 1407 +0530, Amit Saha appeared and said:
> > My situation is like this: I am using 'wvdial' which in turns spawns > > 'pppd'. Any body would know how I can pass the '--kdebug' option to > > 'pppd' in this scenario ?
I'm working from a very old memory here, so apologies if I lead you astray.
wvdial is a command line only - so what output do you get from it?
Also, I see that there is /etc/ppp/options and ~/.ppprc mentioned in the man page - could you set debug options there?
One last thought - can you maintain the connection manually? i.e. through the pppd scripts etc.
-- Steve
Amit Saha [amitsaha.in at gmail.com]
On Fri, Jul 10, 2009 at 2:52 PM, Steve Brown<[email protected]> wrote:
> Hi Amit, > > On Fri, Jul 10, 2009 at 9:49 AM, Amit Saha<[email protected]> wrote: >> > On Thu, Jul 9, 2009 at 5:24 PM, Amit Saha<[email protected]> wrote: >>> >> On Thu, Jul 9, 2009 at 4:50 PM, René Pfeiffer <[email protected]> wrote: >>>> >>> >>>> >>> On Jul 09, 2009 at 1407 +0530, Amit Saha appeared and said: > >> > My situation is like this: I am using 'wvdial' which in turns spawns >> > 'pppd'. Any body would know how I can pass the '--kdebug' option to >> > 'pppd' in this scenario ? > > I'm working from a very old memory here, so apologies if I lead you astray. > > wvdial is a command line only - so what output do you get from it?
This is how it exits:
. . . ^CCaught signal 2: Attempting to exit gracefully... --> Terminating on signal 15 --> pppd: 886 --> Connect time 1.9 minutes. --> pppd: 886 --> pppd: 886
> > Also, I see that there is /etc/ppp/options and ~/.ppprc mentioned in the man > page - could you set debug options there?
Will see..
> > One last thought - can you maintain the connection manually? i.e. through > the pppd scripts etc.
No. It happens with my USB GPRS modem too. I am using 'wvdial' for my CDMA modem.
Thanks Steve!
-Amit
Steve Brown [steve.stevebrown at gmail.com]
Hi AMit,
On 10/07/2009 10:32, Amit Saha wrote:
> On Fri, Jul 10, 2009 at 2:52 PM, Steve Brown<[email protected]> wrote: >> Hi Amit, >> >> On Fri, Jul 10, 2009 at 9:49 AM, Amit Saha<[email protected]> wrote: >>> > On Thu, Jul 9, 2009 at 5:24 PM, Amit Saha<[email protected]> wrote: >>>> >> On Thu, Jul 9, 2009 at 4:50 PM, René Pfeiffer <[email protected]> wrote: >>>>> >>> >>>>> >>> On Jul 09, 2009 at 1407 +0530, Amit Saha appeared and said: >> >>> > My situation is like this: I am using 'wvdial' which in turns spawns >>> > 'pppd'. Any body would know how I can pass the '--kdebug' option to >>> > 'pppd' in this scenario ? >> >> I'm working from a very old memory here, so apologies if I lead you astray. >> >> wvdial is a command line only - so what output do you get from it? > > This is how it exits: > > . > . > . > ^CCaught signal 2: Attempting to exit gracefully...
Are using Ctrl-C to stop wvdial which then gives you this error?
Have you looked at the message logs?
Do you get errors before you kill wvdial?
> No. It happens with my USB GPRS modem too. I am using 'wvdial' for my > CDMA modem.
Have you seen this page:
http://ubuntu-in.info/wiki/index.php/BSNL_CDMA_WLL_Howto
Good luck,
Steve
Ben Okopnik [ben at linuxgazette.net]
On Fri, Jul 10, 2009 at 02:19:53PM +0530, Amit Saha wrote:
> > My situation is like this: I am using 'wvdial' which in turns spawns > 'pppd'. Any body would know how I can pass the '--kdebug' option to > 'pppd' in this scenario ?
I've been using a CDMA modem for the past 10>X>3 years (I'm a little
hazy on whether the early versions were CDMA or some precursor...), and
I just set up the latest iteration - a brand new, tiny USB dongle with
built-in flash memory and an external antenna - this morning, so I might
have something to contribute. 
In my experience, hangups of this sort come down to one thing, something that's already been mentioned: LCP settings. In fact, as far as I'm concerned, the three settings that are absolutely required for reliable operation of a CDMA modem are
connect-delay 3000 # Some modems may require up to 10000 lcp-echo-failure 4 lcp-echo-interval 65535
"wvdial" - or at least "wvdialconf" - can be useful if you know nothing at all about setting up a modem; as you've found out, though, it can get in the way if you're actually trying to debug the connection. Since your modem is actually connecting, why not just drop back to using "pppd" itself and cut out the middleman?
Just for reference, here's the way that I use my CDMA setup:
1) I set up the two files required by "pppd", /etc/ppp/peers/1xevdo and /etc/chatscripts/1xevdo (see below.)
2) When using a GUI environment - which is the usual case - I click on an icon that launches a small xterm which lives in the lower right corner of my screen and shows the results of "pppd" output. This way, not only can I tell that it's still running - I can also kill it with 'Ctrl-C' if I want to.
3) If I ever need to use the modem from a CLI, I just pop into another console, type 'pppd call 1xevdo', and flip back to the console I was using.
It's a flexible system that's been serving me well these last X years.
My /etc/ppp/peers/1xevdo file, with my phone number replaced with #s:
-detach ttyUSB0 115200 debug noauth defaultroute replacedefaultroute usepeerdns connect-delay 3000 user ##########@vzw3g.com # show-password noproxyarp crtscts lock lcp-echo-failure 4 lcp-echo-interval 65535 connect '/usr/sbin/chat -v -t3 -f /etc/chatscripts/1xevdo'
The '/etc/chatscripts/1xevdo' file:
ABORT 'NO CARRIER' ABORT ERROR ABORT 'NO DIALTONE' ABORT BUSY ABORT 'NO ANSWER' '' 'AT' 'OK' 'ATE0V1&F&D2&C1&C2S0=0S7=60' 'OK' 'AT+CSQ' 'OK-AT-OK' 'ATDT#777' TIMEOUT 10 'CONNECT' ''
There's a bit of magic in the latter that sets up variable compression;
this is something that used to be critical - the modem wouldn't connect
without it - that I seem to recall is no longer required, but does no
harm. In any case, feel free to experiment with eliminating stuff - but
only after you've got a reliable connection.
Oh, and you also need to make sure that your password, if one is required, is defined in your /etc/ppp/chap-secrets. The password for Verizon's air cards is 'vzw', so the last line in my 'chap-secrets' looks like this (again, I've replaced the phone number part of my username with '#'s):
##########\@vzw3g\.com * vzw
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Amit Saha [amitsaha.in at gmail.com]
On Fri, Jul 10, 2009 at 9:09 PM, Ben Okopnik<[email protected]> wrote:
> On Fri, Jul 10, 2009 at 02:19:53PM +0530, Amit Saha wrote: >> >> My situation is like this: I am using 'wvdial' which in turns spawns >> 'pppd'. Any body would know how I can pass the '--kdebug' option to >> 'pppd' in this scenario ? > > I've been using a CDMA modem for the past 10>X>3 years (I'm a little > hazy on whether the early versions were CDMA or some precursor...), and > I just set up the latest iteration - a brand new, tiny USB dongle with > built-in flash memory and an external antenna - this morning, so I might > have something to contribute.
I saw that 'wvdial' was intelligent to guess my right settings and I could instantly start using the Modem. Hence, didn;t bother. However, with your help now, I am back to using 'pppd' directly. Now, I shall try and get some more information on its unexpected death.
Thanks a lot.
Best, Amit
Amit Saha [amitsaha.in at gmail.com]
Hello Ben, all:
On Sun, Jul 12, 2009 at 11:29 AM, Amit Saha<[email protected]> wrote:
> On Fri, Jul 10, 2009 at 9:09 PM, Ben Okopnik<[email protected]> wrote: >> On Fri, Jul 10, 2009 at 02:19:53PM +0530, Amit Saha wrote: >>> >>> My situation is like this: I am using 'wvdial' which in turns spawns >>> 'pppd'. Any body would know how I can pass the '--kdebug' option to >>> 'pppd' in this scenario ?
I ran with 'kdebug 1' and nothing much in /var/log/kern.log:
Jul 13 14:46:50 ubuntu904 kernel: [ 6462.801103] usb 6-1: USB disconnect, address 7 Jul 13 14:46:50 ubuntu904 kernel: [ 6462.805601] option 6-1:1.0: device disconnected Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806019] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from tty Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806432] option 6-1:1.1: device disconnected Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806849] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from tty Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806876] option 6-1:1.2: device disconnected Jul 13 14:46:50 ubuntu904 kernel: [ 6462.877478] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from tty Jul 13 14:46:52 ubuntu904 kernel: [ 6464.836135] usb 6-1: new full speed USB device using uhci_hcd and address 8 Jul 13 14:46:58 ubuntu904 kernel: [ 6470.055130] usb 6-1: configuration #1 chosen from 1 choice Jul 13 14:46:58 ubuntu904 kernel: [ 6470.060566] usb-storage: probe of 6-1:1.0 failed with error -1 Jul 13 14:46:58 ubuntu904 kernel: [ 6470.749210] usb 6-1: USB disconnect, address 8 Jul 13 14:46:58 ubuntu904 kernel: [ 6470.989275] usb 6-1: new full speed USB device using uhci_hcd and address 9
I don't get to see any clue.. Any ideas ?
Thanks, Amit
-- Journal: http://amitksaha.wordpress.com, Micro-blog: http://twitter.com/amitsaha Freenode: cornucopic in #scheme, #lisp, #math,#linux, #python
René Pfeiffer [lynx at luchs.at]
On Jul 13, 2009 at 1453 +0530, Amit Saha appeared and said:
> Hello Ben, all: > [...] > I ran with 'kdebug 1' and nothing much in /var/log/kern.log: > <code> > Jul 13 14:46:50 ubuntu904 kernel: [ 6462.801103] usb 6-1: USB > disconnect, address 7 > Jul 13 14:46:50 ubuntu904 kernel: [ 6462.805601] option 6-1:1.0: > device disconnected > Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806019] option1 ttyUSB1: GSM > modem (1-port) converter now disconnected from tty > Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806432] option 6-1:1.1: > device disconnected > Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806849] option1 ttyUSB2: GSM > modem (1-port) converter now disconnected from tty > Jul 13 14:46:50 ubuntu904 kernel: [ 6462.806876] option 6-1:1.2: > device disconnected > Jul 13 14:46:50 ubuntu904 kernel: [ 6462.877478] option1 ttyUSB0: GSM > modem (1-port) converter now disconnected from tty > Jul 13 14:46:52 ubuntu904 kernel: [ 6464.836135] usb 6-1: new full > speed USB device using uhci_hcd and address 8 > Jul 13 14:46:58 ubuntu904 kernel: [ 6470.055130] usb 6-1: > configuration #1 chosen from 1 choice > Jul 13 14:46:58 ubuntu904 kernel: [ 6470.060566] usb-storage: probe of > 6-1:1.0 failed with error -1 > Jul 13 14:46:58 ubuntu904 kernel: [ 6470.749210] usb 6-1: USB > disconnect, address 8 > Jul 13 14:46:58 ubuntu904 kernel: [ 6470.989275] usb 6-1: new full > speed USB device using uhci_hcd and address 9 > </code> > I don't get to see any clue.. Any ideas ?
Maybe your USB device is reconnecting and changing its ID on the USB. I have the same problem with my laptop and a T-Mobile stick. I had to disable the USB 2.0 modules to make it stable.
Best, René.
Amit Saha [amitsaha.in at gmail.com]
On Mon, Jul 13, 2009 at 3:17 PM, René Pfeiffer<[email protected]> wrote:
> On Jul 13, 2009 at 1453 +0530, Amit Saha appeared and said: >> Hello Ben, all: >> [...] >> I ran with 'kdebug 1' and nothing much in /var/log/kern.log:
Curiously enough- the number of times my connection dies (or PPPD dies) has considerably decreased (or even not happening), since I have started running 'pppd' in 'kdebug' mode...
-Amit
Ben Okopnik [ben at linuxgazette.net]
On Thu, Jul 16, 2009 at 08:34:44AM +0530, Amit Saha wrote:
> On Mon, Jul 13, 2009 at 3:17 PM, René Pfeiffer<[email protected]> wrote: > > On Jul 13, 2009 at 1453 +0530, Amit Saha appeared and said: > >> Hello Ben, all: > >> [...] > >> I ran with 'kdebug 1' and nothing much in /var/log/kern.log: > > Curiously enough- the number of times my connection dies (or PPPD > dies) has considerably decreased (or even not happening), since I have > started running 'pppd' in 'kdebug' mode...
Well, cutting steps of unknown reliability out of the equation is always a plus. Years ago, I used to teach classes on PC repair by the "strip-down" method:
1) Unplug everything except the power cord, disconnect all the drives, pull out all the boards and the memory, then fire it up and listen for the appropriate POST beeps.
2) Turn the machine off, add one thing, turn it back on, and look for the correct response.
3) Keep doing step 2 until everything works - or until you've discovered the failed part.
In other words, strip it down to its "known good" state and build up from there. That's a pretty good approach for many things and situations.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *