Re: MC 7304 ipv4v6 - raw-ip in qmi/mm/nm

[Bjørn Mork]

Bjørn Mork  writes:

> And DHCP support is even more complex. DHCP clients must know how to
> handle (add/remove/parse) L2 headers. Or lack of headers in this case.
> I don't know of any client supporting that at the moment.  But it should
> be easier than any other L2 interface type support, since all you need
> to do is drop the L2 header adding/removing/parsing.

I made an attempt to see just how hard it is.  The attached patch is a
bit rough, and doesn't include support for anything but Linux, but it
sort of works:

nemi:/tmp# ./dhclient -d -4 wwan0
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wwan0/
Sending on   LPF/wwan0/
Sending on   Socket/fallback
DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 3
Attempt to assemble hw header for pure IP
Attempt to decode hw header for Pure IP
Received DHCPv4 packet without client-id option and empty hlen field.
DHCPREQUEST on wwan0 to 255.255.255.255 port 67
Attempt to assemble hw header for pure IP
DHCPOFFER from 10.140.149.145
Attempt to decode hw header for Pure IP
Received DHCPv4 packet without client-id option and empty hlen field.
DHCPACK from 10.140.149.145
RTNETLINK answers: File exists
bound to 10.140.149.146 -- renewal in 3595 seconds.


Bjørn

>From ba61b258dd373b4395c08a4fb89a6542d1bec9d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Mon, 21 Dec 2015 01:28:31 +0100
Subject: [PATCH] dhclient: raw IP support
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Bjørn Mork 
---
 common/bpf.c| 27 +++
 common/lpf.c| 44 
 common/packet.c |  6 ++
 includes/dhcp.h |  1 +
 4 files changed, 78 insertions(+)

diff --git a/common/bpf.c b/common/bpf.c
index 39d4f45..27c025d 100644
--- a/common/bpf.c
+++ b/common/bpf.c
@@ -204,6 +204,33 @@ struct bpf_insn *bpf_fddi_filter;
 #endif
 
 int dhcp_bpf_filter_len = sizeof dhcp_bpf_filter / sizeof (struct bpf_insn);
+
+struct bpf_insn dhcp_bpf_ip_filter [] = {
+	/* Make sure it's a UDP packet... */
+	BPF_STMT (BPF_LD + BPF_B + BPF_ABS, 9),
+	BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 6),
+
+	/* Make sure this isn't a fragment... */
+	BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 6),
+	BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 4, 0),
+
+	/* Get the IP header length... */
+	BPF_STMT (BPF_LDX + BPF_B + BPF_MSH, 0),
+
+	/* Make sure it's to the right port... */
+	BPF_STMT (BPF_LD + BPF_H + BPF_IND, 2),
+	BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, 37, 0, 1), /* patch */
+
+	/* If we passed all the tests, ask for the whole packet. */
+	BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
+
+	/* Otherwise, drop it. */
+	BPF_STMT(BPF_RET+BPF_K, 0),
+};
+
+int dhcp_bpf_ip_filter_len = sizeof dhcp_bpf_ip_filter / sizeof (struct bpf_insn);
+
+
 #if defined (HAVE_TR_SUPPORT)
 struct bpf_insn dhcp_bpf_tr_filter [] = {
 /* accept all token ring packets due to variable length header */
diff --git a/common/lpf.c b/common/lpf.c
index ee3820b..22ad61b 100644
--- a/common/lpf.c
+++ b/common/lpf.c
@@ -179,6 +179,9 @@ void if_deregister_send (info)
 extern struct sock_filter dhcp_bpf_filter [];
 extern int dhcp_bpf_filter_len;
 
+extern struct sock_filter dhcp_bpf_ip_filter [];
+extern int dhcp_bpf_ip_filter_len;
+
 #if defined (HAVE_TR_SUPPORT)
 extern struct sock_filter dhcp_bpf_tr_filter [];
 extern int dhcp_bpf_tr_filter_len;
@@ -186,6 +189,7 @@ static void lpf_tr_filter_setup (struct interface_info *);
 #endif
 
 static void lpf_gen_filter_setup (struct interface_info *);
+static void lpf_pureip_filter_setup (struct interface_info *);
 
 void if_register_receive (info)
 	struct interface_info *info;
@@ -212,6 +216,9 @@ void if_register_receive (info)
 		lpf_tr_filter_setup (info);
 	else
 #endif
+	if (info -> hw_address.hbuf [0] == HTYPE_PUREIP)
+		lpf_pureip_filter_setup (info);
+	else
 		lpf_gen_filter_setup (info);
 
 	if (!quiet_interface_discovery)
@@ -276,6 +283,39 @@ static void lpf_gen_filter_setup (info)
 	}
 }
 
