Thank you very much Ben and bjorn, for the spot, the fix, and overall helping
me learn new things.
Acked-By: Enrico Mioso
On Wed, 15 Nov 2017, Bjørn Mork wrote:
Date: Wed, 15 Nov 2017 09:35:02
From: Bjørn Mork
To: net...@vger.kernel.org
Cc: Oliver Neukum ,
Ben Hutchings , linux-usb
huawei_cdc_ncm.c
driver.
V1->V2:
- fixed broken error checks
- some corrections to the commit message
V2->V3:
- variable name changes, to clarify what's happening
- check (and possibly set) the NTB format later in the common bind code path
Signed-off-by: Enrico Mioso
Reported-and-tested-by
huawei_cdc_ncm.c
driver.
V1->V2:
- fixed broken error checks
- some corrections to the commit message
V2->V3:
- variable name changes, to clarify what's happening
- check (and possibly set) the NTB format later in the common bind code path
Signed-Off-By: Enrico Mioso
CC: Bjørn Mork
CC
hello, and thank you Christian for your comment and suggestion.
I will send a new version in the evening: I don't have devices exposing the
same behaviour, so I can't test the code completely.
Still, I will move the check at the suggested point.
But I am worried about interfering with MBIM device
Sorry, I should have made a big mistake with git send-email
From mrkiko...@gmail.com Fri Jul 7 17:53:17 2017
Date: Fri, 7 Jul 2017 17:52:57
From: Enrico Mioso
Cc: Enrico Mioso
Subject: [PATCH RFC V2] Set NTB format again after altsetting switch for Huawei
devices
Some firmwares in Huawei
On Fri, 7 Jul 2017, Bjørn Mork wrote:
Date: Fri, 7 Jul 2017 16:59:09
From: Bjørn Mork
To: Enrico Mioso
Cc: Christian Panton , linux-usb@vger.kernel.org
Subject: Re: [PATCH] [RFC PATCH] Set NTB format again after altsetting switch
for Huawei devices
Enrico Mioso writes:
Some firmwares
huawei_cdc_ncm
driver.
I am not in a confortable position to test this code, so it may containg
serious defects.
Let me know.
Signed-off-by: Enrico Mioso
CC: Bjørn Mork
CC: Christian Panton
CC: linux-usb@vger.kernel.org
---
drivers/net/usb/cdc_ncm.c| 27 +++
drivers
: linux-usb@vger.kernel.org, Enrico Mioso
Subject: Re: cdc_ncm: Specific Huawei E3372h firmware version stuck in NTB-32
[CCing Enrico]
Christian Panton writes:
Found a solution.
I have two mobile broadband Huawei E3372h devices, one with firmware
21.200.07.01.26 (aka the 200-version) and one with
et me
know anyway if this is a problem. thank you all guys for everything,
Enrico
==Date: Wed, 14 Sep 2016 19:31:50
==From: Marek Brudka
==To: Enrico Mioso
==Subject: Re: Question about CDC_NCM_FLAG_NDP_TO_END
==
==Hello Enrico,
==
==As nobody at openwrt forum replied to my request on the way how t
k you for reporting this Sami.
Acked-By: Enrico Mioso
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you very much Peter. In case I'll try. thank you.
Enrico
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you Greg. In case I am able, I'll provide more hints.
Thank you again,
Enrico
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello guys.
with my current hardware setup (EEE PC 701, 1GB RAM), I get occasional PANICs
while in interrupt handlers. It seems I get these when dealing with USB
devices: it happened seeminglsy while using my braille display some days ago,
and repeated today when "hciconfig hci0 up"'ing a bluet
Update referenced specs link to reflect actual file version and location.
Signed-off-by: Enrico Mioso
---
drivers/net/usb/cdc_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 1991e4a..db40175 100644
--- a
Hi Oliver and everybody reading this message.
So V3 of this patch fixed the issue I reported recently.
I wasn't properly accounting for the NDP size when writing new packets to the
SKB: so i ended up writing past the end of SKB buffer.
Thank you for your patience and help.
Enrico
--
To unsubsc
ed wrong NDP acronym definition
- fixed possible NULL pointer dereference
- patch cleanup
V2->V3:
- Properly account for the NDP size when writing new packets to SKB
Signed-off-by: Enrico Mioso
---
drivers/net/usb/cdc_mbim.c | 2 +-
drivers/net/usb/cdc_ncm.c
So, here is what I tried so far:
1 - Check if the pointer gets corrupted somehow (address change): it seems this
doesn't happen at all.
2 - Size problems: I tried setting higher values of the size just in case, with
absolutely no changei n behaviour.
The code that assigns the pointer the addre
Hi Oliver, hello to who is reading this message.
i was re-reading the code and the oops, without understanding what's the
problem. Still: what impressed me is the fact that at some point you see NULL
ptr dereference in unrelated code (fbcon). Is it possible that at some point
the memory portio
Just to be clear - this happens on the real machine as well, but here the trace
is difficult to extract, because even with the help of someone seeing the
screen, I noticed the screen doesn't get updated. I am using vesa right now.
--
To unsubscribe from this list: send the line "unsubscribe linu
n
my patch, DOH. Tell me if I can do something and I'll try. No crashdump
possible it seems, after this crash the system isn't able to kexec.
Enrico Mioso
Trace: from a 32-bit QEMU VM launched with parameters:
qemu-system-i386 -drive file=dsksys.img,index=0,media=disk -boot d -m 51
reproduced in a QEMU X86 VM, from kernel 4.0.4 to current git.
Thanks,
Enrico Mioso
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- fixed possible NULL pointer dereference
- patch cleanup
- rewrote description and commit subject to be more clear
Signed-off-by: Enrico Mioso
---
drivers/net/usb/cdc_mbim.c | 2 +-
drivers/net/usb/cdc_ncm.c| 50
drivers/net/usb/huawei_cdc_nc
Ok, for now I should let go of this - might be it was a little bit too much for
the time constaints I am having.
But thank you for your effort Oliver.
Anyway, trying to write this new TX engine helped me in understand better
things and conceive the patch I sent you affecting cdc_ncm.c, which tri
seems to work pretty well here, and lot of data has been processed so
far.
On Sun, 28 Jun 2015, Enrico Mioso wrote:
Date: Sun, 28 Jun 2015 09:03:37
From: Enrico Mioso
To: Oliver Neukum , linux-usb@vger.kernel.org,
net...@vger.kernel.org
Cc: Enrico Mioso
Subject: [RFC PATCH] cdc_ncm
code works pretty well with an E3372 device I am testing it with.
The problem is - I observed my patch causing system failures when severe OOM
conditions are met. I am not sure the problem is cause by my code, but would
like to hear from you.
Signed-off-by: Enrico Mioso
---
drivers/net/usb
Hi Oliver!
I wish sincerely to thank you again for your time and patience.
On Fri, 26 Jun 2015, Oliver Neukum wrote:
Date: Fri, 26 Jun 2015 10:14:02
From: Oliver Neukum
To: Enrico Mioso
Cc: linux-usb@vger.kernel.org, net...@vger.kernel.org
Subject: Re: [PATCH RFC] 2/2 huawei_cdc_ncm
Hi Oliver! And thank you again.
I like / recommend the usage of open messaging standards: my preferred XMPP ID
(JID) is: mrk...@jit.si.
On Thu, 25 Jun 2015, Oliver Neukum wrote:
Date: Thu, 25 Jun 2015 15:38:46
From: Oliver Neukum
To: Enrico Mioso
Cc: linux-usb@vger.kernel.org, net
Hi Oliver.
Thank you for your patience, and review. I apreciated it very much.
On Thu, 25 Jun 2015, Oliver Neukum wrote:
Date: Thu, 25 Jun 2015 11:49:29
From: Oliver Neukum
To: Enrico Mioso
Cc: linux-usb@vger.kernel.org, net...@vger.kernel.org
Subject: Re: [PATCH RFC] 2/2 huawei_cdc_ncm
Export this function to allow for reusing it in other drivers needing NCM
frames alignment, such as the huawei_cdc_ncm one.
Signed-off-by: Enrico Mioso
---
drivers/net/usb/cdc_ncm.c | 3 ++-
include/linux/usb/cdc_ncm.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a
any aspect of this code is really apreciated -
including suggestions for style and over-long lines problematic to break down,
at least for me.
Lots of lines longer than 80 chars seemed not easily breakable to me: any
suggestion is welcome.
Enrico Mioso (2):
cdc_ncm: export cdc_ncm_align_tail
f actually working, should be
considered as an example: the NCM manager is used here simulating the
cdc_ncm.c behaviour.
Signed-off-by: Enrico Mioso
---
drivers/net/usb/huawei_cdc_ncm.c | 187 ++-
1 file changed, 185 insertions(+), 2 deletions(-)
diff --git a/d
This is useful to split up the cdc_ncm_ndp function later on.
The resulting code will be anyway stateful.
Signed-Off-By: Enrico Mioso
---
include/linux/usb/cdc_ncm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 7c9b484
more easy to modify the location where the NDP is
disposed.
What do you think about this?
>From now on, I need a little bit of help: I think we might work on the
cdc_ncm_ndp16_push function, still I am open to any suggestion.
Let me know if you like this.
Enrico
Enrico Mioso (2):
cdc_ncm:
cdc_ncm_ndp16_find, hence
this code is stateful.
Signed-Off-By: Enrico Mioso
---
drivers/net/usb/cdc_ncm.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 8067b8f..3c837d6 100644
--- a/drivers/net
==To: Enrico Mioso
==Cc: you...@gmail.com, Greg KH , linux-usb@vger.kernel.org,
==net...@vger.kernel.org
==Subject: Re: [cdc_ncm] guidance and help refactoring cdc_ncm
==
==On Mon, 2015-06-01 at 13:41 +0200, Enrico Mioso wrote:
==> Thank you Oliver, thank you all for reading this thread and
On Mon, 1 Jun 2015, Oliver Neukum wrote:
==Date: Mon, 1 Jun 2015 14:00:22
==From: Oliver Neukum
==To: Enrico Mioso
==Cc: you...@gmail.com, Greg KH , linux-usb@vger.kernel.org,
==net...@vger.kernel.org
==Subject: Re: [cdc_ncm] guidance and help refactoring cdc_ncm
==
==On Mon, 2015-06-01 at
Thank you Oliver, thank you all for reading this thread and the attention.
For a more detailed discussion and how we got here, you might google for the
thread:
"Is this 32-bit NCM?"
and
"Is this 32-bit NCM?y" (follow up).
Where the "y" letter comes from a mistake of mine.
The specification does o
Thank you Oliver for the reply.
On Mon, 1 Jun 2015, Oliver Neukum wrote:
==Date: Mon, 1 Jun 2015 09:48:26
==From: Oliver Neukum
==To: Enrico Mioso
==Cc: Greg KH , linux-usb@vger.kernel.org,
==net...@vger.kernel.org, you...@gmail.com
==Subject: Re: [cdc_ncm] guidance and help refactoring
Hello Greg, hello everyone reading.
I am sorry If I wasn't specific enough - I'll be this time! :) Or I try at
least.
On Mon, 1 Jun 2015, Greg KH wrote:
==Date: Mon, 1 Jun 2015 02:59:17
==From: Greg KH
==To: Enrico Mioso
==Cc: linux-usb@vger.kernel.org, net...@vger.kernel.org,
==
with 3G/4G technologies.
2 - To gain more flexibility in the long term.
Thank you guys for reading this message and everything.
Please keep me in CC since I am not subscribed to this list.
Enrico Mioso
My Tox ID is:
7C593F402A3C8632D87AB4B948D492294C39A6A614464ECF843CA3429FB023284180472C7475
I
Thank you. If I'll be able I'll try.
Thank you again guys.
Enrico
On Wed, 11 Feb 2015, Alan Stern wrote:
Date: Wed, 11 Feb 2015 16:21:50
From: Alan Stern
To: Enrico Mioso
Cc: linux-usb@vger.kernel.org, linux-ker...@vger.kernel.org
Subject: Re: intensive IO on usb-storage devi
It seems the problem is also triggerable without rtorrent, but other tools like
git when checking out lots of files (in the kernel git repository for example).
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majord
Hello guys.
the problem is still reproducible with final 3.19 kernel - I can confirm it.
Re-sending the last trace here - don't know if it's available in cxg.de.
For those who might not have read the thread - the problem is: after some
intensive IO to an USB (usb-storage) disk, for a more or less
Hello guys.
Now that 3.19 is out there - I would like to know if I can domething more to
help improve the situation regarding this bug - send some more info. I might
eventually try to debug the problem differently but I will need some more spare
time to do so.
Thank you for all the help and at
The situation is unchanged, but I noticed there is a continous process of
creating workers. They might die at some point, but I noticed them now.
Sorry for the verbosity. Here's the last trace:
http://cxg.de/_dedb43.htm
And process list:
PID TTY STAT TIME COMMAND
1 ?Ss
no process
accessing it - at the moment ony mpd was accessing it, rtorrent and screen
where terminated before it was too late, strangely I got the chance to do so.
It's very interesting guys.
Enrico
On Tue, 3 Feb 2015, Alan Stern wrote:
Date: Tue, 3 Feb 2015 19:02:48
From: Alan Stern
T
Sorry guys - I was wrong: the process appears in the traces.
And if I read the call trace correctly is's stuck in apic_write ?
Enrico
On Tue, 3 Feb 2015, Alan Stern wrote:
Date: Tue, 3 Feb 2015 19:02:48
From: Alan Stern
To: Enrico Mioso
Cc: linux-usb@vger.kernel.org
Subject: Re: intensi
Hello guys.
This time I am managing to use the system while in the "middle of the problem".
From the command: "ps aux"
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.5 22852 2600 ?Ss 09:24 0:01 /sbin/init auto
root 2 0.0 0.
Hello guys!
I was lucky! :)
I was able to reproduce the crash in less time.
So - a big blob of infos about my system: complete dmesg, lspci, lsusb, kernel
config and so on is at
http://www.gstorm.eu/info
The trace is:
http://cxg.de/_59153c.htm
I wasn't able to get other infos, the system wasn't
Hello to everybody reading this list,
Hello alan.
First of all - thank you for your help, attention and time in helping me
troubleshoot this problem.
I am 99% certain the device generating the problem is
Bus 001 Device 010: ID 1e68:0022 TrekStor GmbH & Co. KG
I don't think the problem is on the
Hi guys.
I finally was able to obtain some informations about what was going on - infos
I retained useful.
I am re-sending these, since it seems my previous message didn't get to the
list - but might be I am wrong and didn't find it.
This time I posted all the traces to a pstebin, so that it's e
Hello guys.
I should say that, wafter sending the command to SysRQ, the only output I can
get is:
SYSrq - shot state
nothing more.
There is no way to recover from this situation - no matter what I do.
Sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
Hi guys.
The good news is that the problem is perfectly reproducible with some time -
and some IO of course.
A torrent file of somewhat 14 GB can trigger the issue; with files having a
size of some MB each one.
The bad news is that it triggers too aggressively - and therefore I wasn't able
to g
co
On Sat, 31 Jan 2015, Oliver Neukum wrote:
Date: Sat, 31 Jan 2015 13:20:48
From: Oliver Neukum
To: Enrico Mioso
Cc: linux-usb@vger.kernel.org
Subject: Re: intensive IO on usb-storage device causing system lock
On Sat, 2015-01-31 at 12:10 +0100, Enrico Mioso wrote:
Hi Oliver!
Thank you f
Hi Oliver!
Thank you for the reply and the attention overall.
What do you mean for "do it manually"?
Yeah - I will try do do it via the sysrq key - I can't use the keyboard to
trigger that actually (it's an Apple keyboard; yes I know there's a trick
with it also).
I'll wait until the next time
Hi guys.
I am noticing that in kernel 3.19rc4, the driver from huawei,
hw_cdc_driver
is not able to perform the call to
netif_msg_ifup anymore (receives error -13).
This to say that it would be very important to continue the work on refactoring
cdc_ncm.c driver to let it work with newer huawei de
Hello everyone, hello Bjorn.
Sorry for my prevous private mail, didn't think about it.
So I was wondering how it could be possible to refactor the cdc_ncm.c driver to
queue frames and only when enough data was collected, generate a full NCM
packet.
so I am trying to get clear what's the way t
Yes Bjorn: I should say that's true.
and - in general, touching the device driver to make it flexible is surely
important, especially to make it more easy to fix / "expand" in the future.
I was referring to modifying the huawei_cdc_ncm.c driver only for specific
huawei workarounds / firmware misb
was expecting effectively to see some lost packets, but instead... no.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
Date: Thu, 4 Dec 2014 12:44:56
From: Bjørn Mork
To: Midge Shaojun Tan
Cc: Enrico Mioso ,
Kevin Zhu ,
Eli Britstein ,
Alex Strizhevsky ,
"you...@gmail.com" ,
On Thu, 4 Dec 2014, Bjørn Mork wrote:
"Midge Shaojun Tan" writes:
Hi all,
I test OK with kervel 3.16.4
Need disable other Ethernet network, just like eth1. (Then the DNS and route is
OK)
And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't
respond the ARP mes
... it works only applying cdc_ncm_modify.c; nothing else change. ARP works.
Modesiwtch message not changed.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
Shaojun Tan
To: Enrico Mioso , Bjørn Mork
Cc: Kevin Zhu ,
Eli Britstein ,
Alex Strizhevsky ,
"you...@gmail.com" ,
"linux-usb@vger.kernel.org" ,
"net...@vger.kernel.org"
Subject: Re: Is this 32-bit NCM?y
Hi all,
I test OK with kervel 3.16.4
Need
here.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
Date: Thu, 4 Dec 2014 10:19:11
From: Bjørn Mork
To: Kevin Zhu
Cc: Enrico Mioso ,
Eli Britstein ,
Alex Strizhevsky ,
Midge Shaojun Tan ,
"you...@gmail.com" ,
"linux-usb@vger.kernel.org" ,
"net...@vge
26:20
From: Kevin Zhu
To: Bjørn Mork
Cc: Enrico Mioso ,
Eli Britstein ,
Alex Strizhevsky ,
Midge Shaojun Tan ,
"you...@gmail.com" ,
"linux-usb@vger.kernel.org" ,
"net...@vger.kernel.org"
Subject: Re: Is this 32-bit NCM?y
I will find it out.
Hi Kevin.
Thank you for your hints and work.
Only a note - why disabling ARP? I think it could be a good iea... or does the
hw_cdc_driver do that?
thank you again,
Enrico
On Thu, 4 Dec 2014, Kevin Zhu wrote:
Date: Thu, 4 Dec 2014 09:52:49
From: Kevin Zhu
To: Enrico Mioso
Cc: Bjørn Mork
Hello guys!
I am writing this message to hear if there is any progress,
Enrico
On Wed, 3 Dec 2014, Kevin Zhu wrote:
Date: Wed, 3 Dec 2014 07:05:37
From: Kevin Zhu
To: Enrico Mioso
Cc: Bjørn Mork , Eli Britstein ,
Alex Strizhevsky ,
Midge Shaojun Tan ,
"you...@gmai
Dec 2014 07:05:37
==From: Kevin Zhu
==To: Enrico Mioso
==Cc: Bjørn Mork , Eli Britstein ,
==Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org"
==Subject: Re: Is this 32-bit N
Yes - I think this would be ok. You might try this with the 16-bit river first,
and then with the 32-bit one to see how things work.
I hope for the best.
Let us all know,
Enrico
On Wed, 3 Dec 2014, Kevin Zhu wrote:
==Date: Wed, 3 Dec 2014 06:38:27
==From: Kevin Zhu
==To: Enrico Mioso
==Cc
ers. By the way, I think I see some
NDPs are right after NTH headers in the windows capture.
==
==________
==From: Enrico Mioso
==Sent: Tuesday, December 2, 2014 21:53
==To: Bjørn Mork
==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan
Thank you very much Bjorn.
On Tue, 2 Dec 2014, Bjørn Mork wrote:
==Date: Tue, 2 Dec 2014 14:37:03
==From: Bjørn Mork
==To: Enrico Mioso
==Cc: Kevin Zhu ,
==Eli Britstein ,
==Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@
2014 12:21:18
==From: Bjørn Mork
==To: Enrico Mioso
==Cc: Kevin Zhu ,
==Eli Britstein ,
==Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org"
==Subject: Re: Is this 32-bit
isdup=1,0
... the firmware seemed to ignore it.
But this might not be related to the patch.
Thank you again.
Enrico
On Tue, 2 Dec 2014, Bjørn Mork wrote:
==Date: Tue, 2 Dec 2014 12:21:18
==From: Bjørn Mork
==To: Enrico Mioso
==Cc: Kevin Zhu ,
==Eli Britstein ,
==Alex Strizhevsky ,
==
Testing it right now - let you know in a moment.
On Tue, 2 Dec 2014, Bjørn Mork wrote:
==Date: Tue, 2 Dec 2014 12:21:18
==From: Bjørn Mork
==To: Enrico Mioso
==Cc: Kevin Zhu ,
==Eli Britstein ,
==Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
==
Errata corrige - they might re-define those structurtes to be able to re-use
the same parsing code.
Sorry.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge
needed, and I might try.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.or
Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu
==To: Eli Britstein ,
== Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org&
: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org"
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF
ulationUpdate = "Flag to disable NCM accumulation auto
==updation"
==WwanMbimEnable = "Flag to enable WWAN MBIM function"
==NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume"
==
==Regards,
==Kevin
==
==On 12/02/2014 03:45 PM, Eli Britstein wr
,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org"
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==;
observer.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 08:44:11
==From: Kevin Zhu
==To: Enrico Mioso
==Cc: Eli Britstein , Bjørn Mork ,
==Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
==&qu
d 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
==To: Enrico Mioso
==Cc: Eli Britstein , Bjørn Mork ,
==Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com"
?
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
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com"
my opinion here should be something interesting.
Looking at the inf files of the *ecm* drivers and tracking down registry values
might be effectively useful.
Enrico.
On Mon, 1 Dec 2014, Eli Britstein wrote:
==Date: Mon, 1 Dec 2014 23:02:16
==From: Eli Britstein
==To: Enrico Mioso
==Cc: Kevin Z
ote:
==Date: Mon, 1 Dec 2014 23:02:16
==From: Eli Britstein
==To: Enrico Mioso
==Cc: Kevin Zhu , Bjørn Mork ,
==Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org"
==Subje
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
ri, 28 Nov 2014, Kevin Zhu wrote:
==Date: Fri, 28 Nov 2014 10:23:43
==From: Kevin Zhu
==To: Enrico Mioso
==Cc: Alex Strizhevsky , Bjørn Mork ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org" ,
==
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
wrote:
==Date: Mon, 1 Dec 2014 04:14:10
==From: Kevin Zhu
==To: Enrico Mioso , Alex Strizhevsky
==Cc: Eli Britstein ,
=="linux-usb@vger.kernel.org" ,
=="you...@gmail.com" ,
==Midge Shaojun Tan ,
=="net...@vger.kernel.org" ,
==Bjørn Mork
==Su
discovered that the device might handle the offset in a
different way, have you tried this approach?
On Thu, 27 Nov 2014, Bjørn Mork wrote:
==Date: Thu, 27 Nov 2014 11:03:24
==From: Bjørn Mork
==To: Enrico Mioso
==Cc: you...@gmail.com, alex...@gmail.com, linux-usb@vger.kernel.org,
==net
be fine.
In the windows sniff it returned 1,2; however we are not allowed to change
this.
On Fri, 28 Nov 2014, Bjørn Mork wrote:
==Date: Fri, 28 Nov 2014 10:29:09
==From: Bjørn Mork
==To: Enrico Mioso
==Cc: Alex Strizhevsky , shaojunmidge@audiocodes.com,
==mingying@audiocodes.com
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" wrote:
== Hi guys.
== Sorry for the late our but ... I was trying to figu
rk the second one, this dongle has relevant SW.
==
==On Nov 30, 2014 3:13 AM, "Enrico Mioso" 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 fin
Sorry - by error I did not send the message to all.
Hi everyone, and good Sunday!
The problem is that - between those two firmwares things might change, and so
we don't know what Windows does when it meets this specific branch /version of
the firmware.
I am desperately suspecting that we would no
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
... and what do you think regarding the last arp packet Kevin shared with us
after having changed the remainder fixed value.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/
Sorry - resending message to all.
Is the MAC right? In my case it was, but ... you never know.
And - have you tried the promisc mode, just in case... don't know if this might
even be implementedi n the driver, think not, but...
I don't know what to think anymore.
this ARP packet seems the same as
rom: Kevin Zhu
==To: Enrico Mioso
==Cc: Alex Strizhevsky , Bjørn Mork ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org" ,
==Eli Britstein
==Subject: Re: Is this 32-bit NCM?
==
==As the remai
: Kevin Zhu
==To: Enrico Mioso
==Cc: Alex Strizhevsky , Bjørn Mork ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@vger.kernel.org" ,
==Eli Britstein
==Subject: Re: Is this 32-bit NCM?
==
==As the remainde
Bj-rn, you where right.
I was thinking this was the classic compulsory switch from a bitness to an
higher one.
Sorry.
On Fri, 28 Nov 2014, Kevin Zhu wrote:
==Date: Fri, 28 Nov 2014 09:23:16
==From: Kevin Zhu
==To: Enrico Mioso
==Cc: Alex Strizhevsky , Bjørn Mork ,
==Midge Shaojun Tan
rizhevsky wrote:
== Adding my colleagues - Eli, Kevin & Midge.
==
==Any ideas are welcome ;)
==
==
==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork wrote:
== Enrico Mioso writes:
==
== > Ok - we can arrive to some ocnclusions regarding the
== E3272.
== > Fir
1 - 100 of 175 matches
Mail list logo
