Re: [bisected] UDP / xfrm: NAT-T packets with bad UDP checksum get dropped
> After a few hours of bisecting with a test VM,
> this commit was identified to cause the packet drop:
>
> ***
> commit 0a80966b1043c3e2dc684140f155a3fded308660
> Author: Tom Herbert
> Date: Wed May 7 16:52:39 2014 -0700
>
> net: Verify UDP checksum before handoff to encap
>
> Moving validation of UDP checksum to be done in UDP not encap layer.
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index f2d05d7be743..54ea0a3a48f1 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1495,6 +1495,10 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff
> *skb)
> if (skb->len > sizeof(struct udphdr) && encap_rcv != NULL) {
> int ret;
>
> + /* Verify checksum before giving to encap */
> + if (udp_lib_checksum_complete(skb))
> + goto csum_error;
> +
> ret = encap_rcv(sk, skb);
> if (ret <= 0) {
> UDP_INC_STATS_BH(sock_net(sk),
> ..
> ***
>
> This commit is part of kernel 3.16. Reverting the commit
> brings back the VPN connection using kernel 4.19.67.
..brings back the VPN connection when there's no iptables firewall involved ^^
As soon as netfilter is active, the packets get eaten again.
I've bisected this down to another commit, basically it's "broken" in 4.19.1
and works with with 4.19 vanilla. The commit in question:
*
# git bisect good
4fb0dc97de1cd79399ab0c556f096d8db2bac278 is the first bad commit
commit 4fb0dc97de1cd79399ab0c556f096d8db2bac278
Author: Sean Tranchetti
Date: Tue Oct 23 16:04:31 2018 -0600
net: udp: fix handling of CHECKSUM_COMPLETE packets
[ Upstream commit db4f1be3ca9b0ef7330763d07bf4ace83ad6f913 ]
Current handling of CHECKSUM_COMPLETE packets by the UDP stack is
incorrect for any packet that has an incorrect checksum value.
udp4/6_csum_init() will both make a call to
__skb_checksum_validate_complete() to initialize/validate the csum
field when receiving a CHECKSUM_COMPLETE packet. When this packet
fails validation, skb->csum will be overwritten with the pseudoheader
checksum so the packet can be fully validated by software, but the
skb->ip_summed value will be left as CHECKSUM_COMPLETE so that way
the stack can later warn the user about their hardware spewing bad
checksums. Unfortunately, leaving the SKB in this state can cause
problems later on in the checksum calculation.
Since the the packet is still marked as CHECKSUM_COMPLETE,
udp_csum_pull_header() will SUBTRACT the checksum of the UDP header
from skb->csum instead of adding it, leaving us with a garbage value
in that field. Once we try to copy the packet to userspace in the
udp4/6_recvmsg(), we'll make a call to skb_copy_and_csum_datagram_msg()
to checksum the packet data and add it in the garbage skb->csum value
to perform our final validation check.
Since the value we're validating is not the proper checksum, it's possible
that the folded value could come out to 0, causing us not to drop the
packet. Instead, we believe that the packet was checksummed incorrectly
by hardware since skb->ip_summed is still CHECKSUM_COMPLETE, and we attempt
to warn the user with netdev_rx_csum_fault(skb->dev);
Unfortunately, since this is the UDP path, skb->dev has been overwritten
by skb->dev_scratch and is no longer a valid pointer, so we end up
reading invalid memory.
This patch addresses this problem in two ways:
1) Do not use the dev pointer when calling netdev_rx_csum_fault()
from skb_copy_and_csum_datagram_msg(). Since this gets called
from the UDP path where skb->dev has been overwritten, we have
no way of knowing if the pointer is still valid. Also for the
sake of consistency with the other uses of
netdev_rx_csum_fault(), don't attempt to call it if the
packet was checksummed by software.
2) Add better CHECKSUM_COMPLETE handling to udp4/6_csum_init().
If we receive a packet that's CHECKSUM_COMPLETE that fails
verification (i.e. skb->csum_valid == 0), check who performed
the calculation. It's possible that the checksum was done in
software by the network stack earlier (such as Netfilter's
CONNTRACK module), and if that says the checksum is bad,
we can drop the packet immediately instead of waiting until
we try and copy it to userspace. Otherwise, we need to
mark the SKB as CHECKSUM_NONE, since the skb->csum field
no longer contains the full packet checksum after the
call to __skb_checksum_validate_complete().
Fixes: e6afc8ace6dd ("udp: remove headers from UDP packet
[bisected] UDP / xfrm: NAT-T packets with bad UDP checksum get dropped
Hello together,
after updating many machines already from 3.14 to 4.19.67,
one site showed a non-working IPSec VPN connection with 4.19.x.
This IPSec connection is using UDP NAT traversal on port 4500.
The tunnel gets established fine, but no data flows.
Output of "ip xfrm state" looked sane.
The TRACE iptables firewall target showed the UDP packets
on port 4500 get accepted as expected. Still they didn't appear
in "ip xfrm monitor" and vanish somewhere in the kernel,
no error counter in /proc/net/xfrm_state increased at all.
After a few hours of bisecting with a test VM,
this commit was identified to cause the packet drop:
***
commit 0a80966b1043c3e2dc684140f155a3fded308660
Author: Tom Herbert
Date: Wed May 7 16:52:39 2014 -0700
net: Verify UDP checksum before handoff to encap
Moving validation of UDP checksum to be done in UDP not encap layer.
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index f2d05d7be743..54ea0a3a48f1 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1495,6 +1495,10 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff
*skb)
if (skb->len > sizeof(struct udphdr) && encap_rcv != NULL) {
int ret;
+ /* Verify checksum before giving to encap */
+ if (udp_lib_checksum_complete(skb))
+ goto csum_error;
+
ret = encap_rcv(sk, skb);
if (ret <= 0) {
UDP_INC_STATS_BH(sock_net(sk),
..
***
This commit is part of kernel 3.16. Reverting the commit
brings back the VPN connection using kernel 4.19.67.
I didn't spot the checksum error initially since wireshark and tcpdump
need to be explicitly told to verify checksums and there's a warning
about checksum offloading messing with it.
Further tracing showed the UDP packets leave the source
site with a zero UDP checksum and arrive, after passing
an unknown home router and a few other routers,
with a bogus UDP checksum on the destination side.
I've disabled rx and tx checksum offloading on the target test VM
and also on a router in between, but the packet dumps just
contain a fixed value as UDP checksum (f.e. 0x91c4).
RFC 3948 specifies how ESP packets should be encapsulated
using UDP for NAT traveral:
https://tools.ietf.org/html/rfc3948
***
2.1. UDP-Encapsulated ESP Header Format
the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
receivers MUST NOT depend on the UDP checksum being a zero value.
3.5. Tunnel Mode ESP Decapsulation
1. The UDP header is removed from the packet.
***
I'm wondering how the RFC should be interpreted here
regarding the UDP checksumming?
As far as I can tell it doesn't mention the UDP checksum
should be verified before decapsulation, the ESP packets
will provide proper data authentication anyway.
Cheers,
Thomas
Re: 4.19: Traced deadlock during xfrm_user module load
Hi Florian,
You wrote on Tue, Jun 25, 2019 at 06:53:44PM +0200:
> Thanks for this detailed analysis.
> In this specific case I think this is enough:
>
> diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
> index 92077d459109..61ba92415480 100644
> --- a/net/netfilter/nfnetlink.c
> +++ b/net/netfilter/nfnetlink.c
> @@ -578,7 +578,8 @@ static int nfnetlink_bind(struct net *net, int group)
> ss = nfnetlink_get_subsys(type << 8);
> rcu_read_unlock();
> if (!ss)
> - request_module("nfnetlink-subsys-%d", type);
> + request_module_nowait("nfnetlink-subsys-%d", type);
> return 0;
> }
> #endif
thanks for the patch! We finally found an easy way to reproduce the deadlock,
the following commands instantly trigger the problem on our machines:
rmmod nf_conntrack_netlink
rmmod xfrm_user
conntrack -e NEW -E & modprobe -v xfrm_user
Note: the "-e" filter is needed to trigger the problematic
code path in the kernel.
We were worried that using "_nowait" would introduce other race conditions,
since the requested service might not be available by the time it is required.
On the other hand, if we understand correctly, it seems that after
"nfnetlink_bind()", the caller will listen on the socket for messages
regardless whether the needed modules are loaded, loading or unloaded.
To verify this we added a three second sleep during the initialisation of
nf_conntrack_netlink. The events started to appear after
the delayed init was completed.
If this is the case, then using "_nowait" should suffice as a fix
for the problem. Could you please confirm these assumptions
and give us some piece of mind?
Best regards,
Juliana Rodrigueiro and Thomas Jarosch
4.19: Traced deadlock during xfrm_user module load
ssic init,
this works. In parallel booting systemd world, people might
still hit the issue, so it's worth fixing.
The related function netlink_create() unlocks the table
before requesting modules and locks it afterwards again.
We guess it's racy to call netlink_unlock_table()
before doing the
err = nlk->netlink_bind(net, group + 1);
call in netlink_bind() ?
What would be the best fix here?
Best regards,
Thomas Jarosch and Juliana Rodrigueiro
Re: [PATCH 5/5] isdn: move capi drivers to staging
Hi Arnd,
You wrote on Thu, Apr 25, 2019 at 01:24:09PM +0200:
> > > Right, this is what I'm trying to find out here. I realize that there
> > > are (very few) remaining users of ISDN voice services, but this only
> > > matters if someone uses them
> > >
> > > 1. with a modern Linux kernel, and planning to upgrade beyond linux-5.3
> > > 2. with a device driver that ships with the kernel
> > > 3. using the CAPI subsystem
> > >
> > > I suspect that all three of the above are true in isolation, but onless
> > > at least one person needs all three combined, that doesn't stop us
> > > from staging them out.
> >
> > 1. + 3. applies to us. The mISDN drivers are based on the kernel ones,
> > but maintained in an extra git tree on top of the kernel. The situation
> > is not ideal but that's what it currently is. git repo:
> > https://github.com/ISDN4Linux/mISDN
>
> I'm still confused by this: You say here that you use the CAPI
> subsystem from the mainline kernel (i.e. /dev/capi20 rather
> than mISDNcapid), but this does not appear to interact at all with
> mISDN, neither the in-kernel variant nor the one you link to.
my working theory was that a userspace capi application
talks to mISDNcapid via the kernel's CAPI layer as a proxy.
Karsten's original announcement mentioned
mISDN v2 CAPI support is userspace only:
https://isdn4linux.listserv.isdn4linux.narkive.com/bRkOUkZG/announcement-misdn-fax-capi-2-0-support
I did some preliminary research by removing the /dev/capi20 device node
and checked if "capiinfo" still works via strace -> it does.
# strace -e open,connect capiinfo
open("/usr/lib/libcapi20.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/dev/shm/sem.CAPI20_shared_sem.v0110", O_RDWR|O_NOFOLLOW) = 3
open("/dev/shm/CAPI20_shared_memory.v0110",
O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0666) = 3
open("/usr/lib/capi/lib_capi_mod_misdn.so.2", O_RDONLY|O_CLOEXEC) = 5
open("/usr/lib/capi/lib_capi_mod_std.so.2", O_RDONLY|O_CLOEXEC) = 5
open("/root/.capi20rc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/capi20.conf", O_RDONLY) = 4
open("/dev/capi20", O_RDWR) = -1 ENOENT (No such file or directory)
open("/dev/isdn/capi20", O_RDWR)= -1 ENOENT (No such file or directory)
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/mISDNcapid/sock"}, 110) = 0
Number of Controllers : 1
connect(5, {sa_family=AF_UNIX, sun_path="/var/run/mISDNcapid/sock"}, 110) = 0
Controller 1:
Manufacturer: mISDN
CAPI Version: 2.0
Manufacturer Version: 0.1
Serial Number: 001
..
The trick is the lib_capi_mod_misdn.so library.
It's a plugin for the CAPI tools to directly talk to mISDNcapid.
I will do more thorough research next week if the CAPI userspace stuff runs
with
the kernel CAPI layer disabled. It could be that the userspace tools like
"capiinit" check for the presence of the kernel CAPI interface but don't really
need it. We'll find out.
Intra2net officially supports AVM b1 and c4 cards for fax but we didn't
encounter these cards for years in customer support and I'm also
willing to officially cancel support for those.
-> it's good to move the drivers to staging.
Best regards,
Thomas
Re: [PATCH 5/5] isdn: move capi drivers to staging
Hi Arnd, > Ok, interesting. My understanding was that mISDN CAPI support > was done purely in user space, on top of the mISDN interface. > > I don't see any interfaction between the two in the kernel code, > but if the capi module is required for mISDN, we clearly have to > keep it. We could still move the avm/gigaset/hysdn/cmtp drivers > to staging though, if there are no users for those. AVM Fritz!PCI cards are supported by the mISDN subsystem anyway, the new driver is "avmfritz" and used by us in production. > Right, this is what I'm trying to find out here. I realize that there > are (very few) remaining users of ISDN voice services, but this only > matters if someone uses them > > 1. with a modern Linux kernel, and planning to upgrade beyond linux-5.3 > 2. with a device driver that ships with the kernel > 3. using the CAPI subsystem > > I suspect that all three of the above are true in isolation, but onless > at least one person needs all three combined, that doesn't stop us > from staging them out. 1. + 3. applies to us. The mISDN drivers are based on the kernel ones, but maintained in an extra git tree on top of the kernel. The situation is not ideal but that's what it currently is. git repo: https://github.com/ISDN4Linux/mISDN > That leaves the question of whether there is anyone rolling their > own routers and/or fax machines based on future kernels with the > avm/gigaset/hysdn/cmtp CAPI drivers, and which drivers in particular > that would be. I would guess that isdn4linux is mostly dead and the drivers can be moved to staging. I didn't encounter cmtp (ISDN over Bluetooth) in real life yet. Intra2net uses mISDN v2 only and software fax support in mISDNcapid was developed because of us, so I guess we are the main user, too. [funny side note: I use a 4 port Eicon diva card at home for my SIP -> ISDN gateway. The eicon driver just got removed, too, but it still works fine on Centos 7.x 3.10 kernels. Though this is an exotic use case and I would not NAK the removal of the driver since the kernel maintenance costs don't justify it. If it stops getting supported, I'll either set up something based on mISDNv2 + LCR or get a used Fritz!Box for this task.] > > Intra2net is currently in the process of upgrading to kernel 4.19.x > > and Karsten recently did all the necessary adaptions for mISDN. > > So the ISDN code is used with modern (LTS) kernels ^^ > > Ok. If you are on 4.19 (or moving to that now), I would assume that > you probably upgrade to a future kernel later. Even if you don't > plan to, it's the safe bet. Correct. Intra2net usually moves to LTS kernels and skips a few versions since the migration work takes a few months to verify everything still works. We have an "avocado"[1] automated test framework for the whole distribution but there's always some userspace API compatibility issue, a small patch needed here or a crash there. For example my colleague tries to figure out right now why the Microsoft Hyper-V network driver hangs on module load with kernel 4.19.35 while downgrading to the previous kernel works instantly. Sounds like git bisect "fun" for her... [1] https://avocado-framework.github.io/ https://github.com/intra2net/avocado-i2n Best regards, Thomas Jarosch
Re: [PATCH 5/5] isdn: move capi drivers to staging
Hello Arnd,
You wrote on Tue, Apr 23, 2019 at 05:11:43PM +0200:
> I tried to find any indication of whether the capi drivers are
> still in use, and have not found anything from a long time ago.
>
> With public ISDN networks almost completely shut down over the past 12
> months, there is very little you can actually do with this hardware. The
> main remaining use case would be to connect ISDN voice phones to an
> in-house installation with Asterisk or LCR, but anyone trying this in
> turn seems to be using either the mISDN driver stack, or out-of-tree
> drivers from the hardware vendors.
>
> I may of course have missed something, so I would suggest moving
> these into drivers/staging/ just in case someone still uses one
> of the three remaining in-kernel drivers (avm, hysdn, gigaset).
>
> If nobody complains, we can remove them entirely in six months,
> or otherwise move the core code and any drivers that are still
> needed back into drivers/isdn.
thanks for your isdn4linux cleanup work!
AFAIK the base capi drivers are still needed for mISDN, too.
I quickly checked a machine that uses mISDNcapid for receiving fax
and the modules "capi" and "kernelcapi" are loaded.
# lsmod |grep capi
capi 10751 2
kernelcapi 33675 1 capi
# capiinfo
Number of Controllers : 1
Controller 1:
Manufacturer: mISDN
CAPI Version: 2.0
Manufacturer Version: 0.1
Serial Number: 001
BChannels: 2
Global Options: 0x0001
internal controller supported
B1 protocols support: 0x0013
64 kbit/s with HDLC framing
64 kbit/s bit-transparent operation
T.30 modem for fax group 3
B2 protocols support: 0x0013
ISO 7776 (X.75 SLP)
Transparent
T.30 for fax group 3
B3 protocols support: 0x0031
Transparent
T.30 for fax group 3
T.30 for fax group 3 with extensions
0100
0200
0100
1300
1300
3100
Supplementary services support: 0x
-> I think the CAPI layer is still needed, but Karsten knows best.
The ISDN network of Deutsche Telekom in Germany is still
*in the process* of being shut down, business customers that use
"direct inward dialing" (DID / "Anlagenanschluß") often still use ISDN.
For example we use it here at the office, but preparations for
a SIP migration are being done.
Vodafone Germany guarantees business customers to support ISDN until 2022.
Quite a few people use a SIP -> ISDN converter like the Fritz!Box or LANCOM
routers to keep their fax machines running. It's a bit crazy, but people seem
to love it. We deal with this on a weekly basis to support
our customers during the migration period.
Intra2net is currently in the process of upgrading to kernel 4.19.x
and Karsten recently did all the necessary adaptions for mISDN.
So the ISDN code is used with modern (LTS) kernels ^^
Best regards,
Thomas Jarosch
[IRDA PATCH] mcs7780: Fix initialization when CONFIG_VMAP_STACK is enabled
DMA transfers are not allowed to buffers that are on the stack.
Therefore allocate a buffer to store the result of usb_control_message().
Fixes these bugreports:
https://bugzilla.kernel.org/show_bug.cgi?id=195217
https://bugzilla.redhat.com/show_bug.cgi?id=1421387
https://bugzilla.redhat.com/show_bug.cgi?id=1427398
Shortened kernel backtrace from 4.11.9-200.fc25.x86_64:
kernel: [ cut here ]
kernel: WARNING: CPU: 3 PID: 2957 at drivers/usb/core/hcd.c:1587
kernel: transfer buffer not dma capable
kernel: Call Trace:
kernel: dump_stack+0x63/0x86
kernel: __warn+0xcb/0xf0
kernel: warn_slowpath_fmt+0x5a/0x80
kernel: usb_hcd_map_urb_for_dma+0x37f/0x570
kernel: ? try_to_del_timer_sync+0x53/0x80
kernel: usb_hcd_submit_urb+0x34e/0xb90
kernel: ? schedule_timeout+0x17e/0x300
kernel: ? del_timer_sync+0x50/0x50
kernel: ? __slab_free+0xa9/0x300
kernel: usb_submit_urb+0x2f4/0x560
kernel: ? urb_destroy+0x24/0x30
kernel: usb_start_wait_urb+0x6e/0x170
kernel: usb_control_msg+0xdc/0x120
kernel: mcs_get_reg+0x36/0x40 [mcs7780]
kernel: mcs_net_open+0xb5/0x5c0 [mcs7780]
...
Regression goes back to 4.9, so it's a good candidate for -stable.
Though it's the decision of the maintainer.
Thanks to Dan Williams for adding the "transfer buffer not dma capable"
warning in the first place. It instantly pointed me in the right direction.
Patch has been tested with transferring data from a Polar watch.
Signed-off-by: Thomas Jarosch
---
drivers/net/irda/mcs7780.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/irda/mcs7780.c b/drivers/net/irda/mcs7780.c
index 6f6ed75b63c9..765de3bedb88 100644
--- a/drivers/net/irda/mcs7780.c
+++ b/drivers/net/irda/mcs7780.c
@@ -141,9 +141,19 @@ static int mcs_set_reg(struct mcs_cb *mcs, __u16 reg,
__u16 val)
static int mcs_get_reg(struct mcs_cb *mcs, __u16 reg, __u16 * val)
{
struct usb_device *dev = mcs->usbdev;
- int ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), MCS_RDREQ,
- MCS_RD_RTYPE, 0, reg, val, 2,
- msecs_to_jiffies(MCS_CTRL_TIMEOUT));
+ void *dmabuf;
+ int ret;
+
+ dmabuf = kmalloc(sizeof(__u16), GFP_KERNEL);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), MCS_RDREQ,
+ MCS_RD_RTYPE, 0, reg, dmabuf, 2,
+ msecs_to_jiffies(MCS_CTRL_TIMEOUT));
+
+ memcpy(val, dmabuf, sizeof(__u16));
+ kfree(dmabuf);
return ret;
}
--
2.11.1
Re: [PATCH 3.19 and earlier] fib_rules: Fix dump_rules() not to exit early
Hi Roland,
On Monday, 5. October 2015 10:29:28 Roland Dreier wrote:
> From: Roland Dreier
>
> Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across
> multiple skbs") introduced a regression in "ip rule show" - it ends up
> dumping the first rule over and over and never exiting, because 3.19
> and earlier are missing commit 053c095a82cf ("netlink: make
> nlmsg_end() and genlmsg_end() void"), so fib_nl_fill_rule() ends up
> returning skb->len (i.e. > 0) in the success case.
>
> Fix this by checking the return code for < 0 instead of != 0.
thanks for this fix. You just saved me an afternoon of bisecting :)
I can confirm that this fixes the mentioned issue introduced in 3.14.54.
We have an automated ipsec VPN test that failed after the upgrade:
The "ip rule list" command was hanging forever.
Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
Hi Jeff and Yanir, On Saturday, 30. May 2015 01:18:44 Brown, Aaron F wrote: > > any news on this from the Intel labs? > > Nothing significant. Another one of our testers (whom works more closely > with the current e1000e driver owner than I) has managed to replicate it > on several systems and I know the developer spent some time poking around > the setup, but I don't think he's found the root cause yet and has been > busy chasing a number of other issues. so, any news from the Intel labs? I've seen some "hang fixes" on 03.06.2015, but I'm not sure if they are related to this issue. This problem is pretty annoying: We have a performance penalty for all network cards right now as the buffer size of the core network stack had to be decreased to 4096 bytes again on our side. (https://www.marc.info/?l=linux-netdev&m=142131668206333) Better than no e1000e network connectivity though. The initial report on this issue was on 14.01.2015: https://www.marc.info/?l=linux-netdev&m=142124954120315 Best regards, Thomas -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE: [bisected regression] e1000e: "Detected Hardware Unit Hang"
Hi Aaron, On Monday, 23. March 2015 22:37:08 Brown, Aaron F wrote: > > > > > > And with an internal reproduction of the issue I have created an > > > > internal > > > > > bug report, described my set of reproductions, referenced the similar > > > external ones and assigned it to our current e1000e developer. > > > > > > just wanted to quickly check if there has been any progress > > since the internal bug report has been filed? > > > No, no updates beyond a bit of investigation. any news on this from the Intel labs? Another two months passed ;) It would be nice to get rid of the workaround that limits the max fragment size to 4096. Thanks, Thomas -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
