linux-kernel - RE: USB GADGET: have a question about usb2eth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 18 Oct 2016 10:14:32 +0300
From:   Felipe Balbi <balbi@...nel.org>
To:     Lipengcheng <lpc.li@...ilicon.com>,
        Peter Chen <hzpeterchen@...il.com>
Cc:     "gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: USB GADGET: have a question about usb2eth


Hi,

Lipengcheng <lpc.li@...ilicon.com> writes:
>> -----Original Message-----
>> From: Felipe Balbi [mailto:balbi@...nel.org]
>> Sent: Monday, October 17, 2016 5:29 PM
>> To: Lipengcheng; Peter Chen
>> Cc: gregkh@...uxfoundation.org; linux-usb@...r.kernel.org; linux-kernel@...r.kernel.org
>> Subject: RE: USB GADGET: have a question about usb2eth
>> 
>> 
>> Hi,
>> 
>> (please, avoid top-posting: http://daringfireball.net/2007/07/on_top)
>> 
>> Lipengcheng <lpc.li@...ilicon.com> writes:
>> > Hi,
>> > 	thank you for your suggestion.
>> >
>> > 	I have a question about usb2eth. In the function gen_ndis_set_resp of
>> > the rndis.c, the value of *params->filter may be 0x20 from the pc set
>> > command; Howerver the value is used cdc_filter =
>> > dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c.
>> > If we do not judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is
>> > 0x20, the broadcast packet can not send the pc win7; At the result,
>> > the linux ping the win7 is slow an the first. At the same time, Why
>> > are different value between RNDIS_PACKET_TYPE_PROMISCUOUS and
>> > USB_CDC_PACKET_TYPE_PROMISCUOUS? If the value of
>> > RNDIS_PACKET_TYPE_PROMISCUOUS
>> 
>> because they are defined by different specifications. You should read both CDC specification from USB.org and RNDIS spec from Microsoft to
>> understand the details of that.
> Ok. I will understand the different both CDC specification from USB.org and RNDIS spec from Microsoft. They should have transformational rule in the linux code
> between CDC spe and RNDIS spe. Through debugging, I found there has been no conversion about the filter. I feel a little problem. I will find the rule.
>> 
>> > and USB_CDC_PACKET_TYPE_PROMISCUOUS is same, then the linux ping the
>> > win7 is normal speed.
>> 
>> I don't understand what's going on here. Care to describe which kernel you're using, which USB peripheral controller, what is the actual
>> problem you're trying to solve?
>
> VERSION = 3.18.20

why not v4.9-rc1? We can't help you with your kernel in this forum, I
reckon you realise that :-)

> USB peripheral controller: Synopsys HS OTG Linux Software Driver. It's
> not the standard linux code. But I think the controller do not have
> problem.

so you're not using drivers/usb/dwc2?

> The probem is that I am using one controller board with Linux running
> on it. I want to interface my device to the Host computer (Windows OS)
> through USB.

many have tried and succeeded before you :-)

> I have driver ready at device side (linux) and the bridge has been
> established. The device side ping the Host computer is very slow at
> the first time. It spends a few minutes. The problem is the first ping
> takes too long time. Now I have a way to quickly ping at the first ,
> but I do not know the risk about the change.I will continue debug the
> problem. If it is valuable, I will submit the kernel community.

Well, if you can reproduce the same problem with v4.8 or v4.9-rc1, then
we'll be happy to review your patch.

Thank you

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)