Re: [PATCH net] qmi_wwan: Support dynamic config on Quectel EP06

On Thu, Nov 1, 2018 at 8:30 PM Kristian Evensen wrote: > > On Thu, Nov 1, 2018 at 6:40 PM Kristian Evensen > wrote: > > > > Hi, > > > > On Sat, Sep 8, 2018 at 1:50 PM Kristian Evensen > > wrote: > > > Quectel EP06 (and EM06/EG06) supports dynami

Re: [PATCH net] qmi_wwan: Support dynamic config on Quectel EP06

On Thu, Nov 1, 2018 at 6:40 PM Kristian Evensen wrote: > > Hi, > > On Sat, Sep 8, 2018 at 1:50 PM Kristian Evensen > wrote: > > Quectel EP06 (and EM06/EG06) supports dynamic configuration of USB > > interfaces, without the device changing VID/PID or con

Re: [PATCH net] qmi_wwan: Support dynamic config on Quectel EP06

Hi, On Sat, Sep 8, 2018 at 1:50 PM Kristian Evensen wrote: > 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 > inter

Re: kernels > v4.12 oops/crash with ipsec-traffic: bisected to b838d5e1c5b6e57b10ec8af2268824041e3ea911: ipv4: mark DST_NOGC and remove the operation of dst_free()

Hi, Thanks everyone for all the effort in debugging this issue. On Mon, Sep 10, 2018 at 8:39 AM Steffen Klassert wrote: > The easy fix that could be backported to stable would be > to check skb->dst for NULL and drop the packet in that case. Thought I should just chime in and say that we

Re: [PATCH net] qmi_wwan: Support dynamic config on Quectel EP06

Hei Bjørn, Thanks for the feedback! On Sat, Sep 8, 2018 at 4:12 PM Bjørn Mork wrote: > 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

[PATCH net] qmi_wwan: Support dynamic config on Quectel EP06

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. Signed-off-by: Kristian Evensen --- drivers/net/usb/qmi_wwan.c | 30

Re: [PATCH net-next 0/10] xfrm: remove flow cache

Hi, On Wed, Jun 13, 2018 at 3:43 PM, Kristian Evensen wrote: > Thanks! I will prepare a firmware for one of my devices tonight, start > testing tomorrow and report back when I have some results. We have been testing this patch over the weekend and it has a significant impact on perfo

Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup

Hello, On Tue, Jun 12, 2018 at 10:29 AM, Kristian Evensen wrote: > Thanks for spending time on this. I will see what I can manage in > terms of a bisect. Our last good kernel was 4.9, so at least it > narrows the scope down a bit compared to 4.4 or 4.1. I hope we might have got somewhe

Re: [PATCH net-next 0/10] xfrm: remove flow cache

Hi, On Wed, Jun 13, 2018 at 2:40 PM, Florian Westphal wrote: > Can you test attached patch? > > I'd like to see how much the pcpu cache helps or if it actually hurts > in your setup. > > Subject: [TEST PATCH 4.14.y] xfrm: remove pcpu policy cache > > We need to re-evaluate if this still buys

Re: [PATCH net-next 0/10] xfrm: remove flow cache

Hello, On Tue, Jul 18, 2017 at 8:15 PM, David Miller wrote: > Steffen, I know you have some level of trepidation about this because > there is obviously some performance cost immediately for removing this > DoS problem. In a project I am involved in, we are running ipsec (Strongswan) on

Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup

Hi, On Tue, Jun 12, 2018 at 10:03 AM, Steffen Klassert wrote: > I spent quite some time again yesterday in trying to find a > case where dst_orig can be NULL in xfrm_lookup(). I don't see > how this can happen, so I fear we need a bisection on this. Thanks for spending time on this. I will see

Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup

Hi, On Wed, Jun 6, 2018 at 6:03 PM, Tobias Hommel wrote: > Sorry no progress until now, I currently do not get time to have a deeper look > into that. We're back to 4.1.6 right now. Thanks for letting me know. In the project I am currently involved in, we unfortunately don't have the option of

Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup

On Wed, Jun 6, 2018 at 12:41 PM, Kristian Evensen wrote: > Hi, > > I am experiencing the same issue on a PC Engines APU2 running kernel > 4.14.34, both with and without hardware encryption. With hw. > encryption, the crash occurs within 2-4 hours. Without hw. encryption, > it t

Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup

Hi, I am experiencing the same issue on a PC Engines APU2 running kernel 4.14.34, both with and without hardware encryption. With hw. encryption, the crash occurs within 2-4 hours. Without hw. encryption, it takes 7-8 hours. My setup is nothing crazy, between 7 and 20 tunnels with heavy RX/TX.

[PATCH] netfilter: nf_queue: Replace conntrack entry

l conntrack entry. Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- 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..

Re: Silently dropped UDP packets on kernel 4.14

Hi Michal, Thanks for providing a nice summary of your experience when dealing with this problem. Always nice to know that I am not alone :) On Thu, May 3, 2018 at 11:42 AM, Michal Kubecek wrote: > One of the ideas I had was this: > > - keep also unconfirmed conntracks in

Re: Silently dropped UDP packets on kernel 4.14

Hi Florian, On Thu, May 3, 2018 at 7:03 AM, Florian Westphal wrote: > I'm sorry for suggesting that. > > It doesn't work, because of NAT. > NAT rewrites packet content and changes the reply tuple, but the tuples > determine the hash insertion location. > > I don't know how to

Re: Silently dropped UDP packets on kernel 4.14

Hello, On Wed, May 2, 2018 at 12:42 AM, Kristian Evensen <kristian.even...@gmail.com> wrote: > My knowledge of the conntrack/nat subsystem is not that great, and I > don't know the implications of what I am about to suggest. However, > considering that the two packets represen

Re: Silently dropped UDP packets on kernel 4.14

Hi, Thanks for your quick and detailed reply! On Wed, May 2, 2018 at 12:24 AM, Florian Westphal wrote: > I'm not sure what the best way to solve this is, we either need > to insert earlier in nfqueue case, or do conflict resolution in nfqueue > case (and perhaps also nat undo?

Re: Silently dropped UDP packets on kernel 4.14

On Tue, May 1, 2018 at 8:50 PM, Kristian Evensen <kristian.even...@gmail.com> wrote: > Does anyone have any idea of what could be wrong, where I should look > or other things I can try? I tried to space the requests out a bit in > time (I inserted a sleep 1 between them), and then t

Silently dropped UDP packets on kernel 4.14

Hello, I am currently debugging an issue where it looks like UDP packets are silently dropped. My setup is a client with a tool that sends two UDP packets (DNS requests) "simultaneously" using the same socket, and then a router running latest OpenWRT (with kernel 4.14.37). What I am seeing is

[PATCH net,stable] qmi_wwan: Add support for Quectel EP06

The Quectel EP06 is a Cat. 6 LTE modem. It uses the same interface as the EC20/EC25 for QMI, and requires the same "set DTR"-quirk to work. Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) diff --g

[PATCH net-next] inet_diag: Add equal-operator for ports

and destination port equal operators. INET_DIAG_BC_S_EQ is used to match a source port, INET_DIAG_BC_D_EQ a destination port, and usage is the same as for the existing port operators. I.e., the port to match is stored in the no-member of the next inet_diag_bc_op-struct in the filter. Signed-off-by: Kristian

Re: [PATCH net] qmi_wwan: Add missing skb_reset_mac_header-call

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

[PATCH net] qmi_wwan: Add missing skb_reset_mac_header-call

04.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

[PATH net v2] cdc_ether: Fix handling connection notification

andling") Reported-by: Henning Schild <henning.sch...@siemens.com> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/cdc_ether.c | 38 +++--- 1 file changed, 31 insertions(+), 7 deletions(-) diff --git a/drivers/ne

Re: [PATCH net] cdc_ether: Fix handling connection notification

On Wed, Nov 30, 2016 at 10:51 PM, Bjørn Mork <bj...@mork.no> wrote: > Kristian Evensen <kristian.even...@gmail.com> writes: > >> +void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb) >> +{ >> + struct usb_cdc_notification *event; >> + >&

[PATCH net] cdc_ether: Fix handling connection notification

"cdc_ether: Improve ZTE MF823/831/910 handling") Reported-by: Henning Schild <henning.sch...@siemens.com> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/cdc_ether.c | 38 +++--- 1 file changed, 31 insertion

