Re: MC 7304 ipv4v6

[Bjørn Mork]

Dan Williams  writes:

> Well, if we're going to add rawip support, why bother emulating a
> netdev at all?

(assuming you mean etherdev - we'll need the netdev in any case :)

Good question. Asked before, but I have fewer and fewer arguments. I
know Marcel H has wanted a raw device from the beginning.

> I guess because it's convenient and we don't have to
> destroy the existing wwan0 and create some other tun-type device
> instead.  But still, seems odd that we'd set raw-ip mode and then
> emulate ethernet when all that's really going back and forth is IP.

Yes, it is odd and it does create a few problems which the driver tries
to hide.  It would be more honest to just let userspace decide what to
do, e.g, wrt bridging.

So when the firmware finally gave up messing with the L2 headers, why
should the driver continue to do that? Make it raw IP all the way.  Yes,
I'm starting to lean to that side as well.

The only "real" objection I once had was that I don't think there are
any DHCP clients on Linux that will work with such an interface. But
that is a lousy excuse. Using DHCP here is another bad idea, trying to
make this link like something it isn't.  And if you still want to do it,
then you should be able to fake the headers using the tun driver.

You are right.  The only remaining problem is that it is more work :)

But I believe I implemented it the last time this was discussed.  I'll
see if I can dig up the old code for a demo.  Not going to rush this
anyway.  I'd like everyone to be happy with the result.  And it's going
to be immutable once it's in.


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

Re: ANN: NetworkManager 1.0.8 released

[Michael Biebl]

Hi

Am 23.11.2015 um 18:20 schrieb Lubomir Rintel:
> I'm pleased to announce the release of NetworkManager 1.0.8, the
> latest stable release in the 1.0.x series. We recommend that users
> of 1.0.x series as well as users of older 0.9.10.x series upgrade to
> this release which is D-Bus and C API backwards compatible.

I notice that a new header was added
/usr/include/NetworkManager/nm-version-macros.h

This header is used in
/usr/include/libnm/nm-version.h:#include 

The libnm.pc file doesn't add add /usr/include/NetworkManager
to its include path, so this looks like it might be broken.

Shouldn't libnm.pc have
Requires: NetworkManager >= 1.0.8


Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: MC 7304 ipv4v6

[Dan Williams]

On Tue, 2015-11-24 at 23:52 +0100, Bjørn Mork wrote:
> Bjørn Mork  writes:
> > Dan Williams  writes:
> > > On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote:
> > > 
> > > My vote would be sysfs, with values "raw-ip" or "802.3" that you
> > > can
> > > read and write to the file.  At least then they are human
> > > -readable. 
> > >  It's also easier to use from scripts than parsing ethtool
> > > output.
> > 
> > Maybe even easier with a boolean qmi/raw_ip file, since we are only
> > going
> > to offer two alternatives anyway?  Then you don't have to figure
> > out
> > what strings are accepted, and we won't end up having to parse
> > 'raw-ip/rawip/raw_ip/rwa-ip/rawIP/etc'.
> 
> Including a demo patch (not tested...) to illustrate what I mean:
> 
>  $ cat /sys/class/net/wwan1/qmi/raw_ip 
>  N
>  # echo Y >/sys/class/net/wwan1/qmi/raw_ip
> 
> etc

Well, if we're going to add rawip support, why bother emulating a
netdev at all?  I guess because it's convenient and we don't have to
destroy the existing wwan0 and create some other tun-type device
instead.  But still, seems odd that we'd set raw-ip mode and then
emulate ethernet when all that's really going back and forth is IP.

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

Re: MC 7304 ipv4v6

[Bjørn Mork]

Bjørn Mork  writes:
> Dan Williams  writes:
>> On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote:
>>
>> My vote would be sysfs, with values "raw-ip" or "802.3" that you can
>> read and write to the file.  At least then they are human-readable. 
>>  It's also easier to use from scripts than parsing ethtool output.
>
> Maybe even easier with a boolean qmi/raw_ip file, since we are only going
> to offer two alternatives anyway?  Then you don't have to figure out
> what strings are accepted, and we won't end up having to parse
> 'raw-ip/rawip/raw_ip/rwa-ip/rawIP/etc'.

Including a demo patch (not tested...) to illustrate what I mean:

 $ cat /sys/class/net/wwan1/qmi/raw_ip 
 N
 # echo Y >/sys/class/net/wwan1/qmi/raw_ip

