Re: NetworkManager dispatchers
Hi Dan MM 1.4.12 and NM 1.0.10. I understand that the connection to bearer takes a bit of time, but when I get this: root~# mmcli -b /org/freedesktop/ModemManager1/Bearer/1 Bearer '/org/freedesktop/ModemManager1/Bearer/1' - Status | connected: 'yes' | suspended: 'no' | interface: 'ttyUSB3' | IP timeout: '20' - Properties | apn: 'm2minternet.apn' | roaming: 'allowed' | IP type: 'none' |user: 'none' |password: 'none' | number: 'none' | Rm protocol: 'unknown' - IPv4 configuration | method: 'ppp' | address: 'unknown' | prefix: '0' | gateway: 'unknown' | DNS: none - IPv6 configuration | method: 'unknown' Does it not mean that I am already connected?? If I bring up PPPD manually I could ping and I can wget at this point. On Fri, Mar 4, 2016 at 8:57 AM, Dan Williams wrote: > On Thu, 2016-03-03 at 17:06 -0800, Ali Nematollahi wrote: > > So I did some more work and Here is what I found, which still doesn't > > make > > any sense. > > > > When I checked the "bearer" info with mmcli: > > Bearer '/org/freedesktop/ModemManager1/Bearer/0' > > - > > Status | connected: 'no' > > | suspended: 'no' > > | interface: 'unknown' > > | IP timeout: '20' > > - > > Properties | apn: 'm2minternet.apn' > > | roaming: 'allowed' > > | IP type: 'none' > > |user: 'none' > > |password: 'none' > > | number: 'none' > > | Rm protocol: 'unknown' > > - > > IPv4 configuration | method: 'unknown' > > - > > IPv6 configuration | method: 'unknown' > > The bearer will be created but it takes a bit to be connected, so > that's probably the state you're in here. > > > > > > > so I did a simple-connect AGAIN: > > mmcli -m 0 --simple-connect="apn=m2minternet.apn" > > NetworkManager[2887]: (ttyUSB2): modem state changed, > > 'registered' > > --> 'connecting' (reason: user-requested) > > NetworkManager[2887]: (ttyUSB2): modem state changed, > > 'connecting' > > --> 'connected' (reason: user-requested) > > successfully connected the modem > > root~# mmcli -b /org/freedesktop/ModemManager1/Bearer/1 > > Bearer '/org/freedesktop/ModemManager1/Bearer/1' > > - > > Status | connected: 'yes' > > | suspended: 'no' > > | interface: 'ttyUSB3' > > | IP timeout: '20' > > - > > Properties | apn: 'm2minternet.apn' > > | roaming: 'allowed' > > | IP type: 'none' > > |user: 'none' > > |password: 'none' > > | number: 'none' > > | Rm protocol: 'unknown' > > - > > IPv4 configuration | method: 'ppp' > > | address: 'unknown' > > | prefix: '0' > > | gateway: 'unknown' > > | DNS: none > > - > > IPv6 configuration | method: 'unknown' > > > Good sign! But > > nmcli con up ppp > > NetworkManager[2887]: (ttyUSB2): Activation: starting > > connection > > 'ppp' (94e24340-490b-4f96-91bb-c5511a2a5f50) > > NetworkManager[2887]: (ttyUSB2): device state change: > > disconnected > > -> prepare (reason 'none') [30 40 0] > > NetworkManager[2887]: NetworkManager state is now CONNECTING > > NetworkManager[2887]: (ttyUSB2): Failed to connect 'ppp': > > Connection requested IPv4 but IPv4 is unsuported by the modem. > > > > What version of NetworkManager and ModemManager did you have again? I > seem to recall fixing a bug here recently about mis-identifying the > supported IP types. > > Dan > > > NetworkManager[2887]: (ttyUSB2): device state change: prepare > > -> > > failed (reason 'modem-init-failed') [40 120 28] > > NetworkManager[2887]: NetworkManager state is now > > DISCONNECTED > > NetworkManager[2887]: (ttyUSB2): Activation: failed for > > connection > > 'ppp' > > NetworkManager[2887]: (ttyUSB2): modem state changed, > > 'connected' > > --> 'disconnecting' (reason: user-requested) > > NetworkManager[2887]: (ttyUSB2): device state change: failed > > -> > > disconnected (reason 'none') [120 30 0] > > E
Re: NetworkManager dispatchers
On Thu, 2016-03-03 at 17:06 -0800, Ali Nematollahi wrote: > So I did some more work and Here is what I found, which still doesn't > make > any sense. > > When I checked the "bearer" info with mmcli: > Bearer '/org/freedesktop/ModemManager1/Bearer/0' > - > Status | connected: 'no' > | suspended: 'no' > | interface: 'unknown' > | IP timeout: '20' > - > Properties | apn: 'm2minternet.apn' > | roaming: 'allowed' > | IP type: 'none' > |user: 'none' > |password: 'none' > | number: 'none' > | Rm protocol: 'unknown' > - > IPv4 configuration | method: 'unknown' > - > IPv6 configuration | method: 'unknown' The bearer will be created but it takes a bit to be connected, so that's probably the state you're in here. > > > so I did a simple-connect AGAIN: > mmcli -m 0 --simple-connect="apn=m2minternet.apn" > NetworkManager[2887]: (ttyUSB2): modem state changed, > 'registered' > --> 'connecting' (reason: user-requested) > NetworkManager[2887]: (ttyUSB2): modem state changed, > 'connecting' > --> 'connected' (reason: user-requested) > successfully connected the modem > root~# mmcli -b /org/freedesktop/ModemManager1/Bearer/1 > Bearer '/org/freedesktop/ModemManager1/Bearer/1' > - > Status | connected: 'yes' > | suspended: 'no' > | interface: 'ttyUSB3' > | IP timeout: '20' > - > Properties | apn: 'm2minternet.apn' > | roaming: 'allowed' > | IP type: 'none' > |user: 'none' > |password: 'none' > | number: 'none' > | Rm protocol: 'unknown' > - > IPv4 configuration | method: 'ppp' > | address: 'unknown' > | prefix: '0' > | gateway: 'unknown' > | DNS: none > - > IPv6 configuration | method: 'unknown' > Good sign! But > nmcli con up ppp > NetworkManager[2887]: (ttyUSB2): Activation: starting > connection > 'ppp' (94e24340-490b-4f96-91bb-c5511a2a5f50) > NetworkManager[2887]: (ttyUSB2): device state change: > disconnected > -> prepare (reason 'none') [30 40 0] > NetworkManager[2887]: NetworkManager state is now CONNECTING > NetworkManager[2887]: (ttyUSB2): Failed to connect 'ppp': > Connection requested IPv4 but IPv4 is unsuported by the modem. > What version of NetworkManager and ModemManager did you have again? I seem to recall fixing a bug here recently about mis-identifying the supported IP types. Dan > NetworkManager[2887]: (ttyUSB2): device state change: prepare > -> > failed (reason 'modem-init-failed') [40 120 28] > NetworkManager[2887]: NetworkManager state is now > DISCONNECTED > NetworkManager[2887]: (ttyUSB2): Activation: failed for > connection > 'ppp' > NetworkManager[2887]: (ttyUSB2): modem state changed, > 'connected' > --> 'disconnecting' (reason: user-requested) > NetworkManager[2887]: (ttyUSB2): device state change: failed > -> > disconnected (reason 'none') [120 30 0] > Error: Connection activation failed: Active connection could not be > attached to the device > root~# NetworkManager[2887]: (ttyUSB2): modem state changed, > 'disconnecting' --> 'registered' (reason: user-requested) > > root~# mmcli -b /org/freedesktop/ModemManager1/Bearer/1 > Bearer '/org/freedesktop/ModemManager1/Bearer/1' > - > Status | connected: 'no' > | suspended: 'no' > | interface: 'unknown' > | IP timeout: '20' > - > Properties | apn: 'm2minternet.apn' > | roaming: 'allowed' > | IP type: 'none' > |user: 'none' > |password: 'none' > | number: 'none' > | Rm protocol: 'unknown' > - > IPv4 configuration | method: 'unknown' > - > IPv6 configuration | method: 'unknown' > > > So after a con up, the modem lost its connection it looks like!!! but > why? > > I'm really out of ideas now. I don't know how to progress further :( > > > > On Thu, Mar 3, 2016 at 4:49 PM, Ali Nematollahi > wrote: > > > > > I made a progress. I enabled debugging and I saw the NM was > > complaining > > about dual-stack: > > > > NetworkManager[4883]: Loaded d
Re: nm-pppd-plugin does not start
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: Is this the designed behaviour for NetworkManager
On Fri, 2016-03-04 at 15:49 +, Tim Coote wrote: > > > > On 4 Mar 2016, at 15:03, Thomas Haller wrote: > > > > On Fri, 2016-03-04 at 15:57 +0100, Thomas Haller wrote: > > > > > > On Fri, 2016-03-04 at 11:15 +, Tim Coote wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4 Mar 2016, at 10:40, Thomas Haller > > > > > wrote: > > > > > > > > > > On Fri, 2016-03-04 at 10:19 +, Tim Coote wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hullo > > > > > > > > > > > > I’m starting to migrate my fedora stock to NetworkManager. > > > > > > In > > > > > > one > > > > > > particular test scenario, I tried to create a direct copy > > > > > > of > > > > > > the > > > > > > final machine configuration using NM and the old "systemctl > > > > > > start > > > > > > network” approach. The VMs are temporally separated (ie I > > > > > > spin > > > > > > up > > > > > > the > > > > > > old one save interrogation results about configuration; > > > > > > kill it > > > > > > and > > > > > > repeat with the new one). The only differences between the > > > > > > two > > > > > > machines should be the hostnames (so that the puppet > > > > > > configuration > > > > > > knows them as different machines) and the mac addresses. > > > > > > > > > > > > One inconsistency that I’ve found is that the > > > > > > NetworkManager > > > > > > cannot > > > > > > seem to spin up a tunnel unless the ipv4 addresses differ > > > > > > between > > > > > > the > > > > > > VMs. For the NM controlled VM, pulling apart the actual > > > > > > command > > > > > > run, > > > > > > I see: > > > > > > [code] > > > > > > nmcli con up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 > > > > > > > > > > > > Error: Connection activation failed: No suitable device > > > > > > found > > > > > > for > > > > > > this connection. > > > > > > [/code] > > > > > > > > > > > > where the uuid represents the sit1 device. However, on the > > > > > > same > > > > > > VM > > > > > > (either directly invoked or by turning off NM and running > > > > > > ifup > > > > > > sit1): > > > > > > [code] > > > > > > /etc/sysconfig/network-scripts/ifup-sit sit1 > > > > > > [/code] > > > > > > > > > > > > spins up the tunnel. > > > > > > > > > > > > If I put the ‘copy’ VM on different IP address(es). NM > > > > > > seems > > > > > > happy to > > > > > > spin up the tunnel. Note that in both cases there are no > > > > > > conflicting > > > > > > computers/ip addresses on the network at the same time. > > > > > > > > > > > > Am I (probabably) seeing the intended behaviour for NM - in > > > > > > which > > > > > > case I need to modify my testing approach - or do I need to > > > > > > dig > > > > > > further to confirm a bug? > > > > > > > > > > > > tia > > > > > Hi, > > > > > > > > > > > > > > > which version of NetworkManager? > > > > > > > > > > what gives > > > > > nmcli connection show 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 > > > > > and how does the corresponding ifcfg-file look? > > > > > cat /etc/sysconfig/network-scripts/ifcfg-* > > > > > > > > > > > > > > > Thanks, > > > > > Thomas > > > Hi Tim, > > > > > > > > > Side note: usually it's better to answer with "reply-all", > > > because > > > then > > > the mailing list might help you. > > > > > > > > > > > > > > > > > > Sorry. I wasn’t intending to get into debugging my setup, more > > > > trying > > > > to understand what the design should do. > > > > > > > > in any case: > > > > > > > > NetworkManager-1.0.6-6.fc23.x86_64 (stock f23) > > > Note that this is not the most recent version on f23. Ithould be > > > 1.0.10. > > > > > > > > > > > > > > > > > > > > > > > > the nmcli connection … was gleaned from running sh -x > > > > usr/sbin/ifup > > > > sit1. /usr/sbin/ifup comes from initscripts-9.64- > > > > 1.fc23.x86_64 > > > > > > > > nb. these are the versions of the files that work. To break the > > > > configuration I change the IP addresses from 172.17.1.9 to > > > > 172.17.1.10 and from 192.168.31.61 to 192.168.31.60 throughout. > > > > > > > > /etc/sysconfig/network-scripts/ifcfg-eth0 > > > > # Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI > > > > Express > > > > DEVICE=eth0 > > > > # temp static to avoid dhcp allcotion pluto as default router > > > > BOOTPROTO=none > > > > IPADDR=172.17.1.9 > > > > NETMASK=255.255.0.0 > > > > #HWADDR=00:15:58:09:b2:ec > > > > #needs to override dhcp, dhcp still used to ensure ip address > > > > not > > > > lost - fixme!! > > > > GATEWAY=192.168.31.100 > > > > ONBOOT=yes > > > > NM_CONTROLLED=no > > > > TYPE=Ethernet > > > > USERCTL=no > > > > # not using 6to4, but a dedicated tunnel. seems to work with > > > > this > > > > in, > > > > but generates warnings IPV6TO4INIT=yes > > > > IPV6INIT=yes > > > > IPV6ADDR_SECONDARIES="2001:470:::1/64" > > > > # unclear on value/necessity. I think it's for varying tunnels, > > > > so > > > > probably not essential > > > > IPV6_CONTROL_RADVD=yes > > > > PREFIX=16 > > >
Re: Is this the designed behaviour for NetworkManager
> On 4 Mar 2016, at 15:03, Thomas Haller wrote: > > On Fri, 2016-03-04 at 15:57 +0100, Thomas Haller wrote: >> On Fri, 2016-03-04 at 11:15 +, Tim Coote wrote: >>> On 4 Mar 2016, at 10:40, Thomas Haller wrote: On Fri, 2016-03-04 at 10:19 +, Tim Coote wrote: > > > Hullo > > I’m starting to migrate my fedora stock to NetworkManager. In > one > particular test scenario, I tried to create a direct copy of > the > final machine configuration using NM and the old "systemctl > start > network” approach. The VMs are temporally separated (ie I spin > up > the > old one save interrogation results about configuration; kill it > and > repeat with the new one). The only differences between the two > machines should be the hostnames (so that the puppet > configuration > knows them as different machines) and the mac addresses. > > One inconsistency that I’ve found is that the NetworkManager > cannot > seem to spin up a tunnel unless the ipv4 addresses differ > between > the > VMs. For the NM controlled VM, pulling apart the actual command > run, > I see: > [code] > nmcli con up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 > > Error: Connection activation failed: No suitable device found > for > this connection. > [/code] > > where the uuid represents the sit1 device. However, on the same > VM > (either directly invoked or by turning off NM and running ifup > sit1): > [code] > /etc/sysconfig/network-scripts/ifup-sit sit1 > [/code] > > spins up the tunnel. > > If I put the ‘copy’ VM on different IP address(es). NM seems > happy to > spin up the tunnel. Note that in both cases there are no > conflicting > computers/ip addresses on the network at the same time. > > Am I (probabably) seeing the intended behaviour for NM - in > which > case I need to modify my testing approach - or do I need to dig > further to confirm a bug? > > tia Hi, which version of NetworkManager? what gives nmcli connection show 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 and how does the corresponding ifcfg-file look? cat /etc/sysconfig/network-scripts/ifcfg-* Thanks, Thomas >> >> Hi Tim, >> >> >> Side note: usually it's better to answer with "reply-all", because >> then >> the mailing list might help you. >> >> >>> >>> Sorry. I wasn’t intending to get into debugging my setup, more >>> trying >>> to understand what the design should do. >>> >>> in any case: >>> >>> NetworkManager-1.0.6-6.fc23.x86_64 (stock f23) >> Note that this is not the most recent version on f23. Ithould be >> 1.0.10. >> >> >> >> >>> >>> the nmcli connection … was gleaned from running sh -x usr/sbin/ifup >>> sit1. /usr/sbin/ifup comes from initscripts-9.64-1.fc23.x86_64 >>> >>> nb. these are the versions of the files that work. To break the >>> configuration I change the IP addresses from 172.17.1.9 to >>> 172.17.1.10 and from 192.168.31.61 to 192.168.31.60 throughout. >>> >>> /etc/sysconfig/network-scripts/ifcfg-eth0 >>> # Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI >>> Express >>> DEVICE=eth0 >>> # temp static to avoid dhcp allcotion pluto as default router >>> BOOTPROTO=none >>> IPADDR=172.17.1.9 >>> NETMASK=255.255.0.0 >>> #HWADDR=00:15:58:09:b2:ec >>> #needs to override dhcp, dhcp still used to ensure ip address not >>> lost - fixme!! >>> GATEWAY=192.168.31.100 >>> ONBOOT=yes >>> NM_CONTROLLED=no >>> TYPE=Ethernet >>> USERCTL=no >>> # not using 6to4, but a dedicated tunnel. seems to work with this >>> in, >>> but generates warnings IPV6TO4INIT=yes >>> IPV6INIT=yes >>> IPV6ADDR_SECONDARIES="2001:470:::1/64" >>> # unclear on value/necessity. I think it's for varying tunnels, so >>> probably not essential >>> IPV6_CONTROL_RADVD=yes >>> PREFIX=16 >>> >>> /etc/sysconfig/network-scripts/ifcfg-eth0:1 >>> # Please read /usr/share/doc/initscripts-*/sysconfig.txt >>> # for the documentation of these parameters. >>> GATEWAY=192.168.31.100 >>> DNS1=172.17.31.77 >>> DEVICE=eth0:1 >>> BOOTPROTO=none >>> NETMASK=255.255.255.0 >>> TYPE=Ethernet >>> IPADDR=192.168.31.61 >>> IPV6INIT=yes >>> USERCTL=no >>> ONPARENT=yes >>> NM_CONTROLLED=no >>> PREFIX=24 >>> >>> >>> /etc/sysconfig/network-scripts/ifcfg-lo >>> DEVICE=lo >>> IPADDR=127.0.0.1 >>> NETMASK=255.0.0.0 >>> NETWORK=127.0.0.0 >>> # If you're having problems with gated making 127.0.0.0/8 a >>> martian, >>> # you can change this to something else (255.255.255.255, for >>> example) >>> BROADCAST=127.255.255.255 >>> ONBOOT=yes >>> NAME=loopback >>> >>> /etc/sysconfig/network-scripts/ifcfg-sit1 >>> DEVICE=sit1 >>> BOOTPROTO=none >>> ONBOOT=yes >>> IPV6INIT=yes >>> IPV6TUNNELIPV4=aaa.bbb.ccc. >>> IPV6TUNNELIPV4LOCAL=172.17.1.9 >>> IPV6ADDR=2001:470:
Re: nm-pppd-plugin does not start
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
2016-03-04 12:18 GMT+02:00 matti kaasinen : > It's NM the one creating the interface. Did you compile NM in yocto >> with ppp support? (--with-ppp I think it is) What's the configure >> report output? This would be when you want to force the legacy PPP >> method, though. I still believe you should try NDISDUP on the >> /dev/cdc-wdm0 and WWAN with DHCP... :) >> > 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. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is this the designed behaviour for NetworkManager
On Fri, 2016-03-04 at 10:19 +, Tim Coote wrote: > Hullo > > I’m starting to migrate my fedora stock to NetworkManager. In one > particular test scenario, I tried to create a direct copy of the > final machine configuration using NM and the old "systemctl start > network” approach. The VMs are temporally separated (ie I spin up the > old one save interrogation results about configuration; kill it and > repeat with the new one). The only differences between the two > machines should be the hostnames (so that the puppet configuration > knows them as different machines) and the mac addresses. > > One inconsistency that I’ve found is that the NetworkManager cannot > seem to spin up a tunnel unless the ipv4 addresses differ between the > VMs. For the NM controlled VM, pulling apart the actual command run, > I see: > [code] > nmcli con up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 > > Error: Connection activation failed: No suitable device found for > this connection. > [/code] > > where the uuid represents the sit1 device. However, on the same VM > (either directly invoked or by turning off NM and running ifup sit1): > [code] > /etc/sysconfig/network-scripts/ifup-sit sit1 > [/code] > > spins up the tunnel. > > If I put the ‘copy’ VM on different IP address(es). NM seems happy to > spin up the tunnel. Note that in both cases there are no conflicting > computers/ip addresses on the network at the same time. > > Am I (probabably) seeing the intended behaviour for NM - in which > case I need to modify my testing approach - or do I need to dig > further to confirm a bug? > > tia Hi, which version of NetworkManager? what gives nmcli connection show 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 and how does the corresponding ifcfg-file look? cat /etc/sysconfig/network-scripts/ifcfg-* Thanks, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Is this the designed behaviour for NetworkManager
Hullo I’m starting to migrate my fedora stock to NetworkManager. In one particular test scenario, I tried to create a direct copy of the final machine configuration using NM and the old "systemctl start network” approach. The VMs are temporally separated (ie I spin up the old one save interrogation results about configuration; kill it and repeat with the new one). The only differences between the two machines should be the hostnames (so that the puppet configuration knows them as different machines) and the mac addresses. One inconsistency that I’ve found is that the NetworkManager cannot seem to spin up a tunnel unless the ipv4 addresses differ between the VMs. For the NM controlled VM, pulling apart the actual command run, I see: [code] nmcli con up uuid 4a341ad1-3e31-7ee8-82ee-2019bf995ad8 Error: Connection activation failed: No suitable device found for this connection. [/code] where the uuid represents the sit1 device. However, on the same VM (either directly invoked or by turning off NM and running ifup sit1): [code] /etc/sysconfig/network-scripts/ifup-sit sit1 [/code] spins up the tunnel. If I put the ‘copy’ VM on different IP address(es). NM seems happy to spin up the tunnel. Note that in both cases there are no conflicting computers/ip addresses on the network at the same time. Am I (probabably) seeing the intended behaviour for NM - in which case I need to modify my testing approach - or do I need to dig further to confirm a bug? tia Tim ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-pppd-plugin does not start
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
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 systemd. > > This shouldn'
