Gobi 3000 (1199:901F)

[Jeremy Moles]

Hey everyone! I'm not entirely sure where else to ask this, and I'm 
somewhat desperate at this point having tried everything I'm capable of.


We have a machine here with the card listed in the subject. It shows up 
in lsusb as:


1199:901f Sierra Wireless, Inc.

It will work in Linux so far if--and ONLY IF--you boot into Windows 
first and then soft reboot into Linux. it appears that Windows does 
something to the modem that Linux (currently) does not, and I was 
wondering if anyone here had any advice on what I might try.


What I've done so far:

1) There is a knob in the sysfs hierarchy for this device that lets me 
change the "config" (or something like that, I'm actually working on 
this machine remotely and the customer isn't available right now!) from 
1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing 
so the tty's appear and the device is ready to be perturbed. It responds 
to ATI commands and whatnot, but again, won't work properly unless 
booted in Windows first. I should mention I found this knob entirely by 
accident while hacking on qcserial and trying to accept different "port" 
numbers as they enumerated themselves...


2) I downloaded the CodeAurora GobiSerial driver (which, according to 
the changelog has a fix for "powering on" a device) and modified it to 
work with 3.17 and 3.18 kernels (essentially, this involved re-exporting 
usb-serial.c symbols like usb_serial_probe the code relied on). However, 
I haven't had a chance to try this yet, and I'm not entirely convinced 
(after looking through the code) it really does anything qcserial doesn't.


Anyways, if anyone has any advice, please let us know!
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Gobi 3000 (1199:901F)

[Jeremy Moles]

On 01/09/2015 12:01 PM, Jeremy Moles wrote:
Hey everyone! I'm not entirely sure where else to ask this, and I'm 
somewhat desperate at this point having tried everything I'm capable of.


We have a machine here with the card listed in the subject. It shows 
up in lsusb as:


1199:901f Sierra Wireless, Inc.

It will work in Linux so far if--and ONLY IF--you boot into Windows 
first and then soft reboot into Linux. it appears that Windows does 
something to the modem that Linux (currently) does not, and I was 
wondering if anyone here had any advice on what I might try.


What I've done so far:

1) There is a knob in the sysfs hierarchy for this device that lets me 
change the "config" (or something like that, I'm actually working on 
this machine remotely and the customer isn't available right now!) 
from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after 
doing so the tty's appear and the device is ready to be perturbed. It 
responds to ATI commands and whatnot, but again, won't work properly 
unless booted in Windows first. I should mention I found this knob 
entirely by accident while hacking on qcserial and trying to accept 
different "port" numbers as they enumerated themselves...


2) I downloaded the CodeAurora GobiSerial driver (which, according to 
the changelog has a fix for "powering on" a device) and modified it to 
work with 3.17 and 3.18 kernels (essentially, this involved 
re-exporting usb-serial.c symbols like usb_serial_probe the code 
relied on). However, I haven't had a chance to try this yet, and I'm 
not entirely convinced (after looking through the code) it really does 
anything qcserial doesn't.


Anyways, if anyone has any advice, please let us know!
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


I should also mention I JUST found this thread:

http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html

Which explains exactly what I was seeing when talking about my #1 
attempt (the config option in sysfs; again, it's miraculously I found 
that at all).


I can't piece together everything the thread is talking about, but it 
may job someone's memory. I can also try e-mailing the author of that 
thread directly.

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Gobi 3000 (1199:901F)

[Adam Tauno Williams]

On Fri, 2015-01-09 at 12:01 -0500, Jeremy Moles wrote: 
> Hey everyone! I'm not entirely sure where else to ask this, and I'm 
> somewhat desperate at this point having tried everything I'm capable of.
> We have a machine here with the card listed in the subject. It shows up 
> in lsusb as:
> 1199:901f Sierra Wireless, Inc.
> It will work in Linux so far if--and ONLY IF--you boot into Windows 
> first and then soft reboot into Linux. it appears that Windows does 
> something to the modem that Linux (currently) does not, and I was 
> wondering if anyone here had any advice on what I might try.

It works if you boot into Windows first because the driver in windows
'uploads' the firmware into the device and 'boots' it.  Then it is
operational until the device is power cycled either by the host being
power cycled *or* the host powering off the device [hibernation, etc...]

> 2) I downloaded the CodeAurora GobiSerial driver (which, according to 
> the changelog has a fix for "powering on" a device) and modified it to 
> work with 3.17 and 3.18 kernels (essentially, this involved re-exporting 
> usb-serial.c symbols like usb_serial_probe the code relied on). However, 
> I haven't had a chance to try this yet, and I'm not entirely convinced 
> (after looking through the code) it really does anything qcserial doesn't.

If this driver uploads the binary wad it is likely this will work.

At least this reflects my previous experience getting a Gobi device to
work; albeit of a different vintage.

-- 
Adam Tauno Williams  GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

How Embedded is NetworkManager

[Richard Willis]

I'm posting this question first just to ascertain if using NetworkManager is 
possible in the embedded project I am working on.

This project uses multiple networking interfaces (Eth, WiFi, GSM-Radio, 
Bluetooth) but runs as a "headless" black box, gathering telemetry information 
and providing some gateway support. NetworkManager would be a very good fit for 
this device, but I am concerned that NetworkManager may have link dependencies 
for GUI support, something the product does not have.

I'm interesting in hearing if anyone has tried running NetworkManager without 
any GUI.. is it possible?

FYI, product is similar to a BeagleBone Black.. OS is a variant of Yocto, but 
we can run Debian Wheezy for initial experimentations.

Thanks,


Richard Willis * Sr Embedded S/W Engineer * Webtech Wireless Inc.
Direct +1 604 484 1304 * Front Desk +1 604 434 7337 * FAX +1 604 434 5270
richard.wil...@webtechwireless.com

Webtech Wireless  |  
InterFleet  |  
Quadrant  |  Telematics for the Planet (r)

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Connman WiFi p2p API evaluation

[Bastien Nocera]

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: How Embedded is NetworkManager

[Dan Winship]

On 01/09/2015 12:45 PM, Richard Willis wrote:
> This project uses multiple networking interfaces (Eth, WiFi, GSM-Radio,
> Bluetooth) but runs as a “headless” black box, gathering telemetry
> information and providing some gateway support. NetworkManager would be
> a very good fit for this device, but I am concerned that NetworkManager
> may have link dependencies for GUI support, something the product does
> not have.
> 
> I’m interesting in hearing if anyone has tried running NetworkManager
> without any GUI.. is it possible?

NetworkManager itself has no gui dependency, and as of 0.9.10, there's a
curses-based connection editor (nmtui) so you don't even have to write
out the config files by hand if you don't want to. (In addition to
"nmcli", which is a more powerful command-line-based tool that can be
used to perform just about any operation that NetworkManager exposes
over D-Bus.)

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How Embedded is NetworkManager

[W. Martin Borgert]

Quoting Richard Willis :
I'm interesting in hearing if anyone has tried running  
NetworkManager without any GUI.. is it possible?


Yes, absolutely. I'm using NM and MM in an embedded product since
some years now. Not without problems, but mostly successfully.

FYI, product is similar to a BeagleBone Black.. OS is a variant of  
Yocto, but we can run Debian Wheezy for initial experimentations.


Debian Squeeze here, with possible future change to Debian Jessie.

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How Embedded is NetworkManager

[Thomas Haller]

On Fri, 2015-01-09 at 17:45 +, Richard Willis wrote:
> I’m posting this question first just to ascertain if using
> NetworkManager is possible in the embedded project I am working on.
> 
>  
> 
> This project uses multiple networking interfaces (Eth, WiFi,
> GSM-Radio, Bluetooth) but runs as a “headless” black box, gathering
> telemetry information and providing some gateway support.
> NetworkManager would be a very good fit for this device, but I am
> concerned that NetworkManager may have link dependencies for GUI
> support, something the product does not have.
> 
>  
> 
> I’m interesting in hearing if anyone has tried running NetworkManager
> without any GUI.. is it possible?
> 
>  
> 
> FYI, product is similar to a BeagleBone Black.. OS is a variant of
> Yocto, but we can run Debian Wheezy for initial experimentations.
> 
>  
> 
> Thanks,
> 
Hi Richard,

we are very much interested in NetworkManager being able to run in
restricted environments (whatever that means exactly :) ).

So, in general I would expect NetworkManager to work well for you. And
if you encounter any issues, we would be happy to hear about them.

