How to get Bell Canada 3G USB network up?
Christian Jaeger
I'm trying to get a UMTS/HSPA/HSAP+ usb stick from Bell Canada working
with their network. I'm on Lenny, with a 2.6.33.6 kernel compiled from
kernel.org.
At first I'm "activating" the stick through that usual "mount then
eject the flash volume" handling, and reloading the usbserial kernel
module manually since it doesn't seem to pick up the change of the
product id by itself (wondering why not):
#!/bin/bash
mount /dev/disk/by-id/usb-Novatel_Mass_Storage_012067000784101-0:0
/mnt/usb-Novatel_Mass_Storage_012067000784101-0:0 || exit 1
umount /mnt/usb-Novatel_Mass_Storage_012067000784101-0:0
eject /dev/disk/by-id/usb-Novatel_Mass_Storage_012067000784101-0:0
(
while true; do
sleep 0.5
if lsusb |grep -q 1410:7030; then
exit
fi
done
)
rmmod option
rmmod usbserial
sleep 0.1
modprobe usbserial vendor=0x1410 product=0x7030
modprobe option
BTW loading the "option" module leads to a message 'option: v0.7.2:USB
Driver for GSM modems', but interestingly /dev/ttyUSB0 already exists
with only usbserial loaded and I wonder what the kernel should be
doing apart from handling that tty? The "real" stuff is being done by
pppd in userspace, right? So what does "option" do?
/etc/ppp/peers/bell3g:
# This optionfile was generated by pppconfig 2.3.18.
#
#
hide-password
noauth
noccp
connect "/usr/sbin/chat -v -f /etc/chatscripts/bell3g"
debug
/dev/ttyUSB0
115200
defaultroute
noipdefault
user replace_with_your_login_name
remotename bell3g
ipparam bell3g
usepeerdns
I've added the line with noccp in the above file, following a
suggestion from
https://lists.ubuntu.com/archives/ubuntu-users/2008-January/133699.html,
which seems to have eliminated a "pppd[18364]: Protocol-Reject for
'Compression Control Protocol' (0x80fd) received" error.
/etc/chatscripts/bell3g:
# This chatfile was generated by pppconfig 2.3.18.
# Please do not delete any of the comments. Pppconfig needs them.
#
# ispauth PAP
# abortstring
ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT
'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED
# modeminit
'' ATZ
# ispnumber
OK-AT-OK ATDT*99#
# ispconnect
CONNECT \d\c
# prelogin
# ispname
# isppassword
# postlogin
# end of pppconfig stuff
Running
pon bell3g
now leads to the following output in /var/log/syslog:
Jul 9 10:11:14 novo pppd[18881]: pppd 2.4.4 started by root, uid 0
Jul 9 10:11:15 novo chat[18884]: abort on (BUSY)
Jul 9 10:11:15 novo chat[18884]: abort on (NO CARRIER)
Jul 9 10:11:15 novo chat[18884]: abort on (VOICE)
Jul 9 10:11:15 novo chat[18884]: abort on (NO DIALTONE)
Jul 9 10:11:15 novo chat[18884]: abort on (NO DIAL TONE)
Jul 9 10:11:15 novo chat[18884]: abort on (NO ANSWER)
Jul 9 10:11:15 novo chat[18884]: abort on (DELAYED)
Jul 9 10:11:15 novo chat[18884]: send (ATZ^M)
Jul 9 10:11:15 novo chat[18884]: expect (OK)
Jul 9 10:11:15 novo chat[18884]: ATZ^M^M
Jul 9 10:11:15 novo chat[18884]: OK
Jul 9 10:11:15 novo chat[18884]: -- got it
Jul 9 10:11:15 novo chat[18884]: send (ATDT*99#^M)
Jul 9 10:11:15 novo chat[18884]: expect (CONNECT)
Jul 9 10:11:15 novo chat[18884]: ^M
Jul 9 10:11:15 novo chat[18884]: ATDT*99#^M^M
Jul 9 10:11:15 novo chat[18884]: CONNECT
Jul 9 10:11:15 novo chat[18884]: -- got it
Jul 9 10:11:15 novo chat[18884]: send (\d)
Jul 9 10:11:16 novo pppd[18881]: Serial connection established.
Jul 9 10:11:16 novo pppd[18881]: using channel 5
Jul 9 10:11:16 novo pppd[18881]: Using interface ppp1
Jul 9 10:11:16 novo pppd[18881]: Connect: ppp1 <--> /dev/ttyUSB0
Jul 9 10:11:17 novo pppd[18881]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0xe741e65a> <pcomp> <accomp>]
Jul 9 10:11:17 novo pppd[18881]: rcvd [LCP ConfReq id=0x7 <asyncmap
0x0> <auth chap MD5> <magic 0x33f003c> <pcomp> <accomp>]
Jul 9 10:11:17 novo pppd[18881]: sent [LCP ConfNak id=0x7 <auth pap>]
Jul 9 10:11:17 novo pppd[18881]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0xe741e65a> <pcomp> <accomp>]
Jul 9 10:11:17 novo pppd[18881]: rcvd [LCP ConfReq id=0x8 <asyncmap
0x0> <auth pap> <magic 0x33f003c> <pcomp> <accomp>]
Jul 9 10:11:17 novo pppd[18881]: sent [LCP ConfAck id=0x8 <asyncmap
0x0> <auth pap> <magic 0x33f003c> <pcomp> <accomp>]
Jul 9 10:11:17 novo pppd[18881]: sent [LCP EchoReq id=0x0 magic=0xe741e65a]
Jul 9 10:11:17 novo pppd[18881]: sent [PAP AuthReq id=0x1
user="replace_with_your_login_name" password=<hidden>]
Jul 9 10:11:17 novo pppd[18881]: rcvd [LCP DiscReq id=0x9 magic=0x33f003c]
Jul 9 10:11:17 novo pppd[18881]: rcvd [LCP EchoRep id=0x0
magic=0x33f003c e7 41 e6 5a]
Jul 9 10:11:17 novo pppd[18881]: rcvd [PAP AuthAck id=0x1 ""]
Jul 9 10:11:17 novo pppd[18881]: PAP authentication succeeded
Jul 9 10:11:17 novo pppd[18881]: sent [IPCP ConfReq id=0x1 <compress
VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jul 9 10:11:18 novo pppd[18881]: rcvd [IPCP ConfNak id=0x1 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Jul 9 10:11:18 novo pppd[18881]: sent [IPCP ConfReq id=0x2 <compress
VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Jul 9 10:11:45 novo last message repeated 9 times
Jul 9 10:11:47 novo pppd[18881]: sent [LCP EchoReq id=0x1 magic=0xe741e65a]
Jul 9 10:11:48 novo pppd[18881]: IPCP: timeout sending Config-Requests
Jul 9 10:11:48 novo pppd[18881]: sent [LCP TermReq id=0x2 "No
network protocols running"]
Jul 9 10:11:51 novo pppd[18881]: sent [LCP TermReq id=0x3 "No
network protocols running"]
Jul 9 10:11:54 novo pppd[18881]: Connection terminated.
Jul 9 10:11:55 novo pppd[18881]: Modem hangup
Jul 9 10:11:55 novo pppd[18881]: Exit.
Also wondering about this user stuff, I didn't get any information
from Bell about user/password, maybe there is none (SIM card being
enough authentification)? Would I have to eliminate that somehow?
Thanks for your help
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinx7EHlsZnLdgqTt...@mail.gmail.com
Christian Jaeger
privatly about this.
No, I didn't get it to work with plain pppd, although I mostly stopped
looking into that. Instead I first tried with Ubuntu, got it partially
working (usb modeswitch didn't work reliably), so installed another
laptop with Debian testing and network manager. Network manager can
handle it on first try *once the modem has been usb mode switched*,
but that latter was a real problem, seems the usb mode switch tool
cannot do it reliably, it only switched in some quite rare cases where
the timing of plugging it +-quickly in succession was the reason to
make it work.
So I instead improved my own scripts instead, ending up with the 3
scripts I'm attaching. I've placed them all in /root/local/sbin/, and
changed the file /lib/udev/rules.d/40-usb_modeswitch.rules to contain
the following (replace for the line that is now prefixed with
"#orig"):
# Novatel Wireless devices
#CJ
#orig ATTRS{idVendor}=="1410", ATTRS{idProduct}=="5010",
RUN+="usb_modeswitch '%b/%k'"
ATTRS{idVendor}=="1410", ATTRS{idProduct}=="5010",
RUN+="/root/local/sbin/bellstickactivateudevhack '%b/%k'"
#/CJ
Note that this file is from the usb-modeswitch-data package; it might
be cleaner to create a new file separate from that package instead
(but taking priority over the latter) to make it work regardless
whether usb-modeswitch is installed or not, but considering this is a
hack I didn't care to try.
Note that:
- my above mode switch hack is slow, it takes almost 30 seconds until
the modem is ready
- the 10 second delay in the bellstickactivateudevhack script is
necessary, I guess because something else triggered from udev has to
finish running first; of course this just works around a problem I
don't know and hence a total hack
Also, I've also still got the following problems, which I think are
not related to my hack:
- I already get the connection up the first time I insert the stick,
*but* the connection stops working after about 5-10 seconds (the LED
on the stick goes back to slow flashing mode, which I gather is an
indication for not being connected; network manager still shows it
connected at that point; stopping the connection in network manager
then reactivating it does not work, I have to unplug and replug the
stick); only after a couple fresh tries the connection stays up (it
takes from ~2-10 attempts). Once it stays up, it stays up indefinitely
(as long as I stay in the same location), but of course this is a
major pain, it wastes several minutes of my time. I wonder if it's
related to temperature, since the stick gets quite warm (it eats about
2 W of power all the time even when no transfers are being made),
maybe it does not work right when cold; or maybe the linux drivers
(i.e. network manager) don't implement dealing with base stations
correctly, like they should resend some kind of reaffirmations or so
and don't, and hence require me to kind of do the reaffirmation
manually.
- somehow reception is pretty weak, there are many places where I
don't get a connection where GSM phone calls with my mobile work just
fine (admittedly the latter is with a different provider, but I don't
think that Bell have such a bad network in comparison; maybe the
modern data networks just need closer proximity to the base stations
than GSM).
So I wonder whether the stick is just bad hardware or broken and I
should return it (difficult to do while saying I'm running it under
Linux, I guess?), or whether there is a software solution. I'm tempted
to get rid of it and use a modern mobile phone with bluetooth
tethering instead.
Christian.
Christian Jaeger
down the problem with my disconnects a bit:
It seems that I'm loosing connection whenever the stick changes
connection mode, or at least when it changes from UMTS to HSPA or
HSUPA. Meaning, it connects with UMTS and I'm getting internet access
until it changes ~30 seconds later to one of the latter, then the
internet connection is broken, disconnecting and reconnecting with the
network manager applet won't work, I have to unplug and replug the
stick for another attempt. Seems only if I'm lucky and it decides to
stay on UMTS that I'm getting continuous internet access. This seems
consistent with my observation that I'm often not having any problem
at all in remote areas, whereas in the city core it's worst (meaning,
in areas that only have UMTS access points there is no problem at
all).
Thanks for any ideas on how to solve this (I'll take that to the
network manager developers, too--but then, maybe I'll have a phone
connetion up and running before that and drop it).
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTikA_Vc3xvw+Btbh4...@mail.gmail.com
Christian Jaeger
Bell technical support told me that I should run a firmware upgrade on
the stick (and gave me a link to the exact file). Of course that's a
windows .exe. I tried to run it in a second hand computer store that
let me plug in my Bell stick, but it didn't work, probably because I
didn't install the driver beforehand, the installer and upgrade
utility conflicted with each other. So I gave up for some time.
Now I've finally gotten an own computer with Windows (XP), so I
installed the modem first, then ran the firmware upgrade. Both worked
without problems. Also, on Windows the modem doesn't seem to exhibit
that disconnect problem. Then I tried again on Debian, and nothing
changed, disconnection on first try. Duh.
So, if anyone knows what's left that I could try (well I'll try
contacting some network manager people), or knows which USB UMTS modem
works on Debian in Canada (with Bell), please tell.
Thanks
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTin1A53W_HGPYyq=VR58K2d...@mail.gmail.com
Jasper Noe
>
> Another update in my quest to get that UMTS modem work properly:
>
> Bell technical support told me that I should run a firmware upgrade on
> the stick (and gave me a link to the exact file). Of course that's a
> windows .exe. I tried to run it in a second hand computer store that
> let me plug in my Bell stick, but it didn't work, probably because I
> didn't install the driver beforehand, the installer and upgrade
> utility conflicted with each other. So I gave up for some time.
>
> Now I've finally gotten an own computer with Windows (XP), so I
> installed the modem first, then ran the firmware upgrade. Both worked
> without problems. Also, on Windows the modem doesn't seem to exhibit
> that disconnect problem. Then I tried again on Debian, and nothing
> changed, disconnection on first try. Duh.
>
> So, if anyone knows what's left that I could try (well I'll try
> contacting some network manager people), or knows which USB UMTS modem
> works on Debian in Canada (with Bell), please tell.
>
> Thanks
> Christian.
>
>
Reading your first post on this issue I see that you remove the option module in
favor of usbserial. That advice is all over the net. Are you still doing that ?
I think it is -basically- wrong: 'option' is the specialised driver for this and
many other 3g modems. 'usbserial' is -only- a generic driver on which you can
fall back if-all-else-fails. ( I am citing the author of usbserial )
I suggest that you go back to the beginning, probably a clean, fresh install of
Squeeze, stick the modem in and see what happens. Or a live cd, or, ..
In Squeeze usbmodeswitch is standard.
Then the option module should grab the modem.
The module creates /dev/ttyUSB*
After that the dialling: that is specific for your provider.
HTH, --Jasper.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/loom.2011053...@post.gmane.org
Jasper Noë
>
> Another update in my quest to get that UMTS modem work properly:
>
> Bell technical support told me that I should run a firmware upgrade on
> the stick (and gave me a link to the exact file). Of course that's a
> windows .exe. I tried to run it in a second hand computer store that
> let me plug in my Bell stick, but it didn't work, probably because I
> didn't install the driver beforehand, the installer and upgrade
> utility conflicted with each other. So I gave up for some time.
>
> Now I've finally gotten an own computer with Windows (XP), so I
> installed the modem first, then ran the firmware upgrade. Both worked
> without problems. Also, on Windows the modem doesn't seem to exhibit
> that disconnect problem. Then I tried again on Debian, and nothing
> changed, disconnection on first try. Duh.
>
> So, if anyone knows what's left that I could try (well I'll try
> contacting some network manager people), or knows which USB UMTS modem
> works on Debian in Canada (with Bell), please tell.
>
> Thanks
> Christian.
>
>
Reading your first post on this issue I see that you remove the option
module in favor of usbserial. That advice is all over the net. Are you
still doing that ?
I think it is -basically- wrong: 'option' is the specialised driver for
this and many other 3g modems. 'usbserial' is -only- a generic driver on
which you can fall back if-all-else-fails. ( I am citing the author of
usbserial )
I suggest that you go back to the beginning, probably a clean, fresh
install of Squeeze, stick the modem in and see what happens. Or a live
cd, or, ..
In Squeeze usbmodeswitch is standard.
Then the option module should grab the modem.
The module creates /dev/ttyUSB*
After that the dialling: that is specific for your provider.
HTH, --Jasper.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pablo Sánchez
He is a NM developer .
Good info there .
Pablo Sánchez .
Christian Jaeger
> favor of usbserial. That advice is all over the net. Are you still doing that ?
> I think it is -basically- wrong: 'option' is the specialised driver for this and
> many other 3g modems. 'usbserial' is -only- a generic driver on which you can
> fall back if-all-else-fails. ( I am citing the author of usbserial )
I think I'm only removing the modules so they can be reloaded
afterwards, i.e. to reset their state. At least I think it worked
equally both with reloading option afterwards and without.
Now, option is actually loaded when I connect; and, interestingly it's
not at the top of lsmod output, and, as I realize now, my own
initialization scripts are not even called anymore as it seems. I'm
quite confused; on 2011-03-20
/lib/udev/rules.d/40-usb_modeswitch.rules was changed to a version
that doesn't call my hook. I don't have any record that I did this
myself, and don't remember anything about it, I can only conclude that
some Debian package upgrade did it. Sigh. (Ok I know that /lib isn't
/etc, but then why are those files in /lib? Or do /etc/udev/ files
override those in /lib/udev?)
It seems the option module is actually being used by network manager
(directly or indirectly), since lsmod shows its use count going up to
2 when I'm connecting, and dropping back to 0 when I unplug the stick.
option 12918 2
usb_wwan 6147 1 option
usbserial 21120 7 option,usb_wwan
> I suggest that you go back to the beginning, probably a clean, fresh install of
> Squeeze, stick the modem in and see what happens. Or a live cd, or, ..
I've just booted from a current Ubuntu live image. The exact same
thing happens once it connects: 20 seconds after connection is up it
is being dropped again. (This happened 2 times.) The difference to my
Debian setup is that about 4 further times I tried to up the
connection, it didn't even enter up state; network manager would just
show "connected", but the stick would still blink its LED instead of
going to light it up constantly as it would when connected, then a
couple seconds later network manager would say "disconnected"; after
that no connection attempt succeeds, I unplug+replug the stick to try
again. So it's just worse...
> In Squeeze usbmodeswitch is standard.
Yes, but it didn't work reliably in Ubuntu back when I tried a year
ago, and not at all in Squeeze (testing back then), which led me to
write my own switching scripts.
When I tried it on the newer Ubuntu today, watching syslog and nm
popup messages, it seems usbmode switching is reliable (and fast, in
~2 seconds), but as mentioned it then fails to connect at all in the
majority of cases. Actually I think that's exactly what happened a
year ago, and I probably just mis-concluded that usb mode switching
wasn't reliable on Ubuntu, where in fact the switching itself seems to
work fine, but somehow in about 2/3 of cases leaves it in a state that
doesn't allow it to connect.
How do you connect, using nm or something else?
Well I'm also going to try a Debian live image, to confirm whether
withoug my own scripts it works the same.
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTi=NejD82GBKQi48...@mail.gmail.com
Jasper Noë
>> Reading your first post on this issue I see that you remove the option module in
>> favor of usbserial. That advice is all over the net. Are you still doing that ?
>> I think it is -basically- wrong: 'option' is the specialised driver for this and
>> many other 3g modems. 'usbserial' is -only- a generic driver on which you can
>> fall back if-all-else-fails. ( I am citing the author of usbserial )
>
> I think I'm only removing the modules so they can be reloaded
> afterwards, i.e. to reset their state. At least I think it worked
> equally both with reloading option afterwards and without.
>
> Now, option is actually loaded when I connect; and, interestingly it's
The module is loaded when you insert the modem
> not at the top of lsmod output, and, as I realize now, my own
> initialization scripts are not even called anymore as it seems. I'm
> quite confused; on 2011-03-20
> /lib/udev/rules.d/40-usb_modeswitch.rules was changed to a version
> that doesn't call my hook. I don't have any record that I did this
> myself, and don't remember anything about it, I can only conclude that
> some Debian package upgrade did it. Sigh. (Ok I know that /lib isn't
> /etc, but then why are those files in /lib? Or do /etc/udev/ files
> override those in /lib/udev?)
>
> It seems the option module is actually being used by network manager
> (directly or indirectly), since lsmod shows its use count going up to
> 2 when I'm connecting, and dropping back to 0 when I unplug the stick.
>
> option 12918 2
> usb_wwan 6147 1 option
> usbserial 21120 7 option,usb_wwan
>
I am worried about this 'usb_wwan', it seems to do exactly what 'option'
is supposed to do. rmmod usb_wwan ? Is it nm doing this ?
>
>> I suggest that you go back to the beginning, probably a clean, fresh install of
>> Squeeze, stick the modem in and see what happens. Or a live cd, or, ..
>
> I've just booted from a current Ubuntu live image. The exact same
> thing happens once it connects: 20 seconds after connection is up it
> is being dropped again. (This happened 2 times.) The difference to my
> Debian setup is that about 4 further times I tried to up the
> connection, it didn't even enter up state; network manager would just
> show "connected", but the stick would still blink its LED instead of
> going to light it up constantly as it would when connected, then a
> couple seconds later network manager would say "disconnected"; after
> that no connection attempt succeeds, I unplug+replug the stick to try
> again. So it's just worse...
>
>> In Squeeze usbmodeswitch is standard.
>
> Yes, but it didn't work reliably in Ubuntu back when I tried a year
> ago, and not at all in Squeeze (testing back then), which led me to
> write my own switching scripts.
>
> When I tried it on the newer Ubuntu today, watching syslog and nm
> popup messages, it seems usbmode switching is reliable (and fast, in
> ~2 seconds), but as mentioned it then fails to connect at all in the
> majority of cases. Actually I think that's exactly what happened a
> year ago, and I probably just mis-concluded that usb mode switching
> wasn't reliable on Ubuntu, where in fact the switching itself seems to
> work fine, but somehow in about 2/3 of cases leaves it in a state that
> doesn't allow it to connect.
The modeswitching is just the first stage, a very annoying hurdle, it
has nothing to do with connecting. ( but indeed, if it does not work it
"won't allow you to connect" although that sounds confused to me. )
The second stage is the loading of the proper module which makes the
device accessible. ( presence of /dev/ttyUSB* )
Now we can 'talk' to this thing. It works like an old fashioned
telephoneline-modem with 'AT-' commands, we can tell it to 'dial',
disconnect, scan for available networks, measure signalstrength etc.
One might use 'minicom' to play with it.
Or use 'chat', which is part of the package 'ppp', to write scripts that
manipulate the modem.
>
> How do you connect, using nm or something else?
I avoid nm like the plague, but that said, if it is ready it might be
beautiful. I prefer low-level tools.
Like wvdial. Run 'wvdialconf' -if- the modem is accessible. And then
tweak /etc/wvdial.conf .
I do not own a 3g modem myself, but over time I have made several of
them working, on debian systems.
>
> Well I'm also going to try a Debian live image, to confirm whether
> withoug my own scripts it works the same.
I am curious.
>
> Christian.
bye, --Jasper.
( not sure if I hit your problem at all, but since the hardware is
working in windows, it should ... )
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Jaeger
>> usb_wwan 6147 1 option
>> usbserial 21120 7 option,usb_wwan
>>
>
> I am worried about this 'usb_wwan', it seems to do exactly what 'option' is
> supposed to do. rmmod usb_wwan ? Is it nm doing this ?
As you can see from the lsmod output, usb_wwan is required by option.
>>> I suggest that you go back to the beginning, probably a clean, fresh
>>> install of
>>> Squeeze, stick the modem in and see what happens. Or a live cd, or, ..
So I've done that now (fresh squeeze install on my netbook). It's just
like in the Ubuntu live system: the modem is being recognized and
usb-modeswitched out of the box (some of the times), configuring the
country/provider makes it work, but same story: (1) half the times I
plug in the modem, it won't work at all (modeswitching works and it
shows up in the nm menu, but choosing 'activate' just spins for a
couple seconds but does nothing); (2) if (1) worked, then just as with
my hand hacked older Debian setup, after 20 seconds it will loose
connection about in half of the cases.
BTW lately I've cared to observe the exact moment when it 'crashes'.
It is 20 seconds after connection initiation and really exactly when
it switches from "U" (umts) to "H" (HSPA).
> The modeswitching is just the first stage, a very annoying hurdle, it has
> nothing to do with connecting.
Yes I know, but as I've described, there must be *something* in the
way that Debian's/Ubuntus builtin usbmodeswitch works that leaves the
modem nonworkable in half the cases. Whereas with my own modeswitching
script that's never an issue.
> ( but indeed, if it does not work it "won't
> allow you to connect" although that sounds confused to me. )
(To help explain what I wrote above:
* the modem LED is off after plugging it into the USB port and before
usb modeswitching happens
* after the mode switch runs, the modem LED is blinking in blue
(sometimes it inserts a lone blink in green between the blue ones, no
idea what it means)
* when the modem is connected, the modem LED is lighting up in constant blue
* when there has been traffic, the modem LED color changes to green,
orange, yellow or purple (I don't know what these colors mean, it
might indicate the network speed), but it stays lit up constantly
* when the modem is disconnected (either on purpose through the nm
menu, or when I move to a place with no network coverage (metro), or
when it ' 'crashes' at the 20 second point), it goes back to blue
blinking
Thus I can see when the usb mode switch happened because I see the
blue blinking. Which the fresh Debian install / Ubuntu live system do
100% of the time; only, in what seems to be exactly half of the cases,
choosing connect from the nm menu (which I have to do, I haven't
configured nm to connect automatically) will not bring the connection
up. Which I can see both because nm just goes back to disconnected
state after a couple seconds, and the modem never goes from blinking
to constantly lit mode.)
>
> The second stage is the loading of the proper module which makes the device
> accessible. ( presence of /dev/ttyUSB* )
>
> Now we can 'talk' to this thing. It works like an old fashioned
> telephoneline-modem with 'AT-' commands, we can tell it to 'dial',
> disconnect, scan for available networks, measure signalstrength etc.
> One might use 'minicom' to play with it.
Yeah I know, I used those a bit in the old 56k telephone modem times.
But I haven't really tried to find a command list for 3G modems.
(Also, I'm not sure what to do: how would I bring ppp up in such a
manual scenario, i.e. from minicom? Also, in the old times, once ppp
is up, the computer normally wouldn't send AT commands to the modem,
except to interrupt ppp stream to bring it down. Since nowadays modems
need to transmit state changes like the change from UMTS to HSPA, I
wonder how that happens. In any case, I've got no idea what to look
out for, and also, even if I knew to pinpoint it down to a particular
feature, I'd have to observe what nm is doing, too, to know what else
to try.)
>
> Or use 'chat', which is part of the package 'ppp', to write scripts that
> manipulate the modem.
>
>>
>> How do you connect, using nm or something else?
>
> I avoid nm like the plague, but that said, if it is ready it might be
> beautiful. I prefer low-level tools.
Yeah I tried to go with the low-level tools too, at first, then after
being unsuccessful gave in and went with nm. (I might try to find the
mails I sent during that time; after unsuccessfully trying ppp, I also
tried to go that "option" (iirc) route (the one that supercedes ppp),
w/o success either.)
> Like wvdial. Run 'wvdialconf' -if- the modem is accessible. And then tweak
> /etc/wvdial.conf .
I didn't try wvdial. Hm, I'll have to surf around to figure out how to tweak it.
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTi_dg2zeda1...@mail.gmail.com
Scott Ferguson
<snipped>
> * after the mode switch runs, the modem LED is blinking in blue
UMTS
> (sometimes it inserts a lone blink in green between the blue ones, no
> idea what it means)
changing connection protocol
> * when the modem is connected, the modem LED is lighting up in constant blue
Blue? or Cyan? HSUPA
> * when there has been traffic, the modem LED color changes to green,
(flashing) GPRS
> orange,
Yellow OR flashing Red (sorry Orange is not an option!)
Yellow is HSDPA
flashing Red is a SIM error - remove the SIM card - clean contacts with
a soft white pencil eraser, reinsert (a tiny fold of paper can be
inserted behind the SIM if it requires more pressure against the contacts)
> yellow
HSDPA (again)
> or purple
well it's *supposed* to be Violet, and it flashes
EDGE
>(I don't know what these colors mean,
Yes you do! Now. :-D
Wikipedia will give you a nice explanation of the various protocols.
I'd suggest you give the device no choice eg.force it to only connect
UMTS using the AT commands.
<snipped to save electrons, and Ralf's sanity>
Is that a Novatel U950??
The vendor code should be 0x1410 - what are the product codes please?
If so I suspect it's actually a rebadged Ovation MC950D using the
Qualcomm MSM7200 chipset.
If so the following will probably work for you
(should it break you may keep both pieces)
ATEI (get OK response)
AT$AUTOINSTALL=0
No longer need modeswitch. :-) It's only useful once anyway, and usually
only on Mac or Windoof, it's rare to see Linux drives on the virtual cd
(Alcatel have them, they just don't work).
I normally let that irritating fake cd mount just once (long enough to
copy the software somewhere safe should I ever need it) - then disable
the bl$%dy thing.
If any one know the AT command set for Alcatel I'd love to hear it -
I've never managed to figure out the ZCDRUN or equiv for them.
--
Tuttle? His name's Buttle.
There must be some mistake.
Mistake? [Chuckles]
We don't make mistakes. [Crash!]
Bloody typical. They've gone back
to metric without telling us.
Terry Gilliam's "Brazil"
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jasper Noë
On 11-06-11 20:19, Christian Jaeger wrote:
>>> option 12918 2
>>> usb_wwan 6147 1 option
>>> usbserial 21120 7 option,usb_wwan
>>>
>>
>> I am worried about this 'usb_wwan', it seems to do exactly what 'option' is
>> supposed to do. rmmod usb_wwan ? Is it nm doing this ?
>
> As you can see from the lsmod output, usb_wwan is required by option.
>
I was a bit stupid there. ( I have linux-sources installed and was
looking into these files. )
>>>> I suggest that you go back to the beginning, probably a clean, fresh
>>>> install of
>>>> Squeeze, stick the modem in and see what happens. Or a live cd, or, ..
>
> So I've done that now (fresh squeeze install on my netbook). It's just
> like in the Ubuntu live system: the modem is being recognized and
> usb-modeswitched out of the box (some of the times), configuring the
> country/provider makes it work, but same story: (1) half the times I
> plug in the modem, it won't work at all (modeswitching works and it
> shows up in the nm menu, but choosing 'activate' just spins for a
> couple seconds but does nothing); (2) if (1) worked, then just as with
> my hand hacked older Debian setup, after 20 seconds it will loose
> connection about in half of the cases.
>
> BTW lately I've cared to observe the exact moment when it 'crashes'.
> It is 20 seconds after connection initiation and really exactly when
> it switches from "U" (umts) to "H" (HSPA).
>
So this must be your problem.
I do not know how to help here.
( I see you have another answer that may help )
<snip>
>>
>> The second stage is the loading of the proper module which makes the device
>> accessible. ( presence of /dev/ttyUSB* )
>>
>> Now we can 'talk' to this thing. It works like an old fashioned
>> telephoneline-modem with 'AT-' commands, we can tell it to 'dial',
>> disconnect, scan for available networks, measure signalstrength etc.
>> One might use 'minicom' to play with it.
>
> Yeah I know, I used those a bit in the old 56k telephone modem times.
> But I haven't really tried to find a command list for 3G modems.
I have something here:
http://rjnoe.home.xs4all.nl/0/linux/3g/at-commands/
>
> (Also, I'm not sure what to do: how would I bring ppp up in such a
> manual scenario, i.e. from minicom? Also, in the old times, once ppp
> is up, the computer normally wouldn't send AT commands to the modem,
> except to interrupt ppp stream to bring it down. Since nowadays modems
> need to transmit state changes like the change from UMTS to HSPA, I
> wonder how that happens. In any case, I've got no idea what to look
> out for, and also, even if I knew to pinpoint it down to a particular
> feature, I'd have to observe what nm is doing, too, to know what else
> to try.)
It has multiple entries in /dev : /dev/ttyUSB0 , /dev/ttyUSB1 ,
/dev/ttyUSB2 . One of them is for 'control'.
>
>>
>> Or use 'chat', which is part of the package 'ppp', to write scripts that
>> manipulate the modem.
>>
>>>
>>> How do you connect, using nm or something else?
>>
>> I avoid nm like the plague, but that said, if it is ready it might be
>> beautiful. I prefer low-level tools.
>
> Yeah I tried to go with the low-level tools too, at first, then after
> being unsuccessful gave in and went with nm. (I might try to find the
> mails I sent during that time; after unsuccessfully trying ppp, I also
> tried to go that "option" (iirc) route (the one that supercedes ppp),
> w/o success either.)
>
I don't get that, 'option' is the driver, ppp or whatever else ( NM,
wvdial ) will rely on it. Unless you replace 'option' with 'usbserial'
which, I think, is a mistake.
>> Like wvdial. Run 'wvdialconf' -if- the modem is accessible. And then tweak
>> /etc/wvdial.conf .
>
> I didn't try wvdial. Hm, I'll have to surf around to figure out how to tweak it.
>
> Christian.
>
>
Sometime ago I wrote some scripts, playing with a 'hso' modem. They are
here: http://rjnoe.home.xs4all.nl/0/linux/3g/
I think you can replace 'hso' with 'usb' in some places.
--Jasper.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Jaeger
> On 12/06/11 04:19, Christian Jaeger wrote:
> <snipped>
>> * after the mode switch runs, the modem LED is blinking in blue
>
>
> UMTS
Well, as I said, as long as it's blinking, it isn't connected, at
least as far as the computer is concerned. Of course the modem itself
might already connect to the base stations and the color might already
mean something at that point.
...
>> orange,
>
> Yellow OR flashing Red (sorry Orange is not an option!)
I don't think I've ever seen it red (and never flashing, when it was
connected).
I wouldn't vow having seen orange, especially since the light mixing
in the LED isn't perfect (so depending on angle the yellow is looking
somewhat orange anyway) and color changes sometimes happen quickly. I
thought it was at least 4 colors aside blue, but so maybe it's just
yellow, purple/violet and green.
>> yellow
>
> HSDPA (again)
Well the funny thing is that nm always shows UMTS during the first
seconds then usually HSPA (/HSUPA/HSDPA) afterwards, but the color
change from the modem happens independently: it usually changes from
blue to yellow as soon as there is somewhat intense traffic (of
course, changing to HS*PA from UMTS makes sense for that), which can
be like 5 seconds after connecting already, and still nm only shows
the change to HSPA 15 seconds afterwards.
>> or purple
>
> well it's *supposed* to be Violet, and it flashes
> EDGE
Nah, it doesn't flash when in purple/violet color. Usually that color
is only somewhat shortlived, though, like a couple seconds between
yellow and blue(?) phases, but IIRC I've seen it stay for longer
periods at purple, too, and it never flashed.
> Wikipedia will give you a nice explanation of the various protocols.
(Yep, I've read about them in the past.)
How do you know about the color codes?
> I'd suggest you give the device no choice eg.force it to only connect
> UMTS using the AT commands.
Good point; nm only allows to downgrade to "2G(GPRS/EDGE)" from the
GUI (iirc I tried that and it didn't work, I guess my data-only
contract is 3G only), so I guess I'll have to use another tool like
minicom to inject the AT commands from a script called by a udev hook.
>
> <snipped to save electrons, and Ralf's sanity>
(Ralf?)
Hm, so, which AT commands?
I've not been successful searching for 'novatel "at commands"' and similar.
>
> Is that a Novatel U950??
> The vendor code should be 0x1410 - what are the product codes please?
Novatel MC998D/U998,
before usb mode switching: 1410:5010,
afterwards: 1410:7030
> If so I suspect it's actually a rebadged Ovation MC950D using the
> Qualcomm MSM7200 chipset.
> If so the following will probably work for you
> (should it break you may keep both pieces)
> ATEI (get OK response)
> AT$AUTOINSTALL=0
tie:~# screen /dev/ttyUSB1
AT
OK
ATEI
Manufacturer: Novatel Wireless Incorporated
Model: Ovation MC998D
Revision: 1.16.12.01-02 [2010-05-12 16:23:18]
IMEI: 012067000784103
+GCAP: +CGSM,+DS,+ES
OK
AT$AUTOINSTALL=0
ERROR
Same with screen /dev/ttyUSB3 (whereas screen /dev/ttyUSB{0,2,4}
wouldn't output anything for "AT").
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikw3atWUKKw...@mail.gmail.com
Christian Jaeger
(not sure what you mean)
> I have something here:
> http://rjnoe.home.xs4all.nl/0/linux/3g/at-commands/
Thanks. I'll have to further study that, on cursory look I didn't see
anything to fix the modem at UMTS (to prevent the switch to HSPA, as
suggested by Scott). Although, maybe I'd rather want to fix it at
HSPA. Ordunno. (It's still sad that under windows it seems to be able
to do the switching without crashing.)
> It has multiple entries in /dev : /dev/ttyUSB0 , /dev/ttyUSB1 , /dev/ttyUSB2
> . One of them is for 'control'.
ok
> I don't get that, 'option' is the driver, ppp or whatever else ( NM, wvdial
> ) will rely on it. Unless you replace 'option' with 'usbserial' which, I
> think, is a mistake.
Yeah I guess I've got things mixed up. My brain has already dumped all
the details. I guess I didn't mean ppp but AT. Not sure though. I just
remember that I dealt with a new set of drivers and userspace programs
that would be "all new" because "that's more efficient than the old
AT/ppp way". And I thought that was "option". But maybe it was
something else.
I tried to go that route because the old AT/ppp way didn't work out
and I was hoping that the new thing would be better tailored to the
new 3G world. But in the end I was just stuck, too. Actually I found a
glaring setuid security hole in the software for that on the go, and a
debian package was removed because of that (pre-squeeze).
> Sometime ago I wrote some scripts, playing with a 'hso' modem. They are
> here: http://rjnoe.home.xs4all.nl/0/linux/3g/
> I think you can replace 'hso' with 'usb' in some places.
I'm a bit too tired to try to figure out which of these files goes
where, and how to change them. It's just too much info to process when
I don't really want to deal with all that complexity.. well, really,
I'm still kind of hoping that some network manager guy could lead me
the way, since I'm so close and fixing nm would likely benefit Linux
as a whole more. (Me too I liked low level tools for a long time; but
I've just given in to nm a year ago and it works ok for me, like, wifi
is much less of a pain now than it used to be with my home brewn
tools. I'm still using home brewn stuff, newly written, that allows me
to change between network configurations on the command line, to allow
me to also switch stuff like firewalling and running services and ssh
config and hosts file and resolv.conf and creating tunnels and what
not, I'm just disabling nm in those contexts where it doesn't make
sense.)
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTinFLbk3dhBk...@mail.gmail.com
Scott Ferguson
> 2011/6/11 Scott Ferguson <prettyfly....@gmail.com>:
>> On 12/06/11 04:19, Christian Jaeger wrote:
>> <snipped>
>>> * after the mode switch runs, the modem LED is blinking in blue
>>
>>
>> UMTS
>
> Well, as I said, as long as it's blinking, it isn't connected, at
> least as far as the computer is concerned. Of course the modem itself
> might already connect to the base stations and the color might already
> mean something at that point.
Doesn't necessarily mean an active connection - just that, allegedly,
the service is available.
>
> ...
>>> orange,
>>
>> Yellow OR flashing Red (sorry Orange is not an option!)
>
> I don't think I've ever seen it red (and never flashing, when it was
> connected).
>
> I wouldn't vow having seen orange, especially since the light mixing
> in the LED isn't perfect (so depending on angle the yellow is looking
> somewhat orange anyway) and color changes sometimes happen quickly. I
> thought it was at least 4 colors aside blue, but so maybe it's just
> yellow, purple/violet and green.
Sorry, I'm using the colours claimed by Bell - I've quoted all the
colours it's supposed to display. Changing protocols will give the
appearance of intermediate colours as it flicks between leds.
>
>>> yellow
>>
>> HSDPA (again)
>
> Well the funny thing is that nm always shows UMTS during the first
> seconds then usually HSPA (/HSUPA/HSDPA) afterwards, but the color
> change from the modem happens independently: it usually changes from
> blue to yellow as soon as there is somewhat intense traffic (of
> course, changing to HS*PA from UMTS makes sense for that), which can
> be like 5 seconds after connecting already, and still nm only shows
> the change to HSPA 15 seconds afterwards.
Are you in a marginal signal area?
>
>>> or purple
>>
>> well it's *supposed* to be Violet, and it flashes
>> EDGE
>
> Nah, it doesn't flash when in purple/violet color. Usually that color
> is only somewhat shortlived, though, like a couple seconds between
> yellow and blue(?) phases, but IIRC I've seen it stay for longer
> periods at purple, too, and it never flashed.
You *don't* want EDGE (it's about 3-4 times GPRS == 4 strings, 8 tin cans)
>
>> Wikipedia will give you a nice explanation of the various protocols.
>
> (Yep, I've read about them in the past.)
>
> How do you know about the color codes?
I collect things. Manuals, documentation, tin cans....
>
>> I'd suggest you give the device no choice eg.force it to only connect
>> UMTS using the AT commands.
>
> Good point; nm only allows to downgrade to "2G(GPRS/EDGE)" from the
> GUI (iirc I tried that and it didn't work, I guess my data-only
> contract is 3G only), so I guess I'll have to use another tool like
> minicom to inject the AT commands from a script called by a udev hook.
Gotta watch that - in my country the slower the service the steeper the
charge (inconvience is a luxury)
>
>>
>> <snipped to save electrons, and Ralf's sanity>
>
> (Ralf?)
>
> Hm, so, which AT commands?
>
> I've not been successful searching for 'novatel "at commands"' and similar.
>
>>
>> Is that a Novatel U950??
>> The vendor code should be 0x1410 - what are the product codes please?
>
> Novatel MC998D/U998,
> before usb mode switching: 1410:5010,
> afterwards: 1410:7030
>
>> If so I suspect it's actually a rebadged Ovation MC950D using the
>> Qualcomm MSM7200 chipset.
>> If so the following will probably work for you
>> (should it break you may keep both pieces)
>> ATEI (get OK response)
>> AT$AUTOINSTALL=0
>
> tie:~# screen /dev/ttyUSB1
> AT
> OK
> ATEI
> Manufacturer: Novatel Wireless Incorporated
> Model: Ovation MC998D
Not what I thought ^
I'll have to have dig and see if I have manual for that - from memory
it's less a USBstick and more a USBmouse - bout the size of a pack of cards.
Does AT? give you a list of commands.
> Revision: 1.16.12.01-02 [2010-05-12 16:23:18]
> IMEI: 012067000784103
> +GCAP: +CGSM,+DS,+ES
>
> OK
> AT$AUTOINSTALL=0
> ERROR
>
> Same with screen /dev/ttyUSB3 (whereas screen /dev/ttyUSB{0,2,4}
> wouldn't output anything for "AT").
>
> Christian.
>
cat /dev/ttyUSB0 should give you signal strength and available protocols.
I'll be back later today - I'll have a dig for the command set and check
for firmware updates then, I'm pretty sure SaskTel have the same modem.
Do you have a verbose ppp log somewhere?
Cheers
--
The world is like a ride in an amusement park.
And when you choose to go on it you think it's real because that's how
powerful our minds are.
And the ride goes up and down and round and round.
It has thrills and chills and it's very brightly coloured and it's very
loud and it's fun, for a while.
Some people have been on the ride for a long time and they begin to
question: "Is this real, or is this just a ride?"
And other people have remembered, and they come back to us, they say,
"Hey, don't worry, don't be afraid, ever, because this is just a ride."
And we kill those people. ~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Jaeger
No (rarely, and not now).
> You *don't* want EDGE
(I guess so; also, I think 2G isn't even supported by my contract at all.)
> (it's about 3-4 times GPRS == 4 strings, 8 tin cans)
Heh, took me a while to get the analogy.
> I collect things. Manuals, documentation, tin cans....
Heh.
> Gotta watch that - in my country the slower the service the steeper the
> charge (inconvience is a luxury)
If I'm correct thinking that the older protocols tie up precious
frequency bands for longer for the same amount of traffic, it makes
sense to charge more for it this way. Maybe I could tie the modem to
HSPA (if that doesn't strictly need an UMTS connection first). Maybe
poking around I'd find clues about what goes wrong.
> I'll have to have dig and see if I have manual for that - from memory
> it's less a USBstick and more a USBmouse - bout the size of a pack of cards.
Here's a picture:
http://www.bell.ca/shopping/en_CA_ON.Novatel-Wireless-U998/TurboStickU998.details
>
> Does AT? give you a list of commands.
AT?
ERROR
> cat /dev/ttyUSB0 should give you signal strength and available protocols.
# It didn't output anything while the connection was down (just
block), then I upped the connection, still nothing, but then when it
went down 20(-30) seconds later, this:
NO CARRIER
$CNTI: 0, HSPA+
OK
# it goes on after a while, interestingly while in blinking mode (aka
no (working) connection up anymore):
+CSQ: 12,99
OK
$CNTI: 0, HSPA+
OK
+CREG: 1,2D84,3F80
+CGREG: 1,2D84,3F80
+CSQ: 12,99
OK
$CNTI: 0, HSPA+
OK
...
>
> I'll be back later today - I'll have a dig for the command set and check
> for firmware updates then, I'm pretty sure SaskTel have the same modem.
> Do you have a verbose ppp log somewhere?
I've put the outputs of
# modem-manager --debug 2>&1 |log-timestamp -H > mm.log
# NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon 2>&1
|log-timestamp -H > nm.log
here:
http://christianjaeger.ch/scratch/bell_novatel/
(There you could also find the firmware upgrader that I recently used
on my modem to no avail.)
I appreciate your help.
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimkfO_D0E+F...@mail.gmail.com
Scott Ferguson
>> Are you in a marginal signal area?
>
> No (rarely, and not now).
>
>> You *don't* want EDGE
>
> (I guess so; also, I think 2G isn't even supported by my contract at all.)
>
>
>> cat /dev/ttyUSB0 should give you signal strength and available protocols.
>
> # It didn't output anything while the connection was down (just
> block), then I upped the connection, still nothing, but then when it
> went down 20(-30) seconds later,
That is the expected behaviour.
> this:
>
> NO CARRIER
That ^ makes sense given the scenario you are describing
>
> $CNTI: 0, HSPA+
>
> OK
>
> # it goes on after a while, interestingly while in blinking mode
**********************************
What colour is the blinking light?
> (aka no (working) connection up anymore):
>
> +CSQ: 12,99
>
> OK
>
> $CNTI: 0, HSPA+
>
> OK
>
> +CREG: 1,2D84,3F80
>
> +CGREG: 1,2D84,3F80
>
> +CSQ: 12,99
That is your signal quality. And no - I can't translate it for you.
>
> OK
>
> $CNTI: 0, HSPA+
>
> OK
>
> ...
>
>
>>
>> I'll be back later today - I'll have a dig for the command set and check
>> for firmware updates then, I'm pretty sure SaskTel have the same modem.
>> Do you have a verbose ppp log somewhere?
>
> I've put the outputs of
>
> # modem-manager --debug 2>&1 |log-timestamp -H > mm.log
> # NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon 2>&1
> |log-timestamp -H > nm.log
(Note I've never managed to get nm to do anything useful under KDE, even
though I spent more that 3 minutes trying...)
>
> here:
>
> http://christianjaeger.ch/scratch/bell_novatel/
Thank you.
[reads nm.log - sees word "Canonical" - goes into catatonic state]
Ahhh Ubuntu - I have heard tell of this thing. I swear I have never
touched one.
Normally I go into a frothing fury at the assumption that Debian has
anything to do with Ubuntu.... however I shall do my best to finish what
I started.
Disclaimer - The sheep farmer has nothing to do with things made by wool
mills. But I digress.
>
> (There you could also find the firmware upgrader that I recently used
> on my modem to no avail.)
********************************************************************
Have you successfully managed to use the same modem since failing to
upgrade?
>
> I appreciate your help.
>
> Christian.
>
I have asked two questions above - look for the ******** lines.
Apologies if you've already answered them elsewhere.
If you could bear with me I'll do a bit more reading of those logs and
when I've read your answers I'll formulate a process for isolation
testing this problem.
Cheers
--
It's just a ride and we can change it any time we want.
It's only a choice.
No effort, no work, no job, no savings and money, a choice, right now,
between fear and love.
The eyes of fear want you to put bigger locks on your door, buy guns,
close yourself off.
The eyes of love instead see all of us as one.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Jaeger
> What colour is the blinking light?
I think it just blinks in the color in which it was lit before the
'crash'; I've run another test now and it was yellow then blinked in
yellow.
(BTW I've tried 'screen /dev/ttyUSB1' and sending ATZ and ATH0, and
while these give me OK, it doesn't change anything to the blinking or
color.)
>> +CSQ: 12,99
>
> That is your signal quality. And no - I can't translate it for you.
(nm shows signal strength at around "33%" today, whatever *that*
means. Anyway this is strong enough to give me a stable, fast
connection without any dropouts once the stick passes the magical
20-30 second crash point.)
> [reads nm.log - sees word "Canonical" - goes into catatonic state]
I don't have any problems with them.. (back in 2004 I thought it's a
pity that they forked the project, but now I think it was probably
better that way?)
>> (There you could also find the firmware upgrader that I recently used
>> on my modem to no avail.)
> ********************************************************************
> Have you successfully managed to use the same modem since failing to
> upgrade?
When I said "to no avail" I meant that, although the upgrade ran
successfully through (from a machine running Windows XP), it didn't
change a bit of the behaviour of the modem. (And on the same Windows
installation the modem didn't exhibit the crash neither before nor
after the upgrade.)
> If you could bear with me I'll do a bit more reading of those logs and
Also note 'log.Readme' (which I put up a couple minutes after I sent
the last mail); interestingly the stick goes 'off' ('crashes')
exactly(?) at the point in time when nm talks to it. (Would it be nm
'actively' crashing it?)
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimzW+z79tG-...@mail.gmail.com
Christian Jaeger
http://christianjaeger.ch/scratch/bell_novatel/crashrun2/
Same thing as yesterday, the crash happens exactly at (or then within
+-1 second of) the time nm sends AT+CSQ and then AT$CNTI=0.
Going to try to look up what the latter command means.
Maybe nm just shuts down the modem when it sees "No carrier", and the
no carrier part is maybe a bug in the modem?
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimRCEJ6cmM3LZ4w8=kHk4DM...@mail.gmail.com
Christian Jaeger
> AT$CNTI=0.
>
> Going to try to look up what the latter command means.
>
27007-3d0.pdf does not reference it. Googling "AT$CNTI=0" turns up
http://www.slideshare.net/Dominque23/novatel-u740-firmware-upgrade-272-release-notesdocdoc
"Fixed AT Argument Pointer Issue (raised from the AT$CNTI=0 issue that
would return ERROR instead of the current RAT)."
Still not sure what it means. (Also, the last year mentioned in that
document is 2006, so chances are this fix was done 5 years ago so the
current modem shouldn't suffer from it?)
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimjSLSaz1cs...@mail.gmail.com
Christian Jaeger
stable and testing; it doesn't really explain anything either:
The only references to $CNTI are in plugins/mm-modem-novatel-gsm.c
(there are references to *CNTI in replugins/mm-modem-sierra-gsm.c),
and it's this code that emits the $CNTI=0:
static void
get_access_technology (MMGenericGsm *modem,
MMModemUIntFn callback,
gpointer user_data)
{
MMAtSerialPort *port;
MMCallbackInfo *info;
info = mm_callback_info_uint_new (MM_MODEM (modem), callback, user_data);
port = mm_generic_gsm_get_best_at_port (modem, &info->error);
if (!port) {
mm_callback_info_schedule (info);
return;
}
mm_at_serial_port_queue_command (port, "$CNTI=0", 3,
get_act_request_done, info);
}
I wanted to experiment with removing that command, but first I
installed the unmodified version from testing (recompiled for
Squeeze). Now in the last couple attempts the modem hasn't crashed
anymore, I don't know yet whether that's just because I'm lucky or the
newer version fixes the issue, I'll tell after more testing (different
time of day etc.). (FWIW, I've put up the logs of two successful
connection attempts at
http://christianjaeger.ch/scratch/bell_novatel/mm_testing/ .)
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikupzrjdGfz8KhD4kZHo0nfuwGt=g...@mail.gmail.com
Christian Jaeger
> the modem hasn't crashed
> anymore, I don't know yet whether that's just because I'm lucky or the
> newer version fixes the issue, I'll tell after more testing
I was just lucky, it still crashes. So I intend to play with changing
the AT commnds in the mm source.
(Hm, I guess I should probably test some more under Windows to be sure
that it wasn't just a lucky streak there; sadly I deleted the Windows
when I Debianized the netbook, it will take me some time to reinstall
Windows somewhere.)
BTW, regarding your mention of Ubuntu, I'm not on Ubuntu! I'm on
Squeeze. Just in case you were confused. (I only tried Ubuntu live
some time ago to see whether it was better, and it's exactly the
same.)
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTi=EJGp-_j3wT3Te...@mail.gmail.com
Scott Ferguson
> I wrote:
>> the modem hasn't crashed
>> anymore, I don't know yet whether that's just because I'm lucky or the
>> newer version fixes the issue, I'll tell after more testing
>
> I was just lucky, it still crashes. So I intend to play with changing
> the AT commnds in the mm source.
I'd suggest you don't - just yet as it will increase the number of
factors at play.
Let's see if we can get it working with it's (the modem's) current
settings first - acting on the presumption (assumption?) that it would
work as it stands, should you plug it in to a Windoof box.
>
> (Hm, I guess I should probably test some more under Windows to be sure
> that it wasn't just a lucky streak there; sadly I deleted the Windows
> when I Debianized the netbook, it will take me some time to reinstall
> Windows somewhere.)
Do you use a PIN for you modem??
>
> BTW, regarding your mention of Ubuntu, I'm not on Ubuntu! I'm on
> Squeeze. Just in case you were confused. (I only tried Ubuntu live
> some time ago to see whether it was better, and it's exactly the
> same.)
>
> Christian.
>
I was going off the Canonical string in the nm.log. Given that they
(sic) don't maintain the Debian package.
The Debian package is maintained by Didier Raboud, who if memory serves
me correctly is also the upstream developer.
So my other question is:-
Was that log from trying to connect with Ubuntu - or do you perhaps have
Ubuntu packages installed into Debian??
Usb-modeswitch does the hard work (though sometimes "eject" will achieve
the same result) of exposing the modem - it's easy to test that it has
happened (1410:7030).
That leaves the (relatively) easy part of using the modem.
We'll eliminate network manager from the possible problem causes by just
using pon and poff to test.
I'll give you instructions on how to set that up and test it - if you
could just let me know whether you have a PIN setup for it.
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Jaeger
> settings first - acting on the presumption (assumption?) that it would
> work as it stands, should you plug it in to a Windoof box.
(I meant modifying the source in places where it is sending AT
commands that are not persistently changing the modem.
But I don't know enough about the command set so I guess it's a better
idea to first recheck on Windows to be really sure it works reliably
there (if it doesn't, I will just try to return it to Bell on
warranty). This will take me a couple days though.
But your suggestion to use pon/off is even better (I didn't get it to
work a year ago, but I didn't know a couple things then).
)
> Do you use a PIN for you modem??
No.
> I was going off the Canonical string in the nm.log. Given that they
> (sic) don't maintain the Debian package.
> The Debian package is maintained by Didier Raboud, who if memory serves
> me correctly is also the upstream developer.
The message is "Loaded plugin ifupdown: (C) 2008 Canonical Ltd.", and
"Loaded plugin keyfile: (c) 2007 - 2008 Red Hat, Inc."; that only
means they developed the upstream code (and only of these plugins) and
does not imply that they created the packages.
(There are no mentions of Didier Raboud in the source code of the
network-manager and modemmanager packages, although there are almost
no mentions of individual developers anyway, it's all Novell, Red Hat,
Canonical, Free Software Foundation, and a couple other companies like
Ericsson, Samsung. Michael Biebl is current maintainer of both
packages in Debian.)
> So my other question is:-
> Was that log from trying to connect with Ubuntu -
> or do you perhaps have
> Ubuntu packages installed into Debian??
No, and no.
> Usb-modeswitch does the hard work (though sometimes "eject" will achieve
> the same result) of exposing the modem - it's easy to test that it has
> happened (1410:7030).
> That leaves the (relatively) easy part of using the modem.
> We'll eliminate network manager from the possible problem causes by just
> using pon and poff to test.
Alright.
> I'll give you instructions on how to set that up and test it - if you
> could just let me know whether you have a PIN setup for it.
Nope; it just needs the number (#99* or something) and some domain,
which is inet.bell.ca.
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTi=byKYnZDobMotQ2ZQ=5NaJ6...@mail.gmail.com
Christian Jaeger
sorry, I tend to hit sent too quickly.
number => "*99#"
apn => "inet.bell.ca"
PS. here's how this thread started a year ago:
http://forum.nginx.org/read.php?31,107067,202298
Also, for archival purposes (in case anyone ever replies me there),
here's a link to my post on the network-manager mailing list:
http://thread.gmane.org/gmane.linux.network.networkmanager.devel/18581
Christian.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikCX5hE47RbL=g1DaEGc9...@mail.gmail.com
Scott Ferguson
>> which is..
>
> sorry, I tend to hit sent too quickly.
>
> number => "*99#"
> apn => "inet.bell.ca"
That is as it should be.
Bell don't do a prepaid deal do they?
>
> PS. here's how this thread started a year ago:
> http://forum.nginx.org/read.php?31,107067,202298
>
> Also, for archival purposes (in case anyone ever replies me there),
> here's a link to my post on the network-manager mailing list:
> http://thread.gmane.org/gmane.linux.network.networkmanager.devel/18581
>
> Christian.
>
Thanks.
I'm midway through replying to your previous post.
Soon.
Cheers.
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Jaeger
> Bell don't do a prepaid deal do they?
No (my deal was the cheapest monthly contract, includes 500 MB with
the monthly fee)
Chr.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTimrU623K-Qt...@mail.gmail.com
Scott Ferguson
>> I was going off the Canonical string in the nm.log. Given that they
>> (sic) don't maintain the Debian package.
>> The Debian package is maintained by Didier Raboud, who if memory serves
>> me correctly is also the upstream developer.
>
> The message is "Loaded plugin ifupdown: (C) 2008 Canonical Ltd.", and
> "Loaded plugin keyfile: (c) 2007 - 2008 Red Hat, Inc."; that only
> means they developed the upstream code (and only of these plugins) and
> does not imply that they created the packages.
My mistake. Somehow I confused usb-modeswitch with... well, other
things. I shall have another coffee. :-/
>
> (There are no mentions of Didier Raboud in the source code of the
> network-manager and modemmanager packages, although there are almost
> no mentions of individual developers anyway, it's all Novell, Red Hat,
> Canonical, Free Software Foundation, and a couple other companies like
> Ericsson, Samsung. Michael Biebl is current maintainer of both
> packages in Debian.)
Yes. I just looked it up through Debian package search (Unity).
<snipped>
Note: shouldn't need to supply your ISPs APN - the modem should have,
and supply that when it connects.
Try this:-
Create the following files:-
/etc/ppp/peers/Bell
/etc/chatscripts/Bell
The next one is tricky as I don't know which /dev/ttyUSB* is the modem's
data port... so I suggest you try them all.
First list them:-
$ ls /dev/ttyUSB*
I suspect you'll find 4 - 5 ports created (if the right module is
loaded, but I digress).
Try /dev/ttyUSB4 first, then 2, then 0, then 1, then 3.
for /etc/peers/Bell the contents are (copy and paste between the lines):-
=============
hide-password
noauth
connect "/usr/sbin/chat -v -f /etc/chatscripts/Bell"
debug
#the following line is where to try different ports
/dev/ttyUSB4
115200
defaultroute
noipdefault
user "a"
ipparam Bell
persist
usepeerdns
============
for /etc/chatscripts/Bell the contents are:-
=============
#leave the following line commented for the time being.
#REPORT CONNECT
ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO
DIAL TONE' ABORT 'NO ANSWER' ABO$
'' ATZ
OK-AT-OK "ATDT*99#"
CONNECT \d\c
============
edit /etc/ppp/options and ensure that the line "noauth" is uncommented
Make sure you are in the dip group
$ groups | grep dip
Then try to connect:-
$ pon Bell
Then please run the following commands and save the results to the next
post:-
$ lsusb | grep 1410:7030 | grep Novatel
$ lsmod | grep option
$ lsmod | grep serial
$ dmesg | tail -n 20
$ cat /etc/resolv.conf
# ifconfig
If you manage to connect... use the following to disconnect:-
$ poff Bell
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
> Nope; it just needs the number (#99* or something) and some domain,
> which is inet.bell.ca.
No username/password required?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110613102748.GA19572@desktop
Brian
> Note: shouldn't need to supply your ISPs APN - the modem should have,
> and supply that when it connects.
Are you sure? I thought the APN determined the type of service requested
or obtained.
> ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO
> DIAL TONE' ABORT 'NO ANSWER' ABO$
> '' ATZ
I'd be inclined to have
OK ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK AT+CGDCONT=1,"IP","inet.bell.ca"
at this point.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110613103724.GB19572@desktop
Darac Marjal
> On Mon 13 Jun 2011 at 01:44:12 -0400, Christian Jaeger wrote:
>
> > Nope; it just needs the number (#99* or something) and some domain,
> > which is inet.bell.ca.
>
> No username/password required?
Mobile networks typically authenticate by IMEI/SIM card details. As far
as the network is concerned, a 3G dongle is basically another mobile
phone.
--
Paul Saunders
Scott Ferguson
> On Mon 13 Jun 2011 at 01:44:12 -0400, Christian Jaeger wrote:
>
>> Nope; it just needs the number (#99* or something) and some domain,
>> which is inet.bell.ca.
>
> No username/password required?
>
>
No.
I put "a" in as a username just to make the default ppp settings happy.
"internet" or "santaclaus" will work just as well. No password required
either. I don't know of any Canadian ISPs that require it. Most ISPs I'm
familiar with don't.
When an ISP does require it the log will make it obvious. If the ISP
doesn't require it - the connection will fail.
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Scott Ferguson
Yes. It normally needs to be entered once only. Default is to supply it
every time - unnecessary.
Disclaimer: ex-Complex Data Tester
I now have a configuration package (as a .deb) which I've emailed to
Christian for testing.
For the record - the data port on these devices is /dev/ttyUSB0
They are sold as a "Novatel U988" - they are actually an "Ovation
MC998D" (I'm waiting of the chipset details).
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Scott Ferguson
> On Mon 13 Jun 2011 at 17:49:23 +1000, Scott Ferguson wrote:
>
>> Note: shouldn't need to supply your ISPs APN - the modem should have,
>> and supply that when it connects.
>
> Are you sure? I thought the APN determined the type of service requested
> or obtained.
It does (another poster has answered this question for you).
>
>> ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO
>> DIAL TONE' ABORT 'NO ANSWER' ABO$
>> '' ATZ
>
> I'd be inclined to have
>
> OK ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
What is that supposed to do?
> OK AT+CGDCONT=1,"IP","inet.bell.ca"
The form is correct for INIT2. The OK line is not used in ppp.
(it's a response from the modem)
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
> On 13/06/11 20:37, Brian wrote:
> >
> > I'd be inclined to have
> >
> > OK ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
>
> What is that supposed to do?
Not a lot, apparently. I cut it out and there was still a connection.
> > OK AT+CGDCONT=1,"IP","inet.bell.ca"
>
> The form is correct for INIT2. The OK line is not used in ppp.
> (it's a response from the modem)
So I got rid of this too. And the username/password lines. Without the
ABORT lines the chatscript is down to
'' ATZ
OK "ATDT*99#"
So much for searching out the files on the dongle aimed at Apple Mac
users and taking note of advice given to Windows users of the same ISP,
all of which referred to an APN and username/password!
It's a PAYG dongle, if that makes any difference. I expect a first-time
connection have taken place with the chatscript as it stands now as the
SIM would have been recognised.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110613134544.GD19572@desktop
Wayne Topa
I am using a USB modem from AT&T which is supported by the Debian kernel
so I have held off replying to this thread. If it would help any, I can
show all the files Scott mentioned if you want. I don't want to clutter
this thread unnecessarily though if they would not help.
Wayne
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
> On 13/06/11 20:37, Brian wrote:
> > On Mon 13 Jun 2011 at 17:49:23 +1000, Scott Ferguson wrote:
> >
> >> Note: shouldn't need to supply your ISPs APN - the modem should have,
> >> and supply that when it connects.
> >
> > Are you sure? I thought the APN determined the type of service requested
> > or obtained.
>
> It does (another poster has answered this question for you).
I can see how authentication is via the SIM (rather than a username and
password in the chatscript), but where does the APN fit in? It appears
to me it is needed for the very first connection. After that (in the
case of my ISP) it seems it can be omitted, presumably because the SIM
is matched with the right type of account.
It gets interesting if the APN is changed to an invalid one. No further
connections are possible until the correct one is entered. After that it
can be ommited. Is this behaviour general with mobile broadband?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110613160005.GF19572@desktop
Wayne Topa
I forgot to mention it is also a Novatel but a usbconnect Mercury model.
>
> Wayne
>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Scott Ferguson
> On Mon 13 Jun 2011 at 22:02:17 +1000, Scott Ferguson wrote:
>
>> On 13/06/11 20:37, Brian wrote:
>>>
>>> I'd be inclined to have
>>>
>>> OK ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
>>
>> What is that supposed to do?
>
> Not a lot, apparently. I cut it out and there was still a connection.
Oh - I was hoping you knew the proprietary AT commands used by this
particular modem.
>
>>> OK AT+CGDCONT=1,"IP","inet.bell.ca"
>>
>> The form is correct for INIT2. The OK line is not used in ppp.
>> (it's a response from the modem)
eg. INIT2 would be just:-
AT+CGDCONT=1,"IP","inet.bell.ca"
>
> So I got rid of this too. And the username/password lines. Without the
> ABORT lines the chatscript is down to
>
> '' ATZ
> OK "ATDT*99#"
You *can* connect with just a single CLI instruction... eg.
# pppd ttyUSB0 460800 nodetach defaultroute noipdefault noauth lock
usepeerdns connect 'chat "" "at" "" "at" "OK" "at&f" "OK" "atz" "OK"
"atdt*99***1#" CONNECT'
But it's not a useful form for testing purposes....
>
> So much for searching out the files on the dongle aimed at Apple Mac
> users and taking note of advice given to Windows users of the same ISP,
> all of which referred to an APN and username/password!
It's the first place I'd look if I couldn't get access to the manual -
it just needs to be adjusted to suit the dialer.
It was probably not meant for pon scripting - ppp dialer like wvdial and
kppp use a (slightly) different form.
Treat the following with caution as I can't verify this:-
I "believe" the reasoning behind supplying the APN every connection is
that some ISPs have different APNs for mobile, fixed line, and prepaid
accounts. (Telstra for instance, has half a dozen) So a user might use
the same modem to connect using different accounts to the same ISP -
just picking the best rate plan for the particular area.
>
> It's a PAYG dongle, if that makes any difference.
It often does. If I knew your ISP I could be more specific.
eg. Vodaphone in the UK uses one APN for prepaid and another for post-paid.
> I expect a first-time
> connection have taken place with the chatscript as it stands now as the
> SIM would have been recognised.
>
>
You can test that by using the single line CLI connection commands I've
posted above - just modify the connection port and speed to suit your
requirements.
If it connects then you'll have "proven" that the APN is supplied by the
modem.
I don't know the *nix equivalent, but on Windoof I've used a USB bus
sniffer to see the communication between the modem and the OS - so I
know the APN is retained on the device. I don't know if it (sic) is
stored on the SIM or on the modem it self.
If I sound unsure of myself it's because I am. Each case is different -
even from the same manufacturer. Additionally modems are often
customized for particular ISPs (eg. ZTE MF-627 with hidden ports for
3Mobile). Additionally there isn't a standard in the AT commands used -
though many of them originate from the Rockwell chipset.
Christian's modem from Bell for instance is about 80% standard AT
commands and 20% proprietary. Proprietary (in this case) == closed.
But I digress, and I note that Christian has already spent 6 months
trying to connect with his modem, so I'll try not to add more
non-essential information to his reading list.
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Scott Ferguson
> On Mon 13 Jun 2011 at 22:02:17 +1000, Scott Ferguson wrote:
>
>> On 13/06/11 20:37, Brian wrote:
>>> On Mon 13 Jun 2011 at 17:49:23 +1000, Scott Ferguson wrote:
>>>
>>>> Note: shouldn't need to supply your ISPs APN - the modem should have,
>>>> and supply that when it connects.
>>>
>>> Are you sure? I thought the APN determined the type of service requested
>>> or obtained.
>>
>> It does (another poster has answered this question for you).
>
> I can see how authentication is via the SIM (rather than a username and
> password in the chatscript), but where does the APN fit in? It appears
> to me it is needed for the very first connection.
That is my understanding also. Bear in mind that often, when you buy the
modem it is already configured. The actual dialer software is often
clunky, badly coded, and incorrectly configured.
Try this with Windows:-
Insert modem.
Install dialler software and modem driver.
Modify Windows dialup connection that is created at the same time.
Remove the modem suppled connection software.
Use the Windows dialup connection.
You'll save a lot of RAM, take load off the CPU - and - the dialup
profile doesn't send the APN. Of course you won't get signal strength
info or any of the other dancing bears - but it a quick connection and
usually more stable.
> After that (in the
> case of my ISP) it seems it can be omitted, presumably because the SIM
> is matched with the right type of account.
Or, it's already supplying the correct information... which you'll find
is not the case when you buy the SIM separate from a modem.
>
> It gets interesting if the APN is changed to an invalid one. No further
> connections are possible until the correct one is entered. After that it
> can be ommited.
Think of it as being somewhat similar to your BIOS or your bootloader -
in that settings are reused and can be modified.
With ISDN modems it becomes even simpler - no user intervention required
- just write the word "lightning" on a piece of paper and place it near
an NT1 to reset. ;-p
> Is this behaviour general with mobile broadband?
>
>
There's too many devices and protocols out there for me to generalise.
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Scott Ferguson
> On 06/13/2011 11:23 AM, Wayne Topa wrote:
>> On 06/13/2011 03:49 AM, Scott Ferguson wrote:
>>> On 13/06/11 15:44, Christian Jaeger wrote:
>
>
>>
>> I am using a USB modem from AT&T which is supported by the Debian kernel
>> so I have held off replying to this thread. If it would help any, I can
>> show all the files Scott mentioned if you want. I don't want to clutter
>> this thread unnecessarily though if they would not help.
>
>
> I forgot to mention it is also a Novatel but a usbconnect Mercury model.
>>
>> Wayne
>>
>
>
Hi Wayne,
I haven't had a look at the Debian wiki this week - but it
improves every time I do. Maybe we should be adding this to
http://wiki.debian.org/Modem and http://wiki.debian.org/PPP
So much of what is on the web is outright incorrect or only applicable
in limited circumstances.
A list of modem models by manufacturer and the corresponding AT commands
(esp. disable autorun fakecd) would be brilliant.
Even better would be a tool that could be used to non-destructively find
out the undocumented AT commands for different modems - I've seen some
evidence a similar tool exists for another, irrelevant for my purposes, OS.
Also on my wish list would be some simple documentation on Network
manager for KDE (probably under my nose already).
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Scott Ferguson
> Another update in my quest to get that UMTS modem work properly:
>
> Bell technical support told me that I should run a firmware upgrade on
> the stick (and gave me a link to the exact file). Of course that's a
> windows .exe. I tried to run it in a second hand computer store that
> let me plug in my Bell stick, but it didn't work, probably because I
> didn't install the driver beforehand, the installer and upgrade
> utility conflicted with each other. So I gave up for some time.
>
> Now I've finally gotten an own computer with Windows (XP), so I
> installed the modem first, then ran the firmware upgrade. Both worked
> without problems. Also, on Windows the modem doesn't seem to exhibit
> that disconnect problem. Then I tried again on Debian, and nothing
> changed, disconnection on first try. Duh.
>
> So, if anyone knows what's left that I could try (well I'll try
> contacting some network manager people), or knows which USB UMTS modem
> works on Debian in Canada (with Bell), please tell.
>
> Thanks
> Christian.
>
>
For future posterity. Please post testing results.
==============
Search terms: USB modem 3G Bell wireless Novatel Ovation
==============
I've located a debian Novatel modem configuration package designed for
Ubuntu based distros if anyone would like to try it. I don't have any
Novatel/Ovation modems so am unable to test.
The .deb was packaged by a "Dirk De Schepper" - a link for it is:-
http://www.novatelwireless.com/images/stories/support/linux/novatel_modem_drivers_config_1.1_6.deb
There is a Novatel/Ovation driver package here:-
http://www.novatelwireless.com/content/files/novatel_modem_drivers_binary_2.6.18.1_1.1_1.deb
NOTE: this package appears to be built for an old kernel but the udev
rules should be useful (don't use the provided modules, use standard
debian modules instead)
Instructions here:-
http://www.novatelwireless.com/index.php?option=com_content&view=article&id=83&Itemid=164
Should the packages vanish let me know and I'll make copies available.
NOTE: it would appear that these packages can "flip" the device so
usb-modeswitch may not be required.
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
> Oh - I was hoping you knew the proprietary AT commands used by this
> particular modem.
Sorry, I don't. But I thought the standard ones I gave might have
helped.
> Treat the following with caution as I can't verify this:-
> I "believe" the reasoning behind supplying the APN every connection is
> that some ISPs have different APNs for mobile, fixed line, and prepaid
> accounts. (Telstra for instance, has half a dozen) So a user might use
> the same modem to connect using different accounts to the same ISP -
> just picking the best rate plan for the particular area.
What you say makes sense. Thanks for giving me something to think about.
> You can test that by using the single line CLI connection commands I've
> posted above - just modify the connection port and speed to suit your
> requirements.
> If it connects then you'll have "proven" that the APN is supplied by the
> modem.
I've briefly tested and revised my view to: an APN is needed on making a
first-time connection.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110614100220.GI19572@desktop
Wayne Topa
I guess the wiki is a bit behind. I have been using my Novatel
Usbconnect Mercury modem for over 2 years now and it is not included in
the list.(?) The Sierra driver has been in the kernel since 2.6.32 IIRC.
I was able to find the information on how to connect with it on the
Sierra wireless site. They supplied a script that set up all the PPP
files and the driver. That was before it, the driver, was included in
the kernel.
I am not in an 3G area (that is what an ATT tech says) but I do get 3G
connections 'sometimes' but mostly connect at ~20kbs. Nor good but
better then the 2kbs phone line performance here in the boondocks.
Wayne
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Jaeger
> I am not in an 3G area (that is what an ATT tech says) but I do get 3G
> connections 'sometimes' but mostly connect at ~20kbs. Nor good but
> better then the 2kbs phone line performance here in the boondocks.
In case you're not using one already, it sounds like you could profit
greatly from placing your modem in the focal point of a satellite dish
or similar. (Or even just slightly adapting
http://freeantennas.com/projects/Ez-10/ . Or just search for '3g dish'
or '3g antenna'.)
Christian.
PS. I've been busy yesterday; I shall try the new suggestions today,
thanks Scott and all of you other contributors!
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTinXTZxhPuVs...@mail.gmail.com