date:20120809

Re: 答复: Linux MBIM

2012-08-09 Thread Aleksander Morgado

Hi Franko,

> 
>   Do you have began to develop the MBIM driver for Linux kernel?
>   Do you have got the MBIM device for test?
>   
>   We are developing some devices to support MBIM protocol. We hope that 
> it can be used on Linux.
>   So I think that we maybe do some cooperation for this development.
>   What's your opinions?
> 

A bit out of topic now. ModemManager is currently getting support for
QMI-powered devices, like the Huawei E392. Would you guys be interested
in sponsoring some free devices for developers to test with?

Cheers,

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

[MM] [PATCH] iface-modem: increase number of trials for PIN check from 3 to 6

2012-08-09 Thread Ben Chan

In practice, it may take longer time for a SIM to become ready when the
modem interface tries to use AT+CPIN? to determine if the SIM is
PIN-locked. This patch increases the number of trials for PIN check to
address the issue.
---
 src/mm-iface-modem.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mm-iface-modem.c b/src/mm-iface-modem.c
index d347281..c8d1b96 100644
--- a/src/mm-iface-modem.c
+++ b/src/mm-iface-modem.c
@@ -2124,9 +2124,9 @@ unlock_check_ready (MMIfaceModem *self,
 error->message);
 g_error_free (error);
 
-/* Retry up to 3 times */
+/* Retry up to 6 times */
 if (mm_gdbus_modem_get_unlock_required (ctx->skeleton) != 
MM_MODEM_LOCK_NONE &&
-++ctx->pin_check_tries < 3) {
+++ctx->pin_check_tries < 6) {
 mm_dbg ("Retrying (%u) unlock required check", 
ctx->pin_check_tries);
 if (ctx->pin_check_timeout_id)
 g_source_remove (ctx->pin_check_timeout_id);
-- 
1.7.7.3

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

答复: 答复: Linux MBIM

2012-08-09 Thread Fangxiaozhi (Franko)

Dear Greg:
 Well, great.
 I think that you can send the driver to me, we can test the driver 
with our device,  and debug together.
 Of course, if necessary, we can send a device to you.
 OK?
Best Regards,
Franko Fang

发件人: Greg Suarez [mailto:gpsuarez2...@gmail.com]
发送时间: 2012年8月10日 9:50
收件人: Fangxiaozhi (Franko)
抄送: Bjørn Mork; NetworkManager List
主题: Re: 答复: Linux MBIM

Dear Franko,

I've begun modifying the cdc-ncm driver to support mbim devices.  I do have a 
device to test with but will welcome more devices if Huawei is willing to send 
one.

Thanks,

Greg
On Tue, Aug 7, 2012 at 11:49 PM, Fangxiaozhi (Franko) 
mailto:fangxiao...@huawei.com>> wrote:
Dear Mork & Greg:

Do you have began to develop the MBIM driver for Linux kernel?
Do you have got the MBIM device for test?

We are developing some devices to support MBIM protocol. We hope that 
it can be used on Linux.
So I think that we maybe do some cooperation for this development.
What's your opinions?

Best Regards,
Franko Fang

-邮件原件-
发件人: 
networkmanager-list-boun...@gnome.org

[mailto:networkmanager-list-boun...@gnome.org]
 代表 Bj?rn Mork
发送时间: 2012年7月19日 9:19
收件人: Greg Suarez
抄送: NetworkManager List
主题: Re: Linux MBIM

Greg Suarez mailto:gpsuarez2...@gmail.com>> writes:
> On Mon, Jul 16, 2012 at 12:28 AM, Bjørn Mork 
> mailto:bj...@mork.no>> wrote:
>
>> If I understand this correctly, MBIM devices will combine CDC NCM with a
>> MBIM control channel in the exact same way QMI devices combine CDC ECM
>> with a QMI control channel.  That means that the driver support could be
>> done as simple as combining cdc_ncm with the cdc_wdm subdriver (either
>> in the existing cdc_ncm driver, or as a new separate driver reusing code
>> from cdc_ncm).
>>
>> If this was done, then we would have the MBIM control channel exported
>> to userspace as a /dev/cdc-wdmX device, exactly like qmi_wwan exports
>> its QMI control channel.  Leaving MBIM control protocol implementation
>> for userspace make sense for the same reasons it made sense to leave QMI
>> implementation for userspace.  Boy, am I happy Marcel and others
>> convinced me to do that :-)
>>
>
> I was on the same line of thinking but wasn't aware of the QMI driver.
> Could you point out its location to me?

It's in mainline from 3.4:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/net/usb/qmi_wwan.c

The approach is pretty simple: Reuse the existing cdc_wdm driver as a
subdriver, giving it full ownership of the status interrupt endpoint.
cdc_wdm exports whatever protocol is encapsulated in CDC directly as a
character device. The driver does not care about the contents at all,
leaving that to userspace.  The bulk endpoints are handled by a normal
usbnet based minidriver.  The only difference from any other minidriver
like cdc_ether, is that the status endpoint is unavailable.  But the CDC
notifications are pretty useless anyway, when you have access to a full
management protocol like QMI or MBIM.

The exact same should work equally well for MBIM.  The network driver
part must of course be different, and a lot more complex.  But most of
it is already done in cdc_ncm.  Add push/pull of an ethernet
pseudo-header to make the raw IP packets appear as ethernet (there are
other options, but I believe adding a dummy header is best), and the
registration of the subdriver, and that's it!

Execpt of course for everything I forgot :-)

If I had a device, I would have started with a very simple usbnet +
cdc_wdm driver, verifying that userspace access to the MBIM protocol
worked as assumed.  In fact, qmi_wwan qualifies as that simple driver.
Just add a MBIM class matching rule there and go test MBIM management
from userspace.

The network interface will of course be non-functional.  To add support
for that, I would look thoroughly at cdc_ncm to find out which parts
could be reused and how to best do that without copying any code.  Then
I would start exporting the parts of cdc_ncm that I needed and integrate
them in the new driver.