etc

>From 97df402dab83feb14a7cb61fb7fa950e0bcf8c1d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Mon, 15 Apr 2013 21:55:34 +0200
Subject: [PATCH] net: qmi_wwan: add raw IP support with fake ethernet headers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 66 +-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index af1267fb1139..428b46453efc 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -48,11 +48,55 @@
 struct qmi_wwan_state {
 	struct usb_driver *subdriver;
 	atomic_t pmcount;
-	unsigned long unused;
+	unsigned long flags;
 	struct usb_interface *control;
 	struct usb_interface *data;
 };
 
+enum qmi_wwan_flags {
+	QMI_WWAN_FLAG_RAWIP = 1 << 0,
+};
+
+static ssize_t raw_ip_show(struct device *d, struct device_attribute *attr, char *buf)
+{
+	struct usbnet *dev = netdev_priv(to_net_dev(d));
+	struct qmi_wwan_state *info = (void *)&dev->data;
+
+	return sprintf(buf, "%c\n", info->flags & QMI_WWAN_FLAG_RAWIP ? 'Y' : 'N');
+}
+
+static ssize_t raw_ip_store(struct device *d,  struct device_attribute *attr, const char *buf, size_t len)
+{
+	struct usbnet *dev = netdev_priv(to_net_dev(d));
+	struct qmi_wwan_state *info = (void *)&dev->data;
+	bool enable;
+
+	if (strtobool(buf, &enable))
+		return -EINVAL;
+
+	if (enable) {
+		info->flags |= QMI_WWAN_FLAG_RAWIP;
+		/* cannot do arp in raw IP mode, but must do in 802.3 mode */
+		dev->net->flags |= IFF_NOARP;
+	} else {
+		info->flags &= ~QMI_WWAN_FLAG_RAWIP;
+		dev->net->flags &= ~IFF_NOARP;
+	}
+	return len;
+}
+
+static DEVICE_ATTR_RW(raw_ip);
+
+static struct attribute *qmi_wwan_sysfs_attrs[] = {
+	&dev_attr_raw_ip.attr,
+	NULL,
+};
+
+static struct attribute_group qmi_wwan_sysfs_attr_group = {
+	.name = "qmi",
+	.attrs = qmi_wwan_sysfs_attrs,
+};
+
 /* default ethernet address used by the modem */
 static const u8 default_modem_addr[ETH_ALEN] = {0x02, 0x50, 0xf3};
 
@@ -114,6 +158,24 @@ fix_dest:
 	return 1;
 }
 
+static struct sk_buff *qmi_wwan_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
+{
+	struct qmi_wwan_state *info = (void *)&dev->data;
+
+	if ((skb->len <= ETH_HLEN) || !(info->flags & QMI_WWAN_FLAG_RAWIP))
+		goto out;
+
+	/* only pull header if datagram is IPv4 or IPv6 */
+	skb_reset_mac_header(skb);
+	switch (eth_hdr(skb)->h_proto) {
+	case htons(ETH_P_IP):
+	case htons(ETH_P_IPV6):
+		skb_pull(skb, ETH_HLEN);
+	}
+out:
+	return skb;
+}
+
 /* very simplistic detection of IPv4 or IPv6 headers */
 static bool possibly_iphdr(const char *data)
 {
@@ -312,6 +374,7 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
 		dev->net->dev_addr[0] &= 0xbf;	/* clear "IP" bit */
 	}
 	dev->net->netdev_ops = &qmi_wwan_netdev_ops;
+	dev->net->sysfs_groups[0] = &qmi_wwan_sysfs_attr_group;
 err:
 	return status;
 }
@@ -397,6 +460,7 @@ static const struct driver_info	qmi_wwan_info = {
 	.unbind		= qmi_wwan_unbind,
 	.manage_power	= qmi_wwan_manage_power,
 	.rx_fixup   = qmi_wwan_rx_fixup,
+	.tx_fixup   = qmi_wwan_tx_fixup,
 };
 
 #define HUAWEI_VENDOR_ID	0x12D1
-- 
2.1.4

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

Re: MC 7304 ipv4v6

[Bjørn Mork]

Dan Williams  writes:
> On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote:
>
> My vote would be sysfs, with values "raw-ip" or "802.3" that you can
> read and write to the file.  At least then they are human-readable. 
>  It's also easier to use from scripts than parsing ethtool output.