+static void lpf_pureip_filter_setup (info)
+	struct interface_info *info;
+{
+	struct sock_fprog p;
+
+	memset(, 0, sizeof(p));
+
+	/* Set up the bpf filter program structure.This is defined in
+	   bpf.c */
+	p.len = dhcp_bpf_ip_filter_len;
+	p.filter = dhcp_bpf_ip_filter;
+
+/* Patch the server port into the LPF  program...
+	   XXX changes to filter program may require changes
+	   to the insn number(s) used below! XXX */
+	dhcp_bpf_ip_filter [6].k = ntohs ((short)local_port);
+
+	if (setsockopt (info -> rfdesc, SOL_SOCKET, SO_ATTACH_FILTER, ,
+			sizeof p) < 0) {
+		if (errno == ENOPROTOOPT || errno == EPROTONOSUPPORT ||
+		errno == ESOCKTNOSUPPORT || errno == EPFNOSUPPORT ||
+		errno == EAFNOSUPPORT) {
+			log_error ("socket: %m - make sure");
+	

Re: MC 7304 ipv4v6 - raw-ip in qmi/mm/nm

[Bjørn Mork]

Thomas Schäfer  writes:

> Am Freitag, 18. Dezember 2015, 21:51:42 schrieb Bjørn Mork:
>
>> Just FYI: I ended up with an automated random address, which will be
>> stable for the lifetime of the interface. This has now been accepted
>> into net-next, so SLAAC will be in place along with the qmi raw-ip
>> support in v4.5.
>
>
> It is nice to see the support of raw ip in kernel 4.5. 
>
> Now my questions are:
>
> What are the next steps in libqmi, MM and NM?
>
> How to make the address/DNS-settings? 
>
> in-band - dhcp/slaac
> or 
> out-band via bearer-information?
>
> To bypass some commands of qmi/mm/nm works for tests, but this is far away 
> for 
> daily use "out of the box".
>
> Where should I focus my test activities?

That's up to you to decide :)

Regarding the dhcp support: It would be nice to see a set of DHCP(v6)
utilities which were somewhat more agnostic wrt interface type.  And
that's a completely generic wish, independently of the current wwan/lte
modem support. All DHCPv6 clients should be expected to support ppp
interfaces for example. For DHCPv6 there is absolutely no reason
whatsoever to care about interface type. But some clients will still
refuse to run on anything but ethernet. Go figure:

 nemi:/tmp# echo Y >/sys/class/net/wwan0/qmi/raw_ip 
 nemi:/tmp# ifconfig wwan0 up
 nemi:/tmp# ifconfig wwan0
 wwan0 Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
   inet6 addr: fe80::7f1c:9e91:8e04:70b2/64 Scope:Link
   inet6 addr: 2a02:2121:86:891:d33:30fa:222c:3628/64 Scope:Global
   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
   RX packets:1 errors:0 dropped:0 overruns:0 frame:0
   TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000 
   RX bytes:104 (104.0 B)  TX bytes:696 (696.0 B)
 nemi:/tmp# dhclient -d -S wwan0
 Internet Systems Consortium DHCP Client 4.3.1
 Copyright 2004-2014 Internet Systems Consortium.
 All rights reserved.
 For info, please visit https://www.isc.org/software/dhcp/
 
 Unsupported device type 65534 for "wwan0"
 
 If you think you have received this message due to a bug rather
 than a configuration issue please read the section on submitting
 bugs on either our web page at www.isc.org or in the README file
 before submitting a bug.  These pages explain the proper
 process and the information we find helpful for debugging..
 
 exiting.


Luckily there are better choices availabe.  The Wide DHCPv6 client works
on any type of IPv6 interface:

 nemi:/tmp# dhcp6c -fDi wwan0
 Dec/19/2015 17:32:33: get_duid: extracted an existing DUID from 
/var/lib/dhcpv6/dhcp6c_duid: 00:01:00:01:1e:08:2b:25:00:21:86:a3:25:7d
 Dec/19/2015 17:32:33: dhcp6_reset_timer: reset a timer on wwan0, state=INIT, 
timeo=0, retrans=731
 Dec/19/2015 17:32:34: client6_send: a new XID (67c25c) is generated
 Dec/19/2015 17:32:34: copy_option: set client ID (len 14)
 Dec/19/2015 17:32:34: copy_option: set elapsed time (len 2)
 Dec/19/2015 17:32:34: client6_send: send information request to ff02::1:2%wwan0
 Dec/19/2015 17:32:34: dhcp6_reset_timer: reset a timer on wwan0, 
state=INFOREQ, timeo=0, retrans=900
 Dec/19/2015 17:32:34: client6_recv: receive reply from 
fe80::5dc:b41:f9a3:46f8%wwan0 on wwan0
 Dec/19/2015 17:32:34: dhcp6_get_options: get DHCP option client ID, len 14
 Dec/19/2015 17:32:34:   DUID: 00:01:00:01:1e:08:2b:25:00:21:86:a3:25:7d
 Dec/19/2015 17:32:34: dhcp6_get_options: get DHCP option server ID, len 10
 Dec/19/2015 17:32:34:   DUID: 00:03:00:01:02:50:f3:00:01:00
 Dec/19/2015 17:32:34: dhcp6_remove_event: removing an event on wwan0, 
state=INFOREQ
 Dec/19/2015 17:32:34: client6_recvreply: got an expected reply, sleeping.
 Dec/19/2015 17:32:34: check_exit: exiting

And no, the above is not faked: The MC7455 supports DHCPv6 :) And it
uses an ethernet DUID-LL, for whatever reason. A with a non-unique local
address, just to be on the safe side.  You might wonder where Qualcomm
gets their firmware developers... There is no reason to suspect any of
them for wasting time on RFCs ;) Well, whatever.  It will probably work
most of the time.  But if you ever want an example of a BAD choice of
DUID, there you have it.

The above shows that the Wide DHCPv6 client also has its share of
problems: It does not request DNS servers by default in 'information'
mode.  Creating a config file works around this problem:

 nemi:/tmp# dhcp6c -fDc /tmp/dhcp6c.conf wwan0
 Dec/19/2015 17:32:38: get_duid: extracted an existing DUID from 
/var/lib/dhcpv6/dhcp6c_duid: 00:01:00:01:1e:08:2b:25:00:21:86:a3:25:7d
 Dec/19/2015 17:32:38: cfdebug_print: <3>[interface] (9)
 Dec/19/2015 17:32:38: cfdebug_print: <5>[wwan0] (5)
 Dec/19/2015 17:32:38: cfdebug_print: <3>begin of closure [{] (1)
 Dec/19/2015 17:32:38: cfdebug_print: <3>[information-only] (16)
 Dec/19/2015 17:32:38: cfdebug_print: <3>end of sentence [;] (1)
 Dec/19/2015 17:32:38: cfdebug_print: <3>[request] (7)
 

Re: MC 7304 ipv4v6 - raw-ip in qmi/mm/nm

[Thomas Schäfer]

Am Freitag, 18. Dezember 2015, 21:51:42 schrieb Bjørn Mork:

> Just FYI: I ended up with an automated random address, which will be
> stable for the lifetime of the interface. This has now been accepted
> into net-next, so SLAAC will be in place along with the qmi raw-ip
> support in v4.5.


It is nice to see the support of raw ip in kernel 4.5. 

Now my questions are:

What are the next steps in libqmi, MM and NM?

How to make the address/DNS-settings? 

in-band - dhcp/slaac
or 
out-band via bearer-information?

To bypass some commands of qmi/mm/nm works for tests, but this is far away for 
daily use "out of the box".

Where should I focus my test activities?

Thomas





___
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:
> Bjørn Mork  writes:
>> Reinhard Speyerer  writes:
>>
>>> On Sat, Nov 28, 2015 at 10:58:17PM +0100, Thomas Schäfer wrote:
 [...]
 I would be very happy if somebody tells me the steps for testing with PDP-
 context IPv4v6.
>>>
>>> Not sure whether this also applies to qmi-cli as I used a different
>>> QMI client (which leaves network interface initialization to the
>>> application) for a short dualstack test with Linux kernel 3.12.x and a
>>> MC7304 but for me IPv6 only worked when explicitly assigning a
>>> link-local address with e.g.
>>> # ifconfig wwan inet6 add fe80::1:2:3:4/64 up
>>> when the network interface was set to raw IP mode instead of simply using
>>> # ifconfig wwan inet6 up
>>> as no router solicitations were sent out otherwise.
>>
>> That's a very good point indeed!  I didn't think of the possibility of
>> supporting SLAAC over raw-ip interfaces. I only did manual address
>> config on IPv6 too. Thanks for verifying that the modem replies to RS
>> over raw-ip.
>>
>> I'll see if I can figure out what it takes to automatically assign a
>> link local address for these interfaces. I guess that should be done in
>> any case for proper IPv6 support
>
> hmm, "fixing" this seems simple enough: Just add the necessary code to
> net/ipv6/addrconf.c for handling ARPHRD_NONE devices.  But I have two
> questions:
>
> 1) will random addresses be a problem?  We might have to recreate the
>  address every time the interface comes up, as we have nowhere to store
>  it AFAICS.  So the link-local address will change whenever you toggle
>  the device down/up.
>
> 2) what about other ARPHRD_NONE devices? This is currently 'tun', 'hso'
>  and 'n_gsm'.  Will a default IPv6 link local address be a problem for
>  any of these?
>
> The only device type I know how to test is 'tun'.  And to me it looks
> like an obvious winner there.  Why shouldn't tun devices do SLAAC and
> support other IPv6 link local services by default?  But I don't normally
> use such devices, so I know very little about real use cases...
>
> If we can't add such generic ARPHRD_NONE code, then the alternatives I
> can see are
>  - defined an new ARPHRD_ type with about the same semantics, and add
>ipv6/addrconf code for it
>  - do some driver hack - I believe it is possible to manually create an
>IPv6 device and assign an address from the driver.
>
> I don't like either.  So I guess I will propose the ARPHRD_NONE code.

Just FYI: I ended up with an automated random address, which will be
stable for the lifetime of the interface. This has now been accepted
into net-next, so SLAAC will be in place along with the qmi raw-ip
support in v4.5.


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

Re: MC 7304 ipv4v6 - now works in (my) test environment

[Thomas Schäfer]

Am Montag, 30. November 2015, 13:23:43 schrieb Bjørn Mork:
> I guess it's too late now, but testing this with MM is actually much
> easier.  I was able to successfully change the mode after MM had opened
> the device by using
> 
>  qmicli -p -d /dev/cdc-wdm1 --device-open-net='net-raw-ip|net-no-qos-header'
> --get-service-version-info
> 
> in aother terminal.  This must be done after MM probes and opens the
> modem, but before connecting.


From NM to MM to libqmi to kernel-driver and back. Thank your for the great 
support and the patience. ( especially for the people thinking  the thread 
tends to go off topic)

Today I was able to connect the MC 7304 via dualstack. 
(the huawei E398 did also work, just for reference)

It was a little bit tricky (crazy?), but it did work reproducable.

After switching in raw-mode - via side loading the ModemManager.
echo 1 > /sys/ raw_ip
and 
qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --
get-service-version-info

I made the connection via NetworkManager.

Ironically IPv6 worked better than IPv4. NM was setting addresses, routes and 
DNS for IPv6.

For IPv4 I had to do some things manually.

I have got all information - via different ways for IPv4 and IPv6. But in the 
end - raw ip is the/one solution for that device and maybe for some other.

hpmini:~ # mmcli -b 0
Bearer '/org/freedesktop/ModemManager1/Bearer/0'
  -
  Status |   connected: 'yes'
 |   suspended: 'no'
 |   interface: 'wwan0'
 |  IP timeout: '20'
  -
  Properties | apn: 'internet.telekom'
 | roaming: 'allowed'
 | IP type: 'ipv4v6'
 |user: 'tm'
 |password: 'none'
 |  number: '*99#'
 | Rm protocol: 'unknown'
  -
  IPv4 configuration |   method: 'dhcp'
 |  address: 'unknown'
 |   prefix: '0'
 |  gateway: 'unknown'
 |  DNS: none
 |  MTU: '1430'
  -
  IPv6 configuration |   method: 'dhcp'
 |  address: '2a01:598:b000:1afd:7cfd:efcb:c7:c156'
 |   prefix: '64'
 |  gateway: '2a01:598:b000:1afd:347e:fc7a:f0c1:c014'
 |  DNS: '2a01:598:7ff:0:10:74:210:210'
 |  MTU: '1430'

hpmini:~ # qmicli -p -d /dev/cdc-wdm0 --wds-get-current-settings
[/dev/cdc-wdm0] Current settings retrieved:
   IP Family: IPv4
IPv4 address: 10.18.88.31
IPv4 subnet mask: 255.255.255.192
IPv4 gateway address: 10.18.88.1
IPv4 primary DNS: 10.74.210.210
  IPv4 secondary DNS: 10.74.210.211
 MTU: 1430
 Domains: none


8: wwan0:  mtu 1500 qdisc pfifo_fast state 
UNKNOWN group default qlen 1000
link/none 
inet 10.18.88.31/26 scope global wwan0
   valid_lft forever preferred_lft forever
inet6 2a01:598:b000:1afd:62df:7a2c:4772:e492/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 2a01:598:b000:1afd:2f09:788a:f047:7c27/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 2a01:598:b000:1afd:d6c7:24fe:cddd:bcc5/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 2a01:598:b000:1afd:6a6b:6c6b:7d2a:1177/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 2a01:598:b000:1afd:7a4:e8ba:6a45:a976/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 2a01:598:b000:1afd:a22:970e:6746:dab5/64 scope global mngtmpaddr 
dynamic 
   valid_lft forever preferred_lft forever
inet6 2a01:598:b000:1afd:7cfd:efcb:c7:c156/64 scope global 
   valid_lft forever preferred_lft forever
inet6 fe80::a68d:ed6:2082:861f/64 scope link 
   valid_lft forever preferred_lft forever


Regards,
Thomas Schäfer









 


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

Re: MC 7304 ipv4v6

[Bjørn Mork]

Reinhard Speyerer  writes:
> On Mon, Nov 30, 2015 at 10:53:35AM +0100, Bjørn Mork wrote:
>
>> hmm, "fixing" this seems simple enough: Just add the necessary code to
>> net/ipv6/addrconf.c for handling ARPHRD_NONE devices.  But I have two
>> questions:
>> 
>> 1) will random addresses be a problem?  We might have to recreate the
>>  address every time the interface comes up, as we have nowhere to store
>>  it AFAICS.  So the link-local address will change whenever you toggle
>>  the device down/up.
>
> This might invalidate some fundamental assumptions in the firmware about
> the host environment. My suggestion would therefore be to avoid changing
> the link-local address when changing the network interface up/down status.

Yes.  That's definitely so unexpected that it's better not to implement
it at all..

>> 2) what about other ARPHRD_NONE devices? This is currently 'tun', 'hso'
>>  and 'n_gsm'.  Will a default IPv6 link local address be a problem for
>>  any of these?
>> 
>> The only device type I know how to test is 'tun'.  And to me it looks
>> like an obvious winner there.  Why shouldn't tun devices do SLAAC and
>> support other IPv6 link local services by default?  But I don't normally
>> use such devices, so I know very little about real use cases...
>
> Since tun may have non-IP use cases and n_gsm is a line discipline AFAIK
> we should probably not overload ARPHRD_NONE like this.

I'm not sure that would be a problem, any more than using ethernet for
non-IP is one.

>> If we can't add such generic ARPHRD_NONE code, then the alternatives I
>> can see are
>>  - defined an new ARPHRD_ type with about the same semantics, and add
>>ipv6/addrconf code for it
>>  - do some driver hack - I believe it is possible to manually create an
>>IPv6 device and assign an address from the driver.
>> 
>> I don't like either.  So I guess I will propose the ARPHRD_NONE code.
>> 
>
> Perhaps it might be possible to use raw IP mode with IPv6 without a
> link-local address by using WDS status indications?

It's definitely possible to use raw IP with IPv6 without a link local
address.  But I don't think it should be :)

> The reason I used
> the original ifconfig inet6 up implementation was that this was
> required to trigger SLAAC according to ETSI/3GPP TS 27.060 for early
> MC77xx firmware versions as WDSGetCurrentSettings did not return an
> IPv6 prefix when WDSStartNetwork was finished.
>
> However at least current MC73xx firmware versions (and perhaps also
> other "modern" QMI firmwares) now proactively perform an internal SLAAC
> after a WDSStartNetwork and WDSGetCurrentSettings returns the same IPv6
> prefix as an ifconfig inet6 up with SLAAC in Ethernet mode would.  If
> mReconfigureRequired from the WDSPacketServiceStatusReport TLV 0x01
> would correctly indicate when the IPv6 prefix assigned from the
> network has changed it might be possible to mirror the effect of SLAAC
> for raw IP from user space.

Yes, I know that the prefix could change - in theory.  I have my doubts
whether that would actually work in the real world.  The status is about
the same as for IPv6 renumbering elsewhere: All the necessary tools are
there so you can make it work, but every user and device have made some
bogus assuption that needs fixing first.

I don't think we are any more guaranteed that renumbering will work with
SLAAC than without.  The chances are about the same.

And I believe the good NM people will want to do SLAAC in userspace
anyway.  So the missing link local address might be a non-issue for NM?

In any case, I got very helpful feedback from YOSHIFUJI Hideaki so I
am considering implementing a random (but permanent) ifid allocation
scheme after all.


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

Re: MC 7304 ipv4v6

[Bjørn Mork]

Bjørn Mork  writes:
> Reinhard Speyerer  writes:
>
>> On Sat, Nov 28, 2015 at 10:58:17PM +0100, Thomas Schäfer wrote:
>>> [...]
>>> I would be very happy if somebody tells me the steps for testing with PDP-
>>> context IPv4v6.
>>
>> Not sure whether this also applies to qmi-cli as I used a different
>> QMI client (which leaves network interface initialization to the
>> application) for a short dualstack test with Linux kernel 3.12.x and a
>> MC7304 but for me IPv6 only worked when explicitly assigning a
>> link-local address with e.g.
>> # ifconfig wwan inet6 add fe80::1:2:3:4/64 up
>> when the network interface was set to raw IP mode instead of simply using
>> # ifconfig wwan inet6 up
>> as no router solicitations were sent out otherwise.
>
> That's a very good point indeed!  I didn't think of the possibility of
> supporting SLAAC over raw-ip interfaces. I only did manual address
> config on IPv6 too. Thanks for verifying that the modem replies to RS
> over raw-ip.
>
> I'll see if I can figure out what it takes to automatically assign a
> link local address for these interfaces. I guess that should be done in
> any case for proper IPv6 support

hmm, "fixing" this seems simple enough: Just add the necessary code to
net/ipv6/addrconf.c for handling ARPHRD_NONE devices.  But I have two
questions:

1) will random addresses be a problem?  We might have to recreate the
 address every time the interface comes up, as we have nowhere to store
 it AFAICS.  So the link-local address will change whenever you toggle
 the device down/up.

2) what about other ARPHRD_NONE devices? This is currently 'tun', 'hso'
 and 'n_gsm'.  Will a default IPv6 link local address be a problem for
 any of these?

The only device type I know how to test is 'tun'.  And to me it looks
like an obvious winner there.  Why shouldn't tun devices do SLAAC and
support other IPv6 link local services by default?  But I don't normally
use such devices, so I know very little about real use cases...

If we can't add such generic ARPHRD_NONE code, then the alternatives I
can see are
 - defined an new ARPHRD_ type with about the same semantics, and add
   ipv6/addrconf code for it
 - do some driver hack - I believe it is possible to manually create an
   IPv6 device and assign an address from the driver.

I don't like either.  So I guess I will propose the ARPHRD_NONE code.


Bjørn
___
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:

> Probably.  I don't know how to do that.  Is there an IP family setting
> for qmicli? Another alternative is modifying the 802.3 default in
> ModemManager.  That would be this part of src/mm-port-qmi.c:
>
>if (ctx->set_data_format)
> flags |= (QMI_DEVICE_OPEN_FLAGS_NET_802_3 | 
> QMI_DEVICE_OPEN_FLAGS_NET_NO_QOS_HEADER);
>
> Changing it to something like
>
>if (ctx->set_data_format)
> flags |= (QMI_DEVICE_OPEN_FLAGS_NET_RAW_IP | 
> QMI_DEVICE_OPEN_FLAGS_NET_NO_QOS_HEADER);
>
> should do for a simple test. I don't think you can use NM to configure
> the netdev, though.  So you'll have to do that manually after connecting.

I guess it's too late now, but testing this with MM is actually much
easier.  I was able to successfully change the mode after MM had opened
the device by using

 qmicli -p -d /dev/cdc-wdm1 --device-open-net='net-raw-ip|net-no-qos-header' 
--get-service-version-info

in aother terminal.  This must be done after MM probes and opens the
modem, but before connecting.

(Note: I am testing this on a modem without WDA, which is why I use the
'--device-open-net=' command.  Any modem with WDA support should use
'--wda-set-data-format=' instead.)


Did this to test the fix for the missing IPv6 link local address, with
the attached patch.

Yuck, I do now see the major drawback with the random ifid-method:  For
some reason I imagined it would create an ifid once and then use it for
all prefixes added. Cannot explain where I got that idea from.  The ifid
code is called for every prefix, and if it succeeds then we won't try to
inherit an existing ifid.  So the result is different ifids for every
prefix:

nemi:/home/bjorn# ifconfig wwan1
wwan1 Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  inet addr:10.126.247.221  P-t-P:10.126.247.221  Mask:255.255.255.0
  inet6 addr: fe80::c277:9246:bac8:195a/64 Scope:Link
  inet6 addr: 2a02:2121:81:8d4d:3209:fb71:3275:ce5/64 Scope:Global
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:60 errors:0 dropped:0 overruns:0 frame:0
  TX packets:159 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:5188 (5.0 KiB)  TX bytes:10620 (10.3 KiB)


Bringing the interface down and up again results in two new, unrelated,
ifids:

nemi:/home/bjorn# ifconfig wwan1 down
nemi:/home/bjorn# ifconfig wwan1 up
nemi:/home/bjorn# ifconfig wwan1
wwan1 Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  inet addr:10.126.247.221  P-t-P:10.126.247.221  Mask:255.255.255.0
  inet6 addr: 2a02:2121:81:8d4d:7eea:c498:60eb:edee/64 Scope:Global
  inet6 addr: fe80::8f0b:4ca6:e22e:7149/64 Scope:Link
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:61 errors:0 dropped:0 overruns:0 frame:0
  TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:5292 (5.1 KiB)  TX bytes:10668 (10.4 KiB)



That's not good...  Maybe it's better to let the driver add an address
after all.  Unless there is a way to make the addrconf code always
consider inheritance.


Bjørn
>From 7776a8161fca6de07d45d3c1bde11836bacde0c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Mon, 30 Nov 2015 11:06:40 +0100
Subject: [RFC] ipv6: use a random ifid for headerless devices
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Generating a random ifid for devices with no L2 header
at all, allowing such devices to take part in IPv6
autoconfiguration. The tuntap driver is one example of
a driver where such an ifid would be useful.

Note that as there is no persistence, new addresses
will be generated every time an interface is brought up:

 # ip -6 addr show dev tun0
 8: tun0:  mtu 1500 state UNKNOWN qlen 500
 inet6 fe80::eef2:111c:f270:92ba/64 scope link
valid_lft forever preferred_lft forever
 # ip link set tun0 down
 # ip link set tun0 up
 # ip -6 addr show dev tun0
 8: tun0:  mtu 1500 state UNKNOWN qlen 500
 inet6 fe80::eec0:48d0:6b52:8835/64 scope link
valid_lft forever preferred_lft forever

Signed-off-by: Bjørn Mork 
---
 net/ipv6/addrconf.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d84742f003a9..6cf3cae691a5 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2026,6 +2027,13 @@ static int addrconf_ifid_ip6tnl(u8 *eui, struct net_device *dev)
 	return 0;
 }
 
+static int addrconf_ifid_random(u8 *eui, struct net_device *dev)
+{
+	get_random_bytes(eui, 8);
+	eui[0] |= 0x02;
+	

Re: MC 7304 ipv4v6

[tschaefer]

I would expect to get the Ipv6-information via qmicli and setting them manually 
(later via mm, nm), like now for ipv4.(without dhcp, without slaac)
I want to know if rawip is better than 802.3 in respect to dualstack, where 
some of my devices fail.
Thomas


Am 29.11.2015 17:43 schrieb Reinhard Speyerer :
>
> On Sat, Nov 28, 2015 at 10:58:17PM +0100, Thomas Schäfer wrote: 
> > [...] 
> > I would be very happy if somebody tells me the steps for testing with PDP- 
> > context IPv4v6. 
>
> Not sure whether this also applies to qmi-cli as I used a different 
> QMI client (which leaves network interface initialization to the 
> application) for a short dualstack test with Linux kernel 3.12.x and a 
> MC7304 but for me IPv6 only worked when explicitly assigning a 
> link-local address with e.g. 
> # ifconfig wwan inet6 add fe80::1:2:3:4/64 up 
> when the network interface was set to raw IP mode instead of simply using 
> # ifconfig wwan inet6 up 
> as no router solicitations were sent out otherwise. 
>
> Regards, 
> Reinhard 
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: MC 7304 ipv4v6

[Reinhard Speyerer]

On Sat, Nov 28, 2015 at 10:58:17PM +0100, Thomas Schäfer wrote:
> [...]
> I would be very happy if somebody tells me the steps for testing with PDP-
> context IPv4v6.

Not sure whether this also applies to qmi-cli as I used a different
QMI client (which leaves network interface initialization to the
application) for a short dualstack test with Linux kernel 3.12.x and a
MC7304 but for me IPv6 only worked when explicitly assigning a
link-local address with e.g.
# ifconfig wwan inet6 add fe80::1:2:3:4/64 up
when the network interface was set to raw IP mode instead of simply using
# ifconfig wwan inet6 up
as no router solicitations were sent out otherwise.

Regards,
Reinhard
___
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:

> On Sat, Nov 28, 2015 at 10:58:17PM +0100, Thomas Schäfer wrote:
>> [...]
>> I would be very happy if somebody tells me the steps for testing with PDP-
>> context IPv4v6.
>
> Not sure whether this also applies to qmi-cli as I used a different
> QMI client (which leaves network interface initialization to the
> application) for a short dualstack test with Linux kernel 3.12.x and a
> MC7304 but for me IPv6 only worked when explicitly assigning a
> link-local address with e.g.
> # ifconfig wwan inet6 add fe80::1:2:3:4/64 up
> when the network interface was set to raw IP mode instead of simply using
> # ifconfig wwan inet6 up
> as no router solicitations were sent out otherwise.

That's a very good point indeed!  I didn't think of the possibility of
supporting SLAAC over raw-ip interfaces. I only did manual address
config on IPv6 too. Thanks for verifying that the modem replies to RS
over raw-ip.

I'll see if I can figure out what it takes to automatically assign a
link local address for these interfaces. I guess that should be done in
any case for proper IPv6 support


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

Re: MC 7304 ipv4v6

[Thomas Schäfer]

Am 29.11.2015 um 12:53 schrieb Aleksander Morgado:
> On Sun, Nov 29, 2015 at 11:59 AM, Thomas Schäfer  
> wrote:
>> Am 29.11.2015 um 02:24 schrieb Aleksander Morgado:
>>> On Sat, Nov 28, 2015 at 10:58 PM, Thomas Schäfer  
>>> wrote:
 It works (tested only IPv4, LTE) with the following devices:

 *Telekom Speedstick LTE alias Huawei E398
 *Vodafone K 5005 alias Huawei E398 modified
 *Telekom Speedstick II alias ONE TOUCH L100V LTE
 *MC 7304
 *Vodafone K 5006Z alias ZTE MF821V
 *O2 ZTE MF821D
 *4G-Systems XS-stick W100 LTE  (version 2)
>>>
>>> Which of these support the WDA QMI service?

> Knowing that WDA was available was enough; older Gobi modems don't
> implement that service. Just trying to get an idea of whether we can
> use the existence of that service as an indication that we can default
> to raw-ip.
> 


One (K5005) has no wda.




Telekom Speedstick LTE alias Huawei E398
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.12)
dms (1.7)
nas (1.21)
qos (1.3)
wms (1.4)
pds (1.10)
auth (1.1)
at (1.1)
voice (2.1)
cat2 (2.0)
uim (1.4)
pbm (1.4)
wda (1.0)
cat (0.0)
Vodafone K5005 alias Huawei E398 modified
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.12)
dms (1.6)
nas (1.8)
qos (1.3)
wms (1.3)
pds (1.10)
auth (1.1)
voice (2.1)
cat2 (2.0)
uim (1.4)
pbm (1.4)
cat (0.0)
Telekom Speedstick II alias alcatel ONE TOUCH L100V LTE
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.12)
dms (1.7)
nas (1.21)
qos (1.3)
wms (1.4)
pds (1.10)
auth (1.1)
at (1.1)
voice (2.1)
cat2 (2.0)
uim (1.4)
pbm (1.4)
wda (1.0)
cat (2.0)
MC7304
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.36)
dms (1.14)
nas (1.25)
qos (1.3)
wms (1.10)
pds (1.0)
auth (1.2)
at (1.2)
cat2 (2.16)
uim (1.25)
pbm (1.4)
sar (1.0)
ims (1.0)
ts (1.0)
tmd (1.0)
wda (1.10)
csvt (1.0)
qcmap (1.0)
imsp (1.0)
imsvt (1.0)
coex (1.0)
rfrpe (1.0)
rms (1.0)
unknown [0xf0] (1.0)
Vodafone K5006Z
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.12)
dms (1.6)
nas (1.8)
qos (1.3)
wms (1.4)
pds (1.10)
auth (1.1)
at (1.1)
voice (2.1)
cat2 (2.0)
uim (1.4)
pbm (1.4)
wda (1.0)
cat (2.0)
O2 ZTE MF821D
/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.12)
dms (1.6)
nas (1.8)
qos (1.3)
wms (1.4)
pds (1.10)
auth (1.1)
at (1.1)
voice (2.1)
cat2 (2.0)
uim (1.4)
pbm (1.4)
wda (1.0)
cat (2.0)
4G-Systems XS-Stick W100LTE (v2)
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.23)
dms (1.13)
nas (1.25)
qos (1.3)
wms (1.10)
auth (1.2)
at (1.2)
voice (2.1)
cat2 (2.16)
uim (1.25)
pbm (1.4)
test (1.0)
loc (2.0)
sar (1.0)
ims (1.0)
ts (1.0)
tmd (1.0)
wda (1.3)
csvt (1.0)
imsp (1.0)
imsvt (1.0)
imsa (1.0)
pdc (1.0)
rfrpe (1.0)


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