[PATCH net-next v4] cdc_ether: Improve ZTE MF823/831/910 handling

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 <kristian.even...@gmail.com> Acked-by: Oliver Neukum <oneu...@suse.com> --- drivers/net/usb/cdc_ether.c | 51 +++

[PATCH net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

evices (thanks Lars Melin). Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- 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..87

Re: [PATCH net-next v2] cdc_ether: Improve ZTE MF823/831/910 handling

On Tue, Jul 19, 2016 at 2:33 PM, Oliver Neukum <oli...@neukum.org> 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) >>

[PATCH net-next v2] cdc_ether: Improve ZTE MF823/831/910 handling

try, as 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 <kristian.even...@gmail.com> --- drivers/net/usb/cdc_eth

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

Hi Lars, On Tue, Jul 19, 2016 at 10:30 AM, Lars Melin <lars...@gmail.com> 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

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

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 >>

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

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

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

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

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

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

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

Hi, On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum <oneu...@suse.com> 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,

[PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

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 <kristian.even...@gmail.com> --- drivers/net/usb/cdc_ether.

[PATCH net-next] rndis_host: Set valid random MAC on buggy devices

From: Kristian Evensen <kristian.even...@gmail.com> 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 w

Re: [PATCH] rndis_host: Set random MAC for ZTE MF910

On Thu, Jul 14, 2016 at 9:54 AM, Kristian Evensen <kristian.even...@gmail.com> wrote: > Hi Bjørn, > > On Thu, Jul 14, 2016 at 12:23 AM, Bjørn Mork <bj...@mork.no> wrote: >> >> Or how about the more generic?: >> >> if (bp[0] &

Re: [PATCH] rndis_host: Set random MAC for ZTE MF910

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

[PATCH] rndis_host: Set random MAC for ZTE MF910

From: Kristian Evensen <kristian.even...@gmail.com> 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 chec

[PATCH] net: qmi_wwan: Add SIMCom 7230E

From: Kristian Evensen <kristian.even...@gmail.com> SIMCom 7230E is a QMI LTE module with support for most "normal" bands. Manual testing has showed that only interface five works. Cc: Bjørn Mork <bj...@mork.no> Signed-off-by: Kristian Evensen <kristian.even...@gmail.

[PATCH] net: qmi_wwan: Add WeTelecom-WPD600N

From: Kristian Evensen <kristian.even...@gmail.com> The WeTelecom-WPD600N is an LTE module that, in addition to supporting most "normal" bands, also supports LTE over 450MHz. Manual testing showed that only interface number three replies to QMI messages. Cc: Bjørn Mork <bj...@

Re: [PATCH net v4] rtnl/bond: don't send rtnl msg for unregistered iface

Hello, I have a quick question about this patch. On Wed, May 13, 2015 at 2:19 PM, Nicolas Dichtel nicolas.dich...@6wind.com wrote: diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 837d30b5ffed..7b25f1ef3d75 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@

Re: Non-linear SKBs

Reading through my mail again, I see that I was a bit unclear. What I want to achieve is to share a frag between to skbs (where one has no earlier referance to it). Sorry. [EMAIL PROTECTED] wrote: If the underlying device can do scatter-gather and checksumming, the TCP code builds outgoing

Non-linear SKBs

Hello, I have developed a small patch for the TCP code in 2.6.19 and it works flawlessly. A couple of days ago I decided to make it compatible with 2.6.22.5 and have stumbled upon a problem I cannot solve. In 2.6.19 it seems that all packets (at least the ones my patch work with) are

Adding data to SKB - odd checksum errors

Hello, I am working on an algorithm to add data from the previous skb (on the queue) to the front of the current skb. This should be beneficial for a certain kind of TCP-traffic, and I am curious as to wether it will work or not. Currently I have implemented a small algorithm to copy the

Re: Copy data from one SKB to another

LDB wrote: kalash nainwal wrote: On 2/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I am working on optimizing the TCP-code for a certain type of TCP-stream, and to make one of my optimizations work I need to copy data from one SKB (the data field of the skb) to another SKB

Is the TCP-code threaded?

Hello, I have been looking quite deeply into the TCP-code, but there is one thing I simply dont manage to understand. Can the code process more than one skb on a socket at the time, or is it strictly one and one? E.g say that you are going to send something (an skb), and you recieve an ack