Ah - I didn't knew there where other devices with an embedded AT channel - I really don't imagine what could hide on those devices! :) I can't find the function call you're referrint to, sorry. :( And - another question. how can the cdc_ncm driver handle notifications if it has no control over the ->control endpoint anymore? And - why I'm using a function called *_release_interface_* when I'm not talking about an interface, but an endpoint? But guess this is off-topic :) !! On Mon, 1 Jul 2013, Bj?rn Mork wrote: ==Date: Mon, 01 Jul 2013 18:28:20 +0200 ==From: Bj?rn Mork <bjorn@xxxxxxx> ==To: Enrico Mioso <mrkiko.rs@xxxxxxxxx> ==Cc: linux-usb@xxxxxxxxxxxxxxx ==Subject: Re: Huawei E3131 wwan interface, partial success? == ==Enrico Mioso <mrkiko.rs@xxxxxxxxx> writes: == ==> Hi all guys! ==> I discovered osmething very funny, something I wasn't expecting. ==> And when you'll read the story, for sure you will be in my same position! Let ==> me know. ==> ==> Relying on the immense knowledge and kindness of Bjorn and you all, I gathered ==> some infos about the device who made my life extremely interesting, and not ==> easy. ==> ==> so - what protocol do you think it's embedded over ncm? ==> QMI? ==> <whatever>? ==> ... the protocol seems to be AT. ==> Yes guys - AT! And I could never imagine it looking at the .c driver from ==> Huawei right now. Yes, I'm not extremely acute. But, let's go to the technical ==> thing: ndisdup works. == ==Ahhh! So when Aleksander wrote "supposed to support NDISDUP through the ==NCM port with endpoint 0" he really meant NDISDUP through endpoint 0... == ==Great work! This is encouraging. Now we know that the protocol is ==supportable, and we can even most likely reuse some existing userspace ==support once we have the driver parts in place. == ==> ==> 1 - Detecting connection ==> I could not look at device leds, so I brought an AM radio near it. == ==That's a smart buzzer solution :) == ==> when I give the ndisdup commad on the standard serial ports, nothing ==> happen. ==> ==> 2 - Connecting to the network ==> To connect to the network you use the normal ndisdup command over WDM. ==> ==> At least in my case, the firmware became unstable, extremely unstable, after ==> some minutes. The normal serial ports, and the at^statqry commands are not ==> aware of what's happening, but the connection is activve. to confirm this, I ==> can say that the modem emits ==> ndis^stats:... ==> unsolicited messages, and becomes hot after a while. ==> ==> Here is what happens: echo is never activated on this at port, even with ATE1 ==> command. == ==That's similar to the E367 MBIM firmware, which also has an embedded AT ==command channel. == ==> Script started on Mon Jul 1 17:08:31 2013 ==> KDGKBLED: Inappropriate ioctl for device ## don't worry, caused by setled ==> Error reading current flags setting. Maybe you are not on the console? ==> mrkiko@eeeadesso:/tmp$ sudo modprobe -r cdc_ncm ==> mrkiko@eeeadesso:/tmp$ sudo modprobe -f cdj ==> mrkiko@eeeadesso:/tmp$ sudo dmesg | tail ==> [ 949.084335] usbcore: deregistering interface driver cdc_ncm ==> [ 949.084405] cdc_ncm 3-2:1.1 wwan0: unregister 'cdc_ncm' usb-0000:00:1d.7-2, Mobile Broadband Network Device ==> [ 975.807854] mii: module_layout: kernel tainted. ==> [ 975.807873] Disabling lock debugging due to kernel taint ==> [ 975.824301] usb 3-2: MAC-Address: ...not reporting ==> [ 975.828761] cdc_ncm 3-2:1.1: cdc-wdm0: USB WDM device ==> [ 975.829481] cdc_ncm 3-2:1.1 wwan0: register 'cdc_ncm' at usb-0000:00:1d.7-2, Mobile Broadband Network Device, not reporting ==> [ 975.829616] usbcore: registered new interface driver cdc_ncm ==> ==> And then, minicom ==> mrkiko@eeeadesso:/tmp$ sudo minicom -D /dev/cdc-wdm0 ==[..] == ==> ^RSSI: 22 ==> ==> ^MODE: 5,4 ==> ==> ^RSSI: 8 ==> <I wrote at+csq> ==> ==> ==> +CSQ: 8,99 ==> ==> OK ==> <I wrote at^ndisdup=1,1,"web.coopvoce.it"> ==> OK ==> ==> ^NDISSTAT:0,33,,"IPV4" ==> <It failed because of network low coverage; I retrired.>. ==> OK ==> <Same story, I retried> ==> ^NDISSTAT:0,33,,"IPV4" ==> <Same Story, tried again> ==> OK ==> ==> ^NDISSTAT:1,,,"IPV4" ==> ==> ^DSFLOWRPT:00000002,00000000,00000000,0000000000000000,0000000000000000,00000000,00000000 == ==Nice. You are certainly connected here. ==[..] == ==> [ 1587.967595] cdc_ncm 3-2:1.1: unknown notification 42 received: index 1 len 8 == ==OK, so that's unknown to cdc-wdm which is now handling all ==notifications. cdc-wdm logs the number as decimal, so that's most ==likely a proper (and expected for NCM) USB_CDC_NOTIFY_SPEED_CHANGE. == ==We should probably handle that if we're going this route. Which means ==that the cdc-wdm subdriver interface needs a small extension. == ==> that said - I'm not able to bring up the wwan0 interface right now, but I think ==> it's a problem with the drivers itself. ==> ==> From here on - I need help... == ==Note that cdc_ncm by default requires a link up notification, and you've ==effectively filtered that out. Could the problem be that simple? If ==you haven't already, then remove the == == usbnet_link_change(dev, 0, 0); == ==from your cdc_ncm_bind(). == == == == ==Bj?rn == -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