Re: MC 7304 ipv4v6

[Thomas Schäfer]

Am 29.11.2015 um 02:24 schrieb Aleksander Morgado:
> On Sat, Nov 28, 2015 at 10:58 PM, Thomas Schäfer  
> wrote:
>> It works (tested only IPv4, LTE) with the following devices:
>>
>> *Telekom Speedstick LTE alias Huawei E398
>> *Vodafone K 5005 alias Huawei E398 modified
>> *Telekom Speedstick II alias ONE TOUCH L100V LTE
>> *MC 7304
>> *Vodafone K 5006Z alias ZTE MF821V
>> *O2 ZTE MF821D
>> *4G-Systems XS-stick W100 LTE  (version 2)
> 
> Which of these support the WDA QMI service?
> 


I made the test in "raw-ip" with all these devices. Do you need the
version of wda?

hpmini:~ # qmicli -d /dev/cdc-wdm0 --get-service-version-info
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.23)
dms (1.13)
nas (1.25)
qos (1.3)
wms (1.10)
auth (1.2)
at (1.2)
voice (2.1)
cat2 (2.16)
uim (1.25)
pbm (1.4)
test (1.0)
loc (2.0)
sar (1.0)
ims (1.0)
ts (1.0)
tmd (1.0)
wda (1.3)
csvt (1.0)
imsp (1.0)
imsvt (1.0)
imsa (1.0)
pdc (1.0)
rfrpe (1.0)


or something special like this:

hpmini:~ # qmicli -d /dev/cdc-wdm0 --wda-get-data-format
[/dev/cdc-wdm0] Successfully got data format
   QoS flow header: no
   Link layer protocol: '802-3'
  Uplink data aggregation protocol: 'disabled'
Downlink data aggregation protocol: 'disabled'
 NDP signature: '0'
  Uplink data aggregation max size: '0'
Downlink data aggregation max size: '0'
hpmini:~ #


qmicli -d /dev/cdc-wdm0 --wda-get-supported-messages
error: couldn't get supported WDA messages: QMI protocol error (71):
'InvalidQmiCommand'


Thomas

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

Re: MC 7304 ipv4v6

[Aleksander Morgado]

On Sun, Nov 29, 2015 at 11:59 AM, Thomas Schäfer  wrote:
> Am 29.11.2015 um 02:24 schrieb Aleksander Morgado:
>> On Sat, Nov 28, 2015 at 10:58 PM, Thomas Schäfer  
>> wrote:
>>> It works (tested only IPv4, LTE) with the following devices:
>>>
>>> *Telekom Speedstick LTE alias Huawei E398
>>> *Vodafone K 5005 alias Huawei E398 modified
>>> *Telekom Speedstick II alias ONE TOUCH L100V LTE
>>> *MC 7304
>>> *Vodafone K 5006Z alias ZTE MF821V
>>> *O2 ZTE MF821D
>>> *4G-Systems XS-stick W100 LTE  (version 2)
>>
>> Which of these support the WDA QMI service?
>>
>
>
> I made the test in "raw-ip" with all these devices. Do you need the
> version of wda?
>
> hpmini:~ # qmicli -d /dev/cdc-wdm0 --get-service-version-info
> [/dev/cdc-wdm0] Supported versions:
> ctl (1.5)
> wds (1.23)
> dms (1.13)
> nas (1.25)
> qos (1.3)
> wms (1.10)
> auth (1.2)
> at (1.2)
> voice (2.1)
> cat2 (2.16)
> uim (1.25)
> pbm (1.4)
> test (1.0)
> loc (2.0)
> sar (1.0)
> ims (1.0)
> ts (1.0)
> tmd (1.0)
> wda (1.3)
> csvt (1.0)
> imsp (1.0)
> imsvt (1.0)
> imsa (1.0)
> pdc (1.0)
> rfrpe (1.0)
>
>
> or something special like this:
>
> hpmini:~ # qmicli -d /dev/cdc-wdm0 --wda-get-data-format
> [/dev/cdc-wdm0] Successfully got data format
>QoS flow header: no
>Link layer protocol: '802-3'
>   Uplink data aggregation protocol: 'disabled'
> Downlink data aggregation protocol: 'disabled'
>  NDP signature: '0'
>   Uplink data aggregation max size: '0'
> Downlink data aggregation max size: '0'
> hpmini:~ #

Knowing that WDA was available was enough; older Gobi modems don't
implement that service. Just trying to get an idea of whether we can
use the existence of that service as an indication that we can default
to raw-ip.

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

Re: MC 7304 ipv4v6

[Bjørn Mork]

On November 27, 2015 10:35:26 PM CET, "Thomas Schäfer"  
wrote:
>Bjørn Mork  writes:
>
>> 
>> Works for me(tm).  Only tested on an E392 for now:
>> 
>> 
>> nemi:/tmp# ifconfig wwan1
>> wwan1 Link encap:Ethernet  HWaddr 92:b9:2a:c0:4f:96
>>   BROADCAST MULTICAST  MTU:1500  Metric:1
>>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>> nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip
>> N
>> nemi:/tmp# echo 1 >/sys/class/net/wwan1/qmi/raw_ip
>> nemi:/tmp# ifconfig wwan1
>> wwan1 Link encap:UNSPEC  HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP
>MULTICAST
>>  MTU:1500  Metric:1
>>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>> 
>> nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip
>> Y
>> 
>> bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1 
>> --device-open-net='net-raw-ip|net-no-qos-header'
>> --wds-start-network=apn=telenor --wds-follow-network 
>>[/dev/cdc-wdm1] Network started
>> Packet data handle: '34967784'
>> 
>> Ctrl+C will stop the network
>> [/dev/cdc-wdm1] Connection status: 'connected'
>> 
>
>Did you leave this terminal and opened a second one?

A second one. 


>> bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1  --client-cid=1
>> --client-no-release-cid --wds-get-current-settings [/dev/cdc-wdm1]
>Current
>> settings retrieved:
>>IP Family: IPv4
>> IPv4 address: 46.157.38.113
>> IPv4 subnet mask: 255.255.255.252
>> IPv4 gateway address: 46.157.38.114
>> IPv4 primary DNS: 193.213.112.4
>>   IPv4 secondary DNS: 130.67.15.198
>>  MTU: 1500
>>  Domains: none
>> [/dev/cdc-wdm1] Client ID not released:
>> Service: 'wds'
>> CID: '1'
>
>qmicli  -d /dev/cdc-wdm0
>--device-open-net="net-raw-ip|net-no-qos-header" --
>wds-start-network=apn=internet.t-mobile --wds-follow-network
>[/dev/cdc-wdm0] Network started
>Packet data handle: '38972872'
>
>Ctrl+C will stop the network
>[/dev/cdc-wdm0] Connection status: 'connected'
>[/dev/cdc-wdm0] Connection status: 'connected'
>[/dev/cdc-wdm0] Connection status: 'connected'
>
>
>
>I do not get the data:
>
>hpmini:~ # qmicli  -d /dev/cdc-wdm0 --client-cid=1
>--client-no-release-cid --
>wds-get-current-settings
>[27 Nov 2015, 21:38:18] -Warning ** Error reading from istream:
>Resource 
>temporarily unavailable
>error: operation failed: Transaction timed out
>[/dev/cdc-wdm0] Client ID not released:
>Service: 'wds'
>CID: '1'


