Following up to myself on what I did, because people keep asking me
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.
Attachment:
bellstickactivateudevhack
Description: Binary data
Attachment:
3g-activate
Description: Binary data
Attachment:
3g-activate-stage2
Description: Binary data