* Re: [PATCH net-next] rtnetlink: delay RTM_DELLINK notification until after ndo_uninit()
From: Thomas Graf @ 2014-12-02 10:07 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: netdev, David Miller, Eric Dumazet, Roopa Prabhu, Toshiaki Makita
In-Reply-To: <1417499650-29176-1-git-send-email-maheshb@google.com>
On 12/01/14 at 09:54pm, Mahesh Bandewar wrote:
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2220,8 +2220,16 @@ static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
> return skb->len;
> }
>
> -void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
> - gfp_t flags)
> +void rtmsg_ifinfo_send(struct sk_buff *skb, struct net_device *dev, gfp_t flags)
> +{
> + struct net *net = dev_net(dev);
> +
> + rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, flags);
> +}
> +EXPORT_SYMBOL(rtmsg_ifinfo_send);
> +
> +struct sk_buff *rtmsg_ifinfo(int type, struct net_device *dev,
> + unsigned int change, gfp_t flags, bool fill_only)
> {
> struct net *net = dev_net(dev);
> struct sk_buff *skb;
> @@ -2239,11 +2247,15 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
> kfree_skb(skb);
> goto errout;
> }
> + if (fill_only)
> + return skb;
> +
> rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, flags);
> - return;
> + return NULL;
> errout:
> if (err < 0)
> rtnl_set_sk_err(net, RTNLGRP_LINK, err);
> + return NULL;
> }
I think it would be cleaner to introduce a new function, for example
rtmsg_ifinfo_build_skb() which is called from rtmsg_ifinfo(). The
single caller that requires delayed sending can use the build skb
function directly and then send it off.
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Michael S. Tsirkin @ 2014-12-02 10:08 UTC (permalink / raw)
To: David Laight
Cc: pagupta@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, davem@davemloft.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA007CC@AcuExch.aculab.com>
On Tue, Dec 02, 2014 at 10:00:06AM +0000, David Laight wrote:
> From: Jason Wang
> > > On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> > >> Hello:
> > >>
> > >> We used to orphan packets before transmission for virtio-net. This
> > >> breaks
> > >> socket accounting and can lead serveral functions won't work, e.g:
> > >>
> > >> - Byte Queue Limit depends on tx completion nofication to work.
> > >> - Packet Generator depends on tx completion nofication for the last
> > >> transmitted packet to complete.
> > >> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> > >> work.
> > >>
> > >> This series tries to solve the issue by enabling tx interrupts. To
> > >> minize
> > >> the performance impacts of this, several optimizations were used:
> > >>
> > >> - In guest side, virtqueue_enable_cb_delayed() was used to delay the tx
> > >> interrupt untile 3/4 pending packets were sent.
>
> Doesn't that give problems for intermittent transmits?
>
> ...
>
> David
>
No because it has not effect in that case.
--
MST
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Pankaj Gupta @ 2014-12-02 10:08 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: virtualization, netdev, linux-kernel, davem
In-Reply-To: <20141202095523.GA7877@redhat.com>
>
> On Tue, Dec 02, 2014 at 09:59:48AM +0008, Jason Wang wrote:
> >
> >
> > On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote:
> > >> On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com>
> > >>wrote:
> > >> >
> > >> >
> > >> >On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin <mst@redhat.com>
> > >>wrote:
> > >> >>On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> > >> >>> Hello:
> > >> >>> We used to orphan packets before transmission for virtio-net. This
> > >> >>>breaks
> > >> >>> socket accounting and can lead serveral functions won't work, e.g:
> > >> >>> - Byte Queue Limit depends on tx completion nofication to work.
> > >> >>> - Packet Generator depends on tx completion nofication for the last
> > >> >>> transmitted packet to complete.
> > >> >>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> > >> >>>work.
> > >> >>> This series tries to solve the issue by enabling tx interrupts. To
> > >> >>>minize
> > >> >>> the performance impacts of this, several optimizations were used:
> > >> >>> - In guest side, virtqueue_enable_cb_delayed() was used to delay
> > >>the
> > >> >>>tx
> > >> >>> interrupt untile 3/4 pending packets were sent.
> > >> >>> - In host side, interrupt coalescing were used to reduce tx
> > >> >>>interrupts.
> > >> >>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
> > >> >>> - For guest receiving. No obvious regression on throughput were
> > >> >>> noticed. More cpu utilization were noticed in few cases.
> > >> >>> - For guest transmission. Very huge improvement on througput for
> > >> >>>small
> > >> >>> packet transmission were noticed. This is expected since TSQ and
> > >> >>>other
> > >> >>> optimization for small packet transmission work after tx
> > >>interrupt.
> > >> >>>But
> > >> >>> will use more cpu for large packets.
> > >> >>> - For TCP_RR, regression (10% on transaction rate and cpu
> > >> >>>utilization) were
> > >> >>> found. Tx interrupt won't help but cause overhead in this case.
> > >> >>>Using
> > >> >>> more aggressive coalescing parameters may help to reduce the
> > >> >>>regression.
> > >> >>
> > >> >>OK, you do have posted coalescing patches - does it help any?
> > >> >
> > >> >Helps a lot.
> > >> >
> > >> >For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
> > >> >For small packet TX, it increases 33% - 245% throughput. (reduce about
> > >>60%
> > >> >inters)
> > >> >For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx
> > >>intrs)
> > >> >
> > >> >>
> > >> >>I'm not sure the regression is due to interrupts.
> > >> >>It would make sense for CPU but why would it
> > >> >>hurt transaction rate?
> > >> >
> > >> >Anyway guest need to take some cycles to handle tx interrupts.
> > >> >And transaction rate does increase if we coalesces more tx interurpts.
> > >> >>
> > >> >>
> > >> >>It's possible that we are deferring kicks too much due to BQL.
> > >> >>
> > >> >>As an experiment: do we get any of it back if we do
> > >> >>- if (kick || netif_xmit_stopped(txq))
> > >> >>- virtqueue_kick(sq->vq);
> > >> >>+ virtqueue_kick(sq->vq);
> > >> >>?
> > >> >
> > >> >
> > >> >I will try, but during TCP_RR, at most 1 packets were pending,
> > >> >I suspect if BQL can help in this case.
> > >> Looks like this helps a lot in multiple sessions of TCP_RR.
> > >
> > >so what's faster
> > > BQL + kick each packet
> > > no BQL
> > >?
> >
> > Quick and manual tests (TCP_RR 64, TCP_STREAM 512) does not show obvious
> > differences.
> >
> > May need a complete benchmark to see.
>
> Okay so going forward something like BQL + kick each packet
> might be a good solution.
> The advantage of BQL is that it works without GSO.
> For example, now that we don't do UFO, you might
> see significant gains with UDP.
If I understand correctly, it can also help for small packet
regr. in multiqueue scenario? Would be nice to see the perf. numbers
with multi-queue for small packets streams.
>
>
> > >
> > >
> > >> How about move the BQL patch out of this series?
> > >> Let's first converge tx interrupt and then introduce it?
> > >> (e.g with kicking after queuing X bytes?)
> > >
> > >Sounds good.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
From: Michael S. Tsirkin @ 2014-12-02 10:11 UTC (permalink / raw)
To: Pankaj Gupta; +Cc: netdev, davem, linux-kernel, virtualization
In-Reply-To: <251897174.7356500.1417514915101.JavaMail.zimbra@redhat.com>
On Tue, Dec 02, 2014 at 05:08:35AM -0500, Pankaj Gupta wrote:
>
> >
> > On Tue, Dec 02, 2014 at 09:59:48AM +0008, Jason Wang wrote:
> > >
> > >
> > > On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote:
> > > >> On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang <jasowang@redhat.com>
> > > >>wrote:
> > > >> >
> > > >> >
> > > >> >On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin <mst@redhat.com>
> > > >>wrote:
> > > >> >>On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote:
> > > >> >>> Hello:
> > > >> >>> We used to orphan packets before transmission for virtio-net. This
> > > >> >>>breaks
> > > >> >>> socket accounting and can lead serveral functions won't work, e.g:
> > > >> >>> - Byte Queue Limit depends on tx completion nofication to work.
> > > >> >>> - Packet Generator depends on tx completion nofication for the last
> > > >> >>> transmitted packet to complete.
> > > >> >>> - TCP Small Queue depends on proper accounting of sk_wmem_alloc to
> > > >> >>>work.
> > > >> >>> This series tries to solve the issue by enabling tx interrupts. To
> > > >> >>>minize
> > > >> >>> the performance impacts of this, several optimizations were used:
> > > >> >>> - In guest side, virtqueue_enable_cb_delayed() was used to delay
> > > >>the
> > > >> >>>tx
> > > >> >>> interrupt untile 3/4 pending packets were sent.
> > > >> >>> - In host side, interrupt coalescing were used to reduce tx
> > > >> >>>interrupts.
> > > >> >>> Performance test results[1] (tx-frames 16 tx-usecs 16) shows:
> > > >> >>> - For guest receiving. No obvious regression on throughput were
> > > >> >>> noticed. More cpu utilization were noticed in few cases.
> > > >> >>> - For guest transmission. Very huge improvement on througput for
> > > >> >>>small
> > > >> >>> packet transmission were noticed. This is expected since TSQ and
> > > >> >>>other
> > > >> >>> optimization for small packet transmission work after tx
> > > >>interrupt.
> > > >> >>>But
> > > >> >>> will use more cpu for large packets.
> > > >> >>> - For TCP_RR, regression (10% on transaction rate and cpu
> > > >> >>>utilization) were
> > > >> >>> found. Tx interrupt won't help but cause overhead in this case.
> > > >> >>>Using
> > > >> >>> more aggressive coalescing parameters may help to reduce the
> > > >> >>>regression.
> > > >> >>
> > > >> >>OK, you do have posted coalescing patches - does it help any?
> > > >> >
> > > >> >Helps a lot.
> > > >> >
> > > >> >For RX, it saves about 5% - 10% cpu. (reduce 60%-90% tx intrs)
> > > >> >For small packet TX, it increases 33% - 245% throughput. (reduce about
> > > >>60%
> > > >> >inters)
> > > >> >For TCP_RR, it increase the 3%-10% trans.rate. (reduce 40%-80% tx
> > > >>intrs)
> > > >> >
> > > >> >>
> > > >> >>I'm not sure the regression is due to interrupts.
> > > >> >>It would make sense for CPU but why would it
> > > >> >>hurt transaction rate?
> > > >> >
> > > >> >Anyway guest need to take some cycles to handle tx interrupts.
> > > >> >And transaction rate does increase if we coalesces more tx interurpts.
> > > >> >>
> > > >> >>
> > > >> >>It's possible that we are deferring kicks too much due to BQL.
> > > >> >>
> > > >> >>As an experiment: do we get any of it back if we do
> > > >> >>- if (kick || netif_xmit_stopped(txq))
> > > >> >>- virtqueue_kick(sq->vq);
> > > >> >>+ virtqueue_kick(sq->vq);
> > > >> >>?
> > > >> >
> > > >> >
> > > >> >I will try, but during TCP_RR, at most 1 packets were pending,
> > > >> >I suspect if BQL can help in this case.
> > > >> Looks like this helps a lot in multiple sessions of TCP_RR.
> > > >
> > > >so what's faster
> > > > BQL + kick each packet
> > > > no BQL
> > > >?
> > >
> > > Quick and manual tests (TCP_RR 64, TCP_STREAM 512) does not show obvious
> > > differences.
> > >
> > > May need a complete benchmark to see.
> >
> > Okay so going forward something like BQL + kick each packet
> > might be a good solution.
> > The advantage of BQL is that it works without GSO.
> > For example, now that we don't do UFO, you might
> > see significant gains with UDP.
>
> If I understand correctly, it can also help for small packet
> regr. in multiqueue scenario?
Well BQL generally should only be active for 1:1 mappings.
> Would be nice to see the perf. numbers
> with multi-queue for small packets streams.
> >
> >
> > > >
> > > >
> > > >> How about move the BQL patch out of this series?
> > > >> Let's first converge tx interrupt and then introduce it?
> > > >> (e.g with kicking after queuing X bytes?)
> > > >
> > > >Sounds good.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:13 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <547D7243.80508@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 17950 bytes --]
Ok - I am a newbie; but looking back at the mistake I did last time - I did
modify the memset call at line 1049 to change the padding.
This is wrong ... but, it was an attempt.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==To: Eli Britstein <Eli.Britstein@audiocodes.com>,
== Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "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 wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein@audiocodes.com
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
==> 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@audiocodes.com>
==>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
==>> == Alex Strizhevsky <alexxst@gmail.com>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> == "youtux@gmail.com" <youtux@gmail.com>,
==>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==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@audiocodes.com> ==> ==To: Eli
==>> Britstein <Eli.Britstein@audiocodes.com>,
==>> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
==>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==> ==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@gmail.com> 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
==
^ permalink raw reply
* Re: [RFC PATCH] netfilter: conntrack: cache route for forwarded connections
From: Florian Westphal @ 2014-12-02 10:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, netfilter-devel, brouer, netdev
In-Reply-To: <1417484203.4442.19.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-12-02 at 01:28 +0100, Florian Westphal wrote:
> > ... to avoid per-packet FIB lookup if possible.
> >
> > The cached dst is re-used provided the input interface
> > is the same as that of the previous packet in the same direction.
> >
> > If not, the cached dst is invalidated.
> >
> > This should speed up forwarding when conntrack is already in use
> > anyway, especially when using reverse path filtering -- active RPF
> > enforces two FIB lookups for each packet.
> >
> > Before the routing cache removal this didn't matter since RPF
> > was performed only when route cache didn't yield a result; but without
> > route cache it comes at high price.
> >
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
>
> Seems a good idea (but you might need some IPv6 care, as ( dst =
> dst_check(dst, 0); ) seems to handle IPv4 only)
As usual, you're right...
AFAICS its enough to stash fib sernum of the rt6info too and pass
that as the cookie, phew :-)
> Another idea would be to re-use TCP ehash so that regular IP early demux
> can be used, with a single lookup for both local and forwarded sessions.
Hmm, I'll look at this. Maybe...
> (That would probably require a bit more memory, as you would need to
> insert into TCP ehash some kind of 'tiny sockets' )
... such tiny socket could be stored/tied to the conntrack extension
area.
I think we need to be careful to not re-add the route cache (and the DoS
issues associated with it).
Thanks Eric!
^ permalink raw reply
* Re: [RFC PATCH] netfilter: conntrack: cache route for forwarded connections
From: Florian Westphal @ 2014-12-02 10:21 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Florian Westphal, netfilter-devel, brouer, netdev
In-Reply-To: <alpine.LFD.2.11.1412020827260.1593@ja.home.ssi.bg>
Julian Anastasov <ja@ssi.bg> wrote:
> > The cached dst is re-used provided the input interface
> > is the same as that of the previous packet in the same direction.
> >
> > If not, the cached dst is invalidated.
> >
> > This should speed up forwarding when conntrack is already in use
> > anyway, especially when using reverse path filtering -- active RPF
> > enforces two FIB lookups for each packet.
> >
> > Before the routing cache removal this didn't matter since RPF
> > was performed only when route cache didn't yield a result; but without
> > route cache it comes at high price.
> >
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> > Sending as RFC since I haven't tested this yet (aside from
> > single-forwarded-flow), so no performance data either.
> >
> > - doesn't work when iif changes (it invalidates cached dst), don't
> > think its a problem
>
> The idea is good. But code that caches dsts should
> also handle at least NETDEV_UNREGISTER (NETDEV_DOWN being
> another option) to release dsts. Holding dsts for frozen
> conns in EST state for long time is a problem.
Okay, point taken. Thanks Julian.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:24 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Enrico Mioso, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <547D7243.80508@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 17941 bytes --]
It works!
Now the modem is working... and the answer is in the huawei NDIS driver.
https://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/huawei_ndis/ndis_src.tar.xz
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==To: Eli Britstein <Eli.Britstein@audiocodes.com>,
== Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "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 wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein@audiocodes.com
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
==> 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@audiocodes.com>
==>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
==>> == Alex Strizhevsky <alexxst@gmail.com>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> == "youtux@gmail.com" <youtux@gmail.com>,
==>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==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@audiocodes.com> ==> ==To: Eli
==>> Britstein <Eli.Britstein@audiocodes.com>,
==>> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
==>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==> ==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@gmail.com> 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
==
^ permalink raw reply
* [PATCH net-next 0/9] mlx5 driver updates
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, Eli Cohen
Hi Dave,
The following series contains some fixes to mlx5 as well as update to the list
of supported devices.
Thanks,
Eli
Eli Cohen (8):
net/mlx5_core: Request the mlx5 IB module on driver load
net/mlx5_core: Fix min vectors value in mlx5_enable_msix
net/mlx5_core: Fix command queue size enforcement
net/mlx5_core: Remove unused dev cap enum fields
net/mlx5_core: Print resource number on QP/SRQ async events
net/mlx5_core: Add more supported devices
mlx5: Fix sparse warnings
mlx5: Fix error flow in add_keys
Majd Dibbiny (1):
net/mlx5_core: Clear outbox of dealloc uar
drivers/infiniband/hw/mlx5/mr.c | 3 +++
drivers/infiniband/hw/mlx5/qp.c | 16 +++++++++++++++-
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 4 ++--
drivers/net/ethernet/mellanox/mlx5/core/main.c | 15 +++++++++++++--
drivers/net/ethernet/mellanox/mlx5/core/uar.c | 1 +
include/linux/mlx5/device.h | 8 --------
7 files changed, 35 insertions(+), 14 deletions(-)
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next 1/9] net/mlx5_core: Request the mlx5 IB module on driver load
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Call request module on mlx5_ib so it will be available for applications
requiring it, such as installers that require boot over IB.
Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 71b10b210792..4e3c27e77768 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -43,6 +43,7 @@
#include <linux/mlx5/qp.h>
#include <linux/mlx5/srq.h>
#include <linux/debugfs.h>
+#include <linux/kmod.h>
#include <linux/mlx5/mlx5_ifc.h>
#include "mlx5_core.h"
@@ -840,6 +841,8 @@ struct mlx5_core_event_handler {
void *data);
};
+#define MLX5_IB_MOD "mlx5_ib"
+
static int init_one(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -878,6 +881,10 @@ static int init_one(struct pci_dev *pdev,
goto out_init;
}
+ err = request_module_nowait(MLX5_IB_MOD);
+ if (err)
+ pr_info("failed request module on %s\n", MLX5_IB_MOD);
+
return 0;
out_init:
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 2/9] net/mlx5_core: Fix min vectors value in mlx5_enable_msix
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
mlx5 requires at least one interrupt vector for completions so fix the minvec
argument to pci_enable_msix_range() accordingly.
Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 4e3c27e77768..c9d4a024f186 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -226,7 +226,7 @@ static int mlx5_enable_msix(struct mlx5_core_dev *dev)
table->msix_arr[i].entry = i;
nvec = pci_enable_msix_range(dev->pdev, table->msix_arr,
- MLX5_EQ_VEC_COMP_BASE, nvec);
+ MLX5_EQ_VEC_COMP_BASE + 1, nvec);
if (nvec < 0)
return nvec;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 4/9] net/mlx5_core: Remove unused dev cap enum fields
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
These enumerations are not used so remove them.
Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
include/linux/mlx5/device.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
index 1d67fd32e71c..ea4f1c46f761 100644
--- a/include/linux/mlx5/device.h
+++ b/include/linux/mlx5/device.h
@@ -219,23 +219,15 @@ enum {
};
enum {
- MLX5_DEV_CAP_FLAG_RC = 1LL << 0,
- MLX5_DEV_CAP_FLAG_UC = 1LL << 1,
- MLX5_DEV_CAP_FLAG_UD = 1LL << 2,
MLX5_DEV_CAP_FLAG_XRC = 1LL << 3,
- MLX5_DEV_CAP_FLAG_SRQ = 1LL << 6,
MLX5_DEV_CAP_FLAG_BAD_PKEY_CNTR = 1LL << 8,
MLX5_DEV_CAP_FLAG_BAD_QKEY_CNTR = 1LL << 9,
MLX5_DEV_CAP_FLAG_APM = 1LL << 17,
MLX5_DEV_CAP_FLAG_ATOMIC = 1LL << 18,
MLX5_DEV_CAP_FLAG_BLOCK_MCAST = 1LL << 23,
- MLX5_DEV_CAP_FLAG_ON_DMND_PG = 1LL << 24,
MLX5_DEV_CAP_FLAG_CQ_MODER = 1LL << 29,
MLX5_DEV_CAP_FLAG_RESIZE_CQ = 1LL << 30,
- MLX5_DEV_CAP_FLAG_RESIZE_SRQ = 1LL << 32,
MLX5_DEV_CAP_FLAG_DCT = 1LL << 37,
- MLX5_DEV_CAP_FLAG_REMOTE_FENCE = 1LL << 38,
- MLX5_DEV_CAP_FLAG_TLP_HINTS = 1LL << 39,
MLX5_DEV_CAP_FLAG_SIG_HAND_OVER = 1LL << 40,
MLX5_DEV_CAP_FLAG_CMDIF_CSUM = 3LL << 46,
};
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 6/9] net/mlx5_core: Clear outbox of dealloc uar
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, Majd Dibbiny, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Majd Dibbiny <majd-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
The outbox should be cleared before executing the command.
Signed-off-by: Majd Dibbiny <majd-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx5/core/uar.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/uar.c b/drivers/net/ethernet/mellanox/mlx5/core/uar.c
index 0a6348cefc01..06801d6f595e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/uar.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/uar.c
@@ -96,6 +96,7 @@ int mlx5_cmd_free_uar(struct mlx5_core_dev *dev, u32 uarn)
int err;
memset(&in, 0, sizeof(in));
+ memset(&out, 0, sizeof(out));
in.hdr.opcode = cpu_to_be16(MLX5_CMD_OP_DEALLOC_UAR);
in.uarn = cpu_to_be32(uarn);
err = mlx5_cmd_exec(dev, &in, sizeof(in), &out, sizeof(out));
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 7/9] net/mlx5_core: Add more supported devices
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Add ConnectX-4LX to the list of supported devices as well as their virtual
functions.
Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index c9d4a024f186..3f4525619a07 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -903,8 +903,12 @@ static void remove_one(struct pci_dev *pdev)
}
static const struct pci_device_id mlx5_core_pci_table[] = {
- { PCI_VDEVICE(MELLANOX, 4113) }, /* MT4113 Connect-IB */
+ { PCI_VDEVICE(MELLANOX, 4113) }, /* Connect-IB */
+ { PCI_VDEVICE(MELLANOX, 4114) }, /* Connect-IB VF */
{ PCI_VDEVICE(MELLANOX, 4115) }, /* ConnectX-4 */
+ { PCI_VDEVICE(MELLANOX, 4116) }, /* ConnectX-4 VF */
+ { PCI_VDEVICE(MELLANOX, 4117) }, /* ConnectX-4LX */
+ { PCI_VDEVICE(MELLANOX, 4118) }, /* ConnectX-4LX VF */
{ 0, }
};
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 9/9] mlx5: Fix error flow in add_keys
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: roland-DgEjT+Ai2ygdnm+yROfE0A, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
amirv-VPRAkNaXOzVWk0Htik3J/w, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
If mlx5_core_create_mkey fails, decrease the pending counter to undo the
previous increment.
Signed-off-by: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/hw/mlx5/mr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 4c89b64aa9cf..5a80dd993761 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -159,6 +159,9 @@ static int add_keys(struct mlx5_ib_dev *dev, int c, int num)
sizeof(*in), reg_mr_callback,
mr, &mr->out);
if (err) {
+ spin_lock_irq(&ent->lock);
+ ent->pending--;
+ spin_unlock_irq(&ent->lock);
mlx5_ib_warn(dev, "create mkey failed %d\n", err);
kfree(mr);
break;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net-next 3/9] net/mlx5_core: Fix command queue size enforcement
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem; +Cc: roland, linux-rdma, netdev, ogerlitz, amirv, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli@mellanox.com>
Command queue descriptor page size is 4KB and not the page size used by the
kernel.
Signed-off-by: Eli Cohen <eli@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index 368c6c5ea014..a2853057c779 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -1363,7 +1363,7 @@ int mlx5_cmd_init(struct mlx5_core_dev *dev)
goto err_map;
}
- if (cmd->log_sz + cmd->log_stride > PAGE_SHIFT) {
+ if (cmd->log_sz + cmd->log_stride > MLX5_ADAPTER_PAGE_SHIFT) {
dev_err(&dev->pdev->dev, "command queue size overflow\n");
err = -EINVAL;
goto err_map;
--
2.1.3
^ permalink raw reply related
* [PATCH net-next 5/9] net/mlx5_core: Print resource number on QP/SRQ async events
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem; +Cc: roland, linux-rdma, netdev, ogerlitz, amirv, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli@mellanox.com>
Useful for debugging purposes.
Signed-off-by: Eli Cohen <eli@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index dfd3ad0a39c1..ab684463780b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -225,8 +225,8 @@ static int mlx5_eq_int(struct mlx5_core_dev *dev, struct mlx5_eq *eq)
case MLX5_EVENT_TYPE_WQ_INVAL_REQ_ERROR:
case MLX5_EVENT_TYPE_WQ_ACCESS_ERROR:
rsn = be32_to_cpu(eqe->data.qp_srq.qp_srq_n) & 0xffffff;
- mlx5_core_dbg(dev, "event %s(%d) arrived\n",
- eqe_type_str(eqe->type), eqe->type);
+ mlx5_core_dbg(dev, "event %s(%d) arrived on resource 0x%x\n",
+ eqe_type_str(eqe->type), eqe->type, rsn);
mlx5_rsc_event(dev, rsn, eqe->type);
break;
--
2.1.3
^ permalink raw reply related
* [PATCH net-next 8/9] mlx5: Fix sparse warnings
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem; +Cc: roland, linux-rdma, netdev, ogerlitz, amirv, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli@mellanox.com>
1. Add required __acquire/__release statements to balance spinlock usage.
2. Change the index parameter of begin_wqe() to be unsigned to match supplied
argument type.
Signed-off-by: Eli Cohen <eli@mellanox.com>
---
drivers/infiniband/hw/mlx5/qp.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 0e2ef9fe0e29..1cae1c7132b4 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1011,9 +1011,14 @@ static void mlx5_ib_lock_cqs(struct mlx5_ib_cq *send_cq, struct mlx5_ib_cq *recv
}
} else {
spin_lock_irq(&send_cq->lock);
+ __acquire(&recv_cq->lock);
}
} else if (recv_cq) {
spin_lock_irq(&recv_cq->lock);
+ __acquire(&send_cq->lock);
+ } else {
+ __acquire(&send_cq->lock);
+ __acquire(&recv_cq->lock);
}
}
@@ -1033,10 +1038,15 @@ static void mlx5_ib_unlock_cqs(struct mlx5_ib_cq *send_cq, struct mlx5_ib_cq *re
spin_unlock_irq(&recv_cq->lock);
}
} else {
+ __release(&recv_cq->lock);
spin_unlock_irq(&send_cq->lock);
}
} else if (recv_cq) {
+ __release(&send_cq->lock);
spin_unlock_irq(&recv_cq->lock);
+ } else {
+ __release(&recv_cq->lock);
+ __release(&send_cq->lock);
}
}
@@ -2411,7 +2421,7 @@ static u8 get_fence(u8 fence, struct ib_send_wr *wr)
static int begin_wqe(struct mlx5_ib_qp *qp, void **seg,
struct mlx5_wqe_ctrl_seg **ctrl,
- struct ib_send_wr *wr, int *idx,
+ struct ib_send_wr *wr, unsigned *idx,
int *size, int nreq)
{
int err = 0;
@@ -2737,6 +2747,8 @@ out:
if (bf->need_lock)
spin_lock(&bf->lock);
+ else
+ __acquire(&bf->lock);
/* TBD enable WC */
if (0 && nreq == 1 && bf->uuarn && inl && size > 1 && size <= bf->buf_size / 16) {
@@ -2753,6 +2765,8 @@ out:
bf->offset ^= bf->buf_size;
if (bf->need_lock)
spin_unlock(&bf->lock);
+ else
+ __release(&bf->lock);
}
spin_unlock_irqrestore(&qp->sq.lock, flags);
--
2.1.3
^ permalink raw reply related
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:32 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <547D7243.80508@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 18265 bytes --]
Kevin - it works! the key seems to be in the tx_fixup function; there is a
special handling for frames effectively.
Please ... help me backport those changes to the standard Linux driver - it
will be a gain for us all, and in general you'll have a more probable
maintenance than you would with the driver from huawei.
Sorry huawei guys - I respect you, but there is a reason if drivers needs some
modifications to get merged. Hoping not to sound arrogant, my intent was only
to be clear.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==To: Eli Britstein <Eli.Britstein@audiocodes.com>,
== Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "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 wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein@audiocodes.com
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
==> 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@audiocodes.com>
==>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
==>> == Alex Strizhevsky <alexxst@gmail.com>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> == "youtux@gmail.com" <youtux@gmail.com>,
==>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==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@audiocodes.com> ==> ==To: Eli
==>> Britstein <Eli.Britstein@audiocodes.com>,
==>> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
==>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==> ==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@gmail.com> 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
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:37 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Enrico Mioso, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D7243.80508-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 19101 bytes --]
So, we can say that:
1 - They use 32-bit NCM if I am not wrong: so we where in the right direction
Alex!
2 - The driver is "all-in-one": it supports QMI also, not only cdc_ncm.
3 - It #undefs some things from the headers and might be redefine them...
mhm...
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "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 wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
==> 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-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==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-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> ==> ==To: Eli
==>> Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==> ==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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:45 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D7243.80508-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 19161 bytes --]
Oh - they define even custom structs for NCM_NTH32! :)
Mhm... unfortunately reading all the driver will be needed to find out the
details.
Probably using 16 or 32 bit is ok, but you have the choise now that a cdc_ncm.c
32-bit capable driver exists. But in that case an eventual merge will be
needed, and I might try.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "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 wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
==> 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-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==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-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> ==> ==To: Eli
==>> Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==> ==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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:48 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D7243.80508-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 18949 bytes --]
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 <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "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 wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
==> 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-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==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-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> ==> ==To: Eli
==>> Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==> ==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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
==
^ permalink raw reply
* Fwd: [Bug 89161] New: Regression in bonding driver with devices that have no MAC address
From: Daniel Borkmann @ 2014-12-02 10:56 UTC (permalink / raw)
To: tjc; +Cc: netdev, vfalico
In-Reply-To: <bug-89161-65011@https.bugzilla.kernel.org/>
-------- Original Message --------
Subject: [Bug 89161] New: Regression in bonding driver with devices that have no MAC address
Date: Tue, 02 Dec 2014 10:14:56 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: dborkman@redhat.com
https://bugzilla.kernel.org/show_bug.cgi?id=89161
Bug ID: 89161
Summary: Regression in bonding driver with devices that have no
MAC address
Product: Networking
Version: 2.5
Kernel Version: 3.17.4
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: tjc@wintrmute.net
Regression: No
In kernel 3.13 and earlier, a user could use the "bonding" network module to
enslave devices without MAC addresses, such as ppp devices, in certain modes
(such as balance-rr).
At some point between 3.13 and 3.17, this ability was removed -- even though
apparently a commit was made to specifically ALLOW this to happen:
https://github.com/torvalds/linux/commit/f54424412b6b2f64cae4d7c39d981ca14ce0052c
On kernel 3.13, this was printed to syslog upon enslaving ppp0:
bonding: bond0: Warning: The first slave device specified does not support
setting the MAC address. Setting fail_over_mac to active.
bonding: bond0: enslaving ppp0 as an active interface with an up link.
On kernel 3.17.2 and 3.17.4 (and probably others) instead this error comes up:
bond0: Adding slave ppp0
bond0: The slave device specified does not support setting the MAC address
And the slave is not added.
In case it was relevant, I resorted to manually creating the bond0 with
appropriate options (including fail_over_mac) preset, and yet the problem
persists.
To replicate the problem, setup at least one ppp connection, and then follow
these instructions:
modprobe bonding
echo '+bond0' > /sys/class/net/bonding_masters
echo 'active' > /sys/class/net/bond0/bonding/fail_over_mac
ifconfig bond0 down
echo 'balance-rr' > /sys/class/net/bond0/bonding/mode
ifconfig bond0 202.xx.xx.xx netmask 255.255.255.255 mtu 1492 up
echo '500' > /sys/class/net/bond0/bonding/miimon
ifconfig ppp0 down
echo '+ppp0' > /sys/class/net/bond0/bonding/slaves
Under earlier kernel versions, that would work -- but current stable kernels
fail.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Bjørn Mork @ 2014-12-02 11:21 UTC (permalink / raw)
To: Enrico Mioso
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412021130410.2697@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> Kevin - it works! the key seems to be in the tx_fixup function; there is a
> special handling for frames effectively.
> Please ... help me backport those changes to the standard Linux driver - it
> will be a gain for us all, and in general you'll have a more probable
> maintenance than you would with the driver from huawei.
Very interesting. The NCM code in the huawei driver has a different
origin, so it is quite different and not too easy to merge into the
existing Linux cdc_ncm driver.
But this does pinpoint differences we should explore. One is the
placement of the NDP: The Huawei driver puts it at the end. Another,
which is much easier to test out quickly, is the sequence numbering: The
Huawei driver doesn't use it.
So I wonder if this makes any difference:
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 80a844e0ae03..37f11770acb6 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign)
nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN);
nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16));
- nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
/* count total number of frames in this NTB */
ctx->tx_curr_frame_num = 0;
Bjørn
^ permalink raw reply related
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 11:28 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <87fvcyqoup.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2241 bytes --]
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 <bjorn@mork.no>
==To: Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
== Eli Britstein <Eli.Britstein@audiocodes.com>,
== Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
==> Kevin - it works! the key seems to be in the tx_fixup function; there is a
==> special handling for frames effectively.
==> Please ... help me backport those changes to the standard Linux driver - it
==> will be a gain for us all, and in general you'll have a more probable
==> maintenance than you would with the driver from huawei.
==
==Very interesting. The NCM code in the huawei driver has a different
==origin, so it is quite different and not too easy to merge into the
==existing Linux cdc_ncm driver.
==
==But this does pinpoint differences we should explore. One is the
==placement of the NDP: The Huawei driver puts it at the end. Another,
==which is much easier to test out quickly, is the sequence numbering: The
==Huawei driver doesn't use it.
==
==So I wonder if this makes any difference:
==
==diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
==index 80a844e0ae03..37f11770acb6 100644
==--- a/drivers/net/usb/cdc_ncm.c
==+++ b/drivers/net/usb/cdc_ncm.c
==@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign)
== nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
== nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN);
== nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16));
==- nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==
== /* count total number of frames in this NTB */
== ctx->tx_curr_frame_num = 0;
==
==
==
==Bjørn
==
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox