Re: Qualcomm rmnet driver and qmi_wwan

[Subash Abhinov Kasiviswanathan]

both patches work properly for me.

Maybe it could be helpful in the first patch to add a print when
pass-through setting fails if raw-ip has not been set, just to let the
user know what is happening.



Thanks for testing Daniele.
I can add an error message there when pass through mode setting fails.
Will you be submitting the patch for iproute2. Otherwise, I can do so
a bit later.


Maybe rmnet_is_real_dev_registered(dev->net) instead, since we use that
elsewhere in this function?

Like Daniele said: It would be good to have some way to know when the
rawip condition fails.  Or even better: Automatically force rawip mode
when the rmnet driver attaches.  But that doesn't seem possible?  No
notifications or anything when an rx handler is registered?

Hmm, looking at this I wonder: Is the rawip check really necessary?  
You

skip all the extra rawip code in the driver anyway, so I don't see how
it matters.  But maybe the ethernet header_ops are a problem?

And I wonder about using skb->dev here.  Does that really work?  I
didn't think we set that until later.  Why not use dev->net instead?




Hi Bjørn

Yes, I will switch to using dev->net.
There doesnt seem to be a net device notifier event when the rx 
registration

happens.

If the dev type is ethernet, rmnet driver will try to remove the first 
14
bytes since it assumes an ethernet header is present in the packet. 
Hence the

need for raw ip mode in qmi_wwan.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Qualcomm rmnet driver and qmi_wwan

[Bjørn Mork]

Subash Abhinov Kasiviswanathan  writes:

>> thanks, I will test it on Monday.
>>
>> Just a question for my knowledge: is the new sysfs attribute really
>> needed? I mean, is there not any other way to understand from qmi_wwan
>> without user intervention that there is the rmnet device attached?
>>
>> Regards,
>> Daniele
>>
>
> Hi Daniele
>
> You can check for the rx_handler attached to qmi_wwan dev and see if it
> belongs to rmnet. You can use the attached patch for it but it think the
> sysfs way might be a bit cleaner.
>
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> From f7a2b90948da47ade1b345eddb37b721f5ab65f4 Mon Sep 17 00:00:00 2001
> From: Subash Abhinov Kasiviswanathan 
> Date: Sat, 9 Jun 2018 11:14:22 -0600
> Subject: [PATCH] net: qmi_wwan: Allow packets to pass through to rmnet
>
> Pass through mode is to allow packets in MAP format to be passed
> on to rmnet if the rmnet rx handler is attached to it.
>
> Signed-off-by: Subash Abhinov Kasiviswanathan 
> ---
>  drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c |  4 +++-
>  drivers/net/usb/qmi_wwan.c | 10 ++
>  include/linux/if_rmnet.h   | 20 
>  3 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/if_rmnet.h
>
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c 
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> index 5f4e447..164a18f 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "rmnet_config.h"
>  #include "rmnet_handlers.h"
>  #include "rmnet_vnd.h"
> @@ -48,10 +49,11 @@
>   [IFLA_RMNET_FLAGS]  = { .len = sizeof(struct ifla_rmnet_flags) },
>  };
>  
> -static int rmnet_is_real_dev_registered(const struct net_device *real_dev)
> +int rmnet_is_real_dev_registered(const struct net_device *real_dev)
>  {
>   return rcu_access_pointer(real_dev->rx_handler) == rmnet_rx_handler;
>  }
> +EXPORT_SYMBOL(rmnet_is_real_dev_registered);
>  
>  /* Needs rtnl lock */
>  static struct rmnet_port*
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index f52a9be..abdae63 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* This driver supports wwan (3G/LTE/?) devices using a vendor
>   * specific management protocol called Qualcomm MSM Interface (QMI) -
> @@ -354,6 +355,10 @@ static ssize_t add_mux_store(struct device *d,  struct 
> device_attribute *attr, c
>   if (kstrtou8(buf, 0, _id))
>   return -EINVAL;
>  
> + /* rmnet is already attached here */
> + if (rmnet_is_real_dev_registered(to_net_dev(d)))
> + return -EINVAL;
> +


Maybe rmnet_is_real_dev_registered(dev->net) instead, since we use that
elsewhere in this function?


>   /* mux_id [1 - 0x7f] range empirically found */
>   if (mux_id < 1 || mux_id > 0x7f)
>   return -EINVAL;
> @@ -543,6 +548,11 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct 
> sk_buff *skb)
>   if (skb->len < dev->net->hard_header_len)
>   return 0;
>  
> + if (rawip && rmnet_is_real_dev_registered(skb->dev)) {
> + skb->protocol = htons(ETH_P_MAP);
> + return (netif_rx(skb) == NET_RX_SUCCESS);
> + }

