Re: nm-pppd-plugin does not start

[Aleksander Morgado]

+ MM mailing list

On Sun, Mar 6, 2016 at 11:04 PM, Aleksander Morgado
 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
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm-pppd-plugin does not start

[Aleksander Morgado]

On Fri, Mar 4, 2016 at 5:54 PM, Dan Williams  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.


-- 
Aleksander
https://aleksander.es
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm-pppd-plugin does not start

[Dan Williams]

On Fri, 2016-03-04 at 17:17 +0200, matti kaasinen wrote:
> 2016-03-04 13:50 GMT+02:00 matti kaasinen :
> 
> > 
> > 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.

Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm-pppd-plugin does not start

[matti kaasinen]

2016-03-04 13:50 GMT+02:00 matti kaasinen :

> 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=dcbw/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?

Cheers,
Matti
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm-pppd-plugin does not start

[matti kaasinen]

2016-03-04 12:18 GMT+02:00 matti kaasinen :

> No problem at all, this was just told in the MM recipe commenting systemd
> confuguration variable that was set to inhibit starting service at boot
> (below).
> # no need to start on boot - dbus will start on demand
> SYSTEMD_AUTO_ENABLE = "disable"
>

Naturally this is in MM recipe - and most likely some patching needs to be
done before I can get this modem up and running. So fixing this variable
setting is very trivial.
Cheers,
Matti
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm-pppd-plugin does not start

[matti kaasinen]

Aleksander,
thank your very much for your fine answers. Please find my replies/comments
below.

2016-03-04 1:28 GMT+02:00 Aleksander Morgado :

>
> Did connman/ofono run a DHCP client on the interface?
>

No, I tried to run it manually with following procedure:
ifconfig wwan0 up
dhclient wwan0
DHCP tried for some time but did not give id addresses.
In fact, I also tried this procedure with MM with same results (without
using udev to give ID_MM_IGNORE_PORT properties to cdc-wdm0 and wwan0).


> > However my desktop machine - Ubuntu 14.04 opens connection quite
> smoothly.
> > It has NM version 0.9.8.8 and MM version 1.0.0. Somehow it does not care
> > about this ndisdup problem, but instead opens connection using ppp - no
> > problem at all.
> >
>
> Despite the fact that is using PPP instead of the WWAN iface :)
>
Well, my priority is to get connection work somehow without fiddling.
Majority of traffic is very low speed m2m traffic, so protocol really is no
issue.

>
> > Main difference found from sysfs is that Ubuntu opens only /dev/ttyUSB0
> > /dev/ttyUSB2  /dev/ttyUSB3 devices for this modem whereas am335x board
> opens
> > /dev/ttyUSB0  /dev/ttyUSB1  /dev/ttyUSB2 /dev/cdc-wdm0 and /net/wwan0
> >
> > if I execute following command after plugging in modem:
> > nmcli d
> > Ubuntu provides:
> > ttyUSB3gsm   disconnected
> >
> > am335x board do not provide  have this line
> >
> > If I execute following command on am335x board:
> > mmcli -m 0 --simple-connect="apn=internet"
> >
> > Everything seems going well, solid blue led swithes on, but there is no
> > interface brought up.
>
> You're connecting the modem through MM; while you want to connect the
> modem through NM (NM will talk to MM internally). MM will not bring up
> any interface or configure IP details on the interface; that's NM
> doing it for you when you activate a "gsm" connection type.
>
OK, I thought this could be the problem, but really I did not figure out
the syntax. Now I got it
so it should be
nmcli c up uuid 
or
nmcli c up id 
both  and  coming from the configuration file.

It was also a bit confusing that
nmcli c
command from Ubuntu lists all the configurations below
/etc/NetworkManager/system-connections
while same command from am335x board do not provide this listing.
It seems that am335x needs
nmcli c list
command.

But problem now is that NM does not see this modem. If I execute:
nmcli d
modem is not listed there. Also if I execute:
nmcli c up id 

I will get following respons:
Error: No suitable device found: no device found for connection ''.


