netdev - Re: Huaei E3131

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <871u7gvz2z.fsf@nemi.mork.no>
Date:	Wed, 03 Jul 2013 10:15:32 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Enrico Mioso <mrkiko.rs@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Huaei E3131 - status

Enrico Mioso <mrkiko.rs@...il.com> writes:

> Ok ... As Bjorn stated, cdc-wdm is handling the notifications now - or, better: 
> is not handling them, as it is not made to do these things! The connection 
> stays up and the character device seems to work properly. Obviously cdc-wdm 
> notices me about one single unknown notifications.
> We're ignoring all the notifications from the NCM erspective, but all works 
> because the device probably doesn't rely on them so much.
> Aniway - now I'm conscious about why it works. Now it's time to improve the 
> situation of the driver, and might be the api. Waiting for suggestions and 
> injuries! :)

The only notification actually used for anything by cdc_ncm is
USB_CDC_NOTIFY_NETWORK_CONNECTION, which it uses to set the link up or
down. That functionality is disabled in your driver, leaving the link
always up.

This is of course not entirely correct if we apply a strict NCM
specification to this driver. But it does no harm either.  You have
added support for the embedded management channel, which must be used to
configure and connect the device.  Connection status will also be
reported here, and the managing userspace application (for example
ModemManager) will use this to pick up the actual network connection
state.  So the link state reported by NCM is redundant for these
devices.

The issue is that the few simple notifications standardized in CDC NCM
are sufficient for management of ethernet connections, but not for
3G/LTE connections.  That's why you need access to the additional vendor
specific management channel in the first place.  And when you have that
channel, then the additional NCM notifications are redundant at best.
Or confusing at worst.

The second notification implemented by cdc_ncm is
USB_CDC_NOTIFY_SPEED_CHANGE, which is shown in your logs.  But there is
nothing cdc_ncm can do with this, so it will just log it.  That's mostly
useless, both for wired and wireless devices.  3G/LTE management
applications will pick up the same information via the appropriate
management channel instead.

So the main reason why you should implement support for these
notifications eventually is not so much to handle them, but to silence
cdc-wdm. It will otherwise complain, which will confuse some users.  But
this is a really minor issue, and I see no reason why it should hold
back this driver.  It is perfectly usable as it is, and all necessary
features are implemented.

Bjørn
--
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