Like Daniele said: It would be good to have some way to know when the
rawip condition fails.  Or even better: Automatically force rawip mode
when the rmnet driver attaches.  But that doesn't seem possible?  No
notifications or anything when an rx handler is registered?

Hmm, looking at this I wonder: Is the rawip check really necessary?  You
skip all the extra rawip code in the driver anyway, so I don't see how
it matters.  But maybe the ethernet header_ops are a problem?

And I wonder about using skb->dev here.  Does that really work?  I
didn't think we set that until later.  Why not use dev->net instead?



Bjørn

Re: Qualcomm rmnet driver and qmi_wwan

[Daniele Palmas]

Hi Subash,

2018-06-09 19:55 GMT+02:00 Subash Abhinov Kasiviswanathan
:
>> thanks, I will test it on Monday.
>>
>> Just a question for my knowledge: is the new sysfs attribute really
>> needed? I mean, is there not any other way to understand from qmi_wwan
>> without user intervention that there is the rmnet device attached?
>>
>> Regards,
>> Daniele
>>
>
> Hi Daniele
>
> You can check for the rx_handler attached to qmi_wwan dev and see if it
> belongs to rmnet. You can use the attached patch for it but it think the
> sysfs way might be a bit cleaner.
>

both patches work properly for me.

Maybe it could be helpful in the first patch to add a print when
pass-through setting fails if raw-ip has not been set, just to let the
user know what is happening.

Thanks,
Daniele

>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: Qualcomm rmnet driver and qmi_wwan

[Subash Abhinov Kasiviswanathan]

thanks, I will test it on Monday.

Just a question for my knowledge: is the new sysfs attribute really
needed? I mean, is there not any other way to understand from qmi_wwan
without user intervention that there is the rmnet device attached?

Regards,
Daniele



Hi Daniele

You can check for the rx_handler attached to qmi_wwan dev and see if it
belongs to rmnet. You can use the attached patch for it but it think the
sysfs way might be a bit cleaner.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative ProjectFrom f7a2b90948da47ade1b345eddb37b721f5ab65f4 Mon Sep 17 00:00:00 2001
From: Subash Abhinov Kasiviswanathan 
Date: Sat, 9 Jun 2018 11:14:22 -0600
Subject: [PATCH] net: qmi_wwan: Allow packets to pass through to rmnet

Pass through mode is to allow packets in MAP format to be passed
on to rmnet if the rmnet rx handler is attached to it.

Signed-off-by: Subash Abhinov Kasiviswanathan 
---
 drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c |  4 +++-
 drivers/net/usb/qmi_wwan.c | 10 ++
 include/linux/if_rmnet.h   | 20 
 3 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/if_rmnet.h

diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
index 5f4e447..164a18f 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "rmnet_config.h"
 #include "rmnet_handlers.h"
 #include "rmnet_vnd.h"
@@ -48,10 +49,11 @@
 	[IFLA_RMNET_FLAGS]	= { .len = sizeof(struct ifla_rmnet_flags) },
 };
 
-static int rmnet_is_real_dev_registered(const struct net_device *real_dev)
+int rmnet_is_real_dev_registered(const struct net_device *real_dev)
 {
 	return rcu_access_pointer(real_dev->rx_handler) == rmnet_rx_handler;
 }
+EXPORT_SYMBOL(rmnet_is_real_dev_registered);
 
 /* Needs rtnl lock */
 static struct rmnet_port*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index f52a9be..abdae63 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* This driver supports wwan (3G/LTE/?) devices using a vendor
  * specific management protocol called Qualcomm MSM Interface (QMI) -