I cheated and left out some details.  Like assuming that the allocated wds cid 
was 1. If your modem has made other allocations earlier, for example a previous 
connection attempt, then this won't hold. And you get results like yours.

You could continue guessing until gou hit the correct cid, or you could do it 
properly: allocate a wds cid manually, connect using this cid, then check the 
settings using the same cid.

For ipv4v6 you'll probably want to do this it this way since you have to juggle 
two cids. 


Bjørn

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

Re: MC 7304 ipv4v6

[Thomas Schäfer]

> I cheated and left out some details.  Like assuming that the allocated wds 
> cid was 1. If your modem has made other allocations earlier, for example a 
> previous connection attempt, then this won't hold. And you get results like 
> yours.
> 
> You could continue guessing until gou hit the correct cid, or you could do it 
> properly: allocate a wds cid manually, connect using this cid, then check the 
> settings using the same cid.
> 
> For ipv4v6 you'll probably want to do this it this way since you have to 
> juggle two cids. 
> 
> 
> Bjørn
> 

Sorry I can't follow.

here is the first command in verbose mode on a E398. (7304 has the same
problem)
I see "service = 'wds' cid = '1'

Then

hpmini:~ # qmicli  -d /dev/cdc-wdm0 --client-cid=1
--client-no-release-cid --wds-get-current-settings
error: operation failed: Transaction timed out

[/dev/cdc-wdm0] Client ID not released:

Service: 'wds'

CID: '1'

hpmini:~ #



still fails.


IPv4 or Ipv4v6 is at the moment not important. I try to find the same
base - testing the raw-ip mode. After that I go a step further to "my"
problem.


Regards,
Thomas