Especially if you compile NetworkManager yourself, you should be able to
reduce dependencies further. YMMV.


good luck,
Thomas



signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Gobi 3000 (1199:901F)

[Jeremy Moles]

On 01/09/2015 12:16 PM, Adam Tauno Williams wrote:

On Fri, 2015-01-09 at 12:01 -0500, Jeremy Moles wrote:

Hey everyone! I'm not entirely sure where else to ask this, and I'm
somewhat desperate at this point having tried everything I'm capable of.
We have a machine here with the card listed in the subject. It shows up
in lsusb as:
1199:901f Sierra Wireless, Inc.
It will work in Linux so far if--and ONLY IF--you boot into Windows
first and then soft reboot into Linux. it appears that Windows does
something to the modem that Linux (currently) does not, and I was
wondering if anyone here had any advice on what I might try.

It works if you boot into Windows first because the driver in windows
'uploads' the firmware into the device and 'boots' it.  Then it is
operational until the device is power cycled either by the host being
power cycled *or* the host powering off the device [hibernation, etc...]


2) I downloaded the CodeAurora GobiSerial driver (which, according to
the changelog has a fix for "powering on" a device) and modified it to
work with 3.17 and 3.18 kernels (essentially, this involved re-exporting
usb-serial.c symbols like usb_serial_probe the code relied on). However,
I haven't had a chance to try this yet, and I'm not entirely convinced
(after looking through the code) it really does anything qcserial doesn't.

If this driver uploads the binary wad it is likely this will work.

At least this reflects my previous experience getting a Gobi device to
work; albeit of a different vintage.



The firmware these days looks to be called:

carrier_pri.nvu
spkg_sblz.cwe

...though I'm used to the .mbn files, so I'm not entirely sure what to do.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Connman WiFi p2p API evaluation

[Dan Williams]

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: Gobi 3000 (1199:901F)

[Dan Williams]

On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote:
> On 01/09/2015 12:01 PM, Jeremy Moles wrote:
> > Hey everyone! I'm not entirely sure where else to ask this, and I'm 
> > somewhat desperate at this point having tried everything I'm capable of.
> >
> > We have a machine here with the card listed in the subject. It shows 
> > up in lsusb as:
> >
> > 1199:901f Sierra Wireless, Inc.
> >
> > It will work in Linux so far if--and ONLY IF--you boot into Windows 
> > first and then soft reboot into Linux. it appears that Windows does 
> > something to the modem that Linux (currently) does not, and I was 
> > wondering if anyone here had any advice on what I might try.
> >
> > What I've done so far:
> >
> > 1) There is a knob in the sysfs hierarchy for this device that lets me 
> > change the "config" (or something like that, I'm actually working on 
> > this machine remotely and the customer isn't available right now!) 
> > from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after 
> > doing so the tty's appear and the device is ready to be perturbed. It 
> > responds to ATI commands and whatnot, but again, won't work properly 
> > unless booted in Windows first. I should mention I found this knob 
> > entirely by accident while hacking on qcserial and trying to accept 
> > different "port" numbers as they enumerated themselves...
> >
> > 2) I downloaded the CodeAurora GobiSerial driver (which, according to 
> > the changelog has a fix for "powering on" a device) and modified it to 
> > work with 3.17 and 3.18 kernels (essentially, this involved 
> > re-exporting usb-serial.c symbols like usb_serial_probe the code 
> > relied on). However, I haven't had a chance to try this yet, and I'm 
> > not entirely convinced (after looking through the code) it really does 
> > anything qcserial doesn't.
> >
> > Anyways, if anyone has any advice, please let us know!
> > ___
> > networkmanager-list mailing list
> > networkmanager-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/networkmanager-list
> >
> I should also mention I JUST found this thread:
> 
> http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html
> 
> Which explains exactly what I was seeing when talking about my #1 
> attempt (the config option in sysfs; again, it's miraculously I found 
> that at all).
> 
> I can't piece together everything the thread is talking about, but it 
> may job someone's memory. I can also try e-mailing the author of that 
> thread directly.

When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'?
Also grab 'dmesg' output to see what driver messages there are.  Next,
if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and
lets see what we have.

Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list
-m 0' in case the previous one didn't work.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Aw: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?

[Thomas Schneider]

Hi,

 

here's an update on your questions

 

Let's start with the version of nmcli:


