On Mon, 2016-08-08 at 20:30 +0200, Bjørn Mork wrote:
> Note that this doesn't include *every* ethernet driver, although there
> certainly are some examples. There are also a number of serious
> vendors, providing vendor supported drivers for cards with no known
> issues of this kind.
>
> Where ex
Oliver Neukum writes:
> But why fix similar issues at two different places? And what about
> PCI or other cards that show the same problem?
I guess some sort of common helper would be nice to avoid open coding
this fix everywhere. But you would still have to modify every driver
where it is appl
On Mon, 2016-08-08 at 14:44 +0200, Bjørn Mork wrote:
> Oliver Neukum writes:
> > I don't see how it would be specific for a subsystem. If the patch
> > is correct, it belongs into the networking core.
>
> The bug is in the firmware implementation of the "read unique vendor
> assigned mac address
Oliver Neukum writes:
> On Mon, 2016-07-18 at 16:10 +0200, Kristian Evensen wrote:
>> On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum wrote:
>> > No, you misunderstand me. I don't want quirks if we can avoid it.
>> > But if you need to do this for rndis_host and cdc_ether and maybe other
>> > driv
> On Tue, Jul 19, 2016 at 10:30 AM, Lars Melin wrote:
> > On 2016-07-19 13:40, Kristian Evensen wrote:
> >
> >> I guess I can match on the VID/PID in usbnet, but won't it be cleaner
> >> to add a new bind() function (in cdc_ether) which matches the two PIDs
> >> and leave usbnet as is? Or am I mis
Hi Lars,
On Tue, Jul 19, 2016 at 10:30 AM, Lars Melin wrote:
> On 2016-07-19 13:40, Kristian Evensen wrote:
>
>> I guess I can match on the VID/PID in usbnet, but won't it be cleaner
>> to add a new bind() function (in cdc_ether) which matches the two PIDs
>> and leave usbnet as is? Or am I misun
On 2016-07-19 13:40, Kristian Evensen wrote:
I guess I can match on the VID/PID in usbnet, but won't it be cleaner
to add a new bind() function (in cdc_ether) which matches the two PIDs
and leave usbnet as is? Or am I misunderstanding how to add this
functionality to usbnet?
Matching on the u
On Tue, 2016-07-19 at 08:40 +0200, Kristian Evensen wrote:
> On Tue, Jul 19, 2016 at 8:20 AM, Oliver Neukum wrote:
> >> I had a look at some other drivers, and I think we need to be very
> >> careful about making setting a random MAC too generic. For example, we
> >> might be unlucky and break the
On Tue, Jul 19, 2016 at 8:20 AM, Oliver Neukum wrote:
>> I had a look at some other drivers, and I think we need to be very
>> careful about making setting a random MAC too generic. For example, we
>> might be unlucky and break the possibly_iphdr()-code/assumption in
>> qmi_wwan.c. And there is pr
On Mon, 2016-07-18 at 17:04 +0200, Kristian Evensen wrote:
> On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum wrote:
> >> Ok, sounds good. So far, I have only seen the random MAC issue with
> >> the three previously mentioned devices, but who knows how many else is
> >> out there with the same error
On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum wrote:
>> Ok, sounds good. So far, I have only seen the random MAC issue with
>> the three previously mentioned devices, but who knows how many else is
>> out there with the same error ... I don't think it should be in the
>> core ethernet code, at le
On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum wrote:
>> Ok, sounds good. So far, I have only seen the random MAC issue with
>> the three previously mentioned devices, but who knows how many else is
>> out there with the same error ... I don't think it should be in the
>> core ethernet code, at le
On Mon, 2016-07-18 at 16:10 +0200, Kristian Evensen wrote:
> On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum wrote:
> > No, you misunderstand me. I don't want quirks if we can avoid it.
> > But if you need to do this for rndis_host and cdc_ether and maybe other
> > drivers you should not be touchin
On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum wrote:
> No, you misunderstand me. I don't want quirks if we can avoid it.
> But if you need to do this for rndis_host and cdc_ether and maybe other
> drivers you should not be touching drivers. This belongs into the core
> ethernet code. Your code is
On Mon, 2016-07-18 at 15:23 +0200, Kristian Evensen wrote:
> Hi,
>
> On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum wrote:
> > On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote:
> >> The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to
> >> determine which type of d
Hi,
On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum wrote:
> On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote:
>> The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to
>> determine which type of device to export. In addition, these devices export
>> a REST API which
On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote:
> The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to
> determine which type of device to export. In addition, these devices export
> a REST API which can also be used to control the type of device. So far, on
> Linu
The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to
determine which type of device to export. In addition, these devices export
a REST API which can also be used to control the type of device. So far, on
Linux, the devices have been seen as RNDIS or CDC Ether.
When CDC Ethe
18 matches
Mail list logo
