Re: [PATCH 1/1] initscript: remove all distribution initscripts
Am 01.12.2015 um 19:22 schrieb Thomas Haller: > These initscripts weren't modified for a long time. Are they > just unused or flawless? It seems they are no longer best-practice > (e.g. NetworkManager supports reloading configuration with SIGHUP, > which only x implement). > > Nowadays some distributions moved to systemd and quite possible > nobody uses these scripts. Also, any potential downstream user > already has a (probably modified) copy of these initscripts. > > Just remove them. ok from the Debian/Ubuntu side. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/1] initscript: remove all distribution initscripts
These initscripts weren't modified for a long time. Are they
just unused or flawless? It seems they are no longer best-practice
(e.g. NetworkManager supports reloading configuration with SIGHUP,
which only x implement).
Nowadays some distributions moved to systemd and quite possible
nobody uses these scripts. Also, any potential downstream user
already has a (probably modified) copy of these initscripts.
Just remove them.
---
.gitignore| 5 +-
configure.ac | 7 --
initscript/Arch/networkmanager.in | 67
initscript/Debian/NetworkManager.in | 91
initscript/Mandriva/networkmanager.in | 107 --
initscript/RedHat/NetworkManager.in | 104 -
initscript/SUSE/networkmanager.in | 51 --
initscript/Slackware/rc.networkmanager.in | 92 -
initscript/linexa/networkmanager.in | 59
9 files changed, 2 insertions(+), 581 deletions(-)
delete mode 100644 initscript/Arch/networkmanager.in
delete mode 100755 initscript/Debian/NetworkManager.in
delete mode 100644 initscript/Mandriva/networkmanager.in
delete mode 100755 initscript/RedHat/NetworkManager.in
delete mode 100644 initscript/SUSE/networkmanager.in
delete mode 100644 initscript/Slackware/rc.networkmanager.in
delete mode 100644 initscript/linexa/networkmanager.in
diff --git a/.gitignore b/.gitignore
index d6a956c..6629338 100644
--- a/.gitignore
+++ b/.gitignore
@@ -139,9 +139,6 @@ test-*.trs
/include/nm-version-macros.h
-/initscript/Slackware/rc.networkmanager
-/initscript/*/[Nn]etwork[Mm]anager
-
/introspection/all.xml
/introspection/nmdbus-*.c
/introspection/nmdbus-*.h
@@ -276,5 +273,7 @@ test-*.trs
# but they were on older versions. Thus keep ignoring them
# otherwise when switching branches these untracked files show
# up.
+/initscript/Slackware/rc.networkmanager
+/initscript/*/[Nn]etwork[Mm]anager
/src/settings/plugins/ifnet/tests/check_ifnet
diff --git a/configure.ac b/configure.ac
index c028f32..112f4e5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1061,13 +1061,6 @@ clients/Makefile
clients/cli/Makefile
clients/tui/Makefile
clients/tui/newt/Makefile
-initscript/RedHat/NetworkManager
-initscript/Debian/NetworkManager
-initscript/Slackware/rc.networkmanager
-initscript/SUSE/networkmanager
-initscript/Arch/networkmanager
-initscript/Mandriva/networkmanager
-initscript/linexa/networkmanager
introspection/Makefile
introspection/all.xml
man/Makefile
diff --git a/initscript/Arch/networkmanager.in
b/initscript/Arch/networkmanager.in
deleted file mode 100644
index 4846427..000
--- a/initscript/Arch/networkmanager.in
+++ /dev/null
@@ -1,67 +0,0 @@
-#!/bin/bash
-
-prefix=@prefix@
-exec_prefix=@prefix@
-sbindir=@sbindir@
-
-NETWORKMANAGER_BIN=${sbindir}/NetworkManager
-
-# general config
-. /etc/rc.conf
-. /etc/rc.d/functions
-
-# Sanity checks.
-[ -x $NETWORKMANAGER_BIN ] || exit 0
-
-PID=`pidof -o %PPID $NETWORKMANAGER_BIN`
-case "$1" in
- start)
- stat_busy "Starting NetworkManager"
- [ ! -d /var/run/NetworkManager ] && install -d
/var/run/NetworkManager
- if [ -z "$PID" ]; then
- $NETWORKMANAGER_BIN
- fi
- if [ ! -z "$PID" -o $? -gt 0 ]; then
- stat_fail
- else
- add_daemon networkmanager
- stat_done
- fi
- ;;
- stop)
- stat_busy "Stopping NetworkManager"
- [ ! -z "$PID" ] && kill $PID &> /dev/null
- if [ $? -gt 0 ]; then
- stat_fail
- else
- rm_daemon networkmanager
- stat_done
- fi
- ;;
- restart)
- $0 stop
- sleep 1
- $0 start
- ;;
- sleep)
- /usr/bin/dbus-send --system \
- --dest=org.freedesktop.NetworkManager \
- --type=method_call \
- /org/freedesktop/NetworkManager \
- org.freedesktop.NetworkManager.sleep
- ;;
- wake)
- /usr/bin/dbus-send --system \
- --dest=org.freedesktop.NetworkManager \
- --type=method_call \
- /org/freedesktop/NetworkManager \
- org.freedesktop.NetworkManager.wake
- ;;
- *)
- echo "usage: $0 {start|stop|restart|sleep|wake}"
- ;;
-esac
-exit 0
-
-
-
diff --git a/initscript/Debian/NetworkManager.in
b/initscript/Debian/NetworkManager.in
deleted file mode 100755
index 9cc254e..000
--- a/initscript/Debian/NetworkManager.in
+++ /dev/null
@@ -1,91 +0,0 @@
-#! /bin/sh
-### BEGIN INIT INFO
-# Provides: Ne
Re: MC 7304 ipv4v6 - now works in (my) test environment
Am Montag, 30. November 2015, 13:23:43 schrieb Bjørn Mork: > I guess it's too late now, but testing this with MM is actually much > easier. I was able to successfully change the mode after MM had opened > the device by using > > qmicli -p -d /dev/cdc-wdm1 --device-open-net='net-raw-ip|net-no-qos-header' > --get-service-version-info > > in aother terminal. This must be done after MM probes and opens the > modem, but before connecting. From NM to MM to libqmi to kernel-driver and back. Thank your for the great support and the patience. ( especially for the people thinking the thread tends to go off topic) Today I was able to connect the MC 7304 via dualstack. (the huawei E398 did also work, just for reference) It was a little bit tricky (crazy?), but it did work reproducable. After switching in raw-mode - via side loading the ModemManager. echo 1 > /sys/ raw_ip and qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' -- get-service-version-info I made the connection via NetworkManager. Ironically IPv6 worked better than IPv4. NM was setting addresses, routes and DNS for IPv6. For IPv4 I had to do some things manually. I have got all information - via different ways for IPv4 and IPv6. But in the end - raw ip is the/one solution for that device and maybe for some other. hpmini:~ # mmcli -b 0 Bearer '/org/freedesktop/ModemManager1/Bearer/0' - Status | connected: 'yes' | suspended: 'no' | interface: 'wwan0' | IP timeout: '20' - Properties | apn: 'internet.telekom' | roaming: 'allowed' | IP type: 'ipv4v6' |user: 'tm' |password: 'none' | number: '*99#' | Rm protocol: 'unknown' - IPv4 configuration | method: 'dhcp' | address: 'unknown' | prefix: '0' | gateway: 'unknown' | DNS: none | MTU: '1430' - IPv6 configuration | method: 'dhcp' | address: '2a01:598:b000:1afd:7cfd:efcb:c7:c156' | prefix: '64' | gateway: '2a01:598:b000:1afd:347e:fc7a:f0c1:c014' | DNS: '2a01:598:7ff:0:10:74:210:210' | MTU: '1430' hpmini:~ # qmicli -p -d /dev/cdc-wdm0 --wds-get-current-settings [/dev/cdc-wdm0] Current settings retrieved: IP Family: IPv4 IPv4 address: 10.18.88.31 IPv4 subnet mask: 255.255.255.192 IPv4 gateway address: 10.18.88.1 IPv4 primary DNS: 10.74.210.210 IPv4 secondary DNS: 10.74.210.211 MTU: 1430 Domains: none 8: wwan0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/none inet 10.18.88.31/26 scope global wwan0 valid_lft forever preferred_lft forever inet6 2a01:598:b000:1afd:62df:7a2c:4772:e492/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2a01:598:b000:1afd:2f09:788a:f047:7c27/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2a01:598:b000:1afd:d6c7:24fe:cddd:bcc5/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2a01:598:b000:1afd:6a6b:6c6b:7d2a:1177/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2a01:598:b000:1afd:7a4:e8ba:6a45:a976/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2a01:598:b000:1afd:a22:970e:6746:dab5/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 2a01:598:b000:1afd:7cfd:efcb:c7:c156/64 scope global valid_lft forever preferred_lft forever inet6 fe80::a68d:ed6:2082:861f/64 scope link valid_lft forever preferred_lft forever Regards, Thomas Schäfer ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-applet SIGSEGV
你好 network-manager-applet-1.2.0-0.9.20151119gitbc8a795.fc24.x86_64 coredumpctl gdb: PID: 1676 (nm-applet) Signal: 11 (SEGV) Command Line: nm-applet Executable: /usr/bin/nm-applet Message: Process 1676 (nm-applet) of user 1000 dumped core. Stack trace of thread 1676: #0 0x7fb4349630bd g_type_check_instance_is_fundamentally_a (libgobject-2.0.so.0) #1 0x7fb4349427e7 g_object_unref (libgobject-2.0.so.0) #2 0x558638143747 nma_clear_icon (/usr/bin/nm-applet (deleted)) #3 0x5586381443be nma_icons_free (/usr/bin/nm-applet (deleted)) #4 0x7fb43493d995 g_closure_invoke (libgobject-2.0.so.0) #5 0x7fb434950511 signal_emit_unlocked_R (libgobject-2.0.so.0) #6 0x7fb4349594c0 g_signal_emit_valist (libgobject-2.0.so.0) #7 0x7fb43495988f g_signal_emit (libgobject-2.0.so.0) #8 0x7fb4364f2de4 theme_changed_idle (libgtk-3.so.0) #9 0x7fb43606f188 gdk_threads_dispatch (libgdk-3.so.0) #10 0x7fb43443907a g_main_context_dispatch (libglib-2.0.so.0) #11 0x7fb434439410 g_main_context_iterate.isra.29 (libglib-2.0.so.0) #12 0x7fb434439732 g_main_loop_run (libglib-2.0.so.0) #13 0x55863814358d main (/usr/bin/nm-applet (deleted)) #14 0x7fb433e2b780 __libc_start_main (libc.so.6) #15 0x5586381435e9 _start (/usr/bin/nm-applet (deleted)) Core was generated by `nm-applet'. Program terminated with signal SIGSEGV, Segmentation fault. #2 0x558638143747 in nma_clear_icon (icon=0x558639673c68, applet=) at applet.c:3058 __FUNCTION__ = "nma_clear_icon" #3 0x5586381443be in nma_icons_free (applet=) at applet.c:3068 i = 1 #4 nma_icons_reload (applet=0x558639673b90) at applet.c:3113 error = 0x0 loader = __FUNCTION__ = "nma_icons_reload" #9 0x7fb4364f2de4 in theme_changed_idle (user_data=) at gtkicontheme.c:770 icon_theme = priv = 0x558639673b20 #10 0x7fb43606f188 in gdk_threads_dispatch (data=0x55863972de40) at gdk.c:719 dispatch = 0x55863972de40 ret = 0 #14 0x55863814358d in main (argc=1, argv=0x7ffe943ebf48) at main.c:84 applet = 0x5586396630a0 i = How to reproduce, sometimes it's enough to re-log, sometimes intermediate step "xfwm4 --replace &" is involved. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MC 7304 ipv4v6
Reinhard Speyerer writes: > On Mon, Nov 30, 2015 at 10:53:35AM +0100, Bjørn Mork wrote: > >> hmm, "fixing" this seems simple enough: Just add the necessary code to >> net/ipv6/addrconf.c for handling ARPHRD_NONE devices. But I have two >> questions: >> >> 1) will random addresses be a problem? We might have to recreate the >> address every time the interface comes up, as we have nowhere to store >> it AFAICS. So the link-local address will change whenever you toggle >> the device down/up. > > This might invalidate some fundamental assumptions in the firmware about > the host environment. My suggestion would therefore be to avoid changing > the link-local address when changing the network interface up/down status. Yes. That's definitely so unexpected that it's better not to implement it at all.. >> 2) what about other ARPHRD_NONE devices? This is currently 'tun', 'hso' >> and 'n_gsm'. Will a default IPv6 link local address be a problem for >> any of these? >> >> The only device type I know how to test is 'tun'. And to me it looks >> like an obvious winner there. Why shouldn't tun devices do SLAAC and >> support other IPv6 link local services by default? But I don't normally >> use such devices, so I know very little about real use cases... > > Since tun may have non-IP use cases and n_gsm is a line discipline AFAIK > we should probably not overload ARPHRD_NONE like this. I'm not sure that would be a problem, any more than using ethernet for non-IP is one. >> If we can't add such generic ARPHRD_NONE code, then the alternatives I >> can see are >> - defined an new ARPHRD_ type with about the same semantics, and add >>ipv6/addrconf code for it >> - do some driver hack - I believe it is possible to manually create an >>IPv6 device and assign an address from the driver. >> >> I don't like either. So I guess I will propose the ARPHRD_NONE code. >> > > Perhaps it might be possible to use raw IP mode with IPv6 without a > link-local address by using WDS status indications? It's definitely possible to use raw IP with IPv6 without a link local address. But I don't think it should be :) > The reason I used > the original ifconfig inet6 up implementation was that this was > required to trigger SLAAC according to ETSI/3GPP TS 27.060 for early > MC77xx firmware versions as WDSGetCurrentSettings did not return an > IPv6 prefix when WDSStartNetwork was finished. > > However at least current MC73xx firmware versions (and perhaps also > other "modern" QMI firmwares) now proactively perform an internal SLAAC > after a WDSStartNetwork and WDSGetCurrentSettings returns the same IPv6 > prefix as an ifconfig inet6 up with SLAAC in Ethernet mode would. If > mReconfigureRequired from the WDSPacketServiceStatusReport TLV 0x01 > would correctly indicate when the IPv6 prefix assigned from the > network has changed it might be possible to mirror the effect of SLAAC > for raw IP from user space. Yes, I know that the prefix could change - in theory. I have my doubts whether that would actually work in the real world. The status is about the same as for IPv6 renumbering elsewhere: All the necessary tools are there so you can make it work, but every user and device have made some bogus assuption that needs fixing first. I don't think we are any more guaranteed that renumbering will work with SLAAC than without. The chances are about the same. And I believe the good NM people will want to do SLAAC in userspace anyway. So the missing link local address might be a non-issue for NM? In any case, I got very helpful feedback from YOSHIFUJI Hideaki so I am considering implementing a random (but permanent) ifid allocation scheme after all. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
