Hello Herbert,
That patch just went into stable 4.14 and is causing a regression on my
setup.
Basically, IP_PKTINFO does not work anymore on transport-mode packets,
because skb->cb is now used to store the finish callback.
Was that expected or is it an unforeseen side effect ?
Thanks,
--
Max
On Thu, 2015-10-08 at 14:09 -0700, Tom Herbert wrote:
> I think inet_proto_csum_replace16 should be called here.
inet_proto_csum_replace16() wants a non NULL checksum pointer to update,
and there is no such thing here.
I could pass a dummy value, but inet_proto_csum_replace16() will do
twice mo
m NAT on IPv4, we also update the IPv4 checksum, so
there is no side effect on skb->csum (since the csum over a valid IPv4
header area was already zero).
But IPv6 doesn't have such checksum, so when performing NAT we need to
update skb->csum.
Signed-off-by: Maxime Bizon
---
n
On Tue, 2015-10-06 at 16:23 +0200, Maxime Bizon wrote:
> + if (maniptype == NF_NAT_MANIP_SRC) {
> + from = ipv6h->saddr.s6_addr32;
> + to = target->src.u3.in6.s6_addr32;
> + } else {
> + from = ipv6h->daddr.s6_addr32;
>
m NAT on IPv4, we also update the IPv4 checksum, so
there is no side effect on skb->csum (since the csum over a valid IPv4
header area is zero).
But IPv6 doesn't have such header checksum, so when performing NAT we need to
update skb->csum.
Signed-off-by: Maxime Bizon
---
n
m NAT on IPv4, we also update the IPv4 checksum, so
there is no side effect on skb->csum (since the csum over a valid IPv4
header area is zero).
But IPv6 doesn't have such header checksum, so when performing NAT we need to
update skb->csum.
Signed-off-by: Maxime Bizon
---
n
On Fri, 2015-05-22 at 21:26 +0200, Florian Westphal wrote:
Hello,
> But it does happen, see e.g. following bug report:
> http://marc.info/?l=linux-netdev&m=139870308431986&w=2
>
> Maxime, do you recall what type of traffic generates
> the DF-fragments you reported?
Yep
We are an ISP and provi
On Tue, 2007-10-16 at 21:28 +0200, Lennert Buytenhek wrote:
Hello,
> +#define PORT_CONF0x400
> +#define PORT_CONF_EXT0x404
> +#define PORT_MAC_LO 0x414
> +#define PORT_MAC_HI 0x418
> +#define PORT_SDMA0x41c
> +#define PORT_SERIAL
On Thu, 2006-11-09 at 18:22 +0100, Eric Lemoine wrote:
> Actually I don't understand the purpose of having dev_close() wait for
> __LINK_STATE_RX_SCHED to be cleared. An interrupt may arrive at any
> time after it's cleared, and reset __LINK_STATE_RX_SCHED. Can someone
> explain please?
Further
Some stats reported by ethtool -S on mv643xx_eth device are cleared
between each call.
Is it the wanted behaviour ? If not, the attached patch fixes it.
Signed-off-by: Maxime Bizon <[EMAIL PROTECTED]>
--- linux-2.6.18/drivers/net/mv643xx_eth.c.orig 2006-10-03 18:29:14.0
On Sat, 2006-02-25 at 16:14 +0100, Jean-Baptiste Note wrote:
Hi,
> Obviously Intel doesn't want to manufacture one chipset for each subtle
> difference in legislation in each and every country it sells its chips
> in : Intel wants flexibility.
As pointed out by Jan, the binary approach does not
behaviour regarding server precedence to be
buggy, this fixes it. Else, we will need to somewhat hack the current
code to make the printk correct.
Signed-off-by: Maxime Bizon <[EMAIL PROTECTED]>
--- linux-2.6.16-rc1/net/ipv4/ipconfig.c.old2006-01-17 08:44:47.0
+0100
+++ linux-2
12 matches
Mail list logo