Another approach, which might result in simpler code and therefore be
better, would be adding a few extra functions to cdc_ncm and just add
another driver instance there for MBIM.  Might be best, given the amount
of code that could and should be shared between these two drivers.

Last, there is the question of whether you should bother with the
Microsoft specific descriptors (the magic 0xee string descriptor and
it's friends) or not.  I don't think that is necessary, and there are
some reasons to stay away.  But then I haven't seen a MBIM device yet.
Could be that you need those descriptors to figure out the different
settings, in particular how to enable the alternate functions.

>> A question back to you, Greg:  Why do you ask?
>
>
> I ask because I've been assigned to either come up with a MB

Re: 答复: Linux MBIM

2012-08-09 Thread Greg Suarez

Dear Franko,

I've begun modifying the cdc-ncm driver to support mbim devices.  I do have
a device to test with but will welcome more devices if Huawei is willing to
send one.

Thanks,

Greg

On Tue, Aug 7, 2012 at 11:49 PM, Fangxiaozhi (Franko) <
fangxiao...@huawei.com> wrote:

> Dear Mork & Greg:
>
> Do you have began to develop the MBIM driver for Linux kernel?
> Do you have got the MBIM device for test?
>
> We are developing some devices to support MBIM protocol. We hope
> that it can be used on Linux.
> So I think that we maybe do some cooperation for this development.
> What's your opinions?
>
> Best Regards,
> Franko Fang
>
> -邮件原件-
> 发件人: networkmanager-list-boun...@gnome.org [mailto:
> networkmanager-list-boun...@gnome.org] 代表 Bj?rn Mork
> 发送时间: 2012年7月19日 9:19
> 收件人: Greg Suarez
> 抄送: NetworkManager List
> 主题: Re: Linux MBIM
>
> Greg Suarez  writes:
> > On Mon, Jul 16, 2012 at 12:28 AM, Bjørn Mork  wrote:
> >
> >> If I understand this correctly, MBIM devices will combine CDC NCM with a
> >> MBIM control channel in the exact same way QMI devices combine CDC ECM
> >> with a QMI control channel.  That means that the driver support could be
> >> done as simple as combining cdc_ncm with the cdc_wdm subdriver (either
> >> in the existing cdc_ncm driver, or as a new separate driver reusing code
> >> from cdc_ncm).
> >>
> >> If this was done, then we would have the MBIM control channel exported
> >> to userspace as a /dev/cdc-wdmX device, exactly like qmi_wwan exports
> >> its QMI control channel.  Leaving MBIM control protocol implementation
> >> for userspace make sense for the same reasons it made sense to leave QMI
> >> implementation for userspace.  Boy, am I happy Marcel and others
> >> convinced me to do that :-)
> >>
> >
> > I was on the same line of thinking but wasn't aware of the QMI driver.
> > Could you point out its location to me?
>
> It's in mainline from 3.4:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/net/usb/qmi_wwan.c
>
> The approach is pretty simple: Reuse the existing cdc_wdm driver as a
> subdriver, giving it full ownership of the status interrupt endpoint.
> cdc_wdm exports whatever protocol is encapsulated in CDC directly as a
> character device. The driver does not care about the contents at all,
> leaving that to userspace.  The bulk endpoints are handled by a normal
> usbnet based minidriver.  The only difference from any other minidriver
> like cdc_ether, is that the status endpoint is unavailable.  But the CDC
> notifications are pretty useless anyway, when you have access to a full
> management protocol like QMI or MBIM.
>
> The exact same should work equally well for MBIM.  The network driver
> part must of course be different, and a lot more complex.  But most of
> it is already done in cdc_ncm.  Add push/pull of an ethernet
> pseudo-header to make the raw IP packets appear as ethernet (there are
> other options, but I believe adding a dummy header is best), and the
> registration of the subdriver, and that's it!
>
> Execpt of course for everything I forgot :-)
>
> If I had a device, I would have started with a very simple usbnet +
> cdc_wdm driver, verifying that userspace access to the MBIM protocol
> worked as assumed.  In fact, qmi_wwan qualifies as that simple driver.
> Just add a MBIM class matching rule there and go test MBIM management
> from userspace.
>
> The network interface will of course be non-functional.  To add support
> for that, I would look thoroughly at cdc_ncm to find out which parts
> could be reused and how to best do that without copying any code.  Then
> I would start exporting the parts of cdc_ncm that I needed and integrate
> them in the new driver.
>
> Another approach, which might result in simpler code and therefore be
> better, would be adding a few extra functions to cdc_ncm and just add
> another driver instance there for MBIM.  Might be best, given the amount
> of code that could and should be shared between these two drivers.
>
> Last, there is the question of whether you should bother with the
> Microsoft specific descriptors (the magic 0xee string descriptor and
> it's friends) or not.  I don't think that is necessary, and there are
> some reasons to stay away.  But then I haven't seen a MBIM device yet.
> Could be that you need those descriptors to figure out the different
> settings, in particular how to enable the alternate functions.
>
> >> A question back to you, Greg:  Why do you ask?
> >
> >
> > I ask because I've been assigned to either come up with a MBIM driver or
> > help with an existing effort.
>
> Ah, good.  Then that's solved :-)
>
> May I ask who assigns such fun tasks?
>
>
> >> Do you know of any
> >> device? Or planned device?  Where can I get one? :-)
> >>
> >
> > I should be getting a dev board sometime in the next few weeks.  I don't
> > even know the manufacturer.
> > Where can you get one?  no idea.
>
> OK.  I'll see what pops

More than one IPv6 address via DHCPv6

2012-08-09 Thread Henri Wahl


Hi developers,
If I want to deliver more than one IPv6 address to DHCPv6 clients (a 
global one and an ULA for example) NetworkManager only uses one of them. 
The funny thing is that dhclient being used directly accepts several 
addresses, but dhclient used by NetworkManager ignores the others 
randomly. In an IPv6 world more addresses will be useful, so what do you 
thing about adding this (via dhclient yet existing) functionality?