Maybe even easier with a boolean qmi/raw_ip file, since we are only going
to offer two alternatives anyway?  Then you don't have to figure out
what strings are accepted, and we won't end up having to parse
'raw-ip/rawip/raw_ip/rwa-ip/rawIP/etc'.

But what do you think about the first part of this: Is it acceptable to
leave it to userspace to figure out how to work around the problem,
switching to raw-ip in this case?


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

Re: MC 7304 ipv4v6

[Dan Williams]

On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote:
> Reinhard Speyerer  writes:
> 
> > This looks rather similar to the "Dualstack errors with MC7354"
> > problem
> > described here 
> > https://forum.sierrawireless.com/viewtopic.php?f=117&t=8295 .
> > 
> > Apparently the qmi_wwan patch contained in the thread was not
> > submitted
> > as a Linux kernel patch so far.
> 
> Ouch, bad conscience hitting hard... Again.
> 
> The patch will probably solve the problem, but it makes all the
> header
> fixup magic ten times worse. And at the time I was in doubt whether
> the
> use case was really important enough to warrant a workaround as ugly
> as
> this.  So I wanted to let it rest in the back of my head for a while,
> before making up my mind. The only problem is that there is very
> littly
> that will stick there... And I forgot all about it. Sorry
> 
> (Note that I'm definitely not criticizing the code - it's ugly
> because
> this is an ugly problem. And as the thread shows, I failed to create
> the
> simple solution I hoped for.)
> 
> Thanks for bringing this up again.  I guess we must do something
> about
> it.  But. given the current MC74xx development, I'm really
> tempted
> to say 'use raw IP' in this case.  The thing is, it looks like we
> have
> to support raw IP mode anyway. If so, then we might as well (ab)use
> it
> as workaround for any such header problem instead of adding even more
> specialized ugly header rewriting.
> 
> What do you think?  Is "dual-stack on MC7354" another candidate for
> raw
> IP? If we are going to add it anyway, that is.
> 
> Anyone have any wishes for raw IP driver API/UI?  So far I've added
> about 3 such APIs, and they are all different, non-standard,
> difficult
> to understand and dissatisfying in all ways.  So I think it's best to
> use a completely new method now ;)
> 
> Seriously, if anyone has a good idea then I'm all open for
> proposals. The only requirements I have is that it should be runtime
> configurable and it must be settable per netdev.  I.e., you should be
> able to use both 802.3 and raw-ip qmi_wwan devices at the same time.
> 
> The current approach I use for testing (which I believe I have posted
> a
> few years ago) is ethtool private driver flags.  That's at least a
> standard API.  But I'm all open for sysfs too. Either way, user space
> will have to know about this setting and what it's good for.  And
> sysfs
> has the advantage that you don't need any tool to use it. The cdc_ncm
> sysfs files slipped in without much trouble (although I don't know if
> anyone are using them), so I guess we have a fair chance getting
> something like qmi/linkprotocol or similar accepted too.

My vote would be sysfs, with values "raw-ip" or "802.3" that you can
read and write to the file.  At least then they are human-readable. 
 It's also easier to use from scripts than parsing ethtool output.

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

Re: MC 7304 ipv4v6

[Dan Williams]

Adding libqmi-devel...

On Tue, 2015-11-24 at 21:40 +0100, Reinhard Speyerer wrote:
> [ please keep me CCed, I am not subscribed to the mailing list ]
> 
> On Tue, Nov 24, 2015 at 08:55:42PM +0100, Thomas Schäfer wrote:
> > Am Dienstag, 24. November 2015, 16:06:22 schrieben Sie:
> > > On Mon, 23 Nov 2015 22:42:09 +0100
> > > 
> > 
> > > 
> > > Would you be more specific about the problems you have and attach
> > > more
> > > information?
> > > * What NM, MM versions do you use?
> > 
> > mmcli 1.4.10
> > nmcli tool, version 1.0.6
> > 
> > > * NM, MM logs
> > 
> > are attached. (maybe I have to repeat the test with more debug
> > levels, there 
> > is something wrong about /etc/resolv.conf - the file was correct
> > set by NM)
> > 
> > 
> > > * mmcli -L
> > Found 1 modems:
> > /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless,
> > Incorporated] 
> > MC7304
> > 
> > > * nmcli con show 
> > 
> > is attached.
> > 
> > I made also a trace with wireshark - mc7304.pcapng 
> > It contains 
> > ping to 8.8.8.8 (working)
> > ping6 2600::   (not working)
> > 
> > 
> 
> This looks rather similar to the "Dualstack errors with MC7354"
> problem
> described here 
> https://forum.sierrawireless.com/viewtopic.php?f=117&t=8295 .
> 
> Apparently the qmi_wwan patch contained in the thread was not
> submitted
> as a Linux kernel patch so far.

