thank you. The interesting thing is that, by the way, I am not even able to use the dongle via PPP - it is not relevant, but curious. Ok - at the moment I don't have other ideas. I am sorry. On Mon, 1 Dec 2014, Kevin Zhu wrote: ==Date: Mon, 1 Dec 2014 06:51:31 ==From: Kevin Zhu <Mingying.Zhu@xxxxxxxxxxxxxx> ==To: Enrico Mioso <mrkiko.rs@xxxxxxxxx> ==Cc: Alex Strizhevsky <alexxst@xxxxxxxxx>, == Eli Britstein <Eli.Britstein@xxxxxxxxxxxxxx>, == "linux-usb@xxxxxxxxxxxxxxx" <linux-usb@xxxxxxxxxxxxxxx>, == "youtux@xxxxxxxxx" <youtux@xxxxxxxxx>, == Midge Shaojun Tan <ShaojunMidge.Tan@xxxxxxxxxxxxxx>, == "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx>, == Bjørn Mork <bjorn@xxxxxxx> ==Subject: Re: Is this 32-bit NCM? == ==I'm sorry. == ==According to the wireshark capture, those packets without NCM signature ==are probably some periodical status checking interrupts. And some other ==packets in the same capture do show the NCM signature. Those packets are ==ping packets. == ==Regarding the offset and alignment definition, the specification says as ==below: == ==Alignment requirements are met by controlling the location of the ==payload (the data following the Ether- ==net header in each datagram). This alignment is specified by indicating ==a constraint as a divisor and a ==remainder. The agent formatting a given NTB aligns the payload of each ==datagram by inserting padding, ==such that the offset of each datagram satisfies the constraint: == ==Offset % wNdpInDivisor == wNdpInPayloadRemainder (for IN datagrams) ==Or ==Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams) == == ==Regards, ==Kevin == ==On 12/01/2014 01:28 PM, Enrico Mioso wrote: ==> Sorry. ==> I am a visually impaired person - and use a braille display to read your ==> messages; can't have access to files that don't contain ascii-based content. ==> Sorry Kevin. ==> ==> And thank you for everything. Don't worry about the lateness. ==> It was sunday. ==> ==> ==> On Mon, 1 Dec 2014, Kevin Zhu wrote: ==> ==> ==Date: Mon, 1 Dec 2014 04:14:10 ==> ==From: Kevin Zhu <Mingying.Zhu@xxxxxxxxxxxxxx> ==> ==To: Enrico Mioso <mrkiko.rs@xxxxxxxxx>, Alex Strizhevsky <alexxst@xxxxxxxxx> ==> ==Cc: Eli Britstein <Eli.Britstein@xxxxxxxxxxxxxx>, ==> == "linux-usb@xxxxxxxxxxxxxxx" <linux-usb@xxxxxxxxxxxxxxx>, ==> == "youtux@xxxxxxxxx" <youtux@xxxxxxxxx>, ==> == Midge Shaojun Tan <ShaojunMidge.Tan@xxxxxxxxxxxxxx>, ==> == "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx>, ==> == Bjørn Mork <bjorn@xxxxxxx> ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==Hi Enrico, ==> == ==> ==I think those packets are some interrupt status. Please check my capture by ==> ==wireshark. ==> == ==> ==[IMAGE] ==> == ==> ==And this is a ping packet from window, which indicates it's an NCM packet. ==> == ==> ==[IMAGE] ==> == ==> ==Regards, ==> ==Kevin ==> ==On 11/30/2014 06:39 PM, Enrico Mioso wrote: ==> == ==> ==My impression guys is that this is not cdc_ncm protocol. ==> ==Look how many short packets you can see in there. ==> ==Without any ncm signature. ==> ==right? ==> == ==> == ==> ==On Sun, 30 Nov 2014, Alex Strizhevsky wrote: ==> == ==> ====Date: Sun, 30 Nov 2014 05:22:20 ==> ====From: Alex Strizhevsky <alexxst@xxxxxxxxx> ==> ====To: Mrkiko Rs <mrkiko.rs@xxxxxxxxx> ==> ====Cc: Eli Britstein <Eli.Britstein@xxxxxxxxxxxxxx>, linux-usb@xxxxxxxxxxxxxx ==> ==g, ==> ==== "youtux@xxxxxxxxx" <youtux@xxxxxxxxx>, ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@xxxxxxxxxxxxxx>, ==> ==== "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx>, ==> ==== Kevin Zhu <Mingying.Zhu@xxxxxxxxxxxxxx>, Bjørn Mork <bjorn@xxxxxxx> ==> ====Subject: Re: Is this 32-bit NCM? ==> ==== ==> ==== ==> ====Hi Enrico, ==> ==== ==> ====Actually I have two dongles with different firmwares (23.128.00.00.00 & ==> ====21.286.03.01.209). ==> ====Probably have sent to you the USB capture with the first one. ==> ==== ==> ====In fact we have to make work the second one, this dongle has relevant SW. ==> ==== ==> ====On Nov 30, 2014 3:13 AM, "Enrico Mioso" <mrkiko.rs@xxxxxxxxx> wrote: ==> ==== Hi guys. ==> ==== Sorry for the late our but ... I was trying to figure out ==> ==== something new about ==> ==== this dongle. ==> ==== I also searched for it in my city shops without finding it ==> ==== actually. ==> ==== But then I came back and ... tried to look at some things. ==> ==== ==> ==== Alex, Kevin: in the Windows USB captures you sent me (and that I ==> ==== sent on the ==> ==== List), I can notiche something very strange. ==> ==== with a shell on a computer connected to a test device I can see ==> ==== the following: ==> ==== at+gmr ==> ==== 21.286.03.01.209 ==> ==== OK ==> ==== and so why in the Windows sniff the dongle answers to the same ==> ==== question ==> ==== something like ==> ==== 23.128.00.00.00 ==> ==== ? ==> ==== Alex - was it the same dongle? ==> ==== Kevin or anyone: can you use putty to interact with the dongle ==> ==== under Windows ==> ==== and type some commands, like: ==> ==== at+gmr ==> ==== and other similar commands? ==> ==== If the dongle reports different firmware versions under Linux ==> ==== and Windows, then ==> ==== guys... we need to figure out the Windows switch message. ==> ==== Overmore - in the device installation sh*t, you can see there is ==> ==== a firmware ==> ==== updater... Why? ==> ==== ==> ==== Alex: I used the ==> ==== at^reset ==> ==== command to get the modem back to normal state once; and so it ==> ==== restored the ==> ==== nvram to default or something. ==> ==== If you reconnect it to windows ... i hope it gets re-setup as ==> ==== before. ==> ==== But - nothing harmful to the device, only to it's settings, ==> ==== sorry. ==> ==== I restored the relevant settings and it connects again, but no ==> ==== dhcp. But - be ==> ==== peaceful: other modems out there seems to not get dhcp anyway. ==> ==== this is the state the modem arrives when you buy it, so windows ==> ==== should know ==> ==== Wwhat To Say To The Modem (TM). ==> ==== Another thing - note that: ==> ==== [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed ==> ==== ==> ==== Any ideas, comments, suggestions are highly appreciated guys. ==> ==== Of any type. ==> ==== ==> ==== Bjorn - unfortunately it seems this problem is related to E3727 ==> ==== and E3276 ==> ==== sticks; they can get IP from DHCP but not go ahead. ==> ==== ==> ==== ==> ==== ==> == ==> == ==> ==This email and any files transmitted with it are confidential material. They ==> ==are intended solely for the use of the designated individual or entity to ==> ==whom they are addressed. If the reader of this message is not the intended ==> ==recipient, you are hereby notified that any dissemination, use, distribution ==> ==or copying of this communication is strictly prohibited and may be unlawful. ==> == ==> ==If you have received this email in error please immediately notify the ==> ==sender and delete or destroy any copy of this message ==> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ==