Best regards
Henri Wahl

--
Henri Wahl

IT Department
Leibniz-Institut für Festkörper- u.
Werkstoffforschung Dresden

tel. (03 51) 46 59 - 797
email: h.w...@ifw-dresden.de
http://www.ifw-dresden.de

Nagios status monitor for your desktop:
http://nagstamon.ifw-dresden.de

IFW Dresden e.V., Helmholtzstraße 20, D-01069 Dresden
VR Dresden Nr. 1369
Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

答复: Linux MBIM

2012-08-09 Thread Fangxiaozhi (Franko)

Dear Mork & Greg:

Do you have began to develop the MBIM driver for Linux kernel?
Do you have got the MBIM device for test?

We are developing some devices to support MBIM protocol. We hope that 
it can be used on Linux.
So I think that we maybe do some cooperation for this development.
What's your opinions?

Best Regards,
Franko Fang

-邮件原件-
发件人: networkmanager-list-boun...@gnome.org 
[mailto:networkmanager-list-boun...@gnome.org] 代表 Bj?rn Mork
发送时间: 2012年7月19日 9:19
收件人: Greg Suarez
抄送: NetworkManager List
主题: Re: Linux MBIM

Greg Suarez  writes:
> On Mon, Jul 16, 2012 at 12:28 AM, Bjørn Mork  wrote:
>
>> If I understand this correctly, MBIM devices will combine CDC NCM with a
>> MBIM control channel in the exact same way QMI devices combine CDC ECM
>> with a QMI control channel.  That means that the driver support could be
>> done as simple as combining cdc_ncm with the cdc_wdm subdriver (either
>> in the existing cdc_ncm driver, or as a new separate driver reusing code
>> from cdc_ncm).
>>
>> If this was done, then we would have the MBIM control channel exported
>> to userspace as a /dev/cdc-wdmX device, exactly like qmi_wwan exports
>> its QMI control channel.  Leaving MBIM control protocol implementation
>> for userspace make sense for the same reasons it made sense to leave QMI
>> implementation for userspace.  Boy, am I happy Marcel and others
>> convinced me to do that :-)
>>
>
> I was on the same line of thinking but wasn't aware of the QMI driver.
> Could you point out its location to me?

It's in mainline from 3.4:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/net/usb/qmi_wwan.c

The approach is pretty simple: Reuse the existing cdc_wdm driver as a
subdriver, giving it full ownership of the status interrupt endpoint.
cdc_wdm exports whatever protocol is encapsulated in CDC directly as a
character device. The driver does not care about the contents at all,
leaving that to userspace.  The bulk endpoints are handled by a normal
usbnet based minidriver.  The only difference from any other minidriver
like cdc_ether, is that the status endpoint is unavailable.  But the CDC
notifications are pretty useless anyway, when you have access to a full
management protocol like QMI or MBIM.

The exact same should work equally well for MBIM.  The network driver
part must of course be different, and a lot more complex.  But most of
it is already done in cdc_ncm.  Add push/pull of an ethernet
pseudo-header to make the raw IP packets appear as ethernet (there are
other options, but I believe adding a dummy header is best), and the
registration of the subdriver, and that's it!

Execpt of course for everything I forgot :-)

If I had a device, I would have started with a very simple usbnet +
cdc_wdm driver, verifying that userspace access to the MBIM protocol
worked as assumed.  In fact, qmi_wwan qualifies as that simple driver.
Just add a MBIM class matching rule there and go test MBIM management
from userspace.

The network interface will of course be non-functional.  To add support
for that, I would look thoroughly at cdc_ncm to find out which parts
could be reused and how to best do that without copying any code.  Then
I would start exporting the parts of cdc_ncm that I needed and integrate
them in the new driver.

Another approach, which might result in simpler code and therefore be
better, would be adding a few extra functions to cdc_ncm and just add
another driver instance there for MBIM.  Might be best, given the amount
of code that could and should be shared between these two drivers.

Last, there is the question of whether you should bother with the
Microsoft specific descriptors (the magic 0xee string descriptor and
it's friends) or not.  I don't think that is necessary, and there are
some reasons to stay away.  But then I haven't seen a MBIM device yet.
Could be that you need those descriptors to figure out the different
settings, in particular how to enable the alternate functions.

>> A question back to you, Greg:  Why do you ask?
>
>
> I ask because I've been assigned to either come up with a MBIM driver or
> help with an existing effort.

Ah, good.  Then that's solved :-)

May I ask who assigns such fun tasks?

>> Do you know of any
>> device? Or planned device?  Where can I get one? :-)
>>
>
> I should be getting a dev board sometime in the next few weeks.  I don't
> even know the manufacturer.
> Where can you get one?  no idea.

OK.  I'll see what pops up.

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

答复: Linux MBIM

2012-08-09 Thread Fangxiaozhi (Franko)

Dear Mork & Greg:

Do you have began to develop the MBIM driver for Linux kernel?
Do you have got the MBIM device for test?

We are developing some devices to support MBIM protocol. We hope that 
it can be used on Linux.
So I think that we maybe do some cooperation for this development.
What's your opinions?

Best Regards,
Franko Fang

-邮件原件-
发件人: networkmanager-list-boun...@gnome.org 
[mailto:networkmanager-list-boun...@gnome.org] 代表 Bj?rn Mork
发送时间: 2012年7月19日 9:19
收件人: Greg Suarez
抄送: NetworkManager List
主题: Re: Linux MBIM