Bjorn, is this still needed?  If so, any chance you could work on a
fixup patch?

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

Re: MC 7304 ipv4v6

[Bjørn Mork]

Reinhard Speyerer  writes:

> This looks rather similar to the "Dualstack errors with MC7354" problem
> described here https://forum.sierrawireless.com/viewtopic.php?f=117&t=8295 .
>
> Apparently the qmi_wwan patch contained in the thread was not submitted
> as a Linux kernel patch so far.

Ouch, bad conscience hitting hard... Again.

The patch will probably solve the problem, but it makes all the header
fixup magic ten times worse. And at the time I was in doubt whether the
use case was really important enough to warrant a workaround as ugly as
this.  So I wanted to let it rest in the back of my head for a while,
before making up my mind. The only problem is that there is very littly
that will stick there... And I forgot all about it. Sorry

(Note that I'm definitely not criticizing the code - it's ugly because
this is an ugly problem. And as the thread shows, I failed to create the
simple solution I hoped for.)

Thanks for bringing this up again.  I guess we must do something about
it.  But. given the current MC74xx development, I'm really tempted
to say 'use raw IP' in this case.  The thing is, it looks like we have
to support raw IP mode anyway. If so, then we might as well (ab)use it
as workaround for any such header problem instead of adding even more
specialized ugly header rewriting.

What do you think?  Is "dual-stack on MC7354" another candidate for raw
IP? If we are going to add it anyway, that is.

Anyone have any wishes for raw IP driver API/UI?  So far I've added
about 3 such APIs, and they are all different, non-standard, difficult
to understand and dissatisfying in all ways.  So I think it's best to
use a completely new method now ;)

Seriously, if anyone has a good idea then I'm all open for
proposals. The only requirements I have is that it should be runtime
configurable and it must be settable per netdev.  I.e., you should be
able to use both 802.3 and raw-ip qmi_wwan devices at the same time.

The current approach I use for testing (which I believe I have posted a
few years ago) is ethtool private driver flags.  That's at least a
standard API.  But I'm all open for sysfs too. Either way, user space
will have to know about this setting and what it's good for.  And sysfs
has the advantage that you don't need any tool to use it. The cdc_ncm
sysfs files slipped in without much trouble (although I don't know if
anyone are using them), so I guess we have a fair chance getting
something like qmi/linkprotocol or similar accepted too.


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

Re: MC 7304 ipv4v6

[Dan Williams]

On Tue, 2015-11-24 at 20:55 +0100, Thomas Schäfer wrote:
> Am Dienstag, 24. November 2015, 16:06:22 schrieben Sie:
> > On Mon, 23 Nov 2015 22:42:09 +0100
> > 
> 
> > 
> > Would you be more specific about the problems you have and attach
> > more
> > information?
> > * What NM, MM versions do you use?
> 
> mmcli 1.4.10
> nmcli tool, version 1.0.6
> 
> > * NM, MM logs
> 
> are attached. (maybe I have to repeat the test with more debug
> levels, there 
> is something wrong about /etc/resolv.conf - the file was correct set
> by NM)
> 
> 
> > * mmcli -L
> Found 1 modems:
> /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless,
> Incorporated] 
> MC7304
> 
> > * nmcli con show 
> 
> is attached.
> 
> I made also a trace with wireshark - mc7304.pcapng 
> It contains 
> ping to 8.8.8.8 (working)
> ping6 2600::   (not working)

What if you try to ping6 your DNS server at
 2a01:598:7ff:0:10:74:210:210 ?  Also, can you report the output of:

ip addr
ip -6 route

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

Re: MC 7304 ipv4v6

[Reinhard Speyerer]

[ please keep me CCed, I am not subscribed to the mailing list ]

