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:	Fri, 17 Feb 2012 10:31:14 +0000
From:	Toby Gray <toby.gray@...lvnc.com>
To:	Alexey Orishko <alexey.orishko@...il.com>
CC:	Toby Gray <tg@...lvnc.com>, Oliver Neukum <oliver@...kum.name>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 2/5] usb: cdc-ncm: Set altsetting only when network interface
 is opened

On 17/02/12 09:57, Alexey Orishko wrote:
> On Wed, Feb 15, 2012 at 3:47 PM, Toby Gray<toby.gray@...lvnc.com>  wrote:
>
>> Some NCM devices fail to send the NetworkConnection status if the host
>> is not trying to read from the control interrupt endpoint in the first
>> few seconds after the data interface alternate setting is selected.
> I have a feeling that the problem description above is not correct:
> more likely the fault is related to device initialization or other
> state machine problem in device.

I think I've been explaining my understanding badly and we actually 
agree :) I imagine that the device has code something like the following 
in it's initialization code:

void handle_set_alternate_setting(int altsetting) {
     if (altsetting == 0) {
         reset_interface_configuration();
     } else if (altsetting == 1) {
         queue_networkconnection_notification(DISCONNECTED, 1000MS_TIMEOUT);
         //ignore timeout in sending notification
         queue_speed_configuration_notification(tx_speed, rx_speed, 
1000MS_TIMEOUT);
         //ignore timeout in sending speed configuration
         queue_networkconnection_notification(CONNECTED, 1000MS_TIMEOUT);
         // ignore timeout in sending notification
     }
}

Is that the sort of behavior you were thinking of?

> Looking at the trace, the patch serves its purpose, however there
> might be other devices which can't get network status in time or get
> similar problem. If this would be the case, driver could set a timer
> after selecting alt1; in the absence of the connect message set alt0
> to reset a function when timer expires and set alt1 again.

I might be overly cautious but this behavior sounds like it could impact 
reliability. All my patch series does is keep the device in the reset 
alternate setting until the network interface comes up. My understanding 
is that this won't impact CDC NCM devices which queue the network 
notifications indefinitely and it solves the issue for the device I'm 
having issues with.

My reading of the CDC NCM specification is that it doesn't give any 
timing constraints on when a NetworkConnection notification can come 
from the device. You mentioned that 3G modems can take 1-2 minutes, so 
if some sort of timer was added after selecting alt1, what value could 
be used for it which would work reliably with all NCM CDC devices? Also 
what devices could we test this timer code on?

Regards,

Toby
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