Greg Suarez  writes:
> On Mon, Jul 16, 2012 at 12:28 AM, Bjørn Mork  wrote:
>
>> If I understand this correctly, MBIM devices will combine CDC NCM with a
>> MBIM control channel in the exact same way QMI devices combine CDC ECM
>> with a QMI control channel.  That means that the driver support could be
>> done as simple as combining cdc_ncm with the cdc_wdm subdriver (either
>> in the existing cdc_ncm driver, or as a new separate driver reusing code
>> from cdc_ncm).
>>
>> If this was done, then we would have the MBIM control channel exported
>> to userspace as a /dev/cdc-wdmX device, exactly like qmi_wwan exports
>> its QMI control channel.  Leaving MBIM control protocol implementation
>> for userspace make sense for the same reasons it made sense to leave QMI
>> implementation for userspace.  Boy, am I happy Marcel and others
>> convinced me to do that :-)
>>
>
> I was on the same line of thinking but wasn't aware of the QMI driver.
> Could you point out its location to me?

It's in mainline from 3.4:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/net/usb/qmi_wwan.c

The approach is pretty simple: Reuse the existing cdc_wdm driver as a
subdriver, giving it full ownership of the status interrupt endpoint.
cdc_wdm exports whatever protocol is encapsulated in CDC directly as a
character device. The driver does not care about the contents at all,
leaving that to userspace.  The bulk endpoints are handled by a normal
usbnet based minidriver.  The only difference from any other minidriver
like cdc_ether, is that the status endpoint is unavailable.  But the CDC
notifications are pretty useless anyway, when you have access to a full
management protocol like QMI or MBIM.

The exact same should work equally well for MBIM.  The network driver
part must of course be different, and a lot more complex.  But most of
it is already done in cdc_ncm.  Add push/pull of an ethernet
pseudo-header to make the raw IP packets appear as ethernet (there are
other options, but I believe adding a dummy header is best), and the
registration of the subdriver, and that's it!

Execpt of course for everything I forgot :-)

If I had a device, I would have started with a very simple usbnet +
cdc_wdm driver, verifying that userspace access to the MBIM protocol
worked as assumed.  In fact, qmi_wwan qualifies as that simple driver.
Just add a MBIM class matching rule there and go test MBIM management
from userspace.

The network interface will of course be non-functional.  To add support
for that, I would look thoroughly at cdc_ncm to find out which parts
could be reused and how to best do that without copying any code.  Then
I would start exporting the parts of cdc_ncm that I needed and integrate
them in the new driver.

Another approach, which might result in simpler code and therefore be
better, would be adding a few extra functions to cdc_ncm and just add
another driver instance there for MBIM.  Might be best, given the amount
of code that could and should be shared between these two drivers.

Last, there is the question of whether you should bother with the
Microsoft specific descriptors (the magic 0xee string descriptor and
it's friends) or not.  I don't think that is necessary, and there are
some reasons to stay away.  But then I haven't seen a MBIM device yet.
Could be that you need those descriptors to figure out the different
settings, in particular how to enable the alternate functions.

>> A question back to you, Greg:  Why do you ask?
>
>
> I ask because I've been assigned to either come up with a MBIM driver or
> help with an existing effort.

Ah, good.  Then that's solved :-)

May I ask who assigns such fun tasks?

>> Do you know of any
>> device? Or planned device?  Where can I get one? :-)
>>
>
> I should be getting a dev board sometime in the next few weeks.  I don't
> even know the manufacturer.
> Where can you get one?  no idea.

OK.  I'll see what pops up.

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

named startup & NetworkManager

2012-08-09 Thread Gene Czarcinski


https://bugzilla.redhat.com/show_bug.cgi?id=837173

The above bug report concerns NetworkManager NIC device initialization 
and named.  Yes, the bug is against bind but you should take a look at 
it since it directly involves NetworkManager.


As I say in my comment, I have been able to reliably reproduce the 
problem as a virtual guest but not on real hardware (and I tried).


The problem is that NetworkManager, named, and dhcpd are all started at 
roughly the same time (think at least within a couple seconds). dhcpd 
can handle the fact that when it iinitializes that there are no NICs 
available and when they do become available, is uses them.


But, with respect to named, the fact that the NICs are not available 
makes it get everything pretty much wrong (lots and lots of error 
messages in the system log).  And when the devices have been initialized 
by NetworkManager, named does not look again.  The only way to handle it 
is to restart named after I can login.


I am not familiar enough with how the new initialization (systemd) works 
so I do not know if there is an "easy" answer.


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

[PATCH 2/3] Replace Ad-Hoc WPA-None support with IBSS RSN-PSK.

2012-08-09 Thread Nicolas . Cavallari

From: Nicolas Cavallari 

This completely removes Ad-Hoc WPA-None support, as it is
not supported by the linux kernel since a long time,
have never been standardized and other vendors already
removed support for it since a long time.  The security
of the protocol is also comparable to WEP, especially
when used with TKIP.

Instead, the standard-compliant WPA2/RSN protocol
is used for IBSS/Ad-Hoc mode.  Compared to WPA-None,
this protocol uses the classical Four Way Handshake
for security association and features replay protection.

IBSS RSN-PSK requires wpa_supplicant 1.0 and a recent enough
kernel (best with >= 3.2, 3.0 is still fine)
wpa_supplicant only supports the CCMP cipher when
operating in Ad-Hoc mode; if another cipher is requested,
wpa_supplicant will use CCMP anyway).

IBSS RSN will only be used when mode=adhoc and key_mgmt=wpa-psk
and only if the device claims support for it via nl80211.

---
I tested most of it, but haven't tested everything,
especially the various settings plugins.

 include/NetworkManager.h   |4 +-
 libnm-glib/nm-device-wifi.c|3 +-
 libnm-util/nm-setting-wireless-security.c  |   49 +---
 libnm-util/nm-setting-wireless.c   |   13 +++---
 libnm-util/nm-utils.c  |   29 
 src/nm-wifi-ap-utils.c |   47 +++
 src/nm-wifi-ap.c   |   41 +++-
 src/settings/plugins/ifcfg-rh/reader.c |   13 ++
 src/settings/plugins/ifcfg-rh/writer.c |2 +-
 src/settings/plugins/ifnet/connection_parser.c |   48 ---
 .../plugins/ifnet/tests/wpa_supplicant.conf|   10 ++--
 src/supplicant-manager/nm-supplicant-config.c  |3 +-
 .../nm-supplicant-settings-verify.c|2 +-
 src/wifi/wifi-utils-nl80211.c  |3 ++
 14 files changed, 101 insertions(+), 166 deletions(-)

diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index bb67b8f..b35c097 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -155,6 +155,7 @@ typedef enum {
  * @NM_WIFI_DEVICE_CAP_WPA: device supports WPA1 authentication
  * @NM_WIFI_DEVICE_CAP_RSN: device supports WPA2/RSN authentication
  * @NM_WIFI_DEVICE_CAP_AP: device supports Access Point mode
+ * @NM_WIFI_DEVICE_CAP_IBSS_RSN: device supports WPA2/RSN in an IBSS network.
  *
  * 802.11 specific device encryption and authentication capabilities.
  **/
@@ -166,7 +167,8 @@ typedef enum {
NM_WIFI_DEVICE_CAP_CIPHER_CCMP   = 0x0008,
NM_WIFI_DEVICE_CAP_WPA   = 0x0010,
NM_WIFI_DEVICE_CAP_RSN   = 0x0020,
-   NM_WIFI_DEVICE_CAP_AP= 0x0040
+   NM_WIFI_DEVICE_CAP_AP= 0x0040,
+   NM_WIFI_DEVICE_CAP_IBSS_RSN  = 0x0080
 } NMDeviceWifiCapabilities;
 
 
diff --git a/libnm-glib/nm-device-wifi.c b/libnm-glib/nm-device-wifi.c
index 0058fd1..3e0fac2 100644
--- a/libnm-glib/nm-device-wifi.c
+++ b/libnm-glib/nm-device-wifi.c
@@ -463,8 +463,7 @@ connection_compatible (NMDevice *device, NMConnection 
*connection, GError **erro
if (s_wsec) {
/* Connection has security, verify it against the device's 
capabilities */
key_mgmt = nm_setting_wireless_security_get_key_mgmt (s_wsec);
-   if (   !g_strcmp0 (key_mgmt, "wpa-none")
-   || !g_strcmp0 (key_mgmt, "wpa-psk")
+   if (   !g_strcmp0 (key_mgmt, "wpa-psk")
|| !g_strcmp0 (key_mgmt, "wpa-eap")) {
 
/* Is device only WEP capable? */
diff --git a/libnm-util/nm-setting-wireless-security.c 
b/libnm-util/nm-setting-wireless-security.c
index 336773c..3372394 100644
--- a/libnm-util/nm-setting-wireless-security.c
+++ b/libnm-util/nm-setting-wireless-security.c
@@ -785,8 +785,7 @@ need_secrets (NMSetting *setting)
}
 
/* WPA-PSK infrastructure and adhoc */
-   if (   (strcmp (priv->key_mgmt, "wpa-none") == 0)
-   || (strcmp (priv->key_mgmt, "wpa-psk") == 0)) {
+   if (strcmp (priv->key_mgmt, "wpa-psk") == 0) {
if (!verify_wpa_psk (priv->psk)) {
g_ptr_array_add (secrets, 
NM_SETTING_WIRELESS_SECURITY_PSK);
return secrets;
@@ -834,7 +833,7 @@ verify (NMSetting *setting, GSList *all_settings, GError 
**error)
 {
NMSettingWirelessSecurity *self = NM_SETTING_WIRELESS_SECURITY 
(setting);
NMSettingWirelessSecurityPrivate *priv = 
NM_SETTING_WIRELESS_SECURITY_GET_PRIVATE (self);
-   const char *valid_key_mgmt[] = { "none", "ieee8021x", "wpa-none", 
"wpa-psk", "wpa-eap", NULL };
+   const char *valid_key_mgmt[] = { "none", "ieee8021x", "wpa-psk", 
"wpa-eap", NULL };
const char *valid_auth_algs[] = { "open", "shared", "leap", NULL };
const char *valid_protos[] = { "wpa", "

[PATCH 1/3] Revert "wifi: disable Ad-Hoc WPA connections (lp:905748)"

2012-08-09 Thread Nicolas . Cavallari

From: Nicolas Cavallari 

This reverts commit 69247a00eacd00617acbf1dfcee8497437b8ad39,
which disabled all security in Ad-Hoc networks, due to a bug
of wpa_supplicant that only affected WPA-None.
---
 libnm-util/nm-utils.c  |4 ---
 src/nm-device-wifi.c   |   60 
 src/settings/nm-settings.c |   45 -
 3 files changed, 109 deletions(-)

diff --git a/libnm-util/nm-utils.c b/libnm-util/nm-utils.c
index 65bbd25..607c0e6 100644
--- a/libnm-util/nm-utils.c
+++ b/libnm-util/nm-utils.c
@@ -1285,8 +1285,6 @@ nm_utils_security_valid (NMUtilsSecurityType type,
}
break;
case NMU_SEC_WPA_PSK:
-   if (adhoc)
-   return FALSE;  /* FIXME: Kernel WPA Ad-Hoc support is 
buggy */
if (!(wifi_caps & NM_WIFI_DEVICE_CAP_WPA))
return FALSE;
if (have_ap) {
@@ -1313,8 +1311,6 @@ nm_utils_security_valid (NMUtilsSecurityType type,
}
break;
case NMU_SEC_WPA2_PSK:
-   if (adhoc)
-   return FALSE;  /* FIXME: Kernel WPA Ad-Hoc support is 
buggy */
if (!(wifi_caps & NM_WIFI_DEVICE_CAP_RSN))
return FALSE;
if (have_ap) {
diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
index e2ff77e..0809ce0 100644
--- a/src/nm-device-wifi.c
+++ b/src/nm-device-wifi.c
@@ -967,36 +967,6 @@ real_deactivate (NMDevice *dev)
 }
 
 static gboolean
-is_adhoc_wpa (NMConnection *connection)
-{
-   NMSettingWireless *s_wifi;
-   NMSettingWirelessSecurity *s_wsec;
-   const char *mode, *key_mgmt;
-
-   /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks.  It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc 
networks.
-*/
-
-   s_wifi = nm_connection_get_setting_wireless (connection);
-   g_return_val_if_fail (s_wifi != NULL, FALSE);
-
-   mode = nm_setting_wireless_get_mode (s_wifi);
-   if (g_strcmp0 (mode, NM_SETTING_WIRELESS_MODE_ADHOC) != 0)
-   return FALSE;
-
-   s_wsec = nm_connection_get_setting_wireless_security (connection);
-   if (!s_wsec)
-   return FALSE;
-
-   key_mgmt = nm_setting_wireless_security_get_key_mgmt (s_wsec);
-   if (g_strcmp0 (key_mgmt, "wpa-none") != 0)
-   return FALSE;
-
-   return TRUE;
-}
-
-static gboolean
 real_check_connection_compatible (NMDevice *device,
   NMConnection *connection,
   GError **error)
@@ -1054,14 +1024,6 @@ real_check_connection_compatible (NMDevice *device,
}
}
 
-   if (is_adhoc_wpa (connection)) {
-   g_set_error_literal (error,
-NM_WIFI_ERROR,
-NM_WIFI_ERROR_CONNECTION_INCOMPATIBLE,
-"WPA Ad-Hoc disabled due to kernel bugs");
-   return FALSE;
-   }
-
// FIXME: check channel/freq/band against bands the hardware supports
// FIXME: check encryption against device capabilities
// FIXME: check bitrate against device capabilities
@@ -1222,18 +1184,6 @@ real_complete_connection (NMDevice *device,
return FALSE;
}
 
-   /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks.  It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc 
networks.
-*/
-   if (is_adhoc_wpa (connection)) {
-   g_set_error_literal (error,
-NM_SETTING_WIRELESS_ERROR,
-NM_SETTING_WIRELESS_ERROR_INVALID_PROPERTY,
-"WPA Ad-Hoc disabled due to kernel bugs");
-   return FALSE;
-   }
-
g_assert (ssid);
str_ssid = nm_utils_ssid_to_utf8 (ssid);
format = g_strdup_printf ("%s %%d", str_ssid);
@@ -2789,16 +2739,6 @@ real_act_stage1_prepare (NMDevice *dev, 
NMDeviceStateReason *reason)
connection = nm_act_request_get_connection (req);
g_return_val_if_fail (connection != NULL, NM_ACT_STAGE_RETURN_FAILURE);
 
-   /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks.  It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc 
networks.
-*/
-   if (is_adhoc_wpa (connection)) {
-   nm_log_warn (LOGD_WIFI, "Ad-Hoc WPA disabled due to kernel 
bugs");
-   *reason = NM_DEVICE_STATE_REASON_SUPPLICANT_CONFIG_FAILED;
-   return NM_ACT_STAGE_RETURN_FAILURE;
-   }
-

[PATCH 3/3 applet] Allow to create and connect to Ad-Hoc RSN networks.

2012-08-09 Thread Nicolas . Cavallari

From: Nicolas Cavallari 

This follows changes to Network Manager, which now
supports WPA2/RSN in Ad-Hoc/IBSS mode.
---
 src/applet-dialogs.c   |2 --
 src/connection-editor/page-wireless-security.c |9 ++---
 src/libnm-gtk/nm-wireless-dialog.c |3 +--
 src/wireless-security/ws-wpa-psk.c |   15 +++
 4 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/src/applet-dialogs.c b/src/applet-dialogs.c
index b9ebc47..bb893af 100644
--- a/src/applet-dialogs.c
+++ b/src/applet-dialogs.c
@@ -241,8 +241,6 @@ create_info_label_security (NMConnection *connection)
 
if (!strcmp (key_mgmt, "none"))
label = g_strdup (_("WEP"));
-   else if (!strcmp (key_mgmt, "wpa-none"))
-   label = g_strdup (_("WPA/WPA2"));
else if (!strcmp (key_mgmt, "wpa-psk"))
label = g_strdup (_("WPA/WPA2"));
else
diff --git a/src/connection-editor/page-wireless-security.c 
b/src/connection-editor/page-wireless-security.c
index 09a6744..855f783 100644
--- a/src/connection-editor/page-wireless-security.c
+++ b/src/connection-editor/page-wireless-security.c
@@ -79,8 +79,7 @@ get_default_type_for_security (NMSettingWirelessSecurity *sec)
return NMU_SEC_DYNAMIC_WEP;
}
 
-   if (   !strcmp (key_mgmt, "wpa-none")
-   || !strcmp (key_mgmt, "wpa-psk")) {
+   if (!strcmp (key_mgmt, "wpa-psk")) {
if (find_proto (sec, "rsn"))
return NMU_SEC_WPA2_PSK;
else if (find_proto (sec, "wpa"))
@@ -337,7 +336,7 @@ finish_setup (CEPageWirelessSecurity *self, gpointer 
unused, GError *error, gpoi
ws_wpa_psk = ws_wpa_psk_new (connection, FALSE);
if (ws_wpa_psk) {
add_security_item (self, WIRELESS_SECURITY 
(ws_wpa_psk), sec_model,
-  &iter, _("WPA & WPA2 Personal"), 
FALSE);
+  &iter, _("WPA & WPA2 Personal"), 
TRUE);
if ((active < 0) && ((default_type == NMU_SEC_WPA_PSK) 
|| (default_type == NMU_SEC_WPA2_PSK)))
active = item;
item++;
@@ -472,10 +471,6 @@ validate (CEPage *page, NMConnection *connection, GError 
**error)
s_wireless = nm_connection_get_setting_wireless (connection);
g_assert (s_wireless);
 
-   /* Kernel Ad-Hoc WPA support is busted; it creates open networks.  
Disable
-* WPA when Ad-Hoc is selected.  set_sensitive() will pick up 
self->adhoc
-* and do the right thing.
-*/
mode = nm_setting_wireless_get_mode (s_wireless);
if (g_strcmp0 (mode, NM_SETTING_WIRELESS_MODE_ADHOC) == 0)
self->adhoc = TRUE;
diff --git a/src/libnm-gtk/nm-wireless-dialog.c 
b/src/libnm-gtk/nm-wireless-dialog.c
index 885a1c6..ec7c7e2 100644
--- a/src/libnm-gtk/nm-wireless-dialog.c
+++ b/src/libnm-gtk/nm-wireless-dialog.c
@@ -692,8 +692,7 @@ get_default_type_for_security (NMSettingWirelessSecurity 
*sec,
return NMU_SEC_DYNAMIC_WEP;
}
 
-   if (   !strcmp (key_mgmt, "wpa-none")
-   || !strcmp (key_mgmt, "wpa-psk")) {
+   if (!strcmp (key_mgmt, "wpa-psk")) {
if (!have_ap || (ap_flags & NM_802_11_AP_FLAGS_PRIVACY)) {
if (find_proto (sec, "rsn"))
return NMU_SEC_WPA2_PSK;
diff --git a/src/wireless-security/ws-wpa-psk.c 
b/src/wireless-security/ws-wpa-psk.c
index ceb89e1..02be4ad 100644
--- a/src/wireless-security/ws-wpa-psk.c
+++ b/src/wireless-security/ws-wpa-psk.c
@@ -117,14 +117,13 @@ fill_connection (WirelessSecurity *parent, NMConnection 
*connection)
wireless_security_clear_ciphers (connection);
if (is_adhoc) {
/* Ad-Hoc settings as specified by the supplicant */
-   g_object_set (s_wireless_sec, 
NM_SETTING_WIRELESS_SECURITY_KEY_MGMT, "wpa-none", NULL);
-   nm_setting_wireless_security_add_proto (s_wireless_sec, "wpa");
-   nm_setting_wireless_security_add_pairwise (s_wireless_sec, 
"none");
+   g_object_set (s_wireless_sec, 
NM_SETTING_WIRELESS_SECURITY_KEY_MGMT, "wpa-psk", NULL);
+   nm_setting_wireless_security_add_proto (s_wireless_sec, "rsn");
 
-   /* Ad-hoc can only have _one_ group cipher... default to TKIP 
to be more
-* compatible for now.  Maybe we'll support selecting CCMP 
later.
-*/
-   nm_setting_wireless_security_add_group (s_wireless_sec, "tkip");
+   /* The supplicant only supports CCMP with Ad-hoc RSN;
+* Selecting something else will make it use CCMP anyway. */
+   nm_setting_wireless_security_add_pairwise (s_wireless_sec, 
"cc

Re: IPv6 default routes / NM vs. kernel autoconfig vs DHCP6

2012-08-09 Thread Pavel Simerda

> From: "Stuart D Gathman" 
> One situation that ought to work IMHO (although ~1/2 of IPv6 experts
> disagree) is that DHCP6 should work in concert with routes that are
> not /64.

DHCPv6 should not care about *any* routes.

> For instance, RA provides a 2001:db8:1:2:3::1/80 default route,

Default route is technically always /0 and in case of RA-based default
route it points to a link-local IPv6 address.

> sets the M bit, and DHCP6 provides the address
> 2001:db8:1:2:3::1000.  NM should be able to set the default route
> *and*
> apply the /80 prefix length to the DHCP6 address.  This could get
> non-trivial when there are multiple routes provided by RA.  NM must
> then
> find the route that matches the DHCP6 address to determine the
> correct
> prefix.

With the above information in mind, this is not really the case.

> Note: the experts that disagree feel that all LANs should be /64
> always forever,

This is also stated by IPv6 addressing architecture RFC. But for
non-SLAAC cases, linux won't prevent you from doing that AFAIK
and NM doesn't have any reason to do that either.

So, even though your use case is against RFC, allowing it doesn't
cause any harm.

> and prefixes should only be used in routers.

I don't understand this.

> I find it quite
> handy to be able to subnet the /64 provided by the ISP, and while I
> agree that ISPs should always forever allocate a minimum of /64 to
> end
> users, nevertheless endusers should be able to subnet that and still
> have workstations and devices work without manual configuration.

This is ideology. I won't comment on this as this is purely philosophical
but apparently there is no reason linux or NM should prevent you from
doing that.

Cheers,

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

Re: [MM] [PATCH] broadband-modem: retry +CPIN? when SIM is busy

2012-08-09 Thread Aleksander Morgado


> 
>> When the modem checks if a SIM requires unlock, the SIM may not be
>> ready. This patch modifies modem_load_unlock_required to retry +CPIN?
>> under that scenario.
> 
> The logic to retry the unlock check is kept in the Modem interface file,
> mm-iface-modem.c, see mm_iface_modem_unlock_check(), and it should
> already be doing the retries, even with the 2 second delay between
> retries. Didn't that work for you? Do you have debug logs of a case
> where it didn't work?
> 

It wouldn't be a bad idea, though, to include the AT command retries
logic directly within mm_base_modem_at_command(), so that whenever we
get a SIM_BUSY error we automatically do the 2s delay and retry,
regardless of the command we sent. We could also let plugins modify the
list of errors which should be considered to get retried... Just an idea.

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

Re: [MM] [PATCH] broadband-modem: retry +CPIN? when SIM is busy

2012-08-09 Thread Aleksander Morgado

Hey Ben,

> When the modem checks if a SIM requires unlock, the SIM may not be
> ready. This patch modifies modem_load_unlock_required to retry +CPIN?
> under that scenario.

The logic to retry the unlock check is kept in the Modem interface file,
mm-iface-modem.c, see mm_iface_modem_unlock_check(), and it should
already be doing the retries, even with the 2 second delay between
retries. Didn't that work for you? Do you have debug logs of a case
where it didn't work?


> ---
>  src/mm-broadband-modem.c |   70 +
>  1 files changed, 57 insertions(+), 13 deletions(-)
> 
> diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
> index edc9507..53bce9b 100644
> --- a/src/mm-broadband-modem.c
> +++ b/src/mm-broadband-modem.c
> @@ -816,6 +816,21 @@ static CPinResult unlock_results[] = {
>  { NULL }
>  };
>  
> +typedef struct {
> +MMIfaceModem *self;
> +GSimpleAsyncResult *result;
> +guint retries;
> +} ModemLoadUnlockRequiredContext;
> +
> +static void
> +modem_load_unlock_required_context_complete_and_free 
> (ModemLoadUnlockRequiredContext *ctx)
> +{
> +g_simple_async_result_complete (ctx->result);
> +g_object_unref (ctx->result);
> +g_object_unref (ctx->self);
> +g_free (ctx);
> +}
> +
>  static MMModemLock
>  modem_load_unlock_required_finish (MMIfaceModem *self,
> GAsyncResult *res,
> @@ -828,10 +843,20 @@ modem_load_unlock_required_finish (MMIfaceModem *self,
> G_SIMPLE_ASYNC_RESULT (res)));
>  }
>  
> +static void modem_load_unlock_required_context_step 
> (ModemLoadUnlockRequiredContext *ctx);
> +
> +static gboolean
> +cpin_timeout_cb (ModemLoadUnlockRequiredContext *ctx)
> +{
> +ctx->retries--;
> +modem_load_unlock_required_context_step (ctx);
> +return FALSE;
> +}
> +
>  static void
>  cpin_query_ready (MMIfaceModem *self,
>GAsyncResult *res,
> -  GSimpleAsyncResult *simple)
> +  ModemLoadUnlockRequiredContext *ctx)
>  {
>  
>  MMModemLock lock = MM_MODEM_LOCK_UNKNOWN;
> @@ -840,9 +865,17 @@ cpin_query_ready (MMIfaceModem *self,
>  
>  result = mm_base_modem_at_command_finish (MM_BASE_MODEM (self), res, 
> &error);
>  if (error) {
> -g_simple_async_result_take_error (simple, error);
> -g_simple_async_result_complete (simple);
> -g_object_unref (simple);
> +if (ctx->retries > 0 &&
> +g_error_matches (error,
> + MM_MOBILE_EQUIPMENT_ERROR,
> + MM_MOBILE_EQUIPMENT_ERROR_SIM_BUSY)) {
> +g_error_free (error);
> +/* Retry in 2 seconds */
> +g_timeout_add_seconds (2, (GSourceFunc)cpin_timeout_cb, ctx);
> +} else {
> +g_simple_async_result_take_error (ctx->result, error);
> +modem_load_unlock_required_context_complete_and_free (ctx);
> +}
>  return;
>  }
>  
> @@ -870,11 +903,21 @@ cpin_query_ready (MMIfaceModem *self,
>  }
>  }
>  
> -g_simple_async_result_set_op_res_gpointer (simple,
> +g_simple_async_result_set_op_res_gpointer (ctx->result,
> GUINT_TO_POINTER (lock),
> NULL);
> -g_simple_async_result_complete (simple);
> -g_object_unref (simple);
> +modem_load_unlock_required_context_complete_and_free (ctx);
> +}
> +
> +static void
> +modem_load_unlock_required_context_step (ModemLoadUnlockRequiredContext *ctx)
> +{
> +mm_base_modem_at_command (MM_BASE_MODEM (ctx->self),
> +  "+CPIN?",
> +  3,
> +  FALSE,
> +  (GAsyncReadyCallback)cpin_query_ready,
> +  ctx);
>  }
>  
>  static void
> @@ -882,6 +925,7 @@ modem_load_unlock_required (MMIfaceModem *self,
>  GAsyncReadyCallback callback,
>  gpointer user_data)
>  {
> +ModemLoadUnlockRequiredContext *ctx;
>  GSimpleAsyncResult *result;
>  
>  result = g_simple_async_result_new (G_OBJECT (self),
> @@ -900,13 +944,13 @@ modem_load_unlock_required (MMIfaceModem *self,
>  return;
>  }
>  
> +ctx = g_new0 (ModemLoadUnlockRequiredContext, 1);
> +ctx->self = g_object_ref (self);
> +ctx->retries = 3;
> +ctx->result = result;
> +
>  mm_dbg ("checking if unlock required...");
> -mm_base_modem_at_command (MM_BASE_MODEM (self),
> -  "+CPIN?",
> -  3,
> -  FALSE,
> -  (GAsyncReadyCallback)cpin_query_ready,
> -  result);
> +modem_load_unlock_required_context_step (ctx);
>  }
>  
>  
> /

Re: 答复: Linux MBIM

[MM] [PATCH] iface-modem: increase number of trials for PIN check from 3 to 6

答复: 答复: Linux MBIM

Re: 答复: Linux MBIM

More than one IPv6 address via DHCPv6

答复: Linux MBIM

答复: Linux MBIM

named startup & NetworkManager

[PATCH 2/3] Replace Ad-Hoc WPA-None support with IBSS RSN-PSK.

[PATCH 1/3] Revert "wifi: disable Ad-Hoc WPA connections (lp:905748)"

[PATCH 3/3 applet] Allow to create and connect to Ad-Hoc RSN networks.

Re: IPv6 default routes / NM vs. kernel autoconfig vs DHCP6

Re: [MM] [PATCH] broadband-modem: retry +CPIN? when SIM is busy

Re: [MM] [PATCH] broadband-modem: retry +CPIN? when SIM is busy

14 matches

Site Navigation

Mail list logo

Footer information