@@ -354,6 +355,10 @@ static ssize_t add_mux_store(struct device *d,  struct device_attribute *attr, c
 	if (kstrtou8(buf, 0, _id))
 		return -EINVAL;
 
+	/* rmnet is already attached here */
+	if (rmnet_is_real_dev_registered(to_net_dev(d)))
+		return -EINVAL;
+
 	/* mux_id [1 - 0x7f] range empirically found */
 	if (mux_id < 1 || mux_id > 0x7f)
 		return -EINVAL;
@@ -543,6 +548,11 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 	if (skb->len < dev->net->hard_header_len)
 		return 0;
 
+	if (rawip && rmnet_is_real_dev_registered(skb->dev)) {
+		skb->protocol = htons(ETH_P_MAP);
+		return (netif_rx(skb) == NET_RX_SUCCESS);
+	}
+
 	if (info->flags & QMI_WWAN_FLAG_MUX)
 		return qmimux_rx_fixup(dev, skb);
 
diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
new file mode 100644
index 000..7a7fb96
--- /dev/null
+++ b/include/linux/if_rmnet.h
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ */
+#ifndef _LINUX_IF_RMNET_H_
+#define _LINUX_IF_RMNET_H_
+#include 
+
+#if defined(CONFIG_RMNET)
+extern int rmnet_is_real_dev_registered(const struct net_device *real_dev);
+#else
+static inline
+int rmnet_is_real_dev_registered(const struct net_device *real_dev)
+{
+	return 0;
+}
+#endif
+
+#endif /* !(_LINUX_IF_RMNET_H_) */
-- 
1.9.1

Re: Qualcomm rmnet driver and qmi_wwan

[Daniele Palmas]

Hi Subash,

2018-06-09 4:19 GMT+02:00 Subash Abhinov Kasiviswanathan
:
>> This sounds like a good idea. I probably won't have any time to look at
>> this in the near future, though.  Sorry about that. Extremely overloaded
>> both at work and private right now...
>>
>> But I trust that you and Daniele can work out something. Please keep me
>> CCed, but don't expect timely replies.
>>
>
> Hi Daniele
>
> Can you try out the attached patch.
> I have added a new sysfs attribute pass_through to be used in raw_ip mode
> only. Once you attach rmnet devices on it, the rx_handler will be setup
> and the packet will be processed by rmnet.
>

thanks, I will test it on Monday.

Just a question for my knowledge: is the new sysfs attribute really
needed? I mean, is there not any other way to understand from qmi_wwan
without user intervention that there is the rmnet device attached?

Regards,
Daniele

>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: Qualcomm rmnet driver and qmi_wwan

[Subash Abhinov Kasiviswanathan]

This sounds like a good idea. I probably won't have any time to look at
this in the near future, though.  Sorry about that. Extremely 
overloaded

both at work and private right now...

But I trust that you and Daniele can work out something. Please keep me
CCed, but don't expect timely replies.



Hi Daniele

Can you try out the attached patch.
I have added a new sysfs attribute pass_through to be used in raw_ip 
mode

only. Once you attach rmnet devices on it, the rx_handler will be setup
and the packet will be processed by rmnet.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative ProjectFrom bccfae3707af1be671fe55ea63123438f2dc38a8 Mon Sep 17 00:00:00 2001
From: Subash Abhinov Kasiviswanathan 
Date: Fri, 8 Jun 2018 19:53:08 -0600
Subject: [PATCH] net: qmi_wwan: Add pass through mode

Pass through mode is to allow packets in MAP format to be passed
on to the stack. rmnet driver can be used to process and demultiplex
these packets. Note that pass through mode can be enabled when the
device is in raw ip mode only.

Signed-off-by: Subash Abhinov Kasiviswanathan 
---
 drivers/net/usb/qmi_wwan.c | 72 ++
 1 file changed, 72 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8e8b51f..f52a9be 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -59,6 +59,7 @@ struct qmi_wwan_state {
 enum qmi_wwan_flags {
 	QMI_WWAN_FLAG_RAWIP = 1 << 0,
 	QMI_WWAN_FLAG_MUX = 1 << 1,
+	QMI_WWAN_FLAG_PASS_THROUGH = 1 << 2,
 };
 
 enum qmi_wwan_quirks {
@@ -425,14 +426,80 @@ static ssize_t del_mux_store(struct device *d,  struct device_attribute *attr, c
 	return ret;
 }
 
+static ssize_t pass_through_show(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+	struct usbnet *dev = netdev_priv(to_net_dev(d));
+	struct qmi_wwan_state *info;
+
+	info = (void *)>data;
+	return sprintf(buf, "%c\n",
+		   info->flags & QMI_WWAN_FLAG_PASS_THROUGH ? 'Y' : 'N');
+}
+
+static ssize_t pass_through_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;
+	bool enable;
+	int ret;
+
+	if (strtobool(buf, ))
+		return -EINVAL;
+
+	info = (void *)>data;
+
+	/* no change? */
+	if (enable == (info->flags & QMI_WWAN_FLAG_PASS_THROUGH))
+		return len;
+
+	/* pass through mode can be set for raw ip devices only */
+	if (!(info->flags & QMI_WWAN_FLAG_RAWIP))
+		return -EINVAL;
+
+	if (!rtnl_trylock())
+		return restart_syscall();
+
+	/* we don't want to modify a running netdev */
+	if (netif_running(dev->net)) {
+		netdev_err(dev->net, "Cannot change a running device\n");
+		ret = -EBUSY;
+		goto err;
+	}
+
+	/* let other drivers deny the change */
+	ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE, dev->net);
+	ret = notifier_to_errno(ret);
+	if (ret) {
+		netdev_err(dev->net, "Type change was refused\n");
+		goto err;
+	}
+
+	if (enable)
+		info->flags |= QMI_WWAN_FLAG_PASS_THROUGH;
+	else
+		info->flags &= ~QMI_WWAN_FLAG_PASS_THROUGH;
+	qmi_wwan_netdev_setup(dev->net);
+	call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev->net);
+	ret = len;
+err:
+	rtnl_unlock();
+	return ret;
+}
+
 static DEVICE_ATTR_RW(raw_ip);
 static DEVICE_ATTR_RW(add_mux);
 static DEVICE_ATTR_RW(del_mux);