user@pc1-asus:~$ nmcli -v
nmcli-Werkzeug, Version 0.9.10.0

 

Now permissions:


user@pc1-asus:~$ nmcli general permissions
BEFUGNIS WERT  
org.freedesktop.NetworkManager.enable-disable-network    nein  
org.freedesktop.NetworkManager.enable-disable-wifi   nein  
org.freedesktop.NetworkManager.enable-disable-wwan   nein  
org.freedesktop.NetworkManager.enable-disable-wimax  nein  
org.freedesktop.NetworkManager.sleep-wake    nein  
org.freedesktop.NetworkManager.network-control   nein  
org.freedesktop.NetworkManager.wifi.share.protected  nein  
org.freedesktop.NetworkManager.wifi.share.open   nein  
org.freedesktop.NetworkManager.settings.modify.system    nein  
org.freedesktop.NetworkManager.settings.modify.own   Legitimierung
org.freedesktop.NetworkManager.settings.modify.hostname  Legitimierung

 

Output when running nm-applet w/o root permission:


user@pc1-asus:~$ nm-applet

(nm-applet:1167): libnm-glib-CRITICAL **: nm_secret_agent_register: assertion 'priv->registered == FALSE' failed

(nm-applet:1167): nm-applet-WARNING **: VPN Connection activation failed: (org.freedesktop.NetworkManager.PermissionDenied) Not authorized to control networking.

 

Error message in /var/log/syslog:
Jan  9 20:41:34 pc1-asus NetworkManager[5393]:  Failed to activate 'Netzwerk-Thomas-VPN': Not authorized to control networking.

 

The current config file for the required VPN connection is:


user@pc1-asus:~$ sudo cat /etc/NetworkManager/system-connections/VPN
[connection]
id=VPN
uuid=a6ae2fac-4776-4f74-962c-a63113xx
type=vpn
permissions=user::;
autoconnect=false

[vpn]
service-type=org.freedesktop.NetworkManager.openvpn
connection-type=tls
auth=SHA256
remote=
cipher=AES-256-CBC
comp-lzo=yes
tunnel-mtu=1500
cert-pass-flags=1
cert=/etc/openvpn/config/server.crt
ca=/etc/openvpn/config/server.pem
key=/etc/openvpn/config/server.key
ta=/etc/openvpn/config/ta.key

[ipv6]
method=auto
ip6-privacy=0

[ipv4]
method=auto

 

This config file works perfectly when calling sudo nmcli.



 

I have identified that any user without root permission can utilize NetworkManager and ncmli respectively. In other words, the user needs to be member and run any command with "sudo".

This is also true for using any device connected via USB, e.g. scanner or USB memory stick.


 

 

THX


 

Gesendet: Donnerstag, 08. Januar 2015 um 17:39 Uhr
Von: "Dan Williams" 
An: poma 
Cc: "Thomas Schneider" , networkmanager-list@gnome.org
Betreff: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?

On Wed, 2015-01-07 at 23:42 +0100, poma wrote:
> On 07.01.2015 18:29, Dan Williams wrote:
> > On Mon, 2015-01-05 at 19:14 +0100, Thomas Schneider wrote:
> >> Hello!
> >>
> >> I have installed latest version of NetworkManager and nmcli
> >> respectively + OpenVPN plugin or NetworkManager.
> >>
> >> user@pc1-asus:~$ apt-cache policy network-manager
> >> network-manager:
> >> Installiert: 0.9.10.0-5
> >> Installationskandidat: 0.9.10.0-5
> >> Versionstabelle:
> >> *** 0.9.10.0-5 0
> >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages
> >> 100 /var/lib/dpkg/status
> >> user@pc1-asus:~$ apt-cache policy network-manager-gnome
> >> network-manager-gnome:
> >> Installiert: 0.9.10.0-2
> >> Installationskandidat: 0.9.10.0-2
> >> Versionstabelle:
> >> *** 0.9.10.0-2 0
> >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages
> >> 100 /var/lib/dpkg/status
> >> user@pc1-asus:~$ apt-cache policy network-manager-openvpn
> >> network-manager-openvpn:
> >> Installiert: 0.9.10.0-1
> >> Installationskandidat: 0.9.10.0-1
> >> Versionstabelle:
> >> *** 0.9.10.0-1 0
> >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages
> >> 100 /var/lib/dpkg/status
> >> user@pc1-asus:~$ apt-cache policy network-manager-openvpn-gnome
> >> network-manager-openvpn-gnome:
> >> Installiert: 0.9.10.0-1
> >> Installationskandidat: 0.9.10.0-1
> >> Versionstabelle:
> >> *** 0.9.10.0-1 0
> >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages
> >> 100 /var/lib/dpkg/status
> >>
> >> All maintained connections are working. This includes OpenVPN
> >> connection type, too.
> >> However, in order to use either nm-applet or command-line client
> >> nmcli, I need to be root.
> >> The issue I'm facing is that with older release I could use either
> >> nm-applet or nmcli without root authorization.
> >> This becomes a critical issue in a multi-user desktop PC where most
> >> user neither have root authorization nor can utilize sudo.
> >>
> >> Question:
> >> How can I ensure that both, nm-applet and nmcli, can be used without
> >> root authorization?
> >
> > It's certainly intended that they can all be used without root. When
> > you try to run 'nmcli' as a nor