On Tue, Nov 24, 2015 at 08:55:42PM +0100, Thomas Schäfer wrote:
> Am Dienstag, 24. November 2015, 16:06:22 schrieben Sie:
> > On Mon, 23 Nov 2015 22:42:09 +0100
> > 
> 
> > 
> > Would you be more specific about the problems you have and attach more
> > information?
> > * What NM, MM versions do you use?
> 
> mmcli 1.4.10
> nmcli tool, version 1.0.6
> 
> > * NM, MM logs
> 
> are attached. (maybe I have to repeat the test with more debug levels, there 
> is something wrong about /etc/resolv.conf - the file was correct set by NM)
> 
> 
> > * mmcli -L
> Found 1 modems:
> /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless, 
> Incorporated] 
> MC7304
> 
> > * nmcli con show 
> 
> is attached.
> 
> I made also a trace with wireshark - mc7304.pcapng 
> It contains 
> ping to 8.8.8.8 (working)
> ping6 2600::   (not working)
> 
> 

This looks rather similar to the "Dualstack errors with MC7354" problem
described here https://forum.sierrawireless.com/viewtopic.php?f=117&t=8295 .

Apparently the qmi_wwan patch contained in the thread was not submitted
as a Linux kernel patch so far.

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

Re: MC 7304 ipv4v6

[Thomas Schäfer]

Am Dienstag, 24. November 2015, 16:06:22 schrieben Sie:
> On Mon, 23 Nov 2015 22:42:09 +0100
> 

> 
> Would you be more specific about the problems you have and attach more
> information?
> * What NM, MM versions do you use?

mmcli 1.4.10
nmcli tool, version 1.0.6

> * NM, MM logs

are attached. (maybe I have to repeat the test with more debug levels, there 
is something wrong about /etc/resolv.conf - the file was correct set by NM)


> * mmcli -L
Found 1 modems:
/org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless, Incorporated] 
MC7304

> * nmcli con show 

is attached.

I made also a trace with wireshark - mc7304.pcapng 
It contains 
ping to 8.8.8.8 (working)
ping6 2600::   (not working)

Thank you for your help!

Regards,
Thomas



mc7304.tar.xz
Description: application/xz-compressed-tar
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Revise NM behavior for Unmanaged Devices and Assuming Connections (bgo 746440)

[Dan Williams]

On Mon, 2015-11-09 at 17:43 +0100, Thomas Haller wrote:
> Hi,
> 
> 
> Regarding bug https://bugzilla.gnome.org/show_bug.cgi?id=746440,
> about
> unmanaged devices and assuming connections.
> 
> The current behavior is broken and for nm-1-2 this shall be fixed as
> follows:
> 
> Basically, let NM be less smart and instead of "assuming connections"
> let it "activate-gracefully".
> 
> 
> 
> 
> NetworkManager State and Device State
> =
> 
> For doing the right thing when NM starts (after systemctl restart),
> we must know the previous device state.
> 
> Whenever NM activates, manages or unmanges a device, it will write
> the
> device-state to /var/lib/NetworkManager/NetworkManager.state The
> statefile will get the following new entries:
> 
> [main]
> # When we write the statefile, we also remember the boot-id
> # from /proc/sys/kernel/random/boot_id. We need it to properly
> # detect last_seen_current_boot below.
> boot_id=
> 
> 
> # A unique keyfile section for each device-entry.
> # The following keys are under this group.
> [d/43]
> # a mandatory ifname
> ifname=eth0

I'm wondering about device renames, which can happen at any point. 
 Should we just use the ifindex here instead?  That won't change for
any device unless the device has been deleted and re-created (or
hotplugged) at which point we can probably consider it a new device
anyway, at least for virtual devices.

> # optionally, the hwaddress if available. Note that the
> ifname/hwaddr
> # pair consists the key for the entry. When checking the state
> for
> # a device, we first look for an entry which has the same
> ifname/hwaddr
> # pair. If not found, we ignore the hwaddr.
> hwaddr=00:11:22:33:44:55
> 
> # the managed state with
> # STATE = true | false
> managed=STATE
> 
> # last-seen timestamp in POSIX-time (time()). This
> # is so that we can prune the statefile from devices
> # that we didn't see for a while.
> last_seen_timestamp=1447082472
> 
> # Had NM a connection on the device active? This
> # only makes sense for managed=true. Note that
> # this entry will be ignored when the boot-id differs,
> # that means: it's only considered after a restart, not
> # after system reboot.
> last_connection=$CONNECTION_UUID
> 
> 
> The last_seen_timestamp is there to eventually garbage collect the
> state entry. Note that we write a state-entry for every device we
> see.
> Docker for example creates veth devices with unique names so we must
> eventually forget about devices that we didn't see for a while.
> I think NM should handle  many devices and if the state
> -
> list grows larger, we must prune the older ones.

