Hi Bjørn,
On Wed, Jan 6, 2021 at 3:31 PM Bjørn Mork wrote:
> Nice work!
Thanks a lot!
> Just wondering: Will the same problem affect the usbnet allocated skbs
> as well in case of raw-ip? They will obviously be large enough, but the
> reserved headroom probably isn't when we put an IP packet th
. The reason for using LL_MAX_HEADER and not a more
accurate value, is that we do not know the type of the outgoing network
interface. After making this change, I achieve the same throughput with
the modems as with the dongle.
Signed-off-by: Kristian Evensen
---
drivers/net/usb/qmi_wwan.c | 3 ++-
1
Hi all,
I am using QMI together with QMAP when configuring and connecting my
LTE/5G modules. This all works well, but I have noticed something
strange when modules are disconnected from the host. Most disconnects
goes fine and everything related to module is removed, but sometimes
it happens that
Hi,
On Fri, Nov 13, 2020 at 9:50 AM Kristian Evensen
wrote:
> Yes, you are right in that NAT can have a large effect on performance,
> especially when you start being CPU-limited. However,when using perf
> to profile the kernel during my tests, no function related to
> netfilt
Hi Carl,
Thanks a lot for your reply.
On Fri, Nov 13, 2020 at 9:37 AM Carl Yin(殷张成) wrote:
> For openwrt device, the ' Performance bottleneck ' usually is NAT,
> not usbnet.
> As I remember: MT7621 have dual core, and support Hardware
> acceleration of 'NAT'.
Yes, you are righ
Hi Daniele,
On Thu, Nov 12, 2020 at 7:29 PM Daniele Palmas wrote:
> thanks for testing. Still thinking it could be better to differentiate
> between raw-ip and qmap, but not yet able to find the time to perform
> some tests on my own.
I agree that separating between qmap and non-qmap would be ni
Hi,
On Wed, Sep 9, 2020 at 11:14 AM Daniele Palmas wrote:
>
> Add default rx_urb_size to support QMAP download data aggregation
> without needing additional setup steps in userspace.
>
> The value chosen is the current highest one seen in available modems.
>
> The patch has the side-effect of fix
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
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 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,
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
rror handling of invalid local/peer addresses.
* Use interface name and not index.
* Remove updating fou-header file, it is already done.
Signed-off-by: Kristian Evensen
---
ip/ipfou.c| 135 +++---
man/man8/ip-fou.8 | 49 -
2 fi
Hi David,
On Sun, Apr 21, 2019 at 3:33 AM David Ahern wrote:
> Missed this in v1: you definitely do not want to call ll_init_map here.
> It does a full kink dump which can be expensive on large scale setups.
> ll_name_to_index alone should be fine.
Thanks a lot for all your comments! It is not s
and not index.
* Remove updating fou-header file, it is already done.
Signed-off-by: Kristian Evensen
---
ip/ipfou.c| 137 +++---
man/man8/ip-fou.8 | 49 -
2 files changed, 177 insertions(+), 9 deletions(-)
diff --git a/ip/ipfou.c b/ip/
ey are set. Also, the man page has been updated.
Signed-off-by: Kristian Evensen
---
include/uapi/linux/fou.h | 6 +++
ip/ipfou.c | 106 +--
man/man8/ip-fou.8| 49 +-
3 files changed, 155 insertions(+), 6 deletions(-)
di
Hi,
On Sun, Apr 7, 2019 at 5:27 PM Bjørn Mork wrote:
> I guess this has to go to (at least some of) the stable trees
> eventually, but assume you directed it to net-next for more thorough
> testing first?
Yes, that was my thought exactly. Since this is more an improvement
than a fix, I sent it t
: Kristian Evensen
---
drivers/net/usb/qmi_wwan.c | 65 ++
1 file changed, 31 insertions(+), 34 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 9195f3476b1d..18c4e5d17b05 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers
ype warning and make the ugly comparison function more
readable (kbuild).
* Describe more in detail what has been tested (thanks David Miller).
* Make peer port required if peer address is specified.
Signed-off-by: Kristian Evensen
---
include/uapi/linux/fou.h | 6 ++
net/ipv4/fo
Hi,
On Thu, Mar 21, 2019 at 9:10 PM David Miller wrote:
> This seems to allow adding both a wildcarded and a non-wildcarded fou
> socket, which otherwise has overlapping match scenerios.
>
> I don't think you want to allow that unless you can determine that
> you aren't creating a situation where
on some servers I am
responsible for, and I have not found any regressions. If none of the
new attributes are provided, then an FoU-socket is configured as before.
If any of the new attributes are provided, the FoU-socket is configured
as expected.
Signed-off-by: Kristian Evensen
---
include/uapi
On Sat, Mar 2, 2019 at 4:00 PM Bjørn Mork wrote:
> I am not too happy about the double device id matching with extra magic
> applied. outside the device id table. It does not scale, and it does
> not play well at all with dynamic IDs. But I guess it's acceptable for
> two devices when it was ok
ction
from quectel_ep06_diag_detected() to quectel_diag_detected().
Signed-off-by: Kristian Evensen
---
drivers/net/usb/qmi_wwan.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 18af2f8eee96..74bebbdb4
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
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 configu
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
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 deploy
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 in
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
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 performan
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
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 anyt
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
differen
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 w
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 r
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
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.
On
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
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 some data structure
>
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 solve this problem.
Hello,
On Wed, May 2, 2018 at 12:42 AM, Kristian Evensen
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 represent the same flow, wouldn't
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? not sure).
My kno
On Tue, May 1, 2018 at 8:50 PM, Kristian Evensen
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 the problem went
> away.
I sho
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 that
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
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/d
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
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
[ 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
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
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
"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
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
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
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
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
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
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, 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, 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
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
>
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
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
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);
>>
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
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
From: Kristian Evensen
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
Signed-off-by: Kristian Evensen
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Kristian Evensen
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
Signed-off-by: Kristian Evensen
---
d
Hello,
I have a quick question about this patch.
On Wed, May 13, 2015 at 2:19 PM, Nicolas Dichtel
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
> @@ -2415,6 +2415,9 @@ void rtm
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 pac
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 linear,
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 dat
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 SK
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 a
73 matches
Mail list logo