+static DEVICE_ATTR_RW(pass_through);
 
 static struct attribute *qmi_wwan_sysfs_attrs[] = {
 	_attr_raw_ip.attr,
 	_attr_add_mux.attr,
 	_attr_del_mux.attr,
+	_attr_pass_through.attr,
 	NULL,
 };
 
@@ -479,6 +546,11 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 	if (info->flags & QMI_WWAN_FLAG_MUX)
 		return qmimux_rx_fixup(dev, skb);
 
+	if (rawip && (info->flags & QMI_WWAN_FLAG_PASS_THROUGH)) {
+		skb->protocol = htons(ETH_P_MAP);
+		return (netif_rx(skb) == NET_RX_SUCCESS);
+	}
+
 	switch (skb->data[0] & 0xf0) {
 	case 0x40:
 		proto = htons(ETH_P_IP);
-- 
1.9.1

Re: Qualcomm rmnet driver and qmi_wwan

[Bjørn Mork]

Subash Abhinov Kasiviswanathan  writes:

>> I followed Dan's advice and prepared a very basic test patch
>> (attached) for testing it through ip link.
>>
>> Basically things seem to be properly working with qmicli, but I needed
>> to modify a bit qmi_wwan, so I'm adding Bjørn that maybe can help.
>>
>> Bjørn,
>>
>> I'm trying to add support to rmnet in qmi_wwan: I had to modify the
>> code as in the attached test patch, but I'm not sure it is the right
>> way.
>>
>> This is done under the assumption that the rmnet device would be the
>> only one to register an rx handler to qmi_wwan, but it is probably
>> wrong.
>>
>> Basically I'm wondering if there is a more correct way to understand
>> if an rmnet device is linked to the real qmi_wwan device.
>>
>> Thanks,
>> Daniele
>
>
> Hi Daniele / Bjørn
>
> Is it possible to define a pass through mode in qmi_wwan. This is to
> ensure that all packets in MAP format are passed through instead of
> processing in qmi_wwan layer. The pass through mode would just call
> netif_receive_skb() on all these packets.
>
> That would allow all the packets to be intercepted by the rx_handler
> attached by rmnet which would subsequently de-multiplex and process
> the packets.

This sounds like a good idea. I probably won't have any time to look at
this in the near future, though.  Sorry about that. Extremely overloaded
both at work and private right now...

But I trust that you and Daniele can work out something. Please keep me
CCed, but don't expect timely replies.


Bjørn

Re: Qualcomm rmnet driver and qmi_wwan

[Subash Abhinov Kasiviswanathan]

I followed Dan's advice and prepared a very basic test patch
(attached) for testing it through ip link.

Basically things seem to be properly working with qmicli, but I needed
to modify a bit qmi_wwan, so I'm adding Bjørn that maybe can help.

Bjørn,

I'm trying to add support to rmnet in qmi_wwan: I had to modify the
code as in the attached test patch, but I'm not sure it is the right
way.

This is done under the assumption that the rmnet device would be the
only one to register an rx handler to qmi_wwan, but it is probably
wrong.

Basically I'm wondering if there is a more correct way to understand
if an rmnet device is linked to the real qmi_wwan device.

Thanks,
Daniele



Hi Daniele / Bjørn

Is it possible to define a pass through mode in qmi_wwan. This is to
ensure that all packets in MAP format are passed through instead of
processing in qmi_wwan layer. The pass through mode would just call
netif_receive_skb() on all these packets.

That would allow all the packets to be intercepted by the rx_handler
attached by rmnet which would subsequently de-multiplex and process
the packets.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Qualcomm rmnet driver and qmi_wwan

[Daniele Palmas]

Hi Dan and Subash,

2018-06-05 19:38 GMT+02:00 Subash Abhinov Kasiviswanathan
:
> On 2018-06-05 08:54, Dan Williams wrote:
>>
>> On Tue, 2018-06-05 at 11:38 +0200, Daniele Palmas wrote:
>>>
>>> Hi,
>>>
>>> 2018-02-21 20:47 GMT+01:00 Subash Abhinov Kasiviswanathan
>>> :
>>> > On 2018-02-21 04:38, Daniele Palmas wrote:
>>> > >
>>> > > Hello,
>>> > >
>>> > > in rmnet kernel documentation I read:
>>> > >
>>> > > "This driver can be used to register onto any physical network
>>> > > device in
>>> > > IP mode. Physical transports include USB, HSIC, PCIe and IP
>>> > > accelerator."
>>> > >
>>> > > Does this mean that it can be used in association with the
>>> > > qmi_wwan
>>> > > driver?
>>> > >
>>> > > If yes, can someone give me an hint on the steps to follow?
>>> > >
>>> > > If not, does anyone know if it is possible to modify qmi_wwan in
>>> > > order
>>> > > to take advantage of the features provided by the rmnet driver?
>>> > >
>>> > > In this case hint on the changes for modifying qmi_wwan are
>>> > > welcome.
>>> > >
>>> > > Thanks in advance,
>>> > > Daniele
>>> >
>>> >
>>> > Hi
>>> >
>>> > I havent used qmi_wwan so the following comment is based on code
>>> > inspection.
>>> > qmimux_register_device() is creating qmimux devices with usb net
>>> > device as
>>> > real_dev. The Multiplexing and aggregation header (qmimux_hdr) is
>>> > stripped
>>> > off
>>> > in qmimux_rx_fixup() and the packet is passed on to stack.
>>> >
>>> > You could instead create rmnet devices with the usb netdevice as
>>> > real dev.
>>> > The packets from the usb net driver can be queued to network stack
>>> > directly
>>> > as rmnet driver will setup a RX handler. rmnet driver will process
>>> > the
>>> > packets
>>> > further and then queue to network stack.
>>> >
>>>
>>> in kernel documentation I read that rmnet user space configuration is
>>> done through librmnetctl available at
>>>
>>> https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource
>>> /dataservices/tree/rmnetctl
>>>
>>> However it seems to me that this is a bit outdated (e.g. it does not
>>> properly build since it is looking for kernel header
>>> linux/rmnet_data.h that, as far as I understand, is no more present).
>>>
>>> Is there available a more recent version of the tool?
>
>
> Hi Daniele
>
> The attached patch should have an updated version of the tool.
> Usage -
>
> rmnetcli -n newlink wwan0 rmnet0 1 1
> where wwan0 is the physical device
> rmnet0 is the virtual device to be created
> 1 is the mux id
> the other 1 is the flag to configure DL de-aggregation by default
>
> To delete a device -
>
> ip link delete rmnet0
>
>>
>> I'd expect that somebody (Subash?) would add support for the
>> rmnet/qmimux options to iproute2 via 'ip link' like exists for most
>> other device types.
>
>
> Hi Dan
>
> Yes, I can do that and update the documentation to point to using iproute2.
>

I followed Dan's advice and prepared a very basic test patch
(attached) for testing it through ip link.

Basically things seem to be properly working with qmicli, but I needed
to modify a bit qmi_wwan, so I'm adding Bjørn that maybe can help.

Bjørn,

I'm trying to add support to rmnet in qmi_wwan: I had to modify the
code as in the attached test patch, but I'm not sure it is the right
way.

This is done under the assumption that the rmnet device would be the
only one to register an rx handler to qmi_wwan, but it is probably
wrong.

Basically I'm wondering if there is a more correct way to understand
if an rmnet device is linked to the real qmi_wwan device.

Thanks,
Daniele

>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
From 9c1777d4d93238703172c5e88aaeb9d8b3e372eb Mon Sep 17 00:00:00 2001
From: Daniele Palmas 
Date: Fri, 8 Jun 2018 12:02:49 +0200
Subject: [PATCH 1/1] usb: net: qmi_wwan: add support for rmnet device

This patch allows to use rmnet with qmi_wwan create network
interfaces.

Signed-off-by: Daniele Palmas 
---
 drivers/net/usb/qmi_wwan.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 0946808..dd5f278 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -479,6 +479,11 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
 	if (info->flags & QMI_WWAN_FLAG_MUX)
 		return qmimux_rx_fixup(dev, skb);
 
+	if (rcu_access_pointer(dev->net->rx_handler)) {
+		skb->protocol = htons(ETH_P_MAP);
+		return 1;
+	}
+
 	switch (skb->data[0] & 0xf0) {
 	case 0x40:
 		proto = htons(ETH_P_IP);
-- 
2.7.4

From 88bdb27b6d535600c10ef446391a51fc56691350 Mon Sep 17 00:00:00 2001
From: Daniele Palmas 
Date: Fri, 8 Jun 2018 11:43:49 +0200
Subject: [PATCH 1/1] ip: add rmnet initial support

This patch adds basic support for rmnet devices.

Currently the only possible actions are creating a new link
with a specific mux id and removing a link.

Signed-off-by: Daniele Palmas 
---
 ip/Makefile   |  2 +-
 

Re: Qualcomm rmnet driver and qmi_wwan

[Subash Abhinov Kasiviswanathan]

On 2018-06-05 08:54, Dan Williams wrote:

On Tue, 2018-06-05 at 11:38 +0200, Daniele Palmas wrote:

Hi,

2018-02-21 20:47 GMT+01:00 Subash Abhinov Kasiviswanathan
:
> On 2018-02-21 04:38, Daniele Palmas wrote:
> >
> > Hello,
> >
> > in rmnet kernel documentation I read:
> >
> > "This driver can be used to register onto any physical network
> > device in
> > IP mode. Physical transports include USB, HSIC, PCIe and IP
> > accelerator."
> >
> > Does this mean that it can be used in association with the
> > qmi_wwan
> > driver?
> >
> > If yes, can someone give me an hint on the steps to follow?
> >
> > If not, does anyone know if it is possible to modify qmi_wwan in
> > order
> > to take advantage of the features provided by the rmnet driver?
> >
> > In this case hint on the changes for modifying qmi_wwan are
> > welcome.
> >
> > Thanks in advance,
> > Daniele
>
>
> Hi
>
> I havent used qmi_wwan so the following comment is based on code
> inspection.
> qmimux_register_device() is creating qmimux devices with usb net
> device as
> real_dev. The Multiplexing and aggregation header (qmimux_hdr) is
> stripped
> off
> in qmimux_rx_fixup() and the packet is passed on to stack.
>
> You could instead create rmnet devices with the usb netdevice as
> real dev.
> The packets from the usb net driver can be queued to network stack
> directly
> as rmnet driver will setup a RX handler. rmnet driver will process
> the
> packets
> further and then queue to network stack.
>

in kernel documentation I read that rmnet user space configuration is
done through librmnetctl available at

https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource
/dataservices/tree/rmnetctl

However it seems to me that this is a bit outdated (e.g. it does not
properly build since it is looking for kernel header
linux/rmnet_data.h that, as far as I understand, is no more present).

Is there available a more recent version of the tool?


Hi Daniele

The attached patch should have an updated version of the tool.
Usage -

rmnetcli -n newlink wwan0 rmnet0 1 1
where wwan0 is the physical device
rmnet0 is the virtual device to be created
1 is the mux id
the other 1 is the flag to configure DL de-aggregation by default

To delete a device -

ip link delete rmnet0



I'd expect that somebody (Subash?) would add support for the
rmnet/qmimux options to iproute2 via 'ip link' like exists for most
other device types.


Hi Dan

Yes, I can do that and update the documentation to point to using 
iproute2.


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative ProjectFrom 94abb589a8e60c49d9cc4598a27b50c9f757b623 Mon Sep 17 00:00:00 2001
From: Subash Abhinov Kasiviswanathan 
Date: Tue, 5 Jun 2018 11:20:56 -0600
Subject: [PATCH] librmnetctl: add initial library code

Add initial snapshot of Rmnet Control library for
upstream rmnet driver.

---
 rmnetlib/Makefile.am|2 +
 rmnetlib/cli/Makefile.am|   12 +
 rmnetlib/cli/rmnetcli.c |  502 ++
 rmnetlib/cli/rmnetcli.h |   61 ++
 rmnetlib/inc/librmnetctl.h  |  604 +
 rmnetlib/inc/librmnetctl_hndl.h |   65 ++
 rmnetlib/src/Makefile.am|   14 +
 rmnetlib/src/librmnetctl.c  | 1369 +++
 8 files changed, 2629 insertions(+)
 create mode 100644 rmnetlib/Makefile.am
 create mode 100644 rmnetlib/cli/Makefile.am
 create mode 100644 rmnetlib/cli/rmnetcli.c
 create mode 100644 rmnetlib/cli/rmnetcli.h
 create mode 100644 rmnetlib/inc/librmnetctl.h
 create mode 100644 rmnetlib/inc/librmnetctl_hndl.h
 create mode 100644 rmnetlib/src/Makefile.am
 create mode 100644 rmnetlib/src/librmnetctl.c

diff --git a/rmnetlib/Makefile.am b/rmnetlib/Makefile.am
new file mode 100644
index 000..7cafa82
--- /dev/null
+++ b/rmnetlib/Makefile.am
@@ -0,0 +1,2 @@
+SUBDIRS=src cli
+
diff --git a/rmnetlib/cli/Makefile.am b/rmnetlib/cli/Makefile.am
new file mode 100644
index 000..499ef88
--- /dev/null
+++ b/rmnetlib/cli/Makefile.am
@@ -0,0 +1,12 @@
+AM_CFLAGS = $(CODE_COVERAGE_CFLAGS)
+AM_CFLAGS += -Wall -Werror -Wundef -Wstrict-prototypes -Wno-trigraphs -g
+AM_CFLAGS += -I./../inc
+AM_LDFLAGS = $(CODE_COVERAGE_LDFLAGS)
+
+rmnetcli_SOURCES = rmnetcli.c
+bin_PROGRAMS = rmnetcli
+requiredlibs = ../src/librmnetctl.la
+rmnetcli_LDADD = $(requiredlibs)
+LOCAL_MODULE := librmnetctl
+LOCAL_PRELINK_MODULE := false
+include $(BUILD_SHARED_LIBRARY)
diff --git a/rmnetlib/cli/rmnetcli.c b/rmnetlib/cli/rmnetcli.c
new file mode 100644
index 000..dc81054
--- /dev/null
+++ b/rmnetlib/cli/rmnetcli.c
@@ -0,0 +1,502 @@
+/**
+
+			R M N E T C L I . C
+
+Copyright (c) 2013-2015, 2017-2018 The Linux Foundation. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+	* Redistributions of source code must retain 

Re: Qualcomm rmnet driver and qmi_wwan

[Dan Williams]

On Tue, 2018-06-05 at 11:38 +0200, Daniele Palmas wrote:
> Hi,
> 
> 2018-02-21 20:47 GMT+01:00 Subash Abhinov Kasiviswanathan
> :
> > On 2018-02-21 04:38, Daniele Palmas wrote:
> > > 
> > > Hello,
> > > 
> > > in rmnet kernel documentation I read:
> > > 
> > > "This driver can be used to register onto any physical network
> > > device in
> > > IP mode. Physical transports include USB, HSIC, PCIe and IP
> > > accelerator."
> > > 
> > > Does this mean that it can be used in association with the
> > > qmi_wwan
> > > driver?
> > > 
> > > If yes, can someone give me an hint on the steps to follow?
> > > 
> > > If not, does anyone know if it is possible to modify qmi_wwan in
> > > order
> > > to take advantage of the features provided by the rmnet driver?
> > > 
> > > In this case hint on the changes for modifying qmi_wwan are
> > > welcome.
> > > 
> > > Thanks in advance,
> > > Daniele
> > 
> > 
> > Hi
> > 
> > I havent used qmi_wwan so the following comment is based on code
> > inspection.
> > qmimux_register_device() is creating qmimux devices with usb net
> > device as
> > real_dev. The Multiplexing and aggregation header (qmimux_hdr) is
> > stripped
> > off
> > in qmimux_rx_fixup() and the packet is passed on to stack.
> > 
> > You could instead create rmnet devices with the usb netdevice as
> > real dev.
> > The packets from the usb net driver can be queued to network stack
> > directly
> > as rmnet driver will setup a RX handler. rmnet driver will process
> > the
> > packets
> > further and then queue to network stack.
> > 
> 
> in kernel documentation I read that rmnet user space configuration is
> done through librmnetctl available at
> 
> https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource
> /dataservices/tree/rmnetctl
> 
> However it seems to me that this is a bit outdated (e.g. it does not
> properly build since it is looking for kernel header
> linux/rmnet_data.h that, as far as I understand, is no more present).
> 
> Is there available a more recent version of the tool?

I'd expect that somebody (Subash?) would add support for the
rmnet/qmimux options to iproute2 via 'ip link' like exists for most
other device types.

Dan

> Thanks,
> Daniele
> 
> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project

Re: Qualcomm rmnet driver and qmi_wwan

[Daniele Palmas]

Hi,

2018-02-21 20:47 GMT+01:00 Subash Abhinov Kasiviswanathan
:
> On 2018-02-21 04:38, Daniele Palmas wrote:
>>
>> Hello,
>>
>> in rmnet kernel documentation I read:
>>
>> "This driver can be used to register onto any physical network device in
>> IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator."
>>
>> Does this mean that it can be used in association with the qmi_wwan
>> driver?
>>
>> If yes, can someone give me an hint on the steps to follow?
>>
>> If not, does anyone know if it is possible to modify qmi_wwan in order
>> to take advantage of the features provided by the rmnet driver?
>>
>> In this case hint on the changes for modifying qmi_wwan are welcome.
>>
>> Thanks in advance,
>> Daniele
>
>
> Hi
>
> I havent used qmi_wwan so the following comment is based on code inspection.
> qmimux_register_device() is creating qmimux devices with usb net device as
> real_dev. The Multiplexing and aggregation header (qmimux_hdr) is stripped
> off
> in qmimux_rx_fixup() and the packet is passed on to stack.
>
> You could instead create rmnet devices with the usb netdevice as real dev.
> The packets from the usb net driver can be queued to network stack directly
> as rmnet driver will setup a RX handler. rmnet driver will process the
> packets
> further and then queue to network stack.
>

in kernel documentation I read that rmnet user space configuration is
done through librmnetctl available at

https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/dataservices/tree/rmnetctl

However it seems to me that this is a bit outdated (e.g. it does not
properly build since it is looking for kernel header
linux/rmnet_data.h that, as far as I understand, is no more present).

Is there available a more recent version of the tool?

Thanks,
Daniele

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: Qualcomm rmnet driver and qmi_wwan

[Daniele Palmas]

Hi Subash,

2018-02-21 20:47 GMT+01:00 Subash Abhinov Kasiviswanathan
:
> On 2018-02-21 04:38, Daniele Palmas wrote:
>>
>> Hello,
>>
>> in rmnet kernel documentation I read:
>>
>> "This driver can be used to register onto any physical network device in
>> IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator."
>>
>> Does this mean that it can be used in association with the qmi_wwan
>> driver?
>>
>> If yes, can someone give me an hint on the steps to follow?
>>
>> If not, does anyone know if it is possible to modify qmi_wwan in order
>> to take advantage of the features provided by the rmnet driver?
>>
>> In this case hint on the changes for modifying qmi_wwan are welcome.
>>
>> Thanks in advance,
>> Daniele
>
>
> Hi
>
> I havent used qmi_wwan so the following comment is based on code inspection.
> qmimux_register_device() is creating qmimux devices with usb net device as
> real_dev. The Multiplexing and aggregation header (qmimux_hdr) is stripped
> off
> in qmimux_rx_fixup() and the packet is passed on to stack.
>
> You could instead create rmnet devices with the usb netdevice as real dev.
> The packets from the usb net driver can be queued to network stack directly
> as rmnet driver will setup a RX handler. rmnet driver will process the
> packets
> further and then queue to network stack.
>

Thanks, I will try to do some testing and report my findings.

Regards,
Daniele

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: Qualcomm rmnet driver and qmi_wwan

[Subash Abhinov Kasiviswanathan]

On 2018-02-21 04:38, Daniele Palmas wrote:

Hello,

in rmnet kernel documentation I read:

"This driver can be used to register onto any physical network device 
in
IP mode. Physical transports include USB, HSIC, PCIe and IP 
accelerator."


Does this mean that it can be used in association with the qmi_wwan 
driver?


If yes, can someone give me an hint on the steps to follow?

If not, does anyone know if it is possible to modify qmi_wwan in order
to take advantage of the features provided by the rmnet driver?

In this case hint on the changes for modifying qmi_wwan are welcome.

Thanks in advance,
Daniele


Hi

I havent used qmi_wwan so the following comment is based on code 
inspection.
qmimux_register_device() is creating qmimux devices with usb net device 
as
real_dev. The Multiplexing and aggregation header (qmimux_hdr) is 
stripped off

in qmimux_rx_fixup() and the packet is passed on to stack.

You could instead create rmnet devices with the usb netdevice as real 
dev.
The packets from the usb net driver can be queued to network stack 
directly
as rmnet driver will setup a RX handler. rmnet driver will process the 
packets

further and then queue to network stack.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Qualcomm rmnet driver and qmi_wwan

[Daniele Palmas]

Hello,

in rmnet kernel documentation I read:

"This driver can be used to register onto any physical network device in
IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator."

Does this mean that it can be used in association with the qmi_wwan driver?

If yes, can someone give me an hint on the steps to follow?

If not, does anyone know if it is possible to modify qmi_wwan in order
to take advantage of the features provided by the rmnet driver?

In this case hint on the changes for modifying qmi_wwan are welcome.

Thanks in advance,
Daniele