I don't see a great need to make the number configurable right now.  I
know some systems have hundreds of software devices, but maybe we just
put a cap on the number (500?) and see if it needs to be configurable
through experience.

> 
> Whether to manage a device
> ==
> 
> When NM sees a new device, it will very early decide whether to
> manage
> it (nm_device_finish_init()).
> 
> Preferably, we look at the statefile. If the statefile from a
> previous
> NM run indicates whether the device should be mananged/unmanged, do
> it.
> That means, when the user sets
>   nmcli device eth0 set managed on|off
> we will remember that decision in the statefile (yeay).
> 
> In the absence of a statefile entry, we obey other configuration,
> such
> as udev's NM_MANAGED or NM.conf's unmanaged-devices.
> 
> In the absence of any configuration, we manage hardware devices but
> don't manage software devices.

Do you mean how NM currently does, where software devices it creates
are managed, but externally created ones are unmanaged by default?  If
so I agree.

> 
> Note that NM_UNMANAGED_DEFAULT_UNMANAGED goes away (WIP: refactor
> default-unmanged bug 746566 , lr/default-unmanaged-bgo746566).
> 
> 
> 
> Unmanaged Devices
> =
> 
> For unmanaged devices, that's pretty much it. The device is in state
> unmanaged and NM doesn't touch it. No IFF_UP, no sysctl change, etc.
> User can manage the device anytime via `nmcli device set eth0 managed
> yes` or just by activating a connection on it (unless the device
> cannot
> be managed for other reasons like NM_UNMANAGED_PLATFORM_INIT).
> 
> Note that even for unmanaged devices, we already expose the
> Ip4Config/Ip6Config objects and other runtime information. So the
> user
> can see the IP configuration also for unmanaged devices.
> 
> What we will do here however, if we succeed to
> nm_device_generate_connection() on the device, we will add a new in-
> memory NMSettingsConnection and pretend that that connection is
> active
> on the device. That setting will be updated whenever the device
> changes.
> We will not nm_utils_match_connection(), we just generate a new one.
> However, the user can persist the in-memory connection and 

Re: [PATCH] vpn-connection: lack of ipv4 config in remote VPN is not fatal

[Rafaël Carré]

On 16/11/2015 18:12, Lubomir Rintel wrote:
> On Thu, 2015-11-05 at 12:44 +0100, Rafaël Carré wrote:
>> Hello,
>>
>> On 05/11/2015 12:31, Lubomir Rintel wrote:
>>> Thanks for the patch, Rafaël.
>>>
>>> I'm not sure it's correct, though. The VPN plugin probably should
>>> probably only emit "Config" signal and not "IP4Config" when it has
>>> no
>>> IPv4 configuration.
>>
>> You tell me :)
> 
> I've committed a slightly modified version of the patch to the NM-
> openvpn master.
> 
> I'm wondering if you could try it out and see if it works for you?

Finally got to try it, it doesn't work, the helper fails with:

(process:25280): nm-openvpn-WARNING **: No IP4 netmask/prefix (missing
or invalid 'ifconfig_netmask')

(process:25280): nm-openvpn-WARNING **:
nm-openvpn-service-openvpn-helper did not receive a valid IPv4 or IPv6
configuration from openvpn


> What configuration are you using the openvpn plugin in? A IPv6-only
> setup?

static IPv4 only, the server does not send an IP.

Here is my local OpenVPN config:
---
client
dev tap
proto udp
remote vpn.example.com 1194
remote-random
resolv-retry infinite
nobind
persist-key
persist-tun
cipher none
auth-user-pass
ca ca.pem

comp-lzo

ifconfig 192.168.123.11 255.255.255.0

verb 4
mute 20
---

And here is the file created in /etc/NetworkManager/system-connections/
---
[connection]
id=VPN connection 1
uuid=d5fb8899-39e5-453d-8e72-21fa6606ad16
type=vpn
autoconnect=false
permissions=
secondaries=

[vpn]
connection-type=password
password-flags=1
remote=vpn.example.com
cipher=none
comp-lzo=yes
dev-type=tap
username=username
ca=/path/to/ca.pem
service-type=org.freedesktop.NetworkManager.openvpn

