Re: NM can't see WEP access point
On Fri, 2016-06-10 at 10:11 -0500, Dan Williams wrote:
>
> Jouni confirmed that there is a bug in the supplicant. The
> commit ce8963fc9f197771cd51ba2834fbdf711189641a ('Remove WEP40/WEP104
> cipher suite support for WPA/WPA2') appears to have broken this
> functionality (where the AP advertises WEP support in WPA/RSN IEs),
> but
> it will still work for WEP-only APs. Not sure what his solution will
> be, since this behavior (TSN) is technically allowed by the standards
> for WPA1 (but not necessarily for WPA2/RSN, I believe).
>
> We should likely also modify NM to not reject the AP if the RSN IE
> fails to parse, but to simply ignore WPA2/RSN on that AP and only
> allow
> using TKIP, if present. If the RSN IE fails to parse and the AP does
> not support TKIP, then NM should correctly reject the AP, since
> RSN+WEP
> is not really a valid mode.
The only WEP-equivalent mode on the Airport Express (gen 1) I have is
labeled as "WEP (Transitional Security Network)".
I'll have to see how to set up a hotspot with WEP some other way for my
testing I think.
Cheers
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM can't see WEP access point
On Thu, 2016-06-09 at 10:23 -0500, Dan Williams wrote: > On Thu, 2016-06-09 at 17:13 +0200, Bastien Nocera wrote: > > On Thu, 2016-06-09 at 10:00 -0500, Dan Williams wrote: > > > > > > > > > > > > > > So I missed it before. But your AP isn't actually set for WEP, > > > it's > > > set for WPA/TKIP. If it's actually using just WEP, you won't see > > > any > > > of the RSN/WPA IEs in the beacon. > > Still isn't right that it's not showing though, is it? > > Yeah. Can you 'nmcli g log', then: > > nmcli g log level debug domains domains>,WIFI_SCAN > > and then turn on airplane mode, turn it off, and wait for a bit until > you're sure the AP doesn't get found by NM. Then send me the logs > and > I'll take a look to see if I can figure out why NM doesn't find it. > If > the supplicant sees it, but NM does not, then there's an NM bug > somewhere. Well, wpa_supplicant is throwing an error when you try to get the RSN, so I don't really expect NM to be able to process that access point. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM can't see WEP access point
On Thu, 2016-06-09 at 10:00 -0500, Dan Williams wrote: > > So I missed it before. But your AP isn't actually set for WEP, it's > set for WPA/TKIP. If it's actually using just WEP, you won't see any > of the RSN/WPA IEs in the beacon. Still isn't right that it's not showing though, is it? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM can't see WEP access point
On Tue, 2016-06-07 at 19:13 +0200, Bastien Nocera wrote:
> On Tue, 2016-06-07 at 09:58 -0500, Dan Williams wrote:
> > On Tue, 2016-06-07 at 16:09 +0200, Bastien Nocera wrote:
> > > Hey,
> > >
> > > iwlist scan as root shows:
> > > Cell 17 - Address: 00:24:36:9D:3B:33
> > > Channel:11
> > > Frequency:2.462 GHz (Channel 11)
> > > Quality=70/70 Signal level=-32 dBm
> > > Encryption key:on
> > > ESSID:"WEP test"
> > > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s;
> > > 6
> > > Mb/s
> > > 9 Mb/s; 12 Mb/s; 18 Mb/s
> > > Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
> > > Mode:Master
> > > Extra:tsf=0069f3b5fd9a
> > > Extra: Last beacon: 27430ms ago
> > > IE: Unknown: 00085745502074657374
> > > IE: Unknown: 010882848B960C121824
> > > IE: Unknown: 03010B
> > > IE: Unknown: 0706474220010D1E
> > > IE: Unknown: 2A0100
> > > IE: Unknown: 32043048606C
> > > IE: IEEE 802.11i/WPA2 Version 1
> > > Group Cipher : WEP-104
> > > Pairwise Ciphers (2) : CCMP TKIP
> > > Authentication Suites (1) : PSK
> > > IE: Unknown:
> > > 2D1A2C401700
> > > IE: Unknown:
> > > 3D160B001100
> > > IE: Unknown: 4605020001
> > > IE: WPA Version 1
> > > Group Cipher : WEP-104
> > > Pairwise Ciphers (1) : TKIP
> > > Authentication Suites (1) : PSK
> > > IE: Unknown:
> > > DD180050F2020101070003A427A442435E0062322F00
> > > IE: Unknown: DD07000393016B0B20
> > > IE: Unknown: DD0E0017F207000101060024369D3B33
> > > IE: Unknown: DD0B0017F2010001010007
> > >
> > > Which is a WEP access point created on an Airport Express gen 1
> > > device.
> > > "nmcli -f all device wifi | grep 'WEP test'" doesn't show
> > > anything
> > > related to that access point?
> > >
> > > Any ideas on how to debug this?
> >
> > It depends if the supplicant has actually exposed it via D-Bus yet
> > too.
> >
> > Grab http://people.redhat.com/dcbw/wpas-list.py and sudo-run that
> > with
> > the interface name of your wifi device, and see if the AP shows up
> > in
> > that list. It directly dumps out the supplicant's AP list in a
> > more
> > readable form.
>
> $ sudo ./wpas-list.py wlp2s0
> [sudo] password for hadess:
> 54:64:d9:3e:0e:89 :: ssid='Livebox-0E88' wpa=yes wpa2=yes signal=-58%
> freq=5240
> 18:1e:78:70:c4:6b :: ssid='Livebox-C46A' wpa=yes wpa2=yes signal=-62%
> freq=5520
> Traceback (most recent call last):
> File "./wpas-list.py", line 68, in
> main()
> File "./wpas-list.py", line 46, in main
> props = props_iface.GetAll(WPAS_DBUS_BSSID_INTERFACE)
> File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 70, in
> __call__
> return self._proxy_method(*args, **keywords)
> File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in
> __call__
> **keywords)
> File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: failed to
> parse RSN IE
After adding a try/except:
failed for /fi/w1/wpa_supplicant1/Interfaces/3/BSSs/2
Which is the "WEP test" AP I used.
$ sudo gdbus introspect --system --dest fi.w1.wpa_supplicant1 --object-path
/fi/w1/wpa_supplicant1/Interfaces/3/BSSs/2
interface fi.w1.wpa_supplicant1.BSS {
methods:
signals:
PropertiesChanged(a{sv} properties);
properties:
readonly ay SSID = [0x57, 0x45, 0x50, 0x20, 0x74, 0x65, 0x73, 0x74];
readonly ay BSSID = [0x00, 0x24, 0x36, 0x9d, 0x3b, 0x33];
readonly b Privacy = true;
readonly s Mode = 'infrastructure';
readonly n Signal = -35;
r
Re: nm-connection-editor forgets WPA password
On Tue, 2016-06-07 at 19:29 +0200, Thomas Haller wrote: > On Tue, 2016-06-07 at 19:10 +0200, Bastien Nocera wrote: > > Hey, > > > > I get problems when trying this with both nm-connection-editor and > > gnome-control-center, so it's probably a problem in the common > > code. > > > > 1. Connect to a known wireless network with WPA/WPA2 Personal > > authentication > > 2. Once connected, edit the connection > > 3. In "Wi-Fi Security" select "Dynamic WEP", then "Tunneled TLS" as > > the > > authentication, enter bogus values in "anonymous identity", > > "username" > > and password". Tick the "No CA certificate is required" checkbox. > > 4. "nmcli connection down " > > 5. "nmcli connection up " (you can press Ctrl+C when > > you're bored) > > 6. Re-edit the connection > > 7. Select WPA/WPA Personal in "Wi-Fi Security", and put in the > > actual > > Wi-Fi password > > 8. Run "nmcli connection up " again > > > > " > > Passwords or encryption keys are required to access the wireless > > network 'test'. > > Warning: password for '802-11-wireless-security.psk' not given in > > 'passwd-file' and nmcli cannot ask without '--ask' option. > > " > > > > It will then ask for the password in a loop, and never allow > > connection. > > > > Ideas? Do you prefer this being filed in bugzilla? > > > > > could this be > https://git.gnome.org/browse/network-manager-applet/commit/?id=c21d56 > dd22057103c8125a49307b4ff47b5b644d I've moved the bug to: https://bugzilla.gnome.org/show_bug.cgi?id=767449 Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: How to get GPS NMEA in C from ModemManager?
On Tue, 2016-06-07 at 16:10 -0500, Dan Williams wrote: > On Tue, 2016-06-07 at 13:40 -0700, serena dadak wrote: > > hello there > > > > Is there any sample code to get NMEA strings from MM in C? > > I looked at the example codes in NM but didn't have much luck on > > finding > > samples for GPS. > > You'd use the libdbus C bindings or (easier) glib-based ones with > GDBus. For example, raw libdbus looks like this: > > http://maemo.org/development/training/maemo_platform_development_cont > ent/plain_html/node10/ > > and it isn't exactly pretty. Using a binding, whether that's dbus- > glib, dbus-qt, GDBus, or something else is usually a lot easier. Or use geoclue, and get all that for free: https://www.freedesktop.org/software/geoclue/docs/libgeoclue/GClueSimple.html Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor forgets WPA password
On Tue, 2016-06-07 at 19:29 +0200, Thomas Haller wrote: > On Tue, 2016-06-07 at 19:10 +0200, Bastien Nocera wrote: > > Hey, > > > > I get problems when trying this with both nm-connection-editor and > > gnome-control-center, so it's probably a problem in the common > > code. > > > > 1. Connect to a known wireless network with WPA/WPA2 Personal > > authentication > > 2. Once connected, edit the connection > > 3. In "Wi-Fi Security" select "Dynamic WEP", then "Tunneled TLS" as > > the > > authentication, enter bogus values in "anonymous identity", > > "username" > > and password". Tick the "No CA certificate is required" checkbox. > > 4. "nmcli connection down " > > 5. "nmcli connection up " (you can press Ctrl+C when > > you're bored) > > 6. Re-edit the connection > > 7. Select WPA/WPA Personal in "Wi-Fi Security", and put in the > > actual > > Wi-Fi password > > 8. Run "nmcli connection up " again > > > > " > > Passwords or encryption keys are required to access the wireless > > network 'test'. > > Warning: password for '802-11-wireless-security.psk' not given in > > 'passwd-file' and nmcli cannot ask without '--ask' option. > > " > > > > It will then ask for the password in a loop, and never allow > > connection. > > > > Ideas? Do you prefer this being filed in bugzilla? > > > > > could this be > https://git.gnome.org/browse/network-manager-applet/commit/?id=c21d56 > dd22057103c8125a49307b4ff47b5b644d No, that's already in my tree. It asks for a password repeatedly, even when it is correct. I think that NetworkManager might think it's a different kind of connection compared to what nm-connection-editor thinks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM can't see WEP access point
On Tue, 2016-06-07 at 09:58 -0500, Dan Williams wrote: > On Tue, 2016-06-07 at 16:09 +0200, Bastien Nocera wrote: > > Hey, > > > > iwlist scan as root shows: > > Cell 17 - Address: 00:24:36:9D:3B:33 > > Channel:11 > > Frequency:2.462 GHz (Channel 11) > > Quality=70/70 Signal level=-32 dBm > > Encryption key:on > > ESSID:"WEP test" > > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 > > Mb/s > > 9 Mb/s; 12 Mb/s; 18 Mb/s > > Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s > > Mode:Master > > Extra:tsf=0069f3b5fd9a > > Extra: Last beacon: 27430ms ago > > IE: Unknown: 00085745502074657374 > > IE: Unknown: 010882848B960C121824 > > IE: Unknown: 03010B > > IE: Unknown: 0706474220010D1E > > IE: Unknown: 2A0100 > > IE: Unknown: 32043048606C > > IE: IEEE 802.11i/WPA2 Version 1 > > Group Cipher : WEP-104 > > Pairwise Ciphers (2) : CCMP TKIP > > Authentication Suites (1) : PSK > > IE: Unknown: > > 2D1A2C401700 > > IE: Unknown: > > 3D160B001100 > > IE: Unknown: 4605020001 > > IE: WPA Version 1 > > Group Cipher : WEP-104 > > Pairwise Ciphers (1) : TKIP > > Authentication Suites (1) : PSK > > IE: Unknown: > > DD180050F2020101070003A427A442435E0062322F00 > > IE: Unknown: DD07000393016B0B20 > > IE: Unknown: DD0E0017F207000101060024369D3B33 > > IE: Unknown: DD0B0017F2010001010007 > > > > Which is a WEP access point created on an Airport Express gen 1 > > device. > > "nmcli -f all device wifi | grep 'WEP test'" doesn't show anything > > related to that access point? > > > > Any ideas on how to debug this? > > It depends if the supplicant has actually exposed it via D-Bus yet > too. > > Grab http://people.redhat.com/dcbw/wpas-list.py and sudo-run that > with > the interface name of your wifi device, and see if the AP shows up in > that list. It directly dumps out the supplicant's AP list in a more > readable form. $ sudo ./wpas-list.py wlp2s0 [sudo] password for hadess: 54:64:d9:3e:0e:89 :: ssid='Livebox-0E88' wpa=yes wpa2=yes signal=-58% freq=5240 18:1e:78:70:c4:6b :: ssid='Livebox-C46A' wpa=yes wpa2=yes signal=-62% freq=5520 Traceback (most recent call last): File "./wpas-list.py", line 68, in main() File "./wpas-list.py", line 46, in main props = props_iface.GetAll(WPAS_DBUS_BSSID_INTERFACE) File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 70, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in __call__ **keywords) File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: failed to parse RSN IE Ungood. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-connection-editor forgets WPA password
Hey, I get problems when trying this with both nm-connection-editor and gnome-control-center, so it's probably a problem in the common code. 1. Connect to a known wireless network with WPA/WPA2 Personal authentication 2. Once connected, edit the connection 3. In "Wi-Fi Security" select "Dynamic WEP", then "Tunneled TLS" as the authentication, enter bogus values in "anonymous identity", "username" and password". Tick the "No CA certificate is required" checkbox. 4. "nmcli connection down " 5. "nmcli connection up " (you can press Ctrl+C when you're bored) 6. Re-edit the connection 7. Select WPA/WPA Personal in "Wi-Fi Security", and put in the actual Wi-Fi password 8. Run "nmcli connection up " again " Passwords or encryption keys are required to access the wireless network 'test'. Warning: password for '802-11-wireless-security.psk' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. " It will then ask for the password in a loop, and never allow connection. Ideas? Do you prefer this being filed in bugzilla? Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NM can't see WEP access point
Hey, iwlist scan as root shows: Cell 17 - Address: 00:24:36:9D:3B:33 Channel:11 Frequency:2.462 GHz (Channel 11) Quality=70/70 Signal level=-32 dBm Encryption key:on ESSID:"WEP test" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=0069f3b5fd9a Extra: Last beacon: 27430ms ago IE: Unknown: 00085745502074657374 IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 0706474220010D1E IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : WEP-104 Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 2D1A2C401700 IE: Unknown: 3D160B001100 IE: Unknown: 4605020001 IE: WPA Version 1 Group Cipher : WEP-104 Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: Unknown: DD180050F2020101070003A427A442435E0062322F00 IE: Unknown: DD07000393016B0B20 IE: Unknown: DD0E0017F207000101060024369D3B33 IE: Unknown: DD0B0017F2010001010007 Which is a WEP access point created on an Airport Express gen 1 device. "nmcli -f all device wifi | grep 'WEP test'" doesn't show anything related to that access point? Any ideas on how to debug this? NetworkManager-wifi-1.2.2-2.fc24.x86_64 NetworkManager-1.2.2-2.fc24.x86_64 kernel-4.7.0-0.rc0.git6.1.fc25.x86_64 Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] device: prefer wifi over wwan by default
On Wed, 2015-07-22 at 18:29 +0200, Jean-Christian de Rivaz wrote: Le 22. 07. 15 17:56, Dan Williams a écrit : On Wed, 2015-07-22 at 10:53 +0200, Lubomir Rintel wrote: On Tue, 2015-07-21 at 11:37 +0200, Tore Anderson wrote: This makes wifi preferred to wwan (the modem and bluetooth device types to be specific) by default, so that users that care about being connected at all times can keep both enabled with auto-connect. As wifi is usually unmetered and often faster than wwan, it makes sense to prefer it. This is also how pretty much every smart-phone in the world behaves, so it aligns better with user expectations too. https://bugzilla.gnome.org/show_bug.cgi?id=744754 --- src/devices/nm-device.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c index eba15a3..332182a 100644 --- a/src/devices/nm-device.c +++ b/src/devices/nm-device.c @@ -721,14 +721,14 @@ nm_device_get_priority (NMDevice *self) return 400; case NM_DEVICE_TYPE_BRIDGE: return 425; - case NM_DEVICE_TYPE_MODEM: - return 450; - case NM_DEVICE_TYPE_BT: - return 550; case NM_DEVICE_TYPE_WIFI: return 600; case NM_DEVICE_TYPE_OLPC_MESH: return 650; + case NM_DEVICE_TYPE_MODEM: + return 700; + case NM_DEVICE_TYPE_BT: + return 750; case NM_DEVICE_TYPE_GENERIC: return 950; case NM_DEVICE_TYPE_UNKNOWN: Thank you. Applied to master 1.0 stable branch. I'm OK with this too, though the original idea was that more intentional connections would be preferred. eg, WWAN is a lot less automatic than WiFi, and often costs you more money, thus if you activate a WWAN device you probably want to use it... Hi Dan, As a user I have to disagree with your doubt on this welcome change. While WiFi at least imply that the user select an SSID, there exists SIM cards that are delivered configured to not require a PIN code or a APN password from the user. This make the cellular modem connection even 'less intentional' than a WiFi connection from a user point of view. Still the cellular modem is far more costly than the WiFi, so it's logic to select the WiFi over the cellular modem by default. As a traveler, I alway want to select the WiFi over the cellular modem even if the cellular modem is fully configured, to obviously avoid a much as possible the cellular modem roaming cost when a nearby WiFI provides a good enough internet access. Can't understand why it was not the default from the beginning. I'll add that if and when we get access to EAP-SIM support, a number of Wi-Fi hotspots will be able to use the SIM card as a mean of authentication. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] device: prefer wifi over wwan by default
On Wed, 2015-07-22 at 20:04 +0200, Tore Anderson wrote: snip While WiFi at least imply that the user select an SSID, there exists SIM cards that are delivered configured to not require a PIN code or a APN password from the user. This reminded me of something I've been wondering about for a while: What is the reason why NM asks me to select country, provider, APN and so on when connecting to mobile broadband for the first time? It seems kind of user-unfriendly - MM/NM knows my operator's MCC/MNC (can be seen in mmcli -m 0 -i 0), which can be used to immediately locate the correct provider block in serviceproviders.xml. Assuming there's only one data APN present in that provider block, it could simply be used by default without asking anything. Completely agree there :) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] device: prefer wifi over wwan by default
On Tue, 2015-07-21 at 11:37 +0200, Tore Anderson wrote: This makes wifi preferred to wwan (the modem and bluetooth device types to be specific) by default, so that users that care about being connected at all times can keep both enabled with auto-connect. As wifi is usually unmetered and often faster than wwan, it makes sense to prefer it. This is also how pretty much every smart-phone in the world behaves, so it aligns better with user expectations too. Obviously, +1 ! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Why is NM preferring wwan over wifi?
On Sun, 2015-06-14 at 10:10 +0200, Tore Anderson wrote: I've noticed that a default route on a wifi network is assigned a default metric of 600, while a default route on a wwan connection gets a default metric of 450. The effect of this is that the host will prefer to use wwan over wifi when both are enabled. That's the exact opposite of what I'd expect (based on precedent set by pretty much every smart-phone in the world). While I can easily set different route-metrics on the connections in question, I'm just wondering whether or not this order of preference is really intentional? Curiously enough, when both wifi and wwan are connected, the nm-applet's systray will display the wifi icon (not the wwan one with the little antenna), tricking me into believing that the wifi is indeed the active connection. Completely agree with you, which is why I filed that as a bug: https://bugzilla.gnome.org/show_bug.cgi?id=744754 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connman WiFi p2p API evaluation
On Thu, 2015-01-08 at 16:04 -0600, Dan Williams wrote: Hi, Thomas asked me to look at the Connman P2P/Direct APIs to see if we can share some of the interfaces. I think that's a worthwhile goal, so here's a short writeup of where the APIs stand WRT to NetworkManager's current D-Bus API. Quick question. Would the support in NM require the P2P support in the driver being handled by cfg80211? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connman WiFi p2p API evaluation
Vendor WEXT extensions do have that capability though (I recently ripped out that vendor support in a Realtek driver). On 9 Jan 2015, at 20:25, Dan Williams d...@redhat.com wrote: On Fri, 2015-01-09 at 19:01 +0100, Bastien Nocera wrote: On Thu, 2015-01-08 at 16:04 -0600, Dan Williams wrote: Hi, Thomas asked me to look at the Connman P2P/Direct APIs to see if we can share some of the interfaces. I think that's a worthwhile goal, so here's a short writeup of where the APIs stand WRT to NetworkManager's current D-Bus API. Quick question. Would the support in NM require the P2P support in the driver being handled by cfg80211? Yes. WEXT has no capabilities to handle P2P, if that's what you're asking. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager-openvpn will not connect
On Fri, 2014-07-04 at 16:05 +0200, Thomas Haller wrote: On Fri, 2014-07-04 at 11:30 +, John Frankish wrote: Using networkmanager-openvpn- 0.9.8.4 patched to use libsecret, I am unable to connect. After configuring the vpn connection using gnome-control-center, I'm prompted for the vpn password, but after entering it I get the error Connection activation failed: the VPN service failed to start. Running from the command line gives the output below. The tun module is compiled into the 3.8.13 kernel I'm using (CONFIG_TUN=y), is this the source of the error? Yes. Seems like that is the cause of the error: if (system (/sbin/modprobe tun) == -1) exit (EXIT_FAILURE); https://git.gnome.org/browse/network-manager-openvpn/tree/src/nm-openvpn-service.c#n1626 I am not sure, how to fix that best(?) Ignore errors from the system() call and check for /sys/class/misc/tun ? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Review tracker bug: https://bugzilla.gnome.org/show_bug.cgi?id=728406 (nm-review)
On Tue, 2014-04-29 at 11:59 -0500, Dan Williams wrote: Hi all, Pavel created a tracker bug for all reviews and added all the existing patch/branch review bugs that he could find. Having them all collected in one place makes it a lot easier for everyone to see the outstanding reviews and process them more quickly. Not sure why we didn't do this sooner :) Quicker than looking at the right hand-side of: https://bugzilla.gnome.org/browse.cgi?product=NetworkManager ? I guess you can still use your tracker bug for branch reviews. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPsec Road Warrior Config (Fedora 20)
On Tue, 2014-03-04 at 16:44 -0600, Dan Williams wrote: On Sat, 2014-03-01 at 11:10 -0400, Jorge Fábregas wrote: Hi, I'm in Fedora 20 and wondered if it is possible to configure an IPsec VPN client connection with Network Manager? I tried the Cisco Compatible VPN (vpnc) offered in the GUI but the Add button at the end is grayed out. I also tried installing the NetworkManager-openswan package and proceeded to configure that - in the GUI as well - but the Add button is still grayed out. Am I missing something? Which GUI are you using? If you're using the GNOME control center, then it looks like the OpenSWAN plugin might have some bugs that prevent it from working with the control center network panel. One workaround would be to use nm-connection-editor instead for now. I fixed that, but nobody merged it yet: https://bugzilla.gnome.org/show_bug.cgi?id=720319 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Release management problems
On Fri, 2014-02-07 at 17:28 +0100, Bastien Nocera wrote: snip I guess we should start hiding unstable APIs behind #defines so that Fedora users don't accidentally depend on them. Something like GLIB_VERSION_MAX_ALLOWED would be very useful indeed, and would help curb those problems. I filed https://bugzilla.gnome.org/show_bug.cgi?id=724235 Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Release management problems
Heya, We're running into trouble with the recent Team support in GNOME, as there's no backing NetworkManager release with the necessary team support: https://bugzilla.gnome.org/show_bug.cgi?id=723769 It wouldn't be that much of a problem if Fedora didn't ship git snapshots of the next NetworkManager version. Why ship git snapshots in Fedora that are apparently not good enough for full releases? Could upstream not do with testing on more than Fedora? Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Release management problems
On Fri, 2014-02-07 at 10:44 -0500, Pavel Simerda wrote: - Original Message - From: Bastien Nocera had...@hadess.net To: networkmanager-list@gnome.org Sent: Friday, February 7, 2014 9:24:16 AM Subject: Release management problems Heya, We're running into trouble with the recent Team support in GNOME, as there's no backing NetworkManager release with the necessary team support: https://bugzilla.gnome.org/show_bug.cgi?id=723769 It wouldn't be that much of a problem if Fedora didn't ship git snapshots of the next NetworkManager version. Why ship git snapshots in Fedora that are apparently not good enough for full releases? Could upstream not do with testing on more than Fedora? Sounds like a request for the Fedora NetworkManager package rather than upstream. As I understand it, the Fedora maintainers (while being NM upstream developers as well) want to keep up with the current upstream development and at the same time the current upstream development is so much ahead of the latest upstream release. But it's good enough to go in Fedora stable releases, but not as releases for all distributions to use? I don't understand that. That could improve when the 0.9.10 release is ready. We already had the same problem 6 months ago with 0.9.8. You, if I understand correctly, would prefer to only include upstream NetworkManager final releases to Fedora just to help gnome-control-center developers keep their software compatible with the latest NM release. I would prefer releases to be made for all distributions, or even better, something that syncs up with GNOME releases. I wonder whether such a rationale is a generally accepted one in Fedora. There's NetworkManager developer documentation for the released version to keep using only features existing in that release. I guess there are also non-Fedora Gnome developers who could easily do the pre-release gnome-control-center testing to ensure it can be compiled and used on a system with a released version of NetworkManager. As mentioned in the mail to Dan, something like GLIB_VERSION_MAX_ALLOWED would be useful to avoid this sort of problems, at least from the does it compile stand-point. I don't expect NM to grow the same sort of shield for its D-Bus APIs that we might be using, but for the front-ends to degrade gracefully should it happen. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Release management problems
Hey Dan, On Fri, 2014-02-07 at 11:35 +0100, Dan Winship wrote: On 02/07/2014 09:24 AM, Bastien Nocera wrote: Heya, We're running into trouble with the recent Team support in GNOME, as there's no backing NetworkManager release with the necessary team support: https://bugzilla.gnome.org/show_bug.cgi?id=723769 The bug also mentions geoclue requiring libnm-glib 0.9.9.0, but I don't see any obvious reason why it should from the sources... That seems bogus indeed, I'll check with Zeeshan. It wouldn't be that much of a problem if Fedora didn't ship git snapshots of the next NetworkManager version. Why ship git snapshots in Fedora that are apparently not good enough for full releases? Because all of the NM maintainers are also Fedora developers, and so if bugs show up, we can fix them quickly. Right, this also makes it problematic when new features are added to gnome-control-center (by NM developers, or other Fedora users such as myself) that require newer versions of NetworkManager. I don't think it would be such a problem if stable versions of Fedora used stable versions of NetworkManager. But having a git snapshot shipped in the stable release, when no other distribution gets to ship that snapshot is a bit bizarre in terms of release management (hence the subject of this thread). I guess we should start hiding unstable APIs behind #defines so that Fedora users don't accidentally depend on them. Something like GLIB_VERSION_MAX_ALLOWED would be very useful indeed, and would help curb those problems. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Exporting device supported frequencies
On Mon, 2014-01-20 at 10:27 -0600, Dan Williams wrote: On Sun, 2014-01-19 at 16:45 +0100, Bastien Nocera wrote: Hey, I wanted to show in GNOME's Network settings whether the device supported 5GHz frequencies: https://bugzilla.gnome.org/show_bug.cgi?id=722550 Does NM export it in some way? nmcli d show wlp3s0 didn't show anything that looked like this. Bug updated, a 10-minute branch is at dcbw/5ghz-caps, will that do what you need? I guess we should show 2.4GHz in there as well, so that 5GHz only devices that come out in a couple of years don't end up being tagged as 2.4GHz devices, no? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Exporting device supported frequencies
Hey, I wanted to show in GNOME's Network settings whether the device supported 5GHz frequencies: https://bugzilla.gnome.org/show_bug.cgi?id=722550 Does NM export it in some way? nmcli d show wlp3s0 didn't show anything that looked like this. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager C99 compiler requirement for 0.9.10 (and therefore 0.9.9)
On Thu, 2013-02-28 at 04:57 -0500, Pavel Simerda wrote:
Hi all,
I would like to do *occasional* C99-style declarations in the code to avoid
ugly hacks when using conditionally built code. That means bumping up the
compiler requirements to the C99 standard. As we currently only target to GCC
and possibly LLVM, I don't think it would be a problem.
I will modify the configure.ac to require and use C99, if there are no
objections on the list.
Below you can see an example of code that would benefit from moving
conditional stuff together.
You can also do:
#if !KERNEL_HACKS
{
gboolean link_was_up;
/* Current kernels may break IPv6 networking when performing
this test:
*
* https://bugzilla.redhat.com/show_bug.cgi?id=886116
*
* We're therefore disabling it as a hack to preserve
connectivity on
* kernels that would break it.
*/
/* Loopback can be set up and down */
link_was_up = nm_platform_link_is_up (LO_INDEX);
g_assert (nm_platform_link_set_up (LO_INDEX));
g_assert (nm_platform_link_is_up (LO_INDEX));
g_assert (nm_platform_link_is_connected (LO_INDEX));
}
#endif
No need to bump the requirements. Or you could move the hacks to their
own separate function.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9.8 doesn't realise that DHCP worked
On Tue, 2013-02-26 at 16:52 -0500, Pavel Simerda wrote: - Original Message - From: Bastien Nocera had...@hadess.net Heya, I'm using rawhide on my laptop, and I can get the network to work in sporadic 30 second bursts, as NM doesn't realise that dhclient got an IP address: Feb 26 13:35:16 sirocco dhclient[1177]: bound to 192.168.0.24 -- renewal in 17055 seconds. Feb 26 13:35:59 sirocco NetworkManager[576]: warn (wlan0): DHCPv4 request timed out. Looks wrong. Feb 26 13:35:59 sirocco NetworkManager[576]: info (wlan0): canceled DHCP transaction, DHCP client pid 1177 Feb 26 13:35:59 sirocco NetworkManager[576]: info Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) scheduled... Feb 26 13:35:59 sirocco NetworkManager[576]: info Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) started... Feb 26 13:35:59 sirocco kernel: [ 211.996738] wlan0: deauthenticating from f4:ca:e5:94:aa:60 by local choice (reason=3) Feb 26 13:35:59 sirocco NetworkManager[576]: info (wlan0): device state change: ip-config - failed (reason 'ip-config-unavailable') [70 120 5] Any ideas what might be causing this? I get the same problem on wired and wireless networks. Not really. Did you check if it isn't a selinux issue? I have SELinux in permissive mode, it's not SELinux. We changed quite a lot of stuff but DHCP was always working for me. We didn't modify the dhclient action binary for time, so it might be theoretically somewhere in the dhcp plugin. Btw you said the network works for you sometimes? Does that mean dhclient sets up the address directly? There's an IP address bound, as seen in the logs. Might be explained by what's below. That would suggest it's not running NM's dhcp action script at all but instead runs the default one. I symlink'ed /etc/dhclient-script to /usr/sbin/dhclient-script after seeing dhclient complain about /etc/dhclient-script being missing. It didn't work before either, doesn't work when I remove that symlink, doesn't work when I Maybe also try to killall dhclient (and NetworkManager) before you test once again. The machine's been rebooted a million times already. I doubt that a killall would fix things anymore. I've finally found the problem however. In my /etc I had a copy of the example /etc/dhclient.conf, dating back from the 25th July 2012 (when I debugged dhcp to find why we couldn't connect to the GUADEC wireless network). That file never caused a problem with older versions of NetworkManager or dhclient but it seems that recent version of dhclient or the way it's being called by NM makes it not be ignored anymore. I'm pretty sure that your commit 1a7e7c9031526b0c8973965c826ad7d1b7cc22f9 is the one causing the regression: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1a7e7c9031526b0c8973965c826ad7d1b7cc22f9 It's basically loading anything that lies around, even if it's not relevant for the distribution used. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NM 0.9.8 doesn't realise that DHCP worked
Heya, I'm using rawhide on my laptop, and I can get the network to work in sporadic 30 second bursts, as NM doesn't realise that dhclient got an IP address: Feb 26 13:35:16 sirocco dhclient[1177]: bound to 192.168.0.24 -- renewal in 17055 seconds. Feb 26 13:35:59 sirocco NetworkManager[576]: warn (wlan0): DHCPv4 request timed out. Feb 26 13:35:59 sirocco NetworkManager[576]: info (wlan0): canceled DHCP transaction, DHCP client pid 1177 Feb 26 13:35:59 sirocco NetworkManager[576]: info Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) scheduled... Feb 26 13:35:59 sirocco NetworkManager[576]: info Activation (wlan0) Stage 4 of 5 (IPv4 Configure Timeout) started... Feb 26 13:35:59 sirocco kernel: [ 211.996738] wlan0: deauthenticating from f4:ca:e5:94:aa:60 by local choice (reason=3) Feb 26 13:35:59 sirocco NetworkManager[576]: info (wlan0): device state change: ip-config - failed (reason 'ip-config-unavailable') [70 120 5] Any ideas what might be causing this? I get the same problem on wired and wireless networks. dhclient-4.2.5-7.fc19.x86_64 NetworkManager-0.9.8.0-1.fc19.x86_64 Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 2/5] connectivity: Add libxml2 as a dependency
On Mon, 2013-02-11 at 10:06 -0600, Dan Williams wrote: On Mon, 2013-02-11 at 12:09 -0200, Jonh Wendell wrote: From: Jonh Wendell jonh.wend...@oiwifi.com.br libsoup already depends on libxml2 but we need to explicitly link to it. At least we already theoretically required it; though is it possible to use GMarkup here instead of libxml2? GMarkup would be somewhat simpler, though it's only a subset. Given how it's used, there's probably little reason this couldn't be a regexp. Both GMarkup and libxml2 would choke on broken, slightly broken, and very very broken HTML files. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Modem supporting location information?
On Fri, 2012-11-30 at 17:55 +0100, Aleksander Morgado wrote: On 11/30/2012 05:48 PM, Bastien Nocera wrote: I'm interested in getting a 3G modem that would support A-GPS. I have a (possibly simlocked) option modem: 0af0:6971 Option Globetrotter HSDPA Modem Which tells me that it doesn't support Location services. Does it not support it, or is it not implemented? That one should be supported in ModemManager git master, see: http://sigquit.wordpress.com/2012/03/29/enabling-gps-location-in-modemmanager/ But not A-GPS; just plain GPS for now. What would be needed for A-GPS support? I also have a Huawei E585 modem, which doesn't support switching to USB mode when plugged in, but apparently support A-GPS. If we can make this work, it would save me buying a new dongle. Otherwise, I'm in the market for a 3G modem that supports those. Cheaper is better. Anything on eBay or Amazon that people would recommend? The other modems which (currently) support GPS location services in ModemManager are all those QMI-based modems implementing the PDS service. E.g. my old Gobi 2k modem built-in my Thinkpad laptop does it, and many newer modems (e.g. Pantech UML290) also do it IIRC. How about the Dell 5520 cards? I have one of those stuffed in an ancient Dell machine. Any ideas also on turning the Huawei modem into a USB one? Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Modem supporting location information?
On Tue, 2012-12-04 at 17:11 -0600, Dan Williams wrote: On Fri, 2012-11-30 at 17:48 +0100, Bastien Nocera wrote: Heya, I'm interested in getting a 3G modem that would support A-GPS. I have a (possibly simlocked) option modem: 0af0:6971 Option Globetrotter HSDPA Modem Which tells me that it doesn't support Location services. Does it not support it, or is it not implemented? I also have a Huawei E585 modem, which doesn't support switching to USB mode when plugged in, but apparently support A-GPS. If we can make this work, it would save me buying a new dongle. Otherwise, I'm in the market for a 3G modem that supports those. Cheaper is better. Anything on eBay or Amazon that people would recommend? That should be the Option 225, which has GPS functionality, but you may need to enable it with AT_OIFC=3,1,1,2. Then replug the device, and you'll get 5 ttys: ttyHS0 - ttyHS4. To test, send AT_OGPS=2 on ttyHS1, and then watch ttyHS2 for spew. Is this something that ModemManager would do when you request the location services to be turned on? If you want to unlock it: http://dogber1.blogspot.com/2010/01/unlocker-for-option-gio225.html I've successfully used that guy's unlock for my HP Veer so his stuff is pretty solid. Not much luck from my side, after a couple of fixes, it fails to upload the firmware to the device. Might need to install windows to try it... ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Modem supporting location information?
Heya, I'm interested in getting a 3G modem that would support A-GPS. I have a (possibly simlocked) option modem: 0af0:6971 Option Globetrotter HSDPA Modem Which tells me that it doesn't support Location services. Does it not support it, or is it not implemented? I also have a Huawei E585 modem, which doesn't support switching to USB mode when plugged in, but apparently support A-GPS. If we can make this work, it would save me buying a new dongle. Otherwise, I'm in the market for a 3G modem that supports those. Cheaper is better. Anything on eBay or Amazon that people would recommend? Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unsubscribe from mailing list
On Thu, 2011-12-15 at 18:38 +0100, Volker Fritz wrote: Hi, Pls. unsubscribe me from your mailing list. My e-mail address: v_fr...@t-online.de THANK YOU! There's a link for you to do that at the bottom of every mail: http://mail.gnome.org/mailman/listinfo/networkmanager-list Look for unsubscribe. And good god learn some manners and don't spam a mailing-list with requests like that. Mit freundlichen Grüßen / Yours sincerely Volker Fritz ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-applet fails to compile against gnome-bluetooth-3.3
On Fri, 2011-11-25 at 09:10 -0600, Daniel Drake wrote: Hi, NetworkManager is breaking rawhide because it needs to be rebuilt againts gnome-bluetooth-3.3. However, network-manager-applet fails to rebuild: snip It looks like gnome-bluetooth used to specify dbus-glib includes/libs but no longer does so. Perhaps network-manager-applet compile should use the suggested includes of libnm-glib in this case. Indeed, gnome-bluetooth got ported to GDBus in the 3.4 devel cycle. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] clean up mobile broadband wizard
On Tue, 2011-09-27 at 11:16 -0500, Dan Williams wrote: On Tue, 2011-09-27 at 16:43 +0100, Bastien Nocera wrote: On Tue, 2011-09-27 at 10:00 -0400, Mathieu Trudel-Lapierre wrote: Hi, I noticed many duplicate buttons and page headers in the mobile broadband wizard, attached is a patch that fixes this. It was a bug in GTK+, which I fixed in time for GNOME 3.2 last week. Was the bug only present in development versions of GTK? Yes, the assistant was redesigned as part of GNOME 3.2, in GTK+ 3.1.4 and fixed in 3.2.0. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] clean up mobile broadband wizard
On Tue, 2011-09-27 at 10:00 -0400, Mathieu Trudel-Lapierre wrote: Hi, I noticed many duplicate buttons and page headers in the mobile broadband wizard, attached is a patch that fixes this. It was a bug in GTK+, which I fixed in time for GNOME 3.2 last week. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Change the Password
On Thu, 2011-01-27 at 15:41 +0530, Jos Collin-ERS,HCLTech wrote: Can you please respond to my email? I just want to know is it possible to change the encryption key via dbus or not. No you cannot. You should be able to use the D-Bus API for gnome-keyring to do that instead (that's where the password is stored). ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Change the Password
On Thu, 2011-01-27 at 17:34 +0530, Jos Collin-ERS,HCLTech wrote: Thanks a lot, Bastien. I will work on that. I found that the GetSettings doesn't give the encryption key. I have tried GetSecrets function also, to see where the key is stored, but how ever there is no function to set the secrets. My guess is that this functionality is only available through the native APIs. seahorse (the gnome-keyring manager) can change this, so there's most certainly a way. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: GSM modem via Bluetooth?
On Thu, 2011-01-06 at 13:16 -0600, Dan Williams wrote: snip I spend some time on this over the holidays to figure out what it would take for manually started rfcomm ports to show up as Bluetooth modems and be configurable without the BT wizard. You'll still need to pair the device at some point anyway. The short answer is that yes, this is possible, though it's somewhat icky. But even if NM exported the device as a Bluetooth modem, you'll still need connection details (APN, username, password) before you can ask NM to connect the device. Exactly. I'll look into further cleaning up the proof-of-concept patches I did and see if they can be merged in some form in the near future. I think that this is probably best left alone until someone implements Bluetooth line discipline in pppd and the Linux kernel directly, so that reliance on rfcomm, or creation of serial ports through bluetoothd is unneeded. If you want to be able to use the /dev/rfcomm devices directly, I'd recommend making this hard to setup, so that people don't try and use it as the main way to create a connection to their device, rather as a debugging method (wrong Bluetooth port used for example). Creating an rfcomm device, making sure it stays across reboots, and making sure it points to the right port (which has absolutely no guarantees of staying the same across enabling/disabling the feature on the device), is a sure way to break things, and requires root access. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: GSM modem via Bluetooth?
On Tue, 2011-01-11 at 20:36 +0300, Andrey Borzenkov wrote: On Thu, Jan 6, 2011 at 10:16 PM, Dan Williams d...@redhat.com wrote: I spend some time on this over the holidays to figure out what it would take for manually started rfcomm ports to show up as Bluetooth modems and be configurable without the BT wizard. The short answer is that yes, this is possible, though it's somewhat icky. But even if NM exported the device as a Bluetooth modem, you'll still need connection details (APN, username, password) before you can ask NM to connect the device. That's correct; and as soon as connection was no more ignored by NM I was able to use knetworkmanager to configure it. So now I have fully functional connection definition. I'm guessing it would be easier to setup once NM takes care of creating connections in a way that doesn't require a particular backing store. So you'd set it up using the GNOME Bluetooth wizard, and have access to the same connection in KNetworkManager (or at least until the KDE Bluetooth bits gain the ability to do something similar). Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MM Location API and MBM GPS
On Sun, 2010-09-05 at 15:15 +0100, Sjoerd Simons wrote: Hey, I'm wondering how to best integrate my MBM 3G modems GPS with MM and Gypsy. The GPS on this device works as follows: The modem exposes three serial ports that all support AT commands, one can use AT commands to turn on the GPS, query it's status (e.g. whether it has a lock) and adjust some other settings. To read the actual location information from the GPS another AT command can be send to any of the three serial ports to turn it into an NMEA streaming port. At this point you can point any normal GPS application (like gypsy or gpsd) to this serial port an everything works nicely. Looking at the recent Location interface of MM the ``suggested'' way to implement this seems to be that MM turns one port into the NMEA port and relays the NMEA information over dbus in the Location property, which seems somewhat over the top. It seems more natural to be able to ask MM nicely whether one can have a serial port with NMEA enabled and just use that, at which point Gypsy can take care of everything else. Assuming i'm not the only one that thinks that's a nicer way of doing things, i'd be happy to propose a GpsDevice interface with the needed functionality. I wouldn't put it in the Location interface as that feels more like: the modem itself provides location information instead of the modem has a slave device which gives raw nmea. Comments, suggestions, flames ? :) Dan, rightly so, didn't like the idea of just handing out a socket to Gypsy. There are multiple reasons for that: - you want MM to still have complete control over the ports offered - it would make it hard to push vendor specific hacks to Gypsy - a lot of modems don't actually give you NMEA data at all, so it wouldn't make sense to parse the proprietary format, put it into NMEA, just to have it parsed again The right way to implement this would be through a Geoclue provider, which you could hit directly from your application if you're so enclined, or just let it be one more provider amongst others. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm_ap_get_strength question
On Wed, 2010-07-07 at 10:12 -0300, Franco Miceli wrote: I have a question about the method nm_ap_get_strength. The method reports values of 88 - 90 for signal levels of -50 dBm (as reported by iwlist sc). My question is, what does strength report? A percentage of strength. A quality measurement? If so, what is the math behind its calculation? All the code lives in NetworkManager and is quite involved, as you can see: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-device-wifi.c#n1548 The reason I'm asking this is because while iwlist reports differences in signal level of 20 dB, strength reports differences of only 4 (unit missing). It's a difference of 20dBm, not 20dB. The unit is percentages. The percentage is used to present the quality of the link to users, and shouldn't really be used for anything else. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM + DUN on Fedora-12?
On Wed, 2010-06-23 at 17:39 -0700, Dan Williams wrote: snip Googling around a bit I find people with some of the same problems. You're sure you've: a) paired with the computer successfully b) enabled BT DUN in PDAnet c) whatever it says here? http://www.junefabrics.com/android/bluetooth.php etc. Basically, if that SDP record doesn't show up, there's nothing that Linux or even Windows/Mac OS X can do since the device is saying it's not capable of DUN at all. Because I still haven't added a way to get to the gnome-bluetooth plugins after pairing, you'll need to have PDAnet enabled when pairing. It's on the TODO list, but could be done by anyone with a bit of GTK+ knowledge. See: https://bugzilla.gnome.org/show_bug.cgi?id=575414 Let me know off list if you're interested in working on this. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: BT DUN based systemconnections in 0.8.1 beta
On Tue, 2010-05-25 at 13:11 +0200, van Schelve wrote: Hi, I'm still having problems with bluetooth dun based system connections in 0.8.1 beta: 1. No ui in nm-applet is available 2. if created from scratch as system-connection they not shown in nm-applet With cnetworkmanager I'm able to list such a connection but I'm not able to bring it up with this tool. In this context, can someone explain the commandline interface of networkmanager to me? On http://live.gnome.org/NetworkManager/ReleaseProcess I found that BT DUN should be included in the 0.8.1 release. Can someone clarify this? If dun systemconnections are not part of 0.8.1 release can someone tell me what's missing? You need to pair your device using gnome-bluetooth's wizard, and the wizard to set up DUN will appear on the last page. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager Ignoring rfcomm0 device (bluetooth DUN) on Fedora 13 Beta
On Mon, 2010-05-10 at 12:54 +0800, Ascanio Alba wrote: Hi, I have a bluetooth DUN device (/dev/rfcomm0) exported by modem-manager but being ignored by NetworkManager. This is on Fedora 13 Beta, latest updates-testing. I was getting some SELinux denials but did an audit2allow to remove that variable from the system. blueman attaches to the DUN service. modem-manager sees and exports the device, but NM ignores it. Version: NetworkManager-0.8.0-12.git20100504.fc13.x86_64 Don't use blueman to set up DUN, use the wizard in gnome-bluetooth instead (you'll need to re-pair your device to do that, and it should ask you a question once setup). Blueman's way of setting up rfcomm was always hacky, and is now out-of-date. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager Ignoring rfcomm0 device (bluetooth DUN) on Fedora 13 Beta
On Mon, 2010-05-10 at 21:26 +0800, Ascanio Alba wrote: I tried without blueman and got a similar error message. I disabled blueman and went via the gnome-bluetooth wizard to setup new device. I reached Access Internet using your mobile phone (DUN) Got Detecting phone configuration... MM seems to detect the 3G phone and exported it but NM rejects. Then MM removes the device. I tried this on another system but even worse gnome bluetooth wizard ABRTing. If the bluetooth wizard from gnome-bluetooth crashes, please file a bug. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager Ignoring rfcomm0 device (bluetooth DUN) on Fedora 13 Beta
On Mon, 2010-05-10 at 14:36 +0100, Bastien Nocera wrote: On Mon, 2010-05-10 at 21:26 +0800, Ascanio Alba wrote: I tried without blueman and got a similar error message. I disabled blueman and went via the gnome-bluetooth wizard to setup new device. I reached Access Internet using your mobile phone (DUN) Got Detecting phone configuration... MM seems to detect the 3G phone and exported it but NM rejects. Then MM removes the device. I tried this on another system but even worse gnome bluetooth wizard ABRTing. If the bluetooth wizard from gnome-bluetooth crashes, please file a bug. My guess is that it's a duplicate of: https://bugzilla.redhat.com/show_bug.cgi?id=590666 Which is a bug in NetworkManager's gnome-bluetooth plugin. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add support for OpenSSL's libcrypto as crypto backend
On Fri, 2010-04-09 at 12:11 -0700, Dan Williams wrote: WARNING! Enabling OpenSSL support may cause the combination of libnm-util and GPL programs to be illegal in your jurisdiction. Please check with your lawyer before enabling OpenSSL support. In your jurisdiction? In what jurisdiction would combining incompatible licenses be fine? Not sure I see the point here. FWIW, nss has boatloads of certifications that make it usable as _the_ crypto backend for a lot of countries. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add support for OpenSSL's libcrypto as crypto backend
On Sat, 2010-04-10 at 03:32 +0300, Simos Xenitellis wrote: On Sat, Apr 10, 2010 at 2:40 AM, Bastien Nocera had...@hadess.net wrote: On Fri, 2010-04-09 at 12:11 -0700, Dan Williams wrote: WARNING! Enabling OpenSSL support may cause the combination of libnm-util and GPL programs to be illegal in your jurisdiction. Please check with your lawyer before enabling OpenSSL support. In your jurisdiction? In what jurisdiction would combining incompatible licenses be fine? In countries that have not signed one of the copyright treaties/conventions, etc: http://en.wikipedia.org/wiki/List_of_parties_to_international_copyright_agreements Admittedly, these are just a few countries. This is about author's rights, or copyright of artistic works that would expire, not ownership of code, and conflicts within. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bluetooth ICS
On Thu, 2010-04-08 at 16:54 -0700, Dan Williams wrote: On Thu, 2010-04-08 at 23:53 +0200, Stéphane Maniaci wrote: Hi, Sorry if this question has been asked before, but I got a little bit lost in my researches on the Internet. Is it possible to enable connection sharing via Bluetooth between two _computers_ ? One has an ethernet connection and a bluetooth dongle, the other only has bluetooth. Does the bluetooth spec implements such a possibility ? Not quite yet, but we've got a feature request for it in bugzilla and I've already spent some time thinking about it and discussing implementation details with relevant people (Bastien, really). The general idea is that you'd just check a share my internet connection over bluetooth somewhere, which would poke NM to start up sharing over bluetooth like any normal NM ICS works. I have no idea when this would hit, since some of it depends on other UI components like gnome-bluetooth or kde-bluetooth. The code needed on the gnome-bluetooth side is one function, akin to the one in the gnome-bluetooth plugin for nm-applet to switch on PAN. It's more finding the time to write the NM code that's the problem ;) In the meanwhile, you can use pand on your server. There's already pretty good pages on how to do that. On the connecting side, you can then use gnome-bluetooth to pair and enable the connection to that machine. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Definition for Magic Mouse assistance with XML foo.
On Sun, 2010-03-07 at 10:43 +0100, Grant Williamson wrote:
Are there plans to implement a fully feature cli to control every aspect
of NetworkManager.
i.e. from activating/deactivating a device to say configuring leap?
What on earth does that have to do with the original mail on the HAL
list?
On 03/06/2010 08:56 PM, Mike Mestnik wrote:
Discovered that udev and not hal is used for this now.
Sorry and thank you.
On Fri, Mar 5, 2010 at 11:11 PM, Mike Mestnikmmest...@nagios.com wrote:
I found this some where on-line, but to save space I removed the comments.
What I'd like to accomplish is to switch from evdev to synaptics and
to turn encryption of the Bluetooth connection on. The following
should do this, but it's completely ignored.
overrun:~# cat /etc/hal/fdi/policy/MagicMouse.fdi
?xml version=1.0 encoding=ISO-8859-1?
deviceinfo version=0.2
device
match key=info.product contains=Apple Wireless Mouse
merge key=input.x11_driver type=stringsynaptics/merge
merge key=input.x11_options.SHMConfig type=stringtrue/merge
append key=info.callouts.add type=strlistbash -c 'hcitool enc
$(echo $HAL_PROP_INPUT_ORIGINATING_DEVICE | sed
s%^/org/freedesktop/Hal/devices/bluetooth_acl_\(..\)\(..\)\(..\)\(..\)\(..\)\(..\)$%\1:\2:\3:\4:\5:\6%)'/append
/match
/device
/deviceinfo
Here is some other information:
overrun:~# hal-device
0: udi =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da_logicaldev_input_0'
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'input' (string)
info.capabilities = { 'input', 'input.mouse' } (string list)
linux.device_file = '/dev/input/event7' (string)
info.category = 'input' (string)
input.originating_device =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da' (string)
input.device = '/dev/input/event7' (string)
input.product = 'Apple Wireless Mouse' (string)
info.subsystem = 'input' (string)
info.product = 'Apple Wireless Mouse' (string)
linux.sysfs_path =
'/sys/devices/pci:00/:00:13.0/usb5/5-3/5-3:1.0/bluetooth/hci0/hci0:41/input7/event7'
(string)
info.parent =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da' (string)
input.x11_driver = 'evdev' (string)
info.udi =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da_logicaldev_input_0'
(string)
1: udi =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da_logicaldev_input'
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'input' (string)
info.capabilities = { 'input', 'input.mouse' } (string list)
linux.device_file = '/dev/input/event6' (string)
info.category = 'input' (string)
input.originating_device =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da' (string)
input.device = '/dev/input/event6' (string)
input.product = 'Apple Wireless Mouse' (string)
info.subsystem = 'input' (string)
info.product = 'Apple Wireless Mouse' (string)
linux.sysfs_path =
'/sys/devices/pci:00/:00:13.0/usb5/5-3/5-3:1.0/bluetooth/hci0/hci0:41/input6/event6'
(string)
info.parent =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da' (string)
input.x11_driver = 'evdev' (string)
info.udi =
'/org/freedesktop/Hal/devices/bluetooth_acl_34159ed3c6da_logicaldev_input'
(string)
overrun:~# cat /proc/bus/input/devices
I: Bus=0005 Vendor=05ac Product=030d Version=0084
N: Name=Apple Wireless Mouse
P: Phys=00:15:E9:65:36:E4
S:
Sysfs=/devices/pci:00/:00:13.0/usb5/5-3/5-3:1.0/bluetooth/hci0/hci0:41/input6
U: Uniq=34:15:9E:D3:C6:DA
H: Handlers=mouse1 event6
B: EV=17
B: KEY=3 0 0 0 0 0 0 0 0
B: REL=3
B: MSC=10
I: Bus=0005 Vendor=05ac Product=030d Version=0084
N: Name=Apple Wireless Mouse
P: Phys=00:15:E9:65:36:E4
S:
Sysfs=/devices/pci:00/:00:13.0/usb5/5-3/5-3:1.0/bluetooth/hci0/hci0:41/input7
U: Uniq=34:15:9E:D3:C6:DA
H: Handlers=mouse2 event7
B: EV=f
B: KEY=20 0 7 0 0 0 0 0 0 0 0
B: REL=103
B: ABS=273 0
Yes, I know there are two devices. From what I can tell event7 is
what I would like to connect two, it currently spits out data when I
touch the mouse(that is I don't cause any input that's currently
interpreted). Most of the mouse's event(s) are accessible on this
device, the top of the mouse is one big button that clicks when you
press down. I don't get an event when I do this(while not touching
the multi-touchpad), but when I release I get 64 bytes from the mouse.
More then anything I need help with the syntax and a way to
differentiate each of these devices.
--
Mike Mestnik
Technical Team
___
Nagios Enterprises, LLC
Email: mmest...@nagios.com
Web: www.nagios.com
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
Re: Problems with btdun branch
On Tue, 2010-02-16 at 15:03 -0800, Dan Williams wrote: On Tue, 2010-02-16 at 11:17 +0100, van Schelve wrote: Hi. I want to tryout the btdun branch to see how the work that is in there works an can be used in the filed. Therefore I compiled the btdun branch of network-manager and network-manager-applet under Ubuntu lucid. Now, when pairing the bluetooth mobile using bluetooth-wizard there is a new checkbox: Access the Internet using your mobile phone (DUN) When activating this checkbox bluetooth-wizard freezes. When starting bluetooth-wizard from command-line I see the following messages when trying to activate the checkbox: ** Message: dun_start: starting DUN device discovery... (bluetooth-wizard:2663): GLib-GObject-WARNING **: cannot register existing type `BlingSpinner' What do you get for: grep -r BlingSpinner /usr/lib/gnome-bluetooth/plugins or grep -r BlingSpinner /usr/lib64/gnome-bluetooth/plugins ? Maybe we just need to rename it so it doesn't use a common name and is private to NM. Since the plugins are shared objects we do have to be careful about the types we register with glib. That would probably happen if you don't export the BlingSpinner symbol from your plugin, and use it against an older gnome-bluetooth. gnome-bluetooth in master (and the latest release) uses the spinner I put in GTK+. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection through bluetooth phones
On Mon, 2009-11-09 at 14:22 +0100, Gianluca Sforna wrote: I am looking for some info about how Fedora 12 stands wrt allowing 3G internet connection through a mobile phone. In particular, I tried with my Nokia 6210 Classic and the last step in the wizard shown at: http://blogs.gnome.org/dcbw/2009/07/10/unwire-with-networkmanager/ surely did not include the Access the Internet using your mobile phone button. Any help is appreciated Attach the output of bluetooth-properties -d. My guess is that your phone doesn't have PAN support, and there's currently no DUN support in NetworkManager (though Dan is working on it in a branch). Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection through bluetooth phones
On Mon, 2009-11-09 at 14:40 +0100, Gianluca Sforna wrote: On Mon, Nov 9, 2009 at 2:32 PM, Bastien Nocera had...@hadess.net wrote: Attach the output of bluetooth-properties -d. My guess is that your phone doesn't have PAN support, and there's currently no DUN support in NetworkManager (though Dan is working on it in a branch). Device: Tweety (00:1B:AF:6F:39:50) D-Bus Path: /org/bluez/1423/hci0/dev_00_1B_AF_6F_39_50 Type: Phone Icon: phone Paired: True Trusted: True Connected: False UUIDs: SyncMLClient DialupNetworking OBEXObjectPush OBEXFileTransfer AudioSource A/V_RemoteControlTarget A/V_RemoteControl Headset_-_AG HandsfreeAudioGateway SIM_Access Yep, no PAN support. You'll need to wait for DUN support to be merged into NetworkManager proper then. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection through bluetooth phones
On Mon, 2009-11-09 at 15:08 +0100, Gianluca Sforna wrote: On Mon, Nov 9, 2009 at 3:04 PM, Bastien Nocera had...@hadess.net wrote: On Mon, 2009-11-09 at 14:40 +0100, Gianluca Sforna wrote: On Mon, Nov 9, 2009 at 2:32 PM, Bastien Nocera had...@hadess.net wrote: Attach the output of bluetooth-properties -d. My guess is that your phone doesn't have PAN support, and there's currently no DUN support in NetworkManager (though Dan is working on it in a branch). Device: Tweety (00:1B:AF:6F:39:50) D-Bus Path: /org/bluez/1423/hci0/dev_00_1B_AF_6F_39_50 Type: Phone Icon: phone Paired: True Trusted: True Connected: False UUIDs: SyncMLClient DialupNetworking OBEXObjectPush OBEXFileTransfer AudioSource A/V_RemoteControlTarget A/V_RemoteControl Headset_-_AG HandsfreeAudioGateway SIM_Access Yep, no PAN support. You'll need to wait for DUN support to be merged into NetworkManager proper then. Ok, so with PAN devices it would have worked as advertised? For comparison, this is the output on my Sony Ericsson k850i: UUIDs: SyncMLClient SerialPort DialupNetworking IrMCSync OBEXObjectPush OBEXFileTransfer AudioSource A/V_RemoteControlTarget A/V_RemoteControl Headset_-_AG PANU NAP HandsfreeAudioGateway HumanInterfaceDeviceService Phonebook_Access_-_PSE SEMC HLA SEMC Watch Phone Note the PANU profile. Anyway, thank you very much for the great work on BT stuff! Thanks to Dan for fixing up my early, incomplete code :) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: So very close, but so frustrating...
On Sat, 2009-10-03 at 01:08 -0700, Dan Williams wrote: See the 'btdun' branch of nm-applet, where I've added DUN support to the gnome-bluetooth plugin. There's nothing in the applet or NM side yet, both will need further fixes. But the gnome-bt plugin seems to work OK at the moment. Bastien, can you sanity check it? There's a lot of async dbus calls going on there between the plugin, Bluez, and MM. Needs another set of eyes. 8b0ae181efd1e3856851e6a44e16bd51d440d0ce c1c13b9dff6772bf13ab6217a2eecb986bd67687 I'd do: + return (get_best_method (bdaddr, uuids) != BT_METHOD_UNKNOWN); instead of: + return !!get_best_method (bdaddr, uuids); Also, you're inside the wizard (or the properties, once I actually write that code), so you can remove stuff like: find_device_cb() and use bluetooth_client_get_model() instead Something like: client = bluetooth_client_new (); model = bluetooth_client_get_model(client); /* Loop to find the device's proxy object */ g_object_unref (model); g_object_unref (client); /* change the interface on the proxy object */ That would remove the need to get the default adapter as well. You can use lib/test-client to see what the model looks like (adapters with devices as the children). The code under: /* Watch for BT device property changes */ is probably racy-ish. Would need to connect to the properties before launching the connect Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: So very close, but so frustrating...
On Fri, 2009-10-02 at 01:55 +0100, Rick Jones wrote: I've just installed blueman, to replace bluez-gnome, and it does this perfectly. It's a much better UI-oriented manager for BT devices altogether, it shows my phone, I click on attach serial service, and it exposes the BT modem in DBus. NM 0.7 sees it just like a USB modem and it connects first time. Magic! I'm too hardened to be often impressed first-time with a piece of software, but this was spot-on (does audio, obex, etc just as neatly). OK, it takes a couple of extra clicks to connect the phone, which I guess a built-in NM implementation could do automatically, but that's pretty minor. Except that blueman does this the way that causes Dan to receive bug reports. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: So very close, but so frustrating...
On Thu, 2009-10-01 at 14:39 -0700, Dan Williams wrote: On Wed, 2009-09-30 at 20:18 -0400, Darren Albers wrote: snip At this time Network Manager does not support Bluetooth modems. I think 0.8 supports phones if they use Bluetooth PAN but not Bluetooth DUN. Correct; I may just get bored enough today triaging bugs to go implement DUN in 0.8. That opens up a huge number of cellphones, which will inevitably lead to even more bugs since there's much more phone variation than in the relatively small data card space. Oh well; it would help a lot of people out. 1. Add ability for MM to identify Bluetooth modems 2. Add plugin in bluez to poke at the modem with MM if it doesn't know the type of device, cache the result, the bluez plugin exports the information through a service 3. Add DUN gnome-bluetooth plugin to nm-applet which would poke the bluez service 4. Add native support in NM to do the connection through bluetoothd After 3., if the box is ticked, the device should appear like an unconfigured WWAN modem to the user. The service configuration can then be done through nm-applet. I can certainly take care of 2. and 3. if you do 1. and the left-overs of 4 :) Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp and offline state
On Mon, 2009-09-07 at 15:07 +0200, Pietro Battiston wrote: Il giorno lun, 07/09/2009 alle 12.53 +0200, Pietro Battiston ha scritto: 1) the most clear answer I found to the claim: NM doesn't support generic ppp, so I must connect with $APP_TO_HANDLE_PPP_CONNECTION and NM doesn't notice it, so $APP_USING_NETWORK doesn't connect, thinking I'm disconnected is at [0] and basically says: nobody is working on it, if somebody would like to, please step in. This was obviously an admissible position; is it still true, or did the creation of MobileManager change future hopes of generic (or at least bluetooth) ppp support in NM? I accidentally found http://blogs.gnome.org/dcbw/2009/05/22/a%E2%80%A2b%E2%80%A2c-delicious/ and this answers the bluetooth? part of my question (yes, we'll have bluetooth in 0.8, great, thanks Dan and Bastien), leaving open only the normal modem part (and the other 2 questions). There's no PPP over Bluetooth support yet. It requires changes to ModemManager. There will be PAN support though. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gnome-bluetooth integration
On Thu, 2009-08-06 at 16:30 +0200, Andrzej Wytyczak-Partyka wrote: Hi guys, please consider this patch, which enables iPhone support in the gnome-bluetooth plugin. The iPhone reports a NAP service, instead of a PANU service, but it works - after connecting to that service through NetworkManager a connection is setup and operational. NAP means that the iPhone would access the Internet using your computer, not your computer accessing the internet through your iPhone... If the SDP record is wrong, then it needs to be fixed in bluez, or gnome-bluetooth, not worked around in NetworkManager. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Keep a wlan active without Access Point?
On Sun, 2009-06-14 at 12:03 +0530, Ravindra Wankar wrote: For one, I run apache with virtual host entries for the static IP. Secondly, it was just convenient. We develop web based apps and me and my colleagues need to access apache on each other's machines. Previously I could simply copy-paste a url to someone else in an email or a chat window. Now since I have to use localhost for myself, I have to keep changing localhost to my fully qualified hostname everytime I send the url to someone else. Install nss-mdns, make sure avahi is installed and running, and give out your mDNS hostname. IP addresses might change, but the local hostname (in my desktop's case, cookie.local.) will stay the same. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: idea: WWAN enable/disable
On Sun, 2009-06-14 at 20:28 +0200, Marcel Holtmann wrote: Hi Bastien, hows about adding a option to enable/disable WWAN, same like the feature to en/disable wireless (gnomeapplet: right-click checkbox) on my lenovo-notebook it is quite simple to do it to enable: echo enable /proc/acpi/ibm/wan to disable: echo disable /proc/acpi/ibm/wan to get status: cat /proc/acpi/ibm/wan There's already killswitch support in NetworkManager, just make sure that the method for accessing those is supported in HAL. Not sure how that's going to be handled in the post-HAL world, Dan? starting with 2.6.31 we do have a proper /dev/rfkill interface that can do all this properly without having to involve HAL, udev or similar. Goodie, will have to move gnome-bluetooth to using that scheme. Do you have any references to the API/ioctls for it? Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: idea: WWAN enable/disable
On Sun, 2009-06-14 at 21:06 +0200, Marcel Holtmann wrote: Hi Bastien, hows about adding a option to enable/disable WWAN, same like the feature to en/disable wireless (gnomeapplet: right-click checkbox) on my lenovo-notebook it is quite simple to do it to enable: echo enable /proc/acpi/ibm/wan to disable: echo disable /proc/acpi/ibm/wan to get status: cat /proc/acpi/ibm/wan There's already killswitch support in NetworkManager, just make sure that the method for accessing those is supported in HAL. Not sure how that's going to be handled in the post-HAL world, Dan? starting with 2.6.31 we do have a proper /dev/rfkill interface that can do all this properly without having to involve HAL, udev or similar. Goodie, will have to move gnome-bluetooth to using that scheme. Do you have any references to the API/ioctls for it? it is pretty simple actually. Check include/linux/rfkill.h and it is just poll, read and write. Only one ioctl for rfkill-input replacement in the future, but that is unimportant and will go away. That is it. http://git.sipsolutions.net/gitweb.cgi?p=rfkill.git;a=summary This contains a really simple rfkill userspace tool. Looks good. Hopefully one of Dan or myself will pick it up and wrap it in GObject goodness to share in NM and gnome-bluetooth. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: idea: WWAN enable/disable
On Sun, 2009-06-14 at 20:22 +0100, Bastien Nocera wrote: On Sun, 2009-06-14 at 21:06 +0200, Marcel Holtmann wrote: snip it is pretty simple actually. Check include/linux/rfkill.h and it is just poll, read and write. Only one ioctl for rfkill-input replacement in the future, but that is unimportant and will go away. That is it. http://git.sipsolutions.net/gitweb.cgi?p=rfkill.git;a=summary This contains a really simple rfkill userspace tool. Looks good. Hopefully one of Dan or myself will pick it up and wrap it in GObject goodness to share in NM and gnome-bluetooth. FYI, filed this for gnome-bluetooth: http://bugzilla.gnome.org/show_bug.cgi?id=585765 Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wake Up World! Meet the New Boss, Same as the Old Boss
On Thu, 2009-01-22 at 18:08 -0500, Matthew Saltzman wrote: snip It's bad enough that Mr. Fergau feels compelled to post such irrelevant crap to this list in the first place, but MUST Y'ALL KEEP QUOTING IT?!? It's spam. Christophe wouldn't send that to a number of different lists. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: german translation
On Tue, 2008-09-30 at 16:03 +0200, Christoph Höger wrote: Hi folks, Ive updated the german translation (and screwed up the layout somehow with that) of nm-openvpn. I am not a member of the gnome translation team and have no svn access. So feel free to add it. You should file a bug under the l10n module in the GNOME Bugzilla, and select German as the component. People there will be able to vouch for your translation, and make sure it fits with the GNOME guidelines. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Wed, 2008-08-27 at 17:35 +0300, Tambet Ingo wrote: - GetCharset - s - GetCharsets() - as - SetCharset(s charset) - Do we need these? Do the modems support UTF8? If they do, let's just default to that. The reason I don't like there much is that they seem a bit too low level. They usually support UCS-2, GSM and ASCII, with varying degrees of success, but you're completely right that this should never appear in the public API. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trivial suggestions for enhancement
On Wed, 2008-07-23 at 14:52 +0200, Martin Vidner wrote: On Tue, Jul 22, 2008 at 12:18:15AM +0200, Tobias Wolf wrote: Salve, regarding naming, layout, and organization in the applet, I have a few small proposals prepared online: http://alice-dsl.net/towolf/gnome/reorg.html Tobias, could you please file separate bugs about those problems? Note that most of those problems will be fixed in the future when the NM UI is redesigned. This reminds me of a usability study of the new KDE NM applet, JFYI: http://weblog.obso1337.org/2008/expert-review-of-knetworkmanager-07/ I really don't see much in common. Most of the problems listed in the KDE applet aren't problems in the GNOME one... ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Service Provider Database
On Thu, 2008-06-05 at 11:50 +0300, Antti Kaijanmäki wrote: snip I also mentioned another option which you seem to have discounted, and can easily be used in a DTD. provider gsm / nameService Provider - GSM prepaid/name apnprepaid.provider/apn /provider Your previous mail had type property also with this one and it had the same problem as the first one had. That's why I didn't comment on that. You can: (gsm, name, apn)? | name Would make sure you have an apn when you have a gsm tag. In all cases, you could also use a C program to validate your XML file, which would give you more options. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Service Provider Database
On Wed, 2008-06-04 at 21:57 +0300, Antti Kaijanmäki wrote: Hi, I changed alpha-3 codes to alpha-2 because /usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/iso3166.tab use them. That's also what libgweather uses for its data, as mentioned in my mail to desktop-devel. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Service Provider Database
On Mon, 2008-06-02 at 14:39 +0300, Antti Kaijanmäki wrote: Hello, one part of my project is to create and specify a database for service provider specific settings. I've created an example page in live.gnome.org[1]. Please, comment if you find something missing or you disagree. I will begin with the implementation next week. Will you be using the XML file I sent as an example? Also, I don't think that the gsm and cdma tags are really that useful, they could be properties of the provider instead (or do we have any providers that do both?). Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Service Provider Database
On Mon, 2008-06-02 at 15:12 +0300, Antti Kaijanmäki wrote: ma, 2008-06-02 kello 12:48 +0100, Bastien Nocera kirjoitti: On Mon, 2008-06-02 at 14:39 +0300, Antti Kaijanmäki wrote: Hello, one part of my project is to create and specify a database for service provider specific settings. I've created an example page in live.gnome.org[1]. Please, comment if you find something missing or you disagree. I will begin with the implementation next week. Will you be using the XML file I sent as an example? I could use it, but I would have to write a conversion script from your XML format to the format we decide to use. I rather modify my existing python script instead and make direct conversion from the last GPRS EC database. I believe I've also posted the Perl script that generated the output, which does the country code conversion, and tags the providers properly. Also, I don't think that the gsm and cdma tags are really that useful, they could be properties of the provider instead (or do we have any providers that do both?). with properties you mean attributes? If so then w3school says[1]: There are no rules about when to use attributes and when to use elements. Attributes are handy in HTML. In XML my advice is to avoid them. Use elements instead. And I prefer elements :) If a service provider offers different types of subscriptions then there would be provider element for every different type and the name element would distinguish the types from each other. provider nameService Provider - CDMA/name cdma / /provider provider nameService Provider - GSM/name gsm apninternet/apn /gsm /provider provider nameService Provider - GSM prepaid/name gsm apnprepaid.provider/apn /gsm /provider I'd rather have: provider type=gsm nameService Provider - GSM prepaid/name apnprepaid.provider/apn /provider Or at least: provider type=gsm gsm / nameService Provider - GSM prepaid/name apnprepaid.provider/apn /provider Whether they're GSM or CDMA is a property of the provider. The user would see a drop-down menu with items: Service Provider - CDMA Service Provider - GSM Service Provider - GSM prepaid Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
On Tue, 2008-05-06 at 09:55 -0400, Dan Williams wrote: On Sun, 2008-05-04 at 11:34 +0400, Vitja Makarov wrote: Probe CDC-ACM modems, found in most cell phones on the fly, using AT+GCAP modem command. I tested it with 1 Nokia GSM phone, and 2 CDMA. Great! Thanks for writing this. So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. Or we should mark all the devices that don't use those drivers as V25 modems and install the callout for V25 modems, and devices with a specific driver. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
On Tue, 2008-05-06 at 20:10 +0200, Marcel Holtmann wrote: Hi Dan, So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. be careful with this. If the SIM card needs a PIN code first, we might not be able to send any AT commands at all. I tried for example to get the IMEI before entering the PIN, but that never worked on the cards that I own. Hmm, does that mean the device will only respond to AT+CPIN until you give it the PIN? basically yes. At least that is what I have observed with modem cards. Maybe we need to investigate if there are models that allow commands before the PIN has been entered. The phone case is different, because in that case you mostly have entered the PIN code already using the phone's UI. Maybe all that probing code should be moved to NetworkManager itself then, so it can integrate with PIN queries. We'll need to have a prober for Bluetooth devices anyway, as the supported commands set won't be available through HAL. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: ppp support naming
On Thu, 2008-03-06 at 08:16 +0100, PEDRO MACANAS VALVERDE wrote: De: [EMAIL PROTECTED] en nombre de Dan Williams Enviado el: mié 05/03/2008 19:55 Para: Will Stephenson CC: networkmanager-list@gnome.org Asunto: Re: ppp support naming Just a quick point; _nothing_ should ever use or expose the 2G/3G/4G names anywhere to the user. It could be shown optionally, if the user marks the option. Where possible, we should display model and manufacturer strings in the UI because people usually know they have a Nokia or an LG or a Samsung phone. They don't care if they have a Nokia CDMA phone or a Nokia GSM phone. It's a phone. Or you could just use the OUI from the Bluetooth address if via Bluetooth, or the USB data otherwise. For me and more people, this is important. It is not the same use a GSM phone than a HDPA phone, that can upload and download quicklier (broadband phone or broadband mobile modem, as Huawaei E220). Now, when I have to buy a new mobile phone I wouldn´t buy one older than HSPA . You can't really know that, even if you know all the details about the phone, as even a phone with 3G, GPRS and all the whizzbang might not have contracts to allow that (As I can vouch for with the latest Sony Ericsson I got from Ericsson having a pay-as-you-go SIM card with 5 quid credit). ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp support naming
On Wed, 2008-03-05 at 08:56 +0100, Will Stephenson wrote: On Monday 03 March 2008 19:38:23 Tambet Ingo wrote: On Mon, Mar 3, 2008 at 12:18 PM, Vitja Makarov [EMAIL PROTECTED] wrote: I see it in the tree but I don't see it works, correct me if i'm wrong. It works for GSM and CDMA. As far as I know, GSM and CDMA are instances of certain classes of cellular networks, but GSM and CDMA themselves are not used globally. If I 'm right in this, it would make sense to internally name this support something generic, like 2GCellular and 3GCellular and then the GUI can sort out whether it refers to it as CDMA in EN_us or 3G in EN_gb or UMTS in de. The flipside is users doing a CDMA wtf? when they try to use their cellular card. They're different protocols, and use different command sets. And those strings don't appear in the UI either. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp support naming
On Wed, 2008-03-05 at 11:58 +0100, Will Stephenson wrote: snip Does that mean that we need extra development to support HDSPA/UTMS networks? Does CDMA in NetworkManager only literally support CDMA networks? No, they're already supported. The CDMA and GSM bits in NetworkManager refer to the command sets used by the different technologies, not to the over-the-air technologies. If that's the case, obviously the API naming is fine as is. Otherwise we should make it more generic. More generic for what? They have different command sets, so they use different implementations in NM. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Thu, 2007-11-29 at 14:56 -0500, Dan Williams wrote: On Thu, 2007-11-29 at 15:48 +0200, Tambet Ingo wrote: On Nov 29, 2007 1:47 AM, Bastien Nocera [EMAIL PROTECTED] wrote: I'll be more than happy writing the GPRS bits of it. Awesome! Is there any Bluetooth related code in the code you're writing? No, the current code only handles communications with serial devices like opening, closing, configuring, sending (AT) commands, waiting for any/certain replies, etc. It also implements a GSM (while currently called UmtsDevice, we're looking for a better name for it) device that is implemented on top of serial device and handles the specific AT commands required to establish a connection. Although I have no idea how bluetooth devices work, I assume there's some magic that needs to happen and as a result there will be a serial device that takes AT commands? If so, then bluetooth (NM) device could be just a subclass of the current GSM device, do it's magic in the initialization phase and let the GSM device take care of everything else. I think I've said in a number of places about how I'd like BT DUN to work. Yep, we're just rehashing with a better view of what's been done though :) The BT adapter should be a top-level device which has the ability to create both DUN and PAN connections. PAN connections are very very different from DUN though, and we certainly don't need to implement PAN now. For the DUN case, we don't want to show the BT _adapter_ in the applet menu, we want to show _phones_. So when your phone is around (requires scanning periodically I think?) it'll pop into the menu, and it would work just like I posted in my blog about how 3G cards would work. You've got some connections, and they apply to your phone, and you pick one. That's it. You can't go around scanning forever. People always ask that of Bluetooth, and you can't do it, especially with older BT 1.0 devices that can't scan and do something at the same time. That, and it just drains your battery, and takes a long time to do (longer than looking for an AP using Wi-Fi). What we could do though, is show the paired phones as top-level objects. We could then have sub-menus with the connection providers, and the ability to create new connections. That way, we can warn the user if the phone isn't available, without causing problems. Something has to handle the pairing, and the NMDevice subclass for BT DUN needs to handle talking to BlueZ over D-Bus to pick find the BT adapters and make them scan stuff. We also need to define the NMSetting subclass for Bluetooth. Thoughts here? I don't think that the pairing should happen in NM. We're hoping to have the Bluetooth wizard ready soon (depends on whether we manage to get Marcel to commit our patches ;), and that should be the place where we create the pairings. I'm thinking specifically of the ppp-manager having a special casing for devices that look like Bluetooth addresses, and having it create rfcomm devices as appropriate (as pppd still doesn't have any native Bluetooth support). The way things currently work is that we call pppd only after the serial connection is already established. Can this be done with bluetooth devices as well? It's the way it currently works with rfcomm, but I thought that there was a way to get rid of the /dev/rfcomm0 device creation step and talk directly to the device or something. Bastien? Yep, the way is get David Woodhouse to finish his work on native Bluetooth support in the kernel and in pppd. The good thing is that using the hcid D-Bus service means we can still work-around the problem without being too Linux specific, and with good automation. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Fri, 2007-11-30 at 00:25 +0100, Marcel Holtmann wrote: Hi Dan, snip See my comment above. Scanning doesn't help you to determine if a phone is in range or not. It simply doesn't work this way. Straight from the horse's mouth. Thanks for the clarifications Marcel. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Wed, 2007-11-28 at 11:49 +0200, Tambet Ingo wrote: On Nov 27, 2007 6:40 PM, vikram b [EMAIL PROTECTED] wrote: Hi, I would like use svn trunk's code to setup ppp connection , lets say for dial up (gprs etc). As Dan already said, I have code to drive gsm data cards and we hope to get it to SVN later this week, even if it means there's no way to configure it yet from the UI (the currently missing part). I'll be more than happy writing the GPRS bits of it. Is there any Bluetooth related code in the code you're writing? I'm thinking specifically of the ppp-manager having a special casing for devices that look like Bluetooth addresses, and having it create rfcomm devices as appropriate (as pppd still doesn't have any native Bluetooth support). Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Sun, 2007-06-24 at 22:15 +0200, dragoran wrote: here is a C implementation of the ipwWirelessCtl the udi is hardcoded and I only implemented get for now (will add the rest tomorrow). It also uses all values from the README. yelo_3 you have a typo in your patch (you used getrfkill instead of set ;) ) Bastien: the UDI that will get passed to the script would be that of the killswitch corret? Yes, and it will be passed as a envvar, as in the other scripts. programm is attached... any comments? As this will live in HAL, it should have a better name (Dan was only mimicking the name of the Dell rfkill-helper). -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Mon, 2007-06-25 at 14:01 +0200, dragoran wrote: Dan Williams wrote: On Mon, 2007-06-25 at 13:33 +0200, dragoran wrote: yelo_3 wrote: I've had a look at your implementation. I have a question: Think if someone has 2 ipw cards (I don't know if it is possible, but think it is, since it is an example) will he have 2 killswitches in hal, or just one? If it has two, the script is executed two times, so it would be better to pass to the script the interface to kill, instead of doing a for among all interfaces which have a killswitch thats a good question... but It should be possible (pccard? , but dunno if intel offers that) but than both would have the same killswitch anyway, but hal would show two. I think the scripts will provide multiple killswitches, one for each ipw device found. And once ipwWirelessCtl uses the UDI that's passed to it, it should work fine with multiple killswitches. yes but we use /org/freedesktop/Hal/devices/ipw_wlan_switch as uid which would be the same for multiple killswitches we need something more unique The killswitch should be attached to the wireless card object, not the computer (for Bluetooth, you need to attach to the computer, as the device disappears when killed, for Dell laptops, the device isn't attached to a specific device). -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Mon, 2007-06-25 at 12:28 +, yelo_3 wrote: I think the scripts will provide multiple killswitches, one for each ipw device found. And once ipwWirelessCtl uses the UDI that's passed to it, it should work fine with multiple killswitches. So the work with the UDI might be done in the shell script hal-system-killswitch-?et-power, so that ipwWirelessCtl is invoked with the device name to shut down! this could be done through info.parent as in the C code by dragoran, but in bash No, please don't put any logic in this bash script, except selecting the right binary to run. Do it in C, in the worker program. -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Mon, 2007-06-25 at 12:13 -0400, Dan Williams wrote:
On Mon, 2007-06-25 at 16:09 +0200, dragoran wrote:
On 6/25/07, yelo_3 [EMAIL PROTECTED] wrote:
ok, but this does not solve the problem of multiple
killswitches (will
show up with multiple cards) because both will have
/org/freedesktop/Hal/devices/ipw_wlan_switch as uid.
Yes the previous shell script didn't solve the problem...
sorry. This might mean that the UDI should contain the
interface name as you were saying
The C code misses the setrfkill section, and a !=null check
when you fopen the file.
ok here is a new version.
it implements setrfkill too and uses g_strdup_printf instead of
sprintf.
I don't think argc == 3 is valid for the setrfkill check, since the
number of args will still be 2... I'd just put a check before the
libhal_ctx_init() that does:
if (argc != 2) {
fprintf (stderr, Usage: ipwWirelessCtl [getrfkill] [setrfkill [1|0]]\n);
return -1;
}
or something like that, and get rid of the argc checks for getrfkill and
setrfkill.
I think we should actually just reparent the device to be a child of
Computer. I also think the script should just rfkill _everything_, and
that it should return '1' if _any_ ipw radios are off. This script is
really only a stopgap until the _real_ kernel rfkill interfaces are
complete, and then most these problems go away. So instead of trying to
overengineer the whole thing, I think it should work like this:
a) .fdi file adds _one_ rfkill device if any ipw cards are found
b) 'ipwWirelessCtl getrfkill' checks all ipw devices for rfkill status,
and if one of them is killed, it returns 1
c) 'ipwWirelessCtl setrfkill 1' kills _all_ ipw devices, while
'ipwWirelessCtl 0' re-enables _all_ ipw devices
Sound OK? That way we also don't have to figure out how to unique-ify
the device name, which the future kernel patches will handle for us.
I've attached an updated .fdi file for ipw devices that excludes Dells,
and makes only _one_ killswitch device.
Please attach the killswitch to the device itself, not the computer.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Wed, 2007-06-27 at 15:38 +0200, dragoran wrote: Bastien Nocera wrote: On Sun, 2007-06-24 at 22:15 +0200, dragoran wrote: here is a C implementation of the ipwWirelessCtl the udi is hardcoded and I only implemented get for now (will add the rest tomorrow). It also uses all values from the README. yelo_3 you have a typo in your patch (you used getrfkill instead of set ;) ) Bastien: the UDI that will get passed to the script would be that of the killswitch corret? Yes, and it will be passed as a envvar, as in the other scripts. ok HAL_PROP_UDI ? HAL_PROP_INFO_UDI I believe. programm is attached... any comments? As this will live in HAL, it should have a better name (Dan was only mimicking the name of the Dell rfkill-helper). ok that shouldn't be the problem. any idea how to exclude dell laptops in the .fdi? No idea, but I'm no fdi file guru. Probably a good idea to move this discussion to the HAL list, so you can get comments directly from the horse's mouth. -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Wed, 2007-06-27 at 15:46 +0200, dragoran wrote: Bastien Nocera wrote: snip ok will fix the program to use the env var and open a thread on the hal list. is it subscribers only list or can I post directly to it? No idea, I believe it's subscribers only though. -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Sun, 2007-06-24 at 13:00 +, yelo_3 wrote: Starting from the scripts Dan provided, I tried to add set to them. Here is what I've done Same problems as Dan's scripts, I'll reiterate: You need to disable your script for Dell laptops, in the fdi, otherwise you end up with 2 levels of rfkill, one at the card level, one at the BIOS level. The shell script should be in C, and probably use the UDI passed to it, instead of looking for the device by hand. Finally, You don't handle values 2 and 3 in the Get. From the ipw2200 README: rf_kill read - 0 = RF kill not enabled (radio on) 1 = SW based RF kill active (radio off) 2 = HW based RF kill active (radio off) 3 = Both HW and SW RF kill active (radio off) write - 0 = If SW based RF kill active, turn the radio back on 1 = If radio is on, activate SW based RF kill NOTE: If you enable the SW based RF kill and then toggle the HW based RF kill from ON - OFF - ON, the radio will NOT come back on -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how to have rfkill supported by hal?
On Fri, 2007-06-22 at 23:21 -0400, Dan Williams wrote: On Fri, 2007-06-22 at 18:34 +, yelo_3 wrote: HAL should be fixed to work with ACPI-based laptops. For now, I'd suggest a small daemon that monitors ACPI events (or, have acpid callout scripts write the status to a file somewhere), and then add a section to the HAL rfkill script to read that file for rfkill status. Dan I have acpid installed. I have a script that manually changes /sys/class/net/eth1/device/rf_kill what else should I add to the script, to talk to hal rfkill? I whipped something together in about 30 minutes for ipw2200 and ipw2100 users. You don't need to add anything to that acpi-triggered script; you need to do the following using the attachments I've provided (locations assume Fedora): cp 10-ipw-rfkill-switch.fdi /usr/share/hal/fdi/information/10freedesktop/ cp hal-system-ipw /usr/libexec/hal-system-ipw chmod 755 /usr/libexec/hal-system-ipw cd /usr/lib/hal/scripts/linux patch -p0 /path/to/hal-system-killswitch-get-power-linux.diff Restart HAL, and you're good to go. davidz/bastien: comments? the shellscript could possibly be better of course. If only it was that easy ;) You need to disable your script for Dell laptops, in the fdi, otherwise you end up with 2 levels of rfkill, one at the card level, one at . The shell script should be in C, and probably use the UDI passed to it, instead of looking for the device by hand. Finally, You don't handle values 2 and 3 in the Get. From the ipw2200 README: rf_kill read - 0 = RF kill not enabled (radio on) 1 = SW based RF kill active (radio off) 2 = HW based RF kill active (radio off) 3 = Both HW and SW RF kill active (radio off) write - 0 = If SW based RF kill active, turn the radio back on 1 = If radio is on, activate SW based RF kill NOTE: If you enable the SW based RF kill and then toggle the HW based RF kill from ON - OFF - ON, the radio will NOT come back on You can also support the ipw3945 driver with the same settings. I believe that the iwlwifi drivers are also supportable with the same script. Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM support for Bluetooth NAP connections possible?
On Tue, 2007-06-19 at 08:04 -0400, Dan Williams wrote: snip There are patches for bluetooth PAN in Gnome.org CVS, though I've taken Should read SVN here, I guess. a look at them and I think they need at least another revision (use blocking D-Bus calls, and I think they are a bit too high-level). We definitely want to support various BT network configurations including PAN and DUN. Is that the same code as http://bugzilla.gnome.org/show_bug.cgi?id=432774 ? Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Killswitch Patch
On Thu, 2007-06-14 at 17:13 -0400, Benjamin Kreuter wrote: Hi all -- This patch adds support for HAL's new killswitch functionality. It is somewhat rudimentary and needs a bit of work (little things, nothing major), but I do not have the hardware to test the functionality. Can somebody test this? HAL should support killswitchs on Dell and VAIO laptops. Only Dells support the WLAN killswitch, the VAIOs only support Bluetooth. -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [OT] Is there a how-to on importing a CISCO certificate file to VPNC?
On Wed, 2007-06-13 at 13:01 -0400, Christopher Aillon wrote: Bastien Nocera wrote: On Wed, 2007-06-13 at 03:14 +0530, Rogue wrote: Hi All, I am trying to remove my current dependency of Cisco VPN client by switching to VPNC. Unfortunately I am not able to locate any useful documentation on the web :-( .. Has anyone on this list succeeded in doing this? I see that there are certificates and a shared key to be used, but not sure how to go about with it. NetworkManager-vpnc should have an importer for .pcf files, which contain the VPM definition. This page will allow you to decode the shared password, then you only need your username and password. http://www.unix-ag.uni-kl.de/~massar/bin/cisco-decode We probably ought to do the decoding ourselves, which might be a little tricky, but worthwhile IMO. Filed http://bugzilla.gnome.org/show_bug.cgi?id=447222 Actually, see: http://bugzilla.gnome.org/show_bug.cgi?id=322820 Dan doesn't want it in NM itself, so just parsing the output of the decrypt binary would be good enough, IMO. -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: blocking bug for laptop users (OT sightly )
On Fri, 2007-05-25 at 15:21 +0530, Ritesh Khadgaray wrote: snip Is this supposed to send a dbus message ? The only thing i was able to see is bluez hardware removed, and thats all :( I use a Dell D620 , with rkill switch mapped against bluetooth, and wireless . Which is what's supposed to happen for Bluetooth on Dells. The API is explained in the HAL spec. It's mainly useful to deactivate a Bluetooth or WLAN device in software, not really to see what a possible rfkill switch in hardware does... -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: blocking bug for laptop users
On Thu, 2007-05-24 at 14:20 -0400, Dan Williams wrote: Apparently HAL 0.5.9 has limited rfkill support, and that's what we should be hooking into with NM now. I know, I implemented that with David :) -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: blocking bug for laptop users
On Tue, 2007-05-22 at 20:03 +, yelo_3 wrote: it is blocking because people using a hotkey to switch of/off wireless, will see a different status in the applet: - the hotkey toggles wireless using the dbus method setWirelessEnabled - the applet does not update itself, so the user who disables wireless, will see in the applet that wireless is enabled, and the exact list of wireless network that were active before he had hit the hotkey That's not the right way to do it, especially as some hotkeys act directly on the hardware. The correct way to do it is: - have HAL do get/set on the hardware (either using custom APIs for each models, like already implemented for Dells, or the generic kernel rfkill API) - Make NetworkManager handle the get/set from the hardware -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Feature request: restarting NM from nm-applet
On Mon, 2007-03-12 at 16:27 +0100, Radek Vokál wrote: I have issues with nm-applet and probably dbus, which doesn't recognize my USB Cable modem. So every time I plug in the USB modem I have to restart NetworkManager by hand. Same with my wireless card which has the switch off/on button. So I would like to see a restart option (or rather rescan option) in nm-applet which will look for recently added/removed NICs. You should fix HAL to show your newly plugged in devices properly instead. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
rt73 driver trouble
Heya, I was wondering what needed adding to the rt73 driver to fix that problem up: Jan 22 23:28:42 cookie NetworkManager: informationwpa_supplicant(18094): wpa_driver_wext_set_key: alg=1 key_idx=0 set_tx=1 seq_len=0 key_len=13 Jan 22 23:28:42 cookie NetworkManager: informationwpa_supplicant(18094): Driver did not support SIOCSIWENCODEEXT, trying SIOCSIWENCODE Jan 22 23:28:42 cookie NetworkManager: informationwpa_supplicant(18094): wpa_driver_wext_set_drop_unencrypted Jan 22 23:28:42 cookie NetworkManager: informationwpa_supplicant(18094): State: SCANNING - ASSOCIATING Jan 22 23:28:42 cookie NetworkManager: informationwpa_supplicant(18094): wpa_driver_wext_associate Jan 22 23:28:42 cookie NetworkManager: informationwpa_supplicant(18094): WEXT: Driver did not support SIOCSIWAUTH for AUTH_ALG, trying SIOCSIWENCODE Jan 22 23:28:42 cookie NetworkManager: informationwpa_supplicant(18094): wpa_driver_wext_associate: assoc failed because set_gen_ie failed Jan 22 23:29:01 cookie NetworkManager: informationActivation (rausb0/wireless): association took too long (20s), failing activation. Jan 22 23:29:01 cookie NetworkManager: informationActivation (rausb0) failure scheduled... Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: What distros have intltool 0.35.0?
On Thu, 2006-08-10 at 21:17 -0400, Dan Williams wrote: Hi, I'd like to apply the patch in http://bugzilla.gnome.org/show_bug.cgi?id=343132 to HEAD. However, it appears to require intltool 0.35.0 or later. This patch is not critical and the development versions of some distros that NM supports don't have that, please let me know, and we can push the patch back a bit. But at some point, I'd like to have a flag day and require intltool 0.35.0 on HEAD. I've already had cases where people ask me to modify configure.in, which is fine but not ideal for translators. The requirement is a package-time one, ie. once the tarball is dist'ed, you don't need intltool installed, it's in the tarball. Just like needing a new autoconf if you're not going to re-autogen... FC5 still has an old version, and rawhide/FC6 has it. -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Flaky association with ipw2200 and Linksys WRT54G
On Sun, 2006-04-23 at 10:55 -0400, Wendell MacKenzie wrote: Hi: My earlier reported issue was solved by Robert Hancock's recommendation from Bill Moss's posting that the ipw2200 version 1.1.2 along with NetworkManager 0.6.2 is broken and causes multiple scans to occur before giving up. http://www.ces.clemson.edu/linux/fc2-ipw2200.shtml I commented out the block in ipw2200.c and rebuilt the driver, reloaded and I can now connect to my AP. Unlike you, I still can't use NetworkManager with this same setup (ipw2200 and WRT54G router), despite having followed Bill's document already. So is this a NetworkManager issue or an ipw2200 driver issue? Bill mentions it is an NM issue. -- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Use NetworkManager to connect with a Vodafone Connect Card
On Fri, 2006-01-13 at 18:02 +, [EMAIL PROTECTED] wrote: Hello I would like to know if there is any developer of this excelent application that want to implement this. The NetworkManager should detect the Vodafone card and when we try to connect ask for the PIN (or store it anywhere) I have the scripts to the pppd connect and I can post here. Some portuguese guy made it. I think that Vodafone Connect Card is the same for all contries. I'm from Portugal. We need full fledged PPP support in NM. Bluetooth over GPRS/3G is easy: you need to know the provider/country and the mobile phone to use for the connection. --- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and NIS
On Tue, 2005-12-13 at 13:11 -0500, Dan Williams wrote: On Tue, 2005-12-13 at 18:15 +0100, Stefan Scheler wrote: snip What's still to be done is to set up the nis domain name and modify yp.conf accordingly. This should probably placed somehow in the distribution specific backends (i don't know how distribution specific that task really is)? It likely will be distro-specific. I don't know if anyone has cooked up a resolvconf-type thing to manage yp.conf yet, but surely fewer apps fight over it than resolv.conf. It might be adequate to just not care about this until we find out another tool that wants to write yp.conf as well. The other issue is how to alert the system that yp.conf has changed... On FC and RHEL, you would need to modify /etc/sysconfig/network (to set the NISDOMAIN) and do a service ypbind restart. It would be pretty gross, as ypbind would take a long time to timeout if there are problems. --- Bastien Nocera [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
