[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning



Stephan Seitz <stse+debian@fsing.rootsland.net> writes:
> On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:
>>Never mind wireless lan where you've got a well defined kernel API.  Try
>>to configure a modern 3G/LTE modem using ifupdown, and you will see the
>
> Is this something different from an UMTS usbstick?

No.

> I plug it in, get a
> /dev/ttypUSB0 and do a „pon umts”. No need for NM and Co.

Sure. But you didn't actually configure the device here, did you?  And
you didn't notice that the device fell back from LTE to UTMS.  Or that
it suddenly started roaming to the network on the other side of the
border. Etc.

You didn't even notice that the connection failed because the PIN code
was wrong.  Or did you?  OK, then your chat script has started looking
like a small ModemManager application...

Oh, yeah, and of course /dev/ttyUSB0 wasn't the AT port.  It was the
QCDM port so the chat script just timed out.

The connections provided by these devices are dynamic by nature, and
they typically have management protocols supporting notifications from
device to host.  You may of course ignore this and state that the device
"works" in a static configuration, but most users will want some
monitoring daemon allowing them to make intelligent decisions based on
current available devices and networks.  A little like what
wpa_supplicant does for wireless LANs. That's what ModemManager
provides.

But yes, if „pon umts” is enough for you then you don't need NM (or even
ifupdown - pppd and vim will do).

By modern 3G/LTE modem I mean a device supporting CDC MBIM or a vendor
specific management protocol like QMI.  The firmware of most of these
devices will export a basic AT command set and support PPP on one or
more serial ports, but that only supports a very limited usage pattern
IMHO.  And when it comes to LTE, also limited speed.  Some vendors
implement AT commands for initiating "NDIS" connections, but these are
exceptions and are likely to go away over time as more and more devices
get a "intented for Windows 8" label or somthing like that.  And it
didn't work with your "pon" in any case.


Bjørn


Reply to: