nm-pppd-plugin does not start

[Aleksander Morgado]

+ MM mailing list

On Sun, Mar 6, 2016 at 11:04 PM, Aleksander Morgado
<aleksander at aleksander.es> wrote:
>>> > Good point, ppp is not enabled! Option seems to be --enable-ppp.
>>> > I'll try
>>> > >
>>> > > it. This NDISDUP seemp pretty problematic. In fact I found MM
>>> > > patch whose
>>> > > introduction comment describes pretty much how this modem works (
>>> > > https://cgit.freedesktop.org/ModemManager/ModemManager/log/?h=dcb
>>> > > w/huawei-at-dhcp).
>>> > > I'll check if that helps/works with this MM version - then I
>>> > > suppose, I
>>> > > should contact MM mailing list...
>>> > >
>>> > > >
>>> > > >
>>> > This was the problem with ppp connection. PPP connection started
>>> > working
>>> > after inserting --enable-ppp option to networkmanager configuration
>>> > optios
>>> > (in fact EXTRA_OECONF_append = " --enable-ppp " in my
>>> > networkmanager_0.9.8.10.bbappend recipe). Somehow NDISDUP does not
>>> > seem
>>> > too appealing now. It does not show up as device in nmcli d
>>> > listing. Nor
>>> > does it open interface automatically like Huawei 3131/Hilink does.
>>> > It would
>>> > require some kind of patching/more debugging. If it then worked
>>> > like Huawei
>>> > 3131/HiLink - no need of touching nmcli command at all and no need
>>> > of
>>> > writing configuration file - then I would be interested in trying
>>> > it.
>>> > Otherwise, I don't see what I get out of it compared to PPP
>>> > connection.
>>> >
>>> Hi again!
>>> I was far too curious not trying that Huwei AT^NDISDUP patch. I did
>>> not
>>> find official patch, but I used commit number
>>> 359ec84671f9fc0869443b9f0b9555324a0fff78 to create patch. Patching
>>> worked
>>> without problems, it compiled fine and really it worked!! Operation
>>> from
>>> user point of view was identical to ppp operation: to make config
>>> file and
>>> start connection with nmcli command. Now NM opened wwan0 interface
>>> instead
>>> of ppp0. So, I can confirm that above commit fixes problem in NDISDUP
>>> operation with Huawei 3131 modem that before mode switching shows up
>>> as
>>> 12d1:14fe and afterwards as 12d1:1506.
>>>
>>> Now I need to figure out if I make those udev hacks to force PPP
>>> operation
>>> or MM patching to fix NDISDUP. Do you have plans to merge this patch
>>> to
>>> master branch?
>>
>> Yeah, we have plans to merge it, but I'm a bit concerned about
>> regression risk with other modems that might support DHCP.  What do you
>> think Aleksander?  The patch just makes MM use static bearer IP config
>> if the modem reports valid details with ^DHCP, instead of requiring a
>> DHCP run.  That apparently is required on a number of devices.
>>
>> But ISTR we've had some devices that need DHCP to get kicked into
>> enabling the data connection, though they weren't Huawei.
>
> Yes, let's do this, go merge to git master. If we ever find any Huawei
> modem explicitly not wanting this, we'll handle that in some other
> way.

Tested with my Huawei modems and don't see any regression. This change
is now in ModemManager git master.

Cheers!

-- 
Aleksander
https://aleksander.es