Mhmhm; trying to change different values in the cdc_ncm.c driver might be the only way. I am sorry - I am not noticing strange things, but fixed parameters. Try to change them ... I can not do that, I lost my test system due to a kernel-related programming error, so for now I am a passive observer. On Tue, 2 Dec 2014, Kevin Zhu wrote: ==Date: Tue, 2 Dec 2014 08:44:11 ==From: Kevin Zhu <Mingying.Zhu@xxxxxxxxxxxxxx> ==To: Enrico Mioso <mrkiko.rs@xxxxxxxxx> ==Cc: Eli Britstein <Eli.Britstein@xxxxxxxxxxxxxx>, Bjørn Mork <bjorn@xxxxxxx>, == Alex Strizhevsky <alexxst@xxxxxxxxx>, == Midge Shaojun Tan <ShaojunMidge.Tan@xxxxxxxxxxxxxx>, == "youtux@xxxxxxxxx" <youtux@xxxxxxxxx>, == "linux-usb@xxxxxxxxxxxxxxx" <linux-usb@xxxxxxxxxxxxxxx>, == "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx> ==Subject: Re: Is this 32-bit NCM? == ==Hi all, == ==Here's the registry from windows 7. Attached. One parameter that might ==be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has ==something to do with MaxDatagramSize. Can someone also check the ==registry, in case I missed something? == ==Regards, ==Kevin == ==On 12/02/2014 02:49 PM, Enrico Mioso wrote: ==> Can you try to look at Windows registry keys based on the INF file as suggested ==> or would this be a problem for you? ==> And... if you have any Huawei manutal talking about it: even device's ==> ^DSFLOWRPT ==> might be useful to some extent, but ... this is only just a note in case we ==> don't find anything else. ==> Regards ... and good day to all of you, ==> Enrico ==> ==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==> ==> ==Date: Tue, 2 Dec 2014 07:43:24 ==> ==From: Kevin Zhu <Mingying.Zhu@xxxxxxxxxxxxxx> ==> ==To: Enrico Mioso <mrkiko.rs@xxxxxxxxx> ==> ==Cc: Eli Britstein <Eli.Britstein@xxxxxxxxxxxxxx>, Bjørn Mork <bjorn@xxxxxxx>, ==> == Alex Strizhevsky <alexxst@xxxxxxxxx>, ==> == Midge Shaojun Tan <ShaojunMidge.Tan@xxxxxxxxxxxxxx>, ==> == "youtux@xxxxxxxxx" <youtux@xxxxxxxxx>, ==> == "linux-usb@xxxxxxxxxxxxxxx" <linux-usb@xxxxxxxxxxxxxxx>, ==> == "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx> ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate the ==> ==paddings, but it did not work either, not even DHCP. ==> == ==> ==Regards, ==> ==Kevin ==> == ==> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote: ==> ==> Hi again Eli, ==> ==> Hi Kevin, ==> ==> Hi everyone... ==> ==> ==> ==> As I understand it anyway - the distinction here tends not to be between ==> ==> different types of packets. ==> ==> It tends to be between received and sent packet. ==> ==> We are not able to generate packets that the device retains valid. ==> ==> If you manually configure the IP the device would have assigned you via DHCP, ==> ==> your system will start answering ARP request, saying that the host with IP ==> ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle). ==> ==> However, the other host (gateway) will never know that. Indeed, it'll continue ==> ==> asking who-is at aa.bb.cc.dd ? ==> ==> At least, this is the situation I observed in the test system. ==> ==> ==> ==> ==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==> ==> ==> ==> ==Date: Tue, 2 Dec 2014 04:53:53 ==> ==> ==From: Kevin Zhu <Mingying.Zhu@xxxxxxxxxxxxxx> ==> ==> ==To: Eli Britstein <Eli.Britstein@xxxxxxxxxxxxxx>, ==> ==> == Enrico Mioso <mrkiko.rs@xxxxxxxxx> ==> ==> ==Cc: Bjørn Mork <bjorn@xxxxxxx>, Alex Strizhevsky <alexxst@xxxxxxxxx>, ==> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@xxxxxxxxxxxxxx>, ==> ==> == "youtux@xxxxxxxxx" <youtux@xxxxxxxxx>, ==> ==> == "linux-usb@xxxxxxxxxxxxxxx" <linux-usb@xxxxxxxxxxxxxxx>, ==> ==> == "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx> ==> ==> ==Subject: Re: Is this 32-bit NCM? ==> ==> == ==> ==> ==Hi, ==> ==> == ==> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384, while ==> ==> ==the other packets are less than that. However, the DHCP queries are not ==> ==> ==replied in time either, there's always some delay. ==> ==> == ==> ==> ==By the way, though the device claims to support GET_MAX_DATAGRAM_SIZE, ==> ==> ==but it returns error when the host sends this command to it. I disabled ==> ==> ==this command in NCM driver and tried, but it's the same result. ==> ==> == ==> ==> ==Regards, ==> ==> ==Kevin ==> ==> == ==> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote: ==> ==> ==> Hi Enrico and all, ==> ==> ==> ==> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)? ==> ==> ==> Maybe we can trace to compare them? ==> ==> ==> ==> ==> ==> Sent from my iPhone ==> ==> ==> ==> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@xxxxxxxxx> wrote: ==> ==> ==>> ==> ==> ==>> So ... I have two ideas left for now. ==> ==> ==>> We know for sure the problem is in the way we TX frames, not the way we RX them ==> ==> ==>> (the way we send, generate them, not the way we receive them). ==> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb mailing list for ==> ==> ==>> this first one. ==> ==> ==>> ==> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture? ==> ==> ==>> We might try to take the usb frames generated by Windows, and send them to the ==> ==> ==>> device to see if there is any reaction. It should not be science fiction, I saw ==> ==> ==>> them do that in the eciadsl old project. ==> ==> ==>> 2 - The huawei ndis driver: does it work with these devices? ==> ==> ==>> It should be a little bit out-dated now (at least in terms of dates, it might ==> ==> ==>> work as well): the code is A LOT but, just in case, to see if there is any ==> ==> ==>> chances it'll work. It remains to be seen in which kernels it can actually ==> ==> ==>> compile again. ==> ==> ==>> ==> ==> ==>> If this works we might analyse what's happening and try to debug this out. ==> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm. ==> ==> ==>> Thank you. ==> ==> ==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 ==> == == ==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 ==