> > If I start modem connection from nm app on Ubuntu, ppp connection starts
> and
> > it is brought to interfaces. From logs it seems that it also is using
> > simple-connect method.
> >
>
> NM calls the simple connect in MM; that's regardless of what
> connection type MM will be using afterwards. NM always runs simple
> connect; you shouldn't run it manually.
>
OK, but now there is this problem that "gsm"  device is not shown to NM.

>
> > If I use udev rules to ignore cdc-wdm0 and net/wwan0 on am335x board,
> > simple-connect proceeds up tp "all done", but no ppp is started an in
> fact
> > now even the led is not having solid blue. However, if I start pppd
> manually
> > at this point, connection is established quite well.
>
> Ideally you should use NDISDUP+WWAN; very very likely you can use them
> an you're losing some other thing. If using NDISDUP+WWAN, you won't
> see NM creating a ppp0 interface, you'll just see NM trying to run a
> DHCP client on the WWAN interface once ModemManager has decided the
> WWAN is read for that (once the NDISDUP command has finished).
>
OK,  Here is one problem. NM and MM do not communicate with each other in
my installation or at least with this modem. In fact I do have other Huawei
3131 that communicates in HiLink mode fro reference. That opens eth1
interface automatically without any manual operations. nmcli c command
lists that like ordinary 802-3-ethernet connection. Does MM and NM
communicate in that case?

>
> Have you tried to use the modem with a newer ModemManager in the same
> Ubuntu setup? MM 1.0.0 and MM 1.4.x are totally compatible API wise.
> I'd really try it.
>

No I have not. I prefer not to mess with my desktop unless I become quite
desperate (I'm pretty close to that, though).


> > I have tried to reproduce Ubuntu settings.
> > 1) /etc/NetworkManager/NetworkManager.conf with following contents:
> > [main]
> > plugins=keyfile
> > dns=dnsmasq
> >
> > 2) /etc/NetworkManager/system-connections/Operator with following
> contents:
> > [connection]
> > id=Operator
> > uuid=b9cbaa78-8856-4c82-915b-702048ab3b85
> > type=gsm
> > permissions=user:root:;
> > autoconnect=true
> > timestamp=0
> >
> > [gsm]
> > number=*99#
> > apn=internet
> >
> > [ipv4]
> > method=auto
> >
> > [serial]
> > baud=115200
> >
> > Differences bitween Ubuntu and am335x board:
> > 1) Note that Ubuntu uses upstart and am335x board 

Re: nm-pppd-plugin does not start

[Aleksander Morgado]

On Fri, Mar 4, 2016 at 12:28 AM, Aleksander Morgado
 wrote:
>
>> QUESTIONS:
>> =
>> 1) What is missing in my set-up?
>
> I think you're missing

... 

I think you're basically missing the NM "gsm" connection that you
should activate through NM (e.g. with nmcli), and I'd also try to use
that modem in a newer MM directly in Ubuntu to see if avoiding all the
other integration issues you can make it work with NDISDUP+WWAN.

-- 
Aleksander
https://aleksander.es
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm-pppd-plugin does not start

[Aleksander Morgado]

Hey,

>
> Background:
> =
> I'm trying to integrate Huawei 3131 modem, VID=21d1. Original PID=14fe that
> switches to PID=1506.
>
> I'm working on am335x based embedded board running yocto/linux-ti-staging
> based Linux with 4.1 kernel. NM version is 0.9.8.10 and MM version 1.4.2.
> Board is using systemd.
>
> Base problem is that most likely modem firmware is broken so that it claims
> supporting ndisdup, but in fact it does not. This revealed when I first
> tried using connman/ofono. Connection went up to stage where connection was
> opened wtih  AT^NDISDUP=1,1. Following  AT^DHCP? returned only OK without
> any connection details.
>

Did connman/ofono run a DHCP client on the interface?

> However my desktop machine - Ubuntu 14.04 opens connection quite smoothly.
> It has NM version 0.9.8.8 and MM version 1.0.0. Somehow it does not care
> about this ndisdup problem, but instead opens connection using ppp - no
> problem at all.
>

Despite the fact that is using PPP instead of the WWAN iface :)

