Hi!
I'm trying to investigate on the Huawei E3131 wwan interface - like the E398,
this device ignores the at^ndisdup command.
I wanted to verify if my device was running a jungo firmware or not, since I
found contraddictory informations on the network.
To this end, I patched the cdc_ncm driver with a function was responsible for
the initializzation of jungo devices:
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..79770ed 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -39,6 +39,7 @@
*/
#include <linux/module.h>
+#include <linux/usbdevice_fs.h>
#include <linux/init.h>
#include <linux/netdevice.h>
#include <linux/ctype.h>
@@ -352,6 +353,37 @@ static const struct ethtool_ops cdc_ncm_ethtool_ops = {
.nway_reset = usbnet_nway_reset,
};
+int hw_send_tlp_download_request(struct usb_interface *intf){
+ printk("Entering hw_send_tlp_download_request...\n");
+ struct usb_device *udev = interface_to_usbdev(intf);
+ struct usb_host_interface *interface = intf->cur_altsetting;
+ struct usbdevfs_ctrltransfer req = {0};
+//memset?
+ unsigned char buf[256] = {0};
+ int retval = 0;
+ req.bRequestType = 0xC0;
+ req.bRequest = 0x02;
+ req.wIndex = interface->desc.bInterfaceNumber;
+ req.wValue = 1;
+ req.wLength = 1;
+ req.data = buf;
+ req.timeout = 1000;
+ retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), req.bRequest,
req.bRequestType, req.wValue, req.wIndex, req.data, req.wLength, req.timeout);
+ /*
+ Check the TLP feature is activated or not, response value 0x01
+ indicates success
+ */
+ if (0 < retval && 0x01 == buf[0]){
+ printk("Success!\n");
+ return retval; /* succeeded */
+ }
+ else
+ {
+ printk("Failed...\n");
+ return 0; /* failed */
+ }
+}
+
int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8
data_altsetting)
{
struct cdc_ncm_ctx *ctx;
@@ -1142,7 +1174,10 @@ static int cdc_ncm_check_connect(struct usbnet *dev)
static int
cdc_ncm_probe(struct usb_interface *udev, const struct usb_device_id *prod)
{
- return usbnet_probe(udev, prod);
+ int retval;
+ retval = usbnet_probe(udev, prod);
+ hw_send_tlp_download_request(udev);
+ return retval;
}
static void cdc_ncm_disconnect(struct usb_interface *intf)
and I'm hitting the "failed" case. So, can I say I'm not running a jungo-based
firmware?
And - another note.
I never used ncm devices, so I don't know if there is a way to communicate with
the device directly via ncm protocol (i.e.: not using AT).
When I try to bring up the ncm interface, I always get a "unexpected
notification" message.
Looking at the VERY MESSY w_cdc_driver.c release from Huawei, I noticed there
are various functions to deal with ncm fixups, particularly:
- one for fixing up received packets
- the other for fixing up sent packets
So probably the ncm driver would need a substantial rewrite aniway, making it
more practical to create a new one.
Another thing - the w_cdc_driver.c driver, seems to be free software!
So - am I wrong or do we actually have all the hints we need to implement a
"proper" driver?
But - another quqestion is probably worthwhile: can someone confirm that the
w_cdc_driver.c can establish a connection, even with the device ignoring the
^ndisdup / ^ndisconn commands?
thank you all!!
On Sun, 30 Jun 2013, Bj?rn Mork wrote:
==Date: Sun, 30 Jun 2013 00:35:20 +0200
==From: Bj?rn Mork <[email protected]>
==To: Enrico Mioso <[email protected]>
==Cc: [email protected]
==Subject: Re: Huawei E398 and at^ndisdup
==
==Enrico Mioso <[email protected]> writes:
==
==> Hi all guys!
==> I came across one of the strangest devices ever, at least to me: a Huawei
E3131
==> device:
==> Model: E3131
==> Revision: 21.157.41.01.1037
==> But the usb id says a different story:
==> Bus 003 Device 023: ID 12d1:1506 Huawei Technologies Co., Ltd. E398
==> LTE/UMTS/GSM Modem/Networkcard
==>
==> But this hardware in particular doesn't support LTE.
==
==Huawei reuse device IDs. 12d1:1506 is used for E398, E392 and many
==other devices. So the descriptive text from the device ID database is
==meaningless. There is no way to know what device this is based on the
==USB descriptors only.
==
==> the device is handled by option + cdc_ncm - and that sounds right.
==> Now - the problem: with the
==> at^ndisdup
==> or
==> at^ndisconn
==> commands, it is not possible to establish a connection. How can this device
be
==> used without PPP?
==
==If at^ndisdup doesn't work, then we do not know. You could try snooping
==on Windows and see what it does to connect this modem.
==
==> I saw some patches in modemmanager, but can't understand exactly how things
==> work.
==>
==> I know this is not the right list to post this question - but my hope is
that
==> someone could help me understand.
==
==Yes, as long as this is more related to userspace than drivers, then the
==new ModemManager list is probably more appropriate:
==http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
==
==
==
==Bj?rn
==
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
