Re: NetwokManager fails to start with core dumped
- Original Message - > From: "Dan Williams" > To: "Uldis Jansons" > Cc: networkmanager-list@gnome.org > Sent: Wednesday, December 18, 2013 8:31:58 PM > Subject: Re: NetwokManager fails to start with core dumped > > On Wed, 2013-12-18 at 09:39 +0200, Uldis Jansons wrote: > > - Original Message - > > > From: "Dan Williams" > > > To: "Uldis Jansons" > > > > > > On Tue, 2013-12-17 at 13:34 +0200, Uldis Jansons wrote: > > > > Hi! > > > > > > > > Try to launch NetworkManager but it fails to start in ugly way. > > > > > > Which libnl version do you have? There were some versions in 3.x > > > that > > > did work, and some that didn't, due to bugs in libnl. v3.2.21 > > > should > > > work, as should 3.2.23. I believe 3.2.22 had a crashing bug, and > > > some > > > earlier versions like 3.2.7 had bugs too. > > > > > > Dan > > > > > > > Hi Dan, > > > > I am using libnl-3.2.23 which I believe is the latest. As you were > > mentioned 3.2.21 as bug-free version - tried this one as well. > > Unfortunately changing of NL version didn't solve the problem - > > compilation of NetworkManager fails: > > > > [...cut...] > > CC NetworkManager-nm-system.o > > nm-system.c: In function ‘nm_system_bond_enslave’: > > nm-system.c:1699:21: error: declaration of ‘link’ shadows a global > > declaration [-Werror=shadow] > > Fixed this in 0.9.8 git. > > Dan Thanks Dan, Unfortunately I cannot see it in http://cgit.freedesktop.org/NetworkManager/NetworkManager/ Maybe I look in the whong place? Uldis ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: HUWAEI E1750 NDISDUP
On 18.12.2013 18:57, Dan Williams wrote: > On Wed, 2013-12-18 at 18:38 +0100, poma wrote: >> On 18.12.2013 00:26, Dan Williams wrote: >>> On Tue, 2013-12-17 at 23:50 +0100, poma wrote: HUWAEI E1750 NDISDUP >>> >>> Is the difference between the two modes just the usb_modeswitch >>> commands? I see they have different USB IDs between first and second >>> runs. >> >> USB Modeswitch has nothing to do with it, besides it doesn't work. ;) >> Actually the device switches mode by itself. ;) 'pid 140c' is inherited >> through a warm state(reboot) from proprietary OS. However if the device >> is replugged(cold state) within the Linux kernel, it switches to the >> 'pid 1436' mode. >> And vice versa. > > That's still usb_modeswitch. Windows is sending a specific message to > the Huawei device telling to use a specific mode, and it switches to > that mode. After reboot to Linux, it's still in that mode. But if you > coldplug the device while in Linux, usb_modeswitch sends a message to > the device that is different than what Windows sends. > > On Linux with ModemManager, we would prefer to use the "Windows" mode > since that is more capable. Unfortunately, usb_modeswitch needs changes > to send the correct message to switch to the "Windows" mode too. > > All that said, if possible ModemManager should try to support the > non-Windows cdc-ether mode too, but there may be bugs with that. It's not up to you, it's really up to the HUWAEI folks to be more involved in these issues. Besides I would rather call it the "Firmware Modeswitch", i.e. 'AT^U2DIAG=276' - the default device state, 12d1:1436 ;) poma ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetwokManager fails to start with core dumped
On Wed, 2013-12-18 at 09:39 +0200, Uldis Jansons wrote: > - Original Message - > > From: "Dan Williams" > > To: "Uldis Jansons" > > > > On Tue, 2013-12-17 at 13:34 +0200, Uldis Jansons wrote: > > > Hi! > > > > > > Try to launch NetworkManager but it fails to start in ugly way. > > > > Which libnl version do you have? There were some versions in 3.x > > that > > did work, and some that didn't, due to bugs in libnl. v3.2.21 should > > work, as should 3.2.23. I believe 3.2.22 had a crashing bug, and > > some > > earlier versions like 3.2.7 had bugs too. > > > > Dan > > > > Hi Dan, > > I am using libnl-3.2.23 which I believe is the latest. As you were mentioned > 3.2.21 as bug-free version - tried this one as well. Unfortunately changing > of NL version didn't solve the problem - compilation of NetworkManager fails: > > [...cut...] > CC NetworkManager-nm-system.o > nm-system.c: In function ‘nm_system_bond_enslave’: > nm-system.c:1699:21: error: declaration of ‘link’ shadows a global > declaration [-Werror=shadow] Fixed this in 0.9.8 git. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: HUWAEI E1750 NDISDUP
On Wed, 2013-12-18 at 18:38 +0100, poma wrote: > On 18.12.2013 00:26, Dan Williams wrote: > > On Tue, 2013-12-17 at 23:50 +0100, poma wrote: > >> HUWAEI E1750 NDISDUP > > > > Is the difference between the two modes just the usb_modeswitch > > commands? I see they have different USB IDs between first and second > > runs. > > USB Modeswitch has nothing to do with it, besides it doesn't work. ;) > Actually the device switches mode by itself. ;) 'pid 140c' is inherited > through a warm state(reboot) from proprietary OS. However if the device > is replugged(cold state) within the Linux kernel, it switches to the > 'pid 1436' mode. > And vice versa. That's still usb_modeswitch. Windows is sending a specific message to the Huawei device telling to use a specific mode, and it switches to that mode. After reboot to Linux, it's still in that mode. But if you coldplug the device while in Linux, usb_modeswitch sends a message to the device that is different than what Windows sends. On Linux with ModemManager, we would prefer to use the "Windows" mode since that is more capable. Unfortunately, usb_modeswitch needs changes to send the correct message to switch to the "Windows" mode too. All that said, if possible ModemManager should try to support the non-Windows cdc-ether mode too, but there may be bugs with that. Dan > > In any case, if ModemManager can handle the device, we would expect > > NetworkManager to handle it as well. In general, we'd prefer to handle > > the device with QMI and the QMI network commands instead of NDISDUP, > > unless the device doesn't implement the QMI stack very well. > > > > In both cases, however, ModemManager should be doing the right thing > > wtih either QMI or NDISDUP, then advertise that the IP configuration > > method should be "DHCP", and NetworkManager will perform DHCP on the > > interface and set up the IP configuration. > > Super duper! > Thanks for your response. > > > poma > > > > > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: HUWAEI E1750 NDISDUP
On 18.12.2013 00:10, Aleksander Morgado wrote: > You mean with NDISDUP=1,1 and the like? ModemManager 1.2 will do that > already, you'll just need: > # mmcli -m 0 --simple-connect="apn=whatever" > (instead of passing the AT commands yourself with --command) If the APN entry is already an existing, wouldn't be more convenient e.g. 'mmcli -m 0 --simple-connect="apn=1"' for the 1st entry. ;) > And of course it will be integrated with NetworkManager's nmcli just > fine as every other modem. Super duper! Thanks for your response, as well. poma ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: HUWAEI E1750 NDISDUP
On 18.12.2013 00:26, Dan Williams wrote: > On Tue, 2013-12-17 at 23:50 +0100, poma wrote: >> HUWAEI E1750 NDISDUP > > Is the difference between the two modes just the usb_modeswitch > commands? I see they have different USB IDs between first and second > runs. USB Modeswitch has nothing to do with it, besides it doesn't work. ;) Actually the device switches mode by itself. ;) 'pid 140c' is inherited through a warm state(reboot) from proprietary OS. However if the device is replugged(cold state) within the Linux kernel, it switches to the 'pid 1436' mode. And vice versa. > In any case, if ModemManager can handle the device, we would expect > NetworkManager to handle it as well. In general, we'd prefer to handle > the device with QMI and the QMI network commands instead of NDISDUP, > unless the device doesn't implement the QMI stack very well. > > In both cases, however, ModemManager should be doing the right thing > wtih either QMI or NDISDUP, then advertise that the IP configuration > method should be "DHCP", and NetworkManager will perform DHCP on the > interface and set up the IP configuration. Super duper! Thanks for your response. poma ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling ip4 and IPV6 on F20RC1
* Tore Anderson > Now, my own mobile provider (or probably more correctly, the GGSN vendor > used by my mobile provider) does assume that mobile nodes adhere to the > spec. Because of this, it will unicast the RAs it emits to the > link-local address it expects the mobile node to have configured (i.e. > fe80::a:b:c:d in this case). Now, if the mobile node has played fast and > loose with the standards and skipped configuring this link-local > address, its IP stack will discard the inbound ICMPv6 RA packets as "not > addressed to me". Therefore, it will never see the Prefix Information > Option in the RA, which is the *only* way global addresses is signaled > to the nodes in 3GPP mobile networks. So the node will end up without > any IPv6 address at all (neither global nor link-local), and thus > without any usable connectivity. I'm no 3GPP expert either. You're right that it's pretty clear that the autoconfiguration standard requires link-local addresses for unicast configuration discovery (I hesitate to call it router discovery when you know you're already talking to the router). How complicated a way to convey a coulpe of configuration parameters. Another reason why I understand the IPv6 critics. > I am not disputing that you've seen a working PPP connection without > link-locals. There are probably many situations where IPv6 will work > just hunky-dory without any link-local addresses configured. But that's > besides the point I'm trying to make; just because it works in one place > doesn't mean it will work in another. My point was that in specific cases, link-local addresses may not be needed. Nothing more than that. It looks like you actually agree with that so there's not much more to discuss in this area. > So a piece of software like NM, > which will be used all over the place, ought to adhere to the specs as > closely as possible, Basically I stated that NetworkManager doesn't support some working configurations. I provided at least one example of another tool using such a working configuration that's not 100% compliant given that the requirements in the RFC are apparently intended for fully locally interoperable (physical) nodes but it's not explicitly stated in the document. I didn't even say that NetworkManager must support those configurations, I just guessed it would be useful. And it indeed would, just imagine a running NetworkManager instance in OpenVZ just providing the connection information to the applications. It shouldn't actually treat a missing link-local address as fatal in that case, as it doesn't impact global communication. I believe we actually agree from the beginning, as the *defaults* must be as compliant as possible while still not causing trouble (that's why we pad DNS lifetimes even though it's not explicitly allowed by the standard). I'm talking about further possibilities, not defaults. Those further possibilities don't even need to be accessible via GUI tools, so that ordinary users don't mess with them. I don't see a conflict between our common desire to provide a 99% compliant implementation (or 100% if the standards get fixed) and my intention to provide also a little bit more. You've seen in the past that our intentions are usually pretty much compatible ;). And you must know from our past conversations that I do like link-local addresses for not just setting up the infrastructure setup. Remember the glibc getaddrinfo issues. Cheers, Pavel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling ip4 and IPV6 on F20RC1
* Pavel Simerda > I don't have an IPv6-enabled PPP connection right at hand but I think > I've seen a working setup without one. But I'm not going to set up > one right now, so there's no point in arguing over that. I guess the > simple fact that you technically don't need link-local addresses for > global routing doesn't help you. Here's a real-world example of why link-local addresses may be needed: In 3GPP mobile networks, the network will assign an Interface ID to the node. I'm no 3GPP expert like Bjørn, but I believe this information is is carried in PCO, which is then bridged into e.g. IPV6CP if we're talking PPP. The node is *required* to construct a link-local address on its mobile interface using this network-assigned Interface ID. So if the network has assigned an Interface ID of ::a:b:c:d, the mobile node *must* configure the link-local address fe80::a:b:c:d if it is to comply with the specs. Now, my own mobile provider (or probably more correctly, the GGSN vendor used by my mobile provider) does assume that mobile nodes adhere to the spec. Because of this, it will unicast the RAs it emits to the link-local address it expects the mobile node to have configured (i.e. fe80::a:b:c:d in this case). Now, if the mobile node has played fast and loose with the standards and skipped configuring this link-local address, its IP stack will discard the inbound ICMPv6 RA packets as "not addressed to me". Therefore, it will never see the Prefix Information Option in the RA, which is the *only* way global addresses is signaled to the nodes in 3GPP mobile networks. So the node will end up without any IPv6 address at all (neither global nor link-local), and thus without any usable connectivity. I am not disputing that you've seen a working PPP connection without link-locals. There are probably many situations where IPv6 will work just hunky-dory without any link-local addresses configured. But that's besides the point I'm trying to make; just because it works in one place doesn't mean it will work in another. So a piece of software like NM, which will be used all over the place, ought to adhere to the specs as closely as possible, in order to get maximum compatibility with the various networks it might end up being used in. Tore ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling ip4 and IPV6 on F20RC1
- Original Message - > From: "Bjørn Mork" > To: "Pavel Simerda" > Both link local and global addresses can be manually configured > in the sense that the interface identifier can be manually configured. Obviously. In context of NetworkManager features, static/manual addressing refers to global addresses, configured by the user, that are added to the network interface, while link-local adresses are configured by the kernel. See below. > I don't know anything about OpenVZ, Works pretty well. “venet devices are not fully IPv6 compliant, but still works if you statically assign IPv6 addresses. They do not properly support MAC addresses and consequently link local addresses and can not play nice with neighbor discovery or router advertisements, router discovery, or auto-conf.” (source: http://openvz.org/IPv6) OpenVZ venet interfaces work as expected, you can't distinguish them from compliant IPv6 on Ethernet from the network. Therefore it's 100% interoperable but not compliant. That sounds like the standard which is there to ensure interoperability imposes restrictions that are not necessary for a specific case. Of course OpenVZ could add a pair of link-local adresses for each network but they would never be used in practice. > but ppp links do of course distinguish between link-local and global > addresses. I don't have an IPv6-enabled PPP connection right at hand but I think I've seen a working setup without one. But I'm not going to set up one right now, so there's no point in arguing over that. I guess the simple fact that you technically don't need link-local addresses for global routing doesn't help you. > The Linux kernel does of course also distinguish between link-local and > global addresses, regardless of interface type. Obviously. > Link local and global addresses are not interchangable. Obviously. > > There's actually no reason you would need link-local addresses for > > static configuration. > > I hear you say that. You are wrong. It's actually trivial to test that by either: a) Simply configuring global addresses using iproute and using tools like ping to communicate over the network. b) Actually learning about the protocols and/or watching packet flow using tcpdump or a similar tool. IPv6 routing works exactly the same as IPv4 routing except that ARP packets for the first hop resolution are replaced with ICMP packets. When communicating over global IPv6 addresses, you never need to use a link-local one. If you can challenge that on technical ground, I'm buying you a dinner. - Original Message - > From: "Bjørn Mork" > To: "Pavel Simerda" > Cc: "Tore Anderson" , networkmanager-list@gnome.org, "Dan > Winship" > Sent: Tuesday, December 17, 2013 3:20:10 PM > Subject: Re: Disabling ip4 and IPV6 on F20RC1 > > But unfortunately we need to be a little bit careful about the theory > > written down on paper and the actual needs. Linux has the long history > > of allowing more than just blind following of what's written down. > > I was writing a longer reply to this, but I think I'd better not. This > is just stupid. Please don't call something stupid just because you didn't get it. I'm here to answer any questions if needed. Cheers, Pavel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disabling ip4 and IPV6 on F20RC1
- Original Message - > From: "Dan Winship" > To: "Pavel Simerda" , "Tore Anderson" > Cc: networkmanager-list@gnome.org > Sent: Tuesday, December 17, 2013 3:39:41 PM > Subject: Re: Disabling ip4 and IPV6 on F20RC1 > > On 12/17/2013 06:01 AM, Pavel Simerda wrote: > > 2) But setting disable_ipv6 doesn't really work as expected. See [1] and > > especially the note about disable_ipv6 below the table. The truth is that > > this also wouldn't affect the original poster's use case where the > > specific interface is (hopefully) expected to be always without IP > > addresses. > > Oh, you missed the update I guess. It wasn't a kernel bug, it was > NetworkManager itself interfering with my testing. disable_ipv6 works > just as expected. Indeed. Thanks for the information, that's a good news. Cheers, Pavel > -- Dan > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetwokManager fails to start with core dumped
- Original Message - > From: "Uldis Jansons" > To: "Dan Williams" > Cc: networkmanager-list@gnome.org > Sent: Wednesday, December 18, 2013 9:13:38 AM > Subject: Re: NetwokManager fails to start with core dumped > > > - Original Message - > > From: "Uldis Jansons" > > To: "Dan Williams" > > Cc: networkmanager-list@gnome.org > > Sent: Wednesday, December 18, 2013 9:39:59 AM > > Subject: Re: NetwokManager fails to start with core dumped > > > > > > - Original Message - > > > From: "Dan Williams" > > > To: "Uldis Jansons" > > > > > > Which libnl version do you have? There were some versions in 3.x > > > that > > > did work, and some that didn't, due to bugs in libnl. v3.2.21 > > > should > > > work, as should 3.2.23. I believe 3.2.22 had a crashing bug, and > > > some > > > earlier versions like 3.2.7 had bugs too. > > > > > > Dan > > > > > > > Hi Dan, > > > > I am using libnl-3.2.23 which I believe is the latest. As you were > > mentioned 3.2.21 as bug-free version - tried this one as well. > > Unfortunately changing of NL version didn't solve the problem - > > compilation of NetworkManager fails: > > > > [...cut...] > > CC NetworkManager-nm-system.o > > nm-system.c: In function ‘nm_system_bond_enslave’: > > nm-system.c:1699:21: error: declaration of ‘link’ shadows a global > > declaration [-Werror=shadow] > > cc1: all warnings being treated as errors > > make[4]: *** [NetworkManager-nm-system.o] Error 1 > > make[4]: Leaving directory > > `/home/vas/build/NetworkManager-0.9.8.8/src' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory > > `/home/vas/build/NetworkManager-0.9.8.8/src' > > make[2]: *** [all] Error 2 > > make[2]: Leaving directory > > `/home/vas/build/NetworkManager-0.9.8.8/src' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/vas/build/NetworkManager-0.9.8.8' > > make: *** [all] Error 2 > > Update. > > Failing of make I solved by using --disable-more-warnings with ./configure. > So now everything is built without errors. Unfortunately starting of > NetworkManager still fails even with different netlink library > (libnl-3.2.21). > > [...cut...] > NetworkManager[1948]: Failed to connect to netlink: (4) unable to > allocate netlink link cache for monitoring link status: Operation not > supported > (NetworkManager:1948): GLib-GObject-CRITICAL **: g_type_instance_get_private: > assertion `instance != NULL && instance->g_class != NULL' failed > Segmentation fault (core dumped) As I said already on IRC, I suspect some sort of a system problem here. Did you check whether it could be caused by some selinux, apparmor or similar tool or by some specific kernel configuration? Is the system in any way specific, different from other systems? Could you reproduce with a fresh installation? Cheers, Pavel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetwokManager fails to start with core dumped
- Original Message - > From: "Uldis Jansons" > To: "Dan Williams" > Cc: networkmanager-list@gnome.org > Sent: Wednesday, December 18, 2013 9:39:59 AM > Subject: Re: NetwokManager fails to start with core dumped > > > - Original Message - > > From: "Dan Williams" > > To: "Uldis Jansons" > > > > Which libnl version do you have? There were some versions in 3.x > > that > > did work, and some that didn't, due to bugs in libnl. v3.2.21 > > should > > work, as should 3.2.23. I believe 3.2.22 had a crashing bug, and > > some > > earlier versions like 3.2.7 had bugs too. > > > > Dan > > > > Hi Dan, > > I am using libnl-3.2.23 which I believe is the latest. As you were > mentioned 3.2.21 as bug-free version - tried this one as well. > Unfortunately changing of NL version didn't solve the problem - > compilation of NetworkManager fails: > > [...cut...] > CC NetworkManager-nm-system.o > nm-system.c: In function ‘nm_system_bond_enslave’: > nm-system.c:1699:21: error: declaration of ‘link’ shadows a global > declaration [-Werror=shadow] > cc1: all warnings being treated as errors > make[4]: *** [NetworkManager-nm-system.o] Error 1 > make[4]: Leaving directory > `/home/vas/build/NetworkManager-0.9.8.8/src' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/home/vas/build/NetworkManager-0.9.8.8/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory > `/home/vas/build/NetworkManager-0.9.8.8/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/vas/build/NetworkManager-0.9.8.8' > make: *** [all] Error 2 Update. Failing of make I solved by using --disable-more-warnings with ./configure. So now everything is built without errors. Unfortunately starting of NetworkManager still fails even with different netlink library (libnl-3.2.21). [...cut...] NetworkManager[1948]: Failed to connect to netlink: (4) unable to allocate netlink link cache for monitoring link status: Operation not supported (NetworkManager:1948): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion `instance != NULL && instance->g_class != NULL' failed Segmentation fault (core dumped) Uldis ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