[ipv4]
address1=192.168.123.11/24
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=ignore
---

As you see ipv4.address1 is set but NM is still expecting an ip to be
sent by the remote openvpn server instead of using that one.

> Thanks,
> Lubo
> 
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: MC 7304 ipv4v6

[Aleksander Morgado]

> Is there something special because of the two interfaces? (wwan0, wwan1,
> cdc...0, cdc...1)

The only different thing in the interfaces, as far as I know, is that
one is raw-ip and the other one 803.3 by default.

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

Re: [PATCH 2/2] Added OpenSSL crypto backend

[Lubomir Rintel]

On Tue, 2015-11-24 at 16:01 +0100, Jirka Klimes wrote:
> On Thu, 19 Nov 2015 15:30:46 +0100
> Lubomir Rintel  wrote:
> 
> > Hi Joel,
> > 
> > thanks for the patch but I don't think it makes sense to apply it. 
> > 
> > I think distributing NetworkManager linked with OpenSSL would be a
> > violation of NetworkManager's license (since the OpenSSL license
> > adds
> > an extra restriction, something that is not allowed by General
> > Public
> > License).
> > 
> 
> Maybe, LibreSSL could be used instead.
> http://www.libressl.org/
> https://en.wikipedia.org/wiki/LibreSSL

No. That's essentially just OpenSSL and thus covered by the very same
license.

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

Re: MC 7304 ipv4v6

[Jirka Klimes]

On Mon, 23 Nov 2015 22:42:09 +0100
Thomas Schäfer  wrote:

> Hi,
> 
> There is a device stranded in front of my computer: MC7304.
> It works basically under linux. But I have a problem. The dualstack
> mode of the provided by Deutsche Telekom makes problems. Addresses
> are assigned (IPv4 and IPv6), but only ipv4 is usable.
> 
> Do you have any ideas, where I could start from? The same
> configuration (qmi, mm,nm) runs other devices without problems in
> dualstack.
> 
> Is there something special because of the two interfaces? (wwan0,
> wwan1, cdc...0, cdc...1)
> 
> 
> Regards,
> Thomas
> 

Would you be more specific about the problems you have and attach more
information?
* What NM, MM versions do you use?
* NM, MM logs
* mmcli -L
* nmcli con show 

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

Re: [PATCH 2/2] Added OpenSSL crypto backend

[Jirka Klimes]

On Thu, 19 Nov 2015 15:30:46 +0100
Lubomir Rintel  wrote:

> Hi Joel,
> 
> thanks for the patch but I don't think it makes sense to apply it. 
> 
> I think distributing NetworkManager linked with OpenSSL would be a
> violation of NetworkManager's license (since the OpenSSL license adds
> an extra restriction, something that is not allowed by General Public
> License).
> 

Maybe, LibreSSL could be used instead.
http://www.libressl.org/
https://en.wikipedia.org/wiki/LibreSSL

Jirka

> Please refer to the following link for more details and discussion on
> the topic:
> 
> https://people.gnome.org/~markmc/openssl-and-the-gpl.html
> 
> We do already have two crypto backends whose license doesn't clash
> with our licensing, I suggest you just use those if possible.
> 
> Sorry for that.
> 
> Lubo
> 
> On Thu, 2015-11-19 at 00:01 +, Joel Holdsworth wrote:
> > ---
> >  configure.ac|  16 ++-
> >  libnm-core/Makefile.am  |   6 +
> >  libnm-core/crypto_openssl.c | 324
> > 
> >  po/POTFILES.in  |   1 +
> >  4 files changed, 340 insertions(+), 7 deletions(-)
> >  create mode 100644 libnm-core/crypto_openssl.c
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 7b4ca9a..83ae5a0 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -594,10 +594,12 @@ else
> >  fi
> >  AC_SUBST(NM_MODIFY_SYSTEM_POLICY)
> >  
> > -AC_ARG_WITH(crypto, AS_HELP_STRING([--with-crypto=nss|gnutls],
> > [Cryptography library to use for certificate and key
> > operations]),ac_crypto=$withval, ac_crypto=nss)
> > +AC_ARG_WITH(crypto, AS_HELP_STRING([--with-
> > crypto=nss|gnutls|openssl],
> > +   [Cryptography library to use for certificate and key
> > operations]), ac_crypto=$withval, ac_crypto=nss)
> >  
> ___
> 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