> Main difference found from sysfs is that Ubuntu opens only /dev/ttyUSB0
> /dev/ttyUSB2  /dev/ttyUSB3 devices for this modem whereas am335x board opens
> /dev/ttyUSB0  /dev/ttyUSB1  /dev/ttyUSB2 /dev/cdc-wdm0 and /net/wwan0
>
> if I execute following command after plugging in modem:
> nmcli d
> Ubuntu provides:
> ttyUSB3gsm   disconnected
>
> am335x board do not provide  have this line
>
> If I execute following command on am335x board:
> mmcli -m 0 --simple-connect="apn=internet"
>
> Everything seems going well, solid blue led swithes on, but there is no
> interface brought up.

You're connecting the modem through MM; while you want to connect the
modem through NM (NM will talk to MM internally). MM will not bring up
any interface or configure IP details on the interface; that's NM
doing it for you when you activate a "gsm" connection type.

> If I start modem connection from nm app on Ubuntu, ppp connection starts and
> it is brought to interfaces. From logs it seems that it also is using
> simple-connect method.
>

NM calls the simple connect in MM; that's regardless of what
connection type MM will be using afterwards. NM always runs simple
connect; you shouldn't run it manually.

> If I use udev rules to ignore cdc-wdm0 and net/wwan0 on am335x board,
> simple-connect proceeds up tp "all done", but no ppp is started an in fact
> now even the led is not having solid blue. However, if I start pppd manually
> at this point, connection is established quite well.

Ideally you should use NDISDUP+WWAN; very very likely you can use them
an you're losing some other thing. If using NDISDUP+WWAN, you won't
see NM creating a ppp0 interface, you'll just see NM trying to run a
DHCP client on the WWAN interface once ModemManager has decided the
WWAN is read for that (once the NDISDUP command has finished).

Have you tried to use the modem with a newer ModemManager in the same
Ubuntu setup? MM 1.0.0 and MM 1.4.x are totally compatible API wise.
I'd really try it.

> I have tried to reproduce Ubuntu settings.
> 1) /etc/NetworkManager/NetworkManager.conf with following contents:
> [main]
> plugins=keyfile
> dns=dnsmasq
>
> 2) /etc/NetworkManager/system-connections/Operator with following contents:
> [connection]
> id=Operator
> uuid=b9cbaa78-8856-4c82-915b-702048ab3b85
> type=gsm
> permissions=user:root:;
> autoconnect=true
> timestamp=0
>
> [gsm]
> number=*99#
> apn=internet
>
> [ipv4]
> method=auto
>
> [serial]
> baud=115200
>
> Differences bitween Ubuntu and am335x board:
> 1) Note that Ubuntu uses upstart and am335x board systemd.

This shouldn't be any issue.

> 2) Ubuntu lists one line for each of files in
> /etc/NetworkManager/system-connections folder whereas am335x seems ignoring
> these settings.
>

I think you may be missing the step to create a "gsm" connection and
activate it through NM.

> net/ppp0
> ---
> Ubuntu:
> ModemManager[22598]:  [1456479663.774029] [mm-manager.c:270]
> device_added(): (net/ppp0): could not get port's parent device
>

Normal.

> am335x: no reference for net/ppp0
>

You don't see any reference to the ppp0 interface because it is only
created on-the-fly when needed; in your yocto build we try to use
NDISDUP and WWAN, no PPP involved.

> NM in Ubuntu starts reports reporting ppp with following lines:
> NetworkManager[22606]:  pppd started with pid 23181
> Plugin /usr/lib/x86_64-linux-gnu/pppd/2.4.5/nm-pppd-plugin.so loaded.
> ** Message: nm-ppp-plugin: (plugin_init): initializing
> ** Message: nm-ppp-plugin: (nm_phasechange): status 3 / phase 'serial
> connection'
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyUSB0
>
> all PPP messages from am335x
> plugins/huawei/mm-plugin-huawei.c:543] grab_port(): (tty/ttyUSB0) Port
> flagged as PPP
>

Yes, as said, that is because Ubuntu is using the legacy PPP method in
the Huawei modem. The interface is created on the fly by pppd when NM
starts it. Note that MM does nothing of this.

> src/mm-port-serial-at.c:440]