Re: How Embedded is NetworkManager

[Dan Williams]

On Fri, 2015-01-09 at 17:45 +, Richard Willis wrote:
> I'm posting this question first just to ascertain if using NetworkManager is 
> possible in the embedded project I am working on.
> 
> This project uses multiple networking interfaces (Eth, WiFi, GSM-Radio, 
> Bluetooth) but runs as a "headless" black box, gathering telemetry 
> information and providing some gateway support. NetworkManager would be a 
> very good fit for this device, but I am concerned that NetworkManager may 
> have link dependencies for GUI support, something the product does not have.
> 
> I'm interesting in hearing if anyone has tried running NetworkManager without 
> any GUI.. is it possible?
> 
> FYI, product is similar to a BeagleBone Black.. OS is a variant of Yocto, but 
> we can run Debian Wheezy for initial experimentations.

In addition to the other replies, if you want to build for a single-user
embedded system, there are some configure-time options you might want:

--with-session-tracking=none (don't require consolekit or systemd)
--with-suspend-resume=upower (don't require systemd)
--with-selinux=no (don't require libselinux)
--enable-teamdctl=no (don't use libteam)
--enable-polkit=no (don't use PolicyKit)
--with-libsoup=no (don't do connectivity checking)

Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Connman WiFi p2p API evaluation

[Bastien Nocera]

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  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: Aw: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?

[Dan Williams]

On Fri, 2015-01-09 at 20:49 +0100, Thomas Schneider wrote:
> Hi,
>  
> here's an update on your questions
>  
> Let's start with the version of nmcli:
> user@pc1-asus:~$ nmcli -v
> nmcli-Werkzeug, Version 0.9.10.0
>  
> Now permissions:
> user@pc1-asus:~$ nmcli general permissions
> BEFUGNIS WERT
>  
> org.freedesktop.NetworkManager.enable-disable-networknein

Ok, this indicates that PolicyKit is denying the permissions to these
users.  The most likely reason is that NM has been built with
--with-session-tracking=[ck|systemd] and something is not properly
setting up the login sessions with ConsoleKit or systemd.

PolicyKit has a concept of active (eg, using the computer right now) and
inactive (idle or non-human users) sessions.  NetworkManager uses these
for fast-user-switching and some permissions control.  It's likely that
all users on your machine are considered "inactive" according to
PolicyKit and thus being denied.

What do you get for the following commands?

ck-list-sessions
loginctl
loginctl show-session X (repeat for all sessions from 'loginctl')

if you're using ConsoleKit, your session manager needs to tell
ConsoleKit that it's starting a new session.  I'm not quite sure how
that happens with systemd, but it does somehow.

Alternatively, if you don't care about user permissions and want to
allow any user to control networking you can build NM with
--with-session-tracking=none and --with-polkit=no to disable this
functionality.

Dan
 
> org.freedesktop.NetworkManager.enable-disable-wifi   nein
>  
> org.freedesktop.NetworkManager.enable-disable-wwan   nein
>  
> org.freedesktop.NetworkManager.enable-disable-wimax  nein
>  
> org.freedesktop.NetworkManager.sleep-wakenein
>  
> org.freedesktop.NetworkManager.network-control   nein
>  
> org.freedesktop.NetworkManager.wifi.share.protected  nein
>  
> org.freedesktop.NetworkManager.wifi.share.open   nein
>  
> org.freedesktop.NetworkManager.settings.modify.systemnein
>  
> org.freedesktop.NetworkManager.settings.modify.own   Legitimierung
> org.freedesktop.NetworkManager.settings.modify.hostname  Legitimierung
>  
> Output when running nm-applet w/o root permission:
> user@pc1-asus:~$ nm-applet
> (nm-applet:1167): libnm-glib-CRITICAL **: nm_secret_agent_register:
> assertion 'priv->registered == FALSE' failed
> (nm-applet:1167): nm-applet-WARNING **: VPN Connection activation
> failed: (org.freedesktop.NetworkManager.PermissionDenied) Not
> authorized to control networking.
>  
> Error message in /var/log/syslog:
> Jan  9 20:41:34 pc1-asus NetworkManager[5393]:  Failed to
> activate 'Netzwerk-Thomas-VPN': Not authorized to control networking.
>  
> The current config file for the required VPN connection is:
> user@pc1-asus:~$ sudo cat /etc/NetworkManager/system-connections/VPN
> [connection]
> id=VPN
> uuid=a6ae2fac-4776-4f74-962c-a63113xx
> type=vpn
> permissions=user::;
> autoconnect=false
> [vpn]
> service-type=org.freedesktop.NetworkManager.openvpn
> connection-type=tls
> auth=SHA256
> remote=
> cipher=AES-256-CBC
> comp-lzo=yes
> tunnel-mtu=1500
> cert-pass-flags=1
> cert=/etc/openvpn/config/server.crt
> ca=/etc/openvpn/config/server.pem
> key=/etc/openvpn/config/server.key
> ta=/etc/openvpn/config/ta.key
> [ipv6]
> method=auto
> ip6-privacy=0
> [ipv4]
> method=auto
>  
> This config file works perfectly when calling sudo nmcli.
>  
> I have identified that any user without root permission can utilize
> NetworkManager and ncmli respectively. In other words, the user needs
> to be member and run any command with "sudo".
> This is also true for using any device connected via USB, e.g. scanner
> or USB memory stick.
>  
>  
> THX
>   
> Gesendet: Donnerstag, 08. Januar 2015 um 17:39 Uhr
> Von: "Dan Williams" 
> An: poma 
> Cc: "Thomas Schneider" , networkmanager-list@gnome.org
> Betreff: Re: Only root can utilize nm-applet and nmcli as part of
> NetworkManager - how can other users use it w/o root?
> On Wed, 2015-01-07 at 23:42 +0100, poma wrote:
> > On 07.01.2015 18:29, Dan Williams wrote:
> > > On Mon, 2015-01-05 at 19:14 +0100, Thomas Schneider wrote:
> > >> Hello!
> > >>
> > >> I have installed latest version of NetworkManager and nmcli
> > >> respectively + OpenVPN plugin or NetworkManager.
> > >>
> > >> user@pc1-asus:~$ apt-cache policy network-manager
> > >> network-manager:
> > >> Installiert: 0.9.10.0-5
> > >> Installationskandidat: 0.9.10.0-5
> > >> Versionstabelle:
> > >> *** 0.9.10.0-5 0
> > >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages
> > >> 100 /var/lib/dpkg/status
> > >> user@pc1-asus:~$ apt-cache policy network-manager-gnome
> > >> network-manager-gnome:
> > >> Installiert: 0.9.10.0-2
> > >> Installationskandidat: 0.9.10.0-2
> > >> Versionstabelle:
> > >> *** 0.9.10.0-2 0
> > >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages
> > >> 100 /var/lib/dpkg/status
> > >> user@pc1-asus:~$ ap

Re: Connman WiFi p2p API evaluation

[Dan Williams]

On Fri, 2015-01-09 at 22:58 +0100, Bastien Nocera wrote:
> Vendor WEXT extensions do have that capability though (I recently ripped out 
> that vendor support in a Realtek driver).

NM's implementation would be via wpa_supplicant, and I'm 110% sure that
the supplicant will never support P2P through the WEXT driver :)  So in
the end, yeah, it'll be nl80211/cfg80211 only.

Dan

> > On 9 Jan 2015, at 20:25, Dan Williams  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