hpmini:~ # echo 1 > /sys/class/net/wwan0/qmi/raw_ip
hpmini:~ # qmicli  -v -d /dev/cdc-wdm0
--device-open-net="net-raw-ip|net-no-qos-header"
--wds-start-network=apn=internet.t-mobile --wds-follow-network
[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Opening device with
flags 'net-raw-ip, net-no-qos-header'...
[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Setting network port
data format...
[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sent message...
<< RAW:
<<   length = 21
<<   data   =
01:14:00:00:00:00:00:01:26:00:09:00:10:02:00:02:00:01:01:00:00

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sent message (translated)...
<< QMUX:
<<   length  = 20
<<   flags   = 0x00
<<   service = "ctl"
<<   client  = 0
<< QMI:
<<   flags   = "none"
<<   transaction = 1
<<   tlv_length  = 9
<<   message = "Set Data Format" (0x0026)
<< TLV:
<<   type   = "Protocol" (0x10)
<<   length = 2
<<   value  = 02:00
<<   translated = raw-ip
<< TLV:
<<   type   = "Format" (0x01)
<<   length = 1
<<   value  = 00
<<   translated = absent

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>> RAW:
>>   length = 12
>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
(translated)...
>> QMUX:
>>   length  = 11
>>   flags   = 0x80
>>   service = "ctl"
>>   client  = 0
>> QMI:
>>   flags   = "indication"
>>   transaction = 0
>>   tlv_length  = 0
>>   message = "Sync" (0x0027)

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication received
[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>> RAW:
>>   length = 12
>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
(translated)...
>> QMUX:
>>   length  = 11
>>   flags   = 0x80
>>   service = "ctl"
>>   client  = 0
>> QMI:
>>   flags   = "indication"
>>   transaction = 0
>>   tlv_length  = 0
>>   message = "Sync" (0x0027)

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication received
[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>> RAW:
>>   length = 12
>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
(translated)...
>> QMUX:
>>   length  = 11
>>   flags   = 0x80
>>   service = "ctl"
>>   client  = 0
>> QMI:
>>   flags   = "indication"
>>   transaction = 0
>>   tlv_length  = 0
>>   message = "Sync" (0x0027)

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication received
[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>> RAW:
>>   length = 12
>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
(translated)...
>> QMUX:
>>   length  = 11
>>   flags   = 0x80
>>   service = "ctl"
>>   client  = 0
>> QMI:
>>   flags   = "indication"
>>   transaction = 0
>>   tlv_length  = 0
>>   message = "Sync" (0x0027)

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication received
[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>> RAW:
>>   length = 12
>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00

[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
(translated)...
>> QMUX:
>>   length  = 11
>>   flags   = 0x80
>>   service = "ctl"
>>   client  = 0
>> QMI:
>>   flags   = "indication"
>>   transaction = 0
>>   tlv_length  = 0
>>   message = "Sync" (0x0027)

[28 

Re: MC 7304 ipv4v6

[Bjørn Mork]

Ah, right. I was probably using qmi-proxy without thinking about it. Looks like 
you get a reply to your get-current-settings, but it is picked up by the  
client doing follow-network.

Try using the -p option everywhere


Bjørn

On November 28, 2015 12:51:44 PM CET, "Thomas Schäfer"  
wrote:
>
>> I cheated and left out some details.  Like assuming that the
>allocated wds cid was 1. If your modem has made other allocations
>earlier, for example a previous connection attempt, then this won't
>hold. And you get results like yours.
>> 
>> You could continue guessing until gou hit the correct cid, or you
>could do it properly: allocate a wds cid manually, connect using this
>cid, then check the settings using the same cid.
>> 
>> For ipv4v6 you'll probably want to do this it this way since you have
>to juggle two cids. 
>> 
>> 
>> Bjørn
>> 
>
>Sorry I can't follow.
>
>here is the first command in verbose mode on a E398. (7304 has the same
>problem)
>I see "service = 'wds' cid = '1'
>
>Then
>
>hpmini:~ # qmicli  -d /dev/cdc-wdm0 --client-cid=1
>--client-no-release-cid --wds-get-current-settings
>error: operation failed: Transaction timed out
>
>[/dev/cdc-wdm0] Client ID not released:
>
>Service: 'wds'
>
>CID: '1'
>
>hpmini:~ #
>
>
>
>still fails.
>
>
>IPv4 or Ipv4v6 is at the moment not important. I try to find the same
>base - testing the raw-ip mode. After that I go a step further to "my"
>problem.
>
>
>Regards,
>Thomas
>
>
>
>
>
>hpmini:~ # echo 1 > /sys/class/net/wwan0/qmi/raw_ip
>hpmini:~ # qmicli  -v -d /dev/cdc-wdm0
>--device-open-net="net-raw-ip|net-no-qos-header"
>--wds-start-network=apn=internet.t-mobile --wds-follow-network
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Opening device with
>flags 'net-raw-ip, net-no-qos-header'...
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Setting network port
>data format...
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sent message...
><< RAW:
><<   length = 21
><<   data   =
>01:14:00:00:00:00:00:01:26:00:09:00:10:02:00:02:00:01:01:00:00
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sent message
>(translated)...
><< QMUX:
><<   length  = 20
><<   flags   = 0x00
><<   service = "ctl"
><<   client  = 0
><< QMI:
><<   flags   = "none"
><<   transaction = 1
><<   tlv_length  = 9
><<   message = "Set Data Format" (0x0026)
><< TLV:
><<   type   = "Protocol" (0x10)
><<   length = 2
><<   value  = 02:00
><<   translated = raw-ip
><< TLV:
><<   type   = "Format" (0x01)
><<   length = 1
><<   value  = 00
><<   translated = absent
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>>> RAW:
>>>   length = 12
>>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
>(translated)...
>>> QMUX:
>>>   length  = 11
>>>   flags   = 0x80
>>>   service = "ctl"
>>>   client  = 0
>>> QMI:
>>>   flags   = "indication"
>>>   transaction = 0
>>>   tlv_length  = 0
>>>   message = "Sync" (0x0027)
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication
>received
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>>> RAW:
>>>   length = 12
>>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
>(translated)...
>>> QMUX:
>>>   length  = 11
>>>   flags   = 0x80
>>>   service = "ctl"
>>>   client  = 0
>>> QMI:
>>>   flags   = "indication"
>>>   transaction = 0
>>>   tlv_length  = 0
>>>   message = "Sync" (0x0027)
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication
>received
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>>> RAW:
>>>   length = 12
>>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
>(translated)...
>>> QMUX:
>>>   length  = 11
>>>   flags   = 0x80
>>>   service = "ctl"
>>>   client  = 0
>>> QMI:
>>>   flags   = "indication"
>>>   transaction = 0
>>>   tlv_length  = 0
>>>   message = "Sync" (0x0027)
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication
>received
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message...
>>> RAW:
>>>   length = 12
>>>   data   = 01:0B:00:80:00:00:02:00:27:00:00:00
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Received message
>(translated)...
>>> QMUX:
>>>   length  = 11
>>>   flags   = 0x80
>>>   service = "ctl"
>>>   client  = 0
>>> QMI:
>>>   flags   = "indication"
>>>   transaction = 0
>>>   tlv_length  = 0
>>>   message = "Sync" (0x0027)
>
>[28 Nov 2015, 12:33:42] [Debug] [/dev/cdc-wdm0] Sync indication
>received
>[28 Nov 2015, 

Re: MC 7304 ipv4v6

[Thomas Schäfer]

Am Samstag, 28. November 2015, 13:03:44 schrieben Sie:
> Ah, right. I was probably using qmi-proxy without thinking about it. Looks
> like you get a reply to your get-current-settings, but it is picked up by
> the  client doing follow-network.
> 
> Try using the -p option everywhere


Yes, tschakka!

hpmini:~ # qmicli -p -d /dev/cdc-wdm0 --client-cid=1 --client-no-release-cid 
--wds-get-current-settings[/dev/cdc-wdm0] Current settings retrieved:   
 
   IP Family: IPv4
IPv4 address: 10.210.7.179
IPv4 subnet mask: 255.255.255.248
IPv4 gateway address: 10.210.7.177
IPv4 primary DNS: 10.74.210.210
  IPv4 secondary DNS: 10.74.210.211
 MTU: 1500
 Domains: none
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '1'



ip addr add 10.210.7.179/255.255.255.248 dev wwan0
ip link set up wwan0
ip route add default via 10.210.7.177


It works (tested only IPv4, LTE) with the following devices:

*Telekom Speedstick LTE alias Huawei E398
*Vodafone K 5005 alias Huawei E398 modified
*Telekom Speedstick II alias ONE TOUCH L100V LTE
*MC 7304
*Vodafone K 5006Z alias ZTE MF821V
*O2 ZTE MF821D 
*4G-Systems XS-stick W100 LTE  (version 2)

I made also speedtests, all values are are ok. ( ~30Mbit/s up and down, maybe 
limited by the browser/ performance of the netbook)

Only one thing did never work:

crtl+c for disconnecting has crashed qmicli with segfault. 



I would be very happy if somebody tells me the steps for testing with PDP-
context IPv4v6.

Have a nice Advent,

Thomas


PS: Is it also relevant for the MBIM-devices?




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

Re: MC 7304 ipv4v6

[Aleksander Morgado]

On Tue, Nov 24, 2015 at 11:52 PM, 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

+1 from me.

I'm assuming that the default setting when the modem is detected will
always be 802.3, and only then changed to raw-ip by userspace when
needed. I really hope we can switch to raw-ip automatically for all
modems supporting WDA, as that would be a quick thing to do in e.g.
qmi-network and ModemManager, but who knows what other vendors than
Sierra are doing.

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

Re: MC 7304 ipv4v6

[Aleksander Morgado]

On Sat, Nov 28, 2015 at 10:58 PM, Thomas Schäfer  wrote:
> It works (tested only IPv4, LTE) with the following devices:
>
> *Telekom Speedstick LTE alias Huawei E398
> *Vodafone K 5005 alias Huawei E398 modified
> *Telekom Speedstick II alias ONE TOUCH L100V LTE
> *MC 7304
> *Vodafone K 5006Z alias ZTE MF821V
> *O2 ZTE MF821D
> *4G-Systems XS-stick W100 LTE  (version 2)

Which of these support the WDA QMI service?

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

Re: MC 7304 ipv4v6

[Aleksander Morgado]

On Sat, Nov 28, 2015 at 10:58 PM, Thomas Schäfer  wrote:
> crtl+c for disconnecting has crashed qmicli with segfault.

any chance you could get a quick backtrace?

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

Re: MC 7304 ipv4v6

[Thomas Schäfer]

Bjørn Mork  writes:

> 
> Works for me(tm).  Only tested on an E392 for now:
> 
> 
> nemi:/tmp# ifconfig wwan1
> wwan1 Link encap:Ethernet  HWaddr 92:b9:2a:c0:4f:96
>   BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip
> N
> nemi:/tmp# echo 1 >/sys/class/net/wwan1/qmi/raw_ip
> nemi:/tmp# ifconfig wwan1
> wwan1 Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST
>  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 
> nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip
> Y
> 
> bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1 
> --device-open-net='net-raw-ip|net-no-qos-header'
> --wds-start-network=apn=telenor --wds-follow-network 
>[/dev/cdc-wdm1] Network started
> Packet data handle: '34967784'
> 
> Ctrl+C will stop the network
> [/dev/cdc-wdm1] Connection status: 'connected'
> 

Did you leave this terminal and opened a second one?




> bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1  --client-cid=1
> --client-no-release-cid --wds-get-current-settings [/dev/cdc-wdm1] Current
> settings retrieved:
>IP Family: IPv4
> IPv4 address: 46.157.38.113
> IPv4 subnet mask: 255.255.255.252
> IPv4 gateway address: 46.157.38.114
> IPv4 primary DNS: 193.213.112.4
>   IPv4 secondary DNS: 130.67.15.198
>  MTU: 1500
>  Domains: none
> [/dev/cdc-wdm1] Client ID not released:
> Service: 'wds'
> CID: '1'

qmicli  -d /dev/cdc-wdm0 --device-open-net="net-raw-ip|net-no-qos-header" --
wds-start-network=apn=internet.t-mobile --wds-follow-network
[/dev/cdc-wdm0] Network started
Packet data handle: '38972872'

Ctrl+C will stop the network
[/dev/cdc-wdm0] Connection status: 'connected'
[/dev/cdc-wdm0] Connection status: 'connected'
[/dev/cdc-wdm0] Connection status: 'connected'



I do not get the data:

hpmini:~ # qmicli  -d /dev/cdc-wdm0 --client-cid=1 --client-no-release-cid --
wds-get-current-settings
[27 Nov 2015, 21:38:18] -Warning ** Error reading from istream: Resource 
temporarily unavailable
error: operation failed: Transaction timed out
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '1'


??

Thomas





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

Re: MC 7304 ipv4v6

[Thomas Schäfer]

Hi,

Kernel did compile with the patch. Also switching sys...raw_ip seems to work.



> qmicli -d /dev/cdc-wdm1  --client-cid=1 --client-no-release-cid
> --wds-get-current-settings


but here I get a problem because of unknown option --wds-get-current-settings

Which version of qmicli are you using?

Thomas


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

Re: MC 7304 ipv4v6

[Bjørn Mork]

Thomas Schäfer  writes:

> Hi,
>
> Kernel did compile with the patch. Also switching sys...raw_ip seems to work.
>
>
>
>> qmicli -d /dev/cdc-wdm1  --client-cid=1 --client-no-release-cid
>> --wds-get-current-settings
>
>
> but here I get a problem because of unknown option --wds-get-current-settings
>
> Which version of qmicli are you using?

bjorn@nemi:~$ qmicli --version

qmicli 1.13.5
Copyright (C) 2015 Aleksander Morgado
License GPLv2+: GNU GPL version 2 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Or really git HEAD, I guess


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 Wed, 2015-11-25 at 08:51 +0100, Bjørn Mork wrote:
> 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

The downside is that we know some QMI devices don't support the static
IP configuration returned by GetCurrentSettings.  They only allow DHCP,
or at least DHCP seems to kick the device into actually talking. 
 However, maybe that's just a problem in 802.3 mode and raw-ip always
works on those devices with GetCurrentSettings static info?  Not sure,
but something to make sure we test...

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

Re: MC 7304 ipv4v6

[Thomas Schäfer]

Am 25.11.2015 um 11:12 schrieb Bjørn Mork:

Bjørn Mork  writes:


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.


git is a wonderful tool.  Nothing is ever lost :)

I found my example code in an old v3.2 based branch, and turned it into
a demo on the bus to job.  Note that this requires a minor change to
usbnet.c as well, to prevent it from doing eth_type_trans() on the rx
skbs we pass on to it.  Therefore two, eh.. three, patches.




You are so fast. :-)


Some questions to your detailed solution and the invitation to test.


I need a very recent kernel (I have seen 4.4 in patch 003)?

I need to follow your instructions (why do you use sometimes ifconfig 
instead of ip ?)


- with ModemManager/Networkmanager disabled - exclusively using qmi-cli

so far I can follow.

Your example has IPv4. Do I need additionally qmicli-commands for 
testing IPv4v6?


Because the test contains kernel-compilation, where I am totally out of 
practice, I cannot promise a date for test results.


Regards,

Thomas

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

Re: MC 7304 ipv4v6

[Bjørn Mork]

Thomas Schäfer  writes:
> Am 25.11.2015 um 11:12 schrieb Bjørn Mork:
>> Bjørn Mork  writes:
>>
>>> 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.
>>
>> git is a wonderful tool.  Nothing is ever lost :)
>>
>> I found my example code in an old v3.2 based branch, and turned it into
>> a demo on the bus to job.  Note that this requires a minor change to
>> usbnet.c as well, to prevent it from doing eth_type_trans() on the rx
>> skbs we pass on to it.  Therefore two, eh.. three, patches.
>>
>
>
> You are so fast. :-)
>
>
> Some questions to your detailed solution and the invitation to test.
>
>
> I need a very recent kernel (I have seen 4.4 in patch 003)?

It will probably apply to older versions as well. There hasn't been that
many changes to the qmi_wwan driver.

Yes, I currently use v4.4-rcX.  But that is primarily because I have
found running a recent release candidate to be the best way to eliminate
bugs affecting me, not because it's necessary for this testing.  I don't
know if I'm just lucky, but there tend to be one or two bugs like that
in each release cycle.  The one making cdc_mbim crash with EM7305, or
any other Sierra MBIM device except for the MC74xx, is one current and
nasty example.  I believe it's good to avoid releasing with bugs like
that...  So I risk my file systems running release candidates.

> I need to follow your instructions (why do you use sometimes ifconfig
> instead of ip ?)

Arbitray choice made by fingers with no brain involvement.  Sort of like
DMA :)

> - with ModemManager/Networkmanager disabled - exclusively using qmi-cli
>
> so far I can follow.
>
> Your example has IPv4. Do I need additionally qmicli-commands for
> testing IPv4v6?

Probably.  I don't know how to do that.  Is there an IP family setting
for qmicli? Another alternative is modifying the 802.3 default in
ModemManager.  That would be this part of src/mm-port-qmi.c:

   if (ctx->set_data_format)
flags |= (QMI_DEVICE_OPEN_FLAGS_NET_802_3 | 
QMI_DEVICE_OPEN_FLAGS_NET_NO_QOS_HEADER);

Changing it to something like

   if (ctx->set_data_format)
flags |= (QMI_DEVICE_OPEN_FLAGS_NET_RAW_IP | 
QMI_DEVICE_OPEN_FLAGS_NET_NO_QOS_HEADER);

should do for a simple test. I don't think you can use NM to configure
the netdev, though.  So you'll have to do that manually after connecting.


> Because the test contains kernel-compilation, where I am totally out
> of practice, I cannot promise a date for test results.

No hurry.  The solution is pretty much guaranteed to solve your problem
if Reinhard's guess is correct.  And that is likely.  The real question
is not whether it will work around the firmware bug, but whether and
how we should implement the raw-ip support.



Bjørn
___
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 Wed, 2015-11-25 at 08:51 +0100, Bjørn Mork wrote:
>
>> 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
>
> The downside is that we know some QMI devices don't support the static
> IP configuration returned by GetCurrentSettings.  They only allow DHCP,
> or at least DHCP seems to kick the device into actually talking. 
>  However, maybe that's just a problem in 802.3 mode and raw-ip always
> works on those devices with GetCurrentSettings static info?  Not sure,
> but something to make sure we test...

That is likely an issue with the 802.3 firmware implementation. It
probably needs DHCP to know what mac address the client wants to use.
Based on the number of bugs we've seen in this area, my guess is that
there are multiple solutions of this problem - some from Qualcomm and
some from vendors.  And probably twice as many quirks and workarounds
for when it doesn't work...

But even if it is much simpler, I would be surprised if raw IP works for
all QMI devices/firmwares. I certainly don't think we can blindly assume
so. If we open this box, then we may have to deal with both kinds of
links for the forseeable future.

Maybe a "safe" split would be based on the presence of WDA? If WDA, then
try raw-ip, else continue to use 802.3. Then you at least have the
ability to check if the "set data format" succeeded. Most older devices
will probably default to 802.3 and be tested with that, with some
exceptions as usual.  I believe you had a Pantech UML290 which used raw
IP in Windows?


Bjørn


___
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:

> 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.

git is a wonderful tool.  Nothing is ever lost :)

I found my example code in an old v3.2 based branch, and turned it into
a demo on the bus to job.  Note that this requires a minor change to
usbnet.c as well, to prevent it from doing eth_type_trans() on the rx
skbs we pass on to it.  Therefore two, eh.. three, patches.

Warning: Trying the qmi_wwan raw-ip feature without the usbnet patch is
a sure path to an oops.


Works for me(tm).  Only tested on an E392 for now:


nemi:/tmp# ifconfig wwan1
wwan1 Link encap:Ethernet  HWaddr 92:b9:2a:c0:4f:96  
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip 
N
nemi:/tmp# echo 1 >/sys/class/net/wwan1/qmi/raw_ip
nemi:/tmp# ifconfig wwan1
wwan1 Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip 
Y

bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1  
--device-open-net='net-raw-ip|net-no-qos-header' 
--wds-start-network=apn=telenor --wds-follow-network
[/dev/cdc-wdm1] Network started
Packet data handle: '34967784'

Ctrl+C will stop the network
[/dev/cdc-wdm1] Connection status: 'connected'

bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1  --client-cid=1 --client-no-release-cid 
--wds-get-current-settings
[/dev/cdc-wdm1] Current settings retrieved:
   IP Family: IPv4
IPv4 address: 46.157.38.113
IPv4 subnet mask: 255.255.255.252
IPv4 gateway address: 46.157.38.114
IPv4 primary DNS: 193.213.112.4
  IPv4 secondary DNS: 130.67.15.198
 MTU: 1500
 Domains: none
[/dev/cdc-wdm1] Client ID not released:
Service: 'wds'
CID: '1'


nemi:/tmp# ifconfig wwan1 46.157.38.113
nemi:/tmp# ifconfig wwan1
wwan1 Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  inet addr:46.157.38.113  P-t-P:46.157.38.113  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

nemi:/tmp# ip route add 148.122.171.130 dev wwan1
nemi:/tmp# ping -c3 148.122.171.130
PING 148.122.171.130 (148.122.171.130) 56(84) bytes of data.
64 bytes from 148.122.171.130: icmp_seq=1 ttl=58 time=156 ms
64 bytes from 148.122.171.130: icmp_seq=2 ttl=58 time=24.5 ms
64 bytes from 148.122.171.130: icmp_seq=3 ttl=58 time=27.5 ms

--- 148.122.171.130 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 24.568/69.492/156.345/61.426 ms


nemi:/tmp# tshark -nxxi wwan1
tshark: Lua: Error during loading:
 [string "/usr/share/wireshark/init.lua"]:46: dofile has been disabled due to 
running Wireshark as superuser. See 
http://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running 
Wireshark as an unprivileged user.
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wwan1'
  45 00 00 54 75 99 40 00 40 01 30 05 2e 9d 26 71   E..Tu.@.@.0...
0010  94 7a ab 82 08 00 4d e4 6e c0 00 01 6e 77 55 56   .zM.n...nwUV
0020  00 00 00 00 ad b9 0b 00 00 00 00 00 10 11 12 13   
0030  14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23    !"#
0040  24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33   $%&'()*+,-./0123
0050  34 35 36 37   4567

  45 04 00 54 01 98 00 00 3a 01 ea 02 94 7a ab 82   E..T:z..
0010  2e 9d 26 71 00 00 55 e4 6e c0 00 01 6e 77 55 56   ..
0020  00 00 00 00 ad b9 0b 00 00 00 00 00 10 11 12 13   
0030  14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23    !"#
0040  24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33   $%&'()*+,-./0123
0050  34 35 36 37   4567

  45 00 00 54 76 2f 40 00 40 01 2f 6f 2e 9d 26 71   E..Tv/@.@./o..
0010  94 7a ab 82 08 00 73 dc 6e c0 00 02 6f 77 55 56   .zs.n...owUV
0020  00 00 00 00 86 c0 0b 00 00 00 00 00 10 11 12 13   
0030  14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23    !"#
0040  24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 

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 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 *)>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 *)>data;
+	bool enable;
+
+	if (strtobool(buf, ))
+		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[] = {
+	_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 *)>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 = _wwan_netdev_ops;
+	dev->net->sysfs_groups[0] = _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

[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

[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=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

[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: 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=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

[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=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

[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=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

[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: 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: 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