PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
Acked-by: Oliver Neukum
---
drivers/net/usb/cdc_ether.c | 51 +
1 file changed, 51 insertions(+)
dif
Hi,
On Mon, Jun 24, 2019 at 6:26 PM Bjørn Mork wrote:
> Doh! Right you are. Thanks to both you and Andrey for quick and good
> help.
>
> We obviously have some bad code patterns here, since this apparently
> worked for Kristian by pure luck.
Thanks a lot to everyone for spotting and fixing my m
onntrack entry.
Signed-off-by: Kristian Evensen
---
net/netfilter/nfnetlink_queue.c | 68 +
1 file changed, 68 insertions(+)
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
index c97966298..150c11ff4 100644
--- a/net/netfilter/nfnetli
operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 53
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
>
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, 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 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
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
>> an
the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 60 +
1 f
On Tue, Jul 19, 2016 at 2:33 PM, Oliver Neukum wrote:
> On Tue, 2016-07-19 at 13:49 +0200, Kristian Evensen wrote:
>> @@ -428,10 +434,47 @@ int usbnet_cdc_bind(struct usbnet *dev, struct
>> usb_interface *intf)
>> return status;
>> }
>>
&g
evices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 54 +
1 file changed, 54 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 7cba2c3..874caad 100644
--- a/drivers/n
From: Kristian Evensen
All ZTE MF910 mifis, at least on some revisions, export the same MAC
address (36:4b:50:b7:ef:da). Check for this MAC address and set a random
MAC if detected.
Also, changed the memcpy() to ether_addr_copy(), as pointed out by
checkpatch.
Signed-off-by: Kristian Evensen
Hi Bjørn,
On Thu, Jul 14, 2016 at 12:23 AM, Bjørn Mork wrote:
>
> Or how about the more generic?:
>
> if (bp[0] & 0x02)
> eth_hw_addr_random(net);
> else
> ether_addr_copy(net->dev_addr, bp);
>
> That would catch similar screwups from other vendors
On Thu, Jul 14, 2016 at 9:54 AM, Kristian Evensen
wrote:
> Hi Bjørn,
>
> On Thu, Jul 14, 2016 at 12:23 AM, Bjørn Mork wrote:
>>
>> Or how about the more generic?:
>>
>> if (bp[0] & 0x02)
>> eth_hw_addr_random(net);
>>
From: Kristian Evensen
Some devices of the same type all export the same, random MAC address. This
behavior has been seen on the ZTE MF910, MF823 and MF831, and there are
probably more devices out there. Fix this by generating a valid random MAC
address if we read a random MAC from device.
Also
ling")
Reported-by: Henning Schild
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 45e5e43..fe7b288 10064
"cdc_ether: Improve ZTE MF823/831/910 handling")
Reported-by: Henning Schild
Signed-off-by: Kristian Evensen
---
drivers/net/usb/cdc_ether.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers
On Wed, Nov 30, 2016 at 10:51 PM, Bjørn Mork wrote:
> Kristian Evensen writes:
>
>> +void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
>> +{
>> + struct usb_cdc_notification *event;
>> +
>> + if (urb->actual_length &l
From: Kristian Evensen
There seems to be a new version of the Microchip Pick16F1454 with a
different PID (0xf2f7). This device should also be ignored by the HID
driver. The PID was observed with the second version of the Yepkit Ykush
USB hub.
Signed-off-by: Kristian Evensen
---
drivers/hid
Hi all,
I was able to trigger the same issue as reported by Paul, and came
across this patch (+ Daniele's other patch and thread on the libqmi
mailing list). Applying Paul's fix solved the problem for me, changing
the MTU of the QMI interface now works fine. Thanks a lot to everyone
involved!
I j
Hi Daniele,
On Mon, Sep 7, 2020 at 10:35 AM Daniele Palmas wrote:
> there was also another recent thread about this and the final plan was
> to simply increase the rx urb size setting to the highest value we are
> aware of (see https://www.spinics.net/lists/linux-usb/msg198858.html):
> this shoul
Hi,
On Sat, Oct 26, 2019 at 3:27 PM Sasha Levin wrote:
>
> From: Daniele Palmas
>
> [ Upstream commit e0ae2c578d3909e60e9448207f5d83f785f1129f ]
>
> This patch adds support for Telit FN980 0x1050 composition
>
> 0x1050: tty, adb, rmnet, tty, tty, tty, tty
>
> Signed-off-by: Daniele Palmas
> Ack
[ 304.031034]
[ 304.032805] ---[ end trace b778c482b3f0bda9 ]---
[ 304.041384] Kernel panic - not syncing: Fatal exception in interrupt
[ 304.051975] Rebooting in 3 seconds..
While the oops is for a 4.9-kernel, I was able to trigger the same oops with
net-next as of yesterday.
Signed-off-by: Kris
Hei,
On Tue, Nov 7, 2017 at 2:02 PM, Bjørn Mork wrote:
> And his should probably go to stable as well? with a
>
> Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Yes, I forgot to add the fixes-tag + comment about stable. Should I submit a v2?
-Kristian
26 matches
Mail list logo
