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: <6e60e3dc73f1d9f797298afaa60dd8776455521d.camel@redhat.com>
Date:   Mon, 10 Sep 2018 09:42:13 -0500
From:   Dan Williams <dcbw@...hat.com>
To:     Bjørn Mork <bjorn@...k.no>,
        Kristian Evensen <kristian.evensen@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net] qmi_wwan: Support dynamic config on Quectel EP06

On Sat, 2018-09-08 at 16:12 +0200, Bjørn Mork wrote:
> Kristian Evensen <kristian.evensen@...il.com> writes:
> 
> > Quectel EP06 (and EM06/EG06) supports dynamic configuration of USB
> > interfaces, without the device changing VID/PID or configuration
> > number.
> > When the configuration is updated and interfaces are added/removed,
> > the
> > interface numbers change. This means that the current code for
> > matching
> > EP06 does not work.
> 
> That's annoying, but hardly surprising. They obviously try to make
> life
> as hard as possible for the drivers.  I wonder what the Windows
> drivers
> do here, if there are any?  Or are these modules only used in
> embedded
> Linux devices?
> 
> > This patch removes the current EP06 interface number match, and
> > replaces
> > it with a match on class, subclass and protocol. Unfortunately,
> > matching
> > on those three alone is not enough, as the diag interface exports
> > the
> > same values as QMI. The other serial interfaces + adb export
> > different
> > values and do not match.
> > 
> > The diag interface only has two endpoints, while the QMI interface
> > has
> > three. I have therefore added a check for number of interfaces, and
> > we
> > ignore the interface if the number of endpoints equals two.
> 
> Could this break if more/other functions are enabled?  Are you sure
> there can't be any other type of serial function with 3 endpoints and
> ff/ff/ff?  Well, I guess no one knows for sure... And this is more
> than
> good enough until it breaks. Thanks for solving the puzzle.  Looks
> good
> to me.

I'm sure they could add another serial interface with ff/ff/ff and 3
endpoints, but I don't know what else we can do to make this device
work correctly.  I double-checked the permutations & logic and it makes
sense to me.

Acked-by: Dan Williams <dcbw@...hat.com>

Dan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