Hi,
I have tried to set up quagga with tcp-md5 support from kernel. All seems ok
with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp
packets have an invalid md5 digest.
If i run tcpdump on the mashine the packets are generated, it shows on the
outgoing interface invalid md5 digests.
Are there known issues about tcp-md5 and e1000 NICs?
Regards
Marc
On Tue, 22 May 2007 09:33:29 +0200
Marc Donner <[email protected]> wrote:
> Hi,
>
> I have tried to set up quagga with tcp-md5 support from kernel. All seems ok
> with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp
> packets have an invalid md5 digest.
> If i run tcpdump on the mashine the packets are generated, it shows on the
> outgoing interface invalid md5 digests.
> Are there known issues about tcp-md5 and e1000 NICs?
>
Hi Marc
CCed netdev as more appropriate to discuss about network stuff.
Would be nice if you sent some tcpdump samples to share with us, and tell us
which exact linux version you tried.
You could try "ethtool -K tx off", and/or other ethtool -K settings
In article <[email protected]> (at Tue, 22 May 2007 10:57:38 +0200), Eric Dumazet <[email protected]> says:
> > I have tried to set up quagga with tcp-md5 support from kernel. All seems ok
> > with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp
> > packets have an invalid md5 digest.
> > If i run tcpdump on the mashine the packets are generated, it shows on the
> > outgoing interface invalid md5 digests.
> > Are there known issues about tcp-md5 and e1000 NICs?
:
> You could try "ethtool -K tx off", and/or other ethtool -K settings
Disabling offloading should help; currently tcp-md5 stack
blindly copy md5-signature from the first segment
which is not appropriate for rest of segments.
--yoshfuji
Eric Dumazet wrote:
> On Tue, 22 May 2007 09:33:29 +0200
> Marc Donner <[email protected]> wrote:
>
>> Hi,
>>
>> I have tried to set up quagga with tcp-md5 support from kernel. All seems ok
>> with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp
>> packets have an invalid md5 digest.
>> If i run tcpdump on the mashine the packets are generated, it shows on the
>> outgoing interface invalid md5 digests.
>> Are there known issues about tcp-md5 and e1000 NICs?
>>
>
> Hi Marc
>
> CCed netdev as more appropriate to discuss about network stuff.
>
> Would be nice if you sent some tcpdump samples to share with us, and tell us
> which exact linux version you tried.
>
> You could try "ethtool -K tx off", and/or other ethtool -K settings
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I had this with e1000 NICs and it was just because I had TSO on.
It is disabled with ethtool as Eric suggests
Cheers,
Dunc
From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Tue, 22 May 2007 18:36:47 +0900 (JST)
> In article <[email protected]> (at Tue, 22 May 2007 10:57:38 +0200), Eric Dumazet <[email protected]> says:
>
> > > I have tried to set up quagga with tcp-md5 support from kernel. All seems ok
> > > with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp
> > > packets have an invalid md5 digest.
> > > If i run tcpdump on the mashine the packets are generated, it shows on the
> > > outgoing interface invalid md5 digests.
> > > Are there known issues about tcp-md5 and e1000 NICs?
> :
> > You could try "ethtool -K tx off", and/or other ethtool -K settings
>
> Disabling offloading should help; currently tcp-md5 stack
> blindly copy md5-signature from the first segment
> which is not appropriate for rest of segments.
It is clear we should disable TSO for sockets making use of TCP-MD5.
On Tuesday 22 May 2007, David Miller wrote:
> From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
> Date: Tue, 22 May 2007 18:36:47 +0900 (JST)
>
> > In article <[email protected]> (at Tue, 22 May
2007 10:57:38 +0200), Eric Dumazet <[email protected]> says:
> > > > I have tried to set up quagga with tcp-md5 support from kernel. All
> > > > seems ok with a intel e100 NIC, but as i testetd with a intel e1000
> > > > NIC the tcp packets have an invalid md5 digest.
> > > > If i run tcpdump on the mashine the packets are generated, it shows
> > > > on the outgoing interface invalid md5 digests.
> > > > Are there known issues about tcp-md5 and e1000 NICs?
> > >
> > > You could try "ethtool -K tx off", and/or other ethtool -K settings
> >
> > Disabling offloading should help; currently tcp-md5 stack
> > blindly copy md5-signature from the first segment
> > which is not appropriate for rest of segments.
>
> It is clear we should disable TSO for sockets making use of TCP-MD5.
disabling tso works. thanks
From: David Miller <[email protected]>
Date: Tue, 22 May 2007 03:14:32 -0700 (PDT)
> From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
> Date: Tue, 22 May 2007 18:36:47 +0900 (JST)
>
> > In article <[email protected]> (at Tue, 22 May 2007 10:57:38 +0200), Eric Dumazet <[email protected]> says:
> >
> > > > I have tried to set up quagga with tcp-md5 support from kernel. All seems ok
> > > > with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp
> > > > packets have an invalid md5 digest.
> > > > If i run tcpdump on the mashine the packets are generated, it shows on the
> > > > outgoing interface invalid md5 digests.
> > > > Are there known issues about tcp-md5 and e1000 NICs?
> > :
> > > You could try "ethtool -K tx off", and/or other ethtool -K settings
> >
> > Disabling offloading should help; currently tcp-md5 stack
> > blindly copy md5-signature from the first segment
> > which is not appropriate for rest of segments.
>
> It is clear we should disable TSO for sockets making use of TCP-MD5.
I'm going to fix this as follows:
commit 3d7dbeac58d0669c37e35a3b91bb41c0146395ce
Author: David S. Miller <[email protected]>
Date: Tue Jun 12 14:36:42 2007 -0700
[TCP]: Disable TSO if MD5SIG is enabled.
Signed-off-by: David S. Miller <[email protected]>
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 97e294e..354721d 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -878,6 +878,7 @@ int tcp_v4_md5_do_add(struct sock *sk, __be32 addr,
kfree(newkey);
return -ENOMEM;
}
+ sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
}
if (tcp_alloc_md5sig_pool() == NULL) {
kfree(newkey);
@@ -1007,7 +1008,7 @@ static int tcp_v4_parse_md5_keys(struct sock *sk, char __user *optval,
return -EINVAL;
tp->md5sig_info = p;
-
+ sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
}
newkey = kmemdup(cmd.tcpm_key, cmd.tcpm_keylen, GFP_KERNEL);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 4f06a51..193d9d6 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -590,6 +590,7 @@ static int tcp_v6_md5_do_add(struct sock *sk, struct in6_addr *peer,
kfree(newkey);
return -ENOMEM;
}
+ sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
}
tcp_alloc_md5sig_pool();
if (tp->md5sig_info->alloced6 == tp->md5sig_info->entries6) {
@@ -724,6 +725,7 @@ static int tcp_v6_parse_md5_keys (struct sock *sk, char __user *optval,
return -ENOMEM;
tp->md5sig_info = p;
+ sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
}
newkey = kmemdup(cmd.tcpm_key, cmd.tcpm_keylen, GFP_KERNEL);