Re: Problems with gobi 4000 connecting via QMI
On Mon, 2016-02-22 at 20:05 +0100, Harald Jung wrote: > Hi, > > a firmware update fixes the problem: > The update did not work with windows 10-64bit, but with windows 7- > 32bit. > > Firmware Update: > http://h20564.www2.hp.com/hpsc/swd/public/detail?sp4ts.oid=5405133 > ItemId=ob_152395_1=4060 Thanks for the update; good to know it's a firmware thing. They are always the most frustrating to figure out :) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-1-2 blocker cleanup
On Mon, 2016-02-22 at 12:27 +0100, Lubomir Rintel wrote: > Hi, > > with the 1.2 release approaching, we need to decide on which bugs set > for 1.2 > milestone need to block the release. No new features should remain in > the list, > only things that absolutely need to be fixed before the release such > as > regressions. > > I propose that these should be retargetted for nm-1.4: > > 683206: maximize device availability (IFF_UP/IFF_LOWER_UP) for IPv6 > link-local communication during runtime and after exit > 699843: leave interface configuration when removing from NM > management > 708829: dnssec: support per-connection DNSSEC options for local zones > 699810: dns: support for unbound with split DNS and DNSSEC > 746440: improve behavior for assumed and unmanaged devices, do better > at seamless take over, and don't touch devices > 760907: fix handling of invalid connections in libnm/libnm-glib Yeah, I think all of these can get retargeted. > And I think these should remain blocking 1.2: > > 697370: live reconfiguration of NMDevices Like Thomas said, what is left to do here? Obviously we're not going to fix everything for 1.2 so I think we should just split/clone this for specific properties and close 697370? > > 740574: support appindicator based systrays (found in Unity, KDE, > Enlightenment and more) This one was only about some additional nice-to-have stuff that would make the applet easier to maintain. So I went ahead and did the required dbusmenu changes and applet side (both linked in the bug) but we have to wait for a code review on Launchpad and a new library release. If things happen in the next few weeks I'm happy to merge that code for 1.2. But I doubt it... > 736406: NetworkManager.service should use KillMode=mixed> > 740739: cannot activate shared connection on physically disconnected > ethernet > 748302: [review] lr/cli-add-master: Make it possible to specify > master connection/device for any connection profile > 760998: resync with systemd upstream code before 1.2 > 761389: don't mess with interface handled by clatd > 762322: reapply does not restore IP configuration > 762331: revert behavioral change for NM_UNMANAGED_USER_CONFIG being > overwritable by USER_EXPLICIT Thomas fixed this one already it seems. > 762333: ensure autoconnection does not make a device > !NM_UNMANAGED_USER_EXPLICT > 341323: [ENH] Verify subject of remote certificate [See dependency > tree for bug 341323] Yeah, this one should get enabled, and maybe we even add it to editor while we're at it. I think domain_suffix_match is also simpler for users and administrators to implement anyway. Anything I didn't comment on I agree with your assessment. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with gobi 4000 connecting via QMI
Hi, a firmware update fixes the problem: The update did not work with windows 10-64bit, but with windows 7-32bit. Firmware Update: http://h20564.www2.hp.com/hpsc/swd/public/detail?sp4ts.oid=5405133=ob_152395_1=4060 regards Harald ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-1-2 blocker cleanup
On Mon, 2016-02-22 at 12:27 +0100, Lubomir Rintel wrote: > I propose that these should be retargetted for nm-1.4: > 760907: fix handling of invalid connections in libnm/libnm-glib I think this should be fixed for 1.2. But it needs discussion how to fix it. The fix itself should be simple. > And I think these should remain blocking 1.2: > 697370: live reconfiguration of NMDevices I would move this to 1.4 What is missing here? Sure, we need UI support like nmcli commands nmcli device modify $DEV +ipv4.addresses 192.168.5.2/24 nmcli connection modify --reapply $CON +ipv4.addresses 192.168.5.2/24 That seems like a follow-up (nmcli) feature. We already have D-Bus API in place and we did already great internal improvements that make this possible (lr/applied-connection and lr/reapply). > 736406: NetworkManager.service should use KillMode=mixed I don't think we can even do this as of now. It would kill our dhclient instances. I would move to 1.4. > 740574: support appindicator based systrays (found in Unity, KDE, > Enlightenment and more) This seems to be fixed for the most part. The remaining parts seem a lot of effort. I would postpone to 1.4. > 760998: resync with systemd upstream code before 1.2 (I just did that recently, but let's keep this as a reminder to resync again as 1.2 gets closer. This bug is never really fixed, but should be done from time to time). I agree with all the rest. thank you, 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
nm-1-2 blocker cleanup
Hi, with the 1.2 release approaching, we need to decide on which bugs set for 1.2 milestone need to block the release. No new features should remain in the list, only things that absolutely need to be fixed before the release such as regressions. I propose that these should be retargetted for nm-1.4: 683206: maximize device availability (IFF_UP/IFF_LOWER_UP) for IPv6 link-local communication during runtime and after exit 699843: leave interface configuration when removing from NM management 708829: dnssec: support per-connection DNSSEC options for local zones 699810: dns: support for unbound with split DNS and DNSSEC 746440: improve behavior for assumed and unmanaged devices, do better at seamless take over, and don't touch devices 760907: fix handling of invalid connections in libnm/libnm-glib And I think these should remain blocking 1.2: 697370: live reconfiguration of NMDevices 736406: NetworkManager.service should use KillMode=mixed 740574: support appindicator based systrays (found in Unity, KDE, Enlightenment and more) 740739: cannot activate shared connection on physically disconnected ethernet 748302: [review] lr/cli-add-master: Make it possible to specify master connection/device for any connection profile 760998: resync with systemd upstream code before 1.2 761389: don't mess with interface handled by clatd 762322: reapply does not restore IP configuration 762331: revert behavioral change for NM_UNMANAGED_USER_CONFIG being overwritable by USER_EXPLICIT 762333: ensure autoconnection does not make a device !NM_UNMANAGED_USER_EXPLICT 341323: [ENH] Verify subject of remote certificate [See dependency tree for bug 341323] This is of course not a definitive selection; I'm just asking for your input at this point. Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFC: Network namespaces in NM
On 21.02.2016 16:39, Thomas Haller wrote: > On Sat, 2016-02-20 at 18:12 +0100, Stjepan Groš wrote: >> On 20.02.2016 00:39, Thomas Haller wrote: >>> On Thu, 2016-02-04 at 12:21 +0100, Stjepan Groš wrote: Hi! Is anyone working on network namespaces support in NetworkManager? Or was thinking what is a "proper way" of implementing them? I'm experimenting with adding support to NM and what I implemented so far is: 1. Added objects NMNetnsController which would control all network namespaces managed by NM. 2. Each network namespace is represented with an object NMNetns and exposed on DBus. There are no methods so far but only a property name which contains network namespace's name on the filesystem. 3. NMNetnsController exposes object NetworkNamespacesController with methods AddNetworkNamepace and ListNetworkNamespaces. The first one take a name as an argument and creates a new (iproute2 compatible) network namespace, while the second one provides a list of existing namespaces. 4. When new network namespace is created (using AddNetworkNamepace method) a new, private, platform layer is instantiated and loopback interface within namespace activated. Note that new platform layer has to be created because once a socket is opened in one network namespace it is bound to the given namespace no matter which namespace is active so current singleton object wouldn't work without heavy refactoring! What I intend to do next is: 1. NM has to monitor devices/IP addresses in new network namespaces properly. 2. Methods that would allow an IPv4 or IPv6 address to be assigned in some network namespace. All the code is here: https://github.com/sgros/MIF_NetworkManager and since this is PoC, there are A LOT OF BUGS AND MISSING FEATURES. So, what do you think? Any comments, suggestions, critiques, etc? SG P.S. To be able to run patched NM you also need patched libndp library available here: https://github.com/sgros/MIF_libndp >>> Hi Sjepan, >>> >>> >>> I think adding namespace support to platform needs to be more >>> elaborate. There is also udev, ethtool, sysctl, which must be >>> considered and the NMPlatform instance must transparently switch >>> namespace as needed. >>> >>> I did that here: >>> https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=t >>> h/platform-netns >> I agree that it should be a bit more thought out. That's the reason I >> still consider my approach to be experimental. >> >> If I got it right, you made NMPlatform object network namespace aware >> and you still have a single NMPlatform object (singleton)? > NMPlatform is a singleton in the sense that there exists a > nm_platform_get() function which returns a particular (singleton) > instance and most callers use that function. But NMPlatform can already > completely be used non-singleton-style. If any caller wishes to use a > different platform instance then the "default" singleton, he can > already do so. Yes, I changed the call nm_platform_get() (and NM_PLATFORM_GET) into nm_netns_get_platform(), which returns platform specific to some network namespace. The exception is NMManager object which manages root network namespace for which "singleton" (or main) is still valid. Also, there are few corner cases while objects are constructed that required me to change initialization process and in one case return main platform object if particular network namespace's platform object isn't fully initialized yet. > I agree with your change to let NMDevice have distinct platform > instances instead of using the singleton instance. > >> Where do you intend to introduce management of network namespaces, >> e.g. where will you create/delete them? > A NMPlatform instance entirely lives inside a namespace (because it > basically wraps the platform cache and the netlink socket -- both > contain information that is only relevant within one namespace. > Theoretically, NMPlatform could be multi-namespace, but then it would > need an entirely different (namespace aware) API and one cache per > namespace. Which would make platform even more complex. It's cleaner > and simpler to have NMPlatform not multi-namespace. > > Thus creating and management of namespaces should be done outside of > NMPlatform. nm_platform_netns_create() is not so nice, because > something *inside* the namespace should not create another namespace. Fully agree with this. > > On th/platform-netns, creation is done via nmp_netns_new(). > Switching via nmp_netns_push()/nmp_netns_pop(), and deletion via > nmp_netns_unref(). I didn't look at nmp object, and still don't know the exact purpose it is used for. It seemed to me as something internal to platform and
