Re: [swinog] Swisscom IPv6 Routing weirdness

2021-02-26 Diskussionsfäden Gert Doering
Hi,

On Fri, Feb 26, 2021 at 05:01:38PM +0100, Claudio Luck wrote:
> Checksum errors are rather common to originate in virtualization 
> platforms. It is one of the things to check for when deploying new 
> infrastructure. Even some bigger resellers hand out VMs with these 
> problems: I occasionally have to add a "ethtool -K $IFACE rx off tx off" 
> command to the boot process.

These are not true checksum "errors".

It's just that the kernel knows it does not need to bother, because 
hardware will take care of it, so spends your CPU cycles for more useful
work.

*tcpdump* does not know.  All tcpdump can see is "I see a packet handed 
towards the NIC, and the checksum does not match" - which is reported.

Tcpdump does not see how the packet will end up on the wire.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Swisscom IPv6 Routing weirdness

2021-02-26 Diskussionsfäden Claudio Luck
On 26.02.21 12:29, Silvan M. Gebhardt wrote:
> Isn't that the case with tcp_offload enabled in the NIC that tcpdump will see 
> incorrect checksums?
> 
> 

> I'm by no means a tcpdump expert:
> 
> Those incorrect checksums: are my systems generating incorrect checksums
> or is it the swisscom side? It seems weird that different systems with
> different OS at different customers would all start making wrong tcp
> checksums.

Checksum errors are rather common to originate in virtualization 
platforms. It is one of the things to check for when deploying new 
infrastructure. Even some bigger resellers hand out VMs with these 
problems: I occasionally have to add a "ethtool -K $IFACE rx off tx off" 
command to the boot process.

Cheers
Claudio



pEpkey.asc
Description: application/pgp-keys

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Swisscom IPv6 Routing weirdness

2021-02-26 Diskussionsfäden Silvan M. Gebhardt
Isn't that the case with tcp_offload enabled in the NIC that tcpdump will see 
incorrect checksums?


>>>
I'm by no means a tcpdump expert:

Those incorrect checksums: are my systems generating incorrect checksums
or is it the swisscom side? It seems weird that different systems with
different OS at different customers would all start making wrong tcp
checksums.


Best Regards

Jean-Pierre



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Swisscom IPv6 Routing weirdness

2021-02-26 Diskussionsfäden Benoît Panizzon
I don't seem to have problem from AS6772:

$ openssl s_client -connect [2a02:a90:c400:5001::2]:https
[ssh handshake stuff]
GET / HTTP/1.0

HTTP/1.0 301 Moved Permanently
Location: https://www.swisscom.ch/de/privatkunden.html
Connection: close
Content-Length: 252
[...]

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Swisscom IPv6 Routing weirdness

2021-02-26 Diskussionsfäden Jean-Pierre Schwickerath
Hi Jeroen

There were two issues, one has been resolved, which was the routing
issue I was seeing from one of the networks where I tested from.

What remains is that I can't open a successful TCP connection to
www.swisscom.ch on Port 443 when coming from a non-swisscom network.

> Check with a tcpdump, don't forget to include ICMP.
>
> Could also be an MTU issue or something on your side killing it.
>
> Of course the behavior of the "load balancer" says quite a few things... 
> sbb.ch is like that too...
>
I tried different ISPs to which I have access and I can't establish a
IPv6 connection to port TCP/443 to neither 2a02:a90:c400:4001::2 nor
2a02:a90:c400:5001::2 which seems the two loadbalancers responsible for
www.swisscom.ch except from a Swisscom Business DSL connection.

Init7 -> fail

UPC Business -> fail

Tineo/Netrics -> fail

NTS -> fail

TCP dump looks like that

tcpdump -v -ni eth1 host 2a02:a90:c400:4001::2
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
262144 bytes
08:19:41.525301 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xdf6f), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090291639 ecr 0,nop,wscale 7], length 0
08:19:42.522914 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xde75), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090291889 ecr 0,nop,wscale 7], length 0
08:19:44.526884 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xdc80), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090292390 ecr 0,nop,wscale 7], length 0
08:19:48.534889 IP6 (hlim 64, next-header TCP (6) payload length: 40)
2a00:c38:102::194.39622 > 2a02:a90:c400:4001::2.443: Flags [S], cksum
0x7192 (incorrect -> 0xd896), seq 788917482, win 28800, options [mss
1440,sackOK,TS val 2090293392 ecr 0,nop,wscale 7], length 0
08:19:53.528648 IP6 (hlim 51, next-header TCP (6) payload length: 20)
2a02:a90:c400:4001::2.443 > 2a00:c38:102::194.39622: Flags [R.], cksum
0x85fa (correct), seq 0, ack 788917483, win 0, length 0

Sometimes, if I try hard enough I get a TCP connection and something
like a TLS1.3 session but no successul TLS negociation (neither with
wget nor with openssl s_client): then it looks like that:

08:27:26.984895 IP6 (flowlabel 0x76030, hlim 64, next-header TCP (6)
payload length: 20) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53984: Flags [R.], cksum 0xcb4a (correct), seq
448778729, ack 2002587856, win 234, length 0
08:27:32.727483 IP6 (flowlabel 0x90338, hlim 64, next-header TCP (6)
payload length: 40) 2001:1a88:2200:505::6.53988 >
2a02:a90:c400:4001::2.443: Flags [S], cksum 0x9a58 (incorrect ->
0x3075), seq 3336725868, win 64800, options [mss 1440,sackOK,TS val
1531978773 ecr 0,nop,wscale 7], length 0
08:27:32.727864 IP6 (flowlabel 0x53256, hlim 64, next-header TCP (6)
payload length: 32) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53988: Flags [S.], cksum 0x6587 (correct), seq
83163391, ack 3336725869, win 28800, options [mss
1440,nop,nop,sackOK,nop,wscale 7], length 0
08:27:32.727910 IP6 (flowlabel 0x90338, hlim 64, next-header TCP (6)
payload length: 20) 2001:1a88:2200:505::6.53988 >
2a02:a90:c400:4001::2.443: Flags [.], cksum 0x9a44 (incorrect ->
0x14cb), seq 1, ack 1, win 507, length 0
08:27:32.728373 IP6 (flowlabel 0x90338, hlim 64, next-header TCP (6)
payload length: 337) 2001:1a88:2200:505::6.53988 >
2a02:a90:c400:4001::2.443: Flags [P.], cksum 0x9b81 (incorrect ->
0x4bc2), seq 1:318, ack 1, win 507, length 317
08:27:32.728556 IP6 (flowlabel 0x53256, hlim 64, next-header TCP (6)
payload length: 20) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53988: Flags [.], cksum 0x149f (correct), seq 1,
ack 318, win 234, length 0
08:27:44.732866 IP6 (flowlabel 0x53256, hlim 64, next-header TCP (6)
payload length: 20) 2a02:a90:c400:4001::2.443 >
2001:1a88:2200:505::6.53988: Flags [R.], cksum 0x149b (correct), seq 1,
ack 318, win 234, length 0

I'm by no means a tcpdump expert:

Those incorrect checksums: are my systems generating incorrect checksums
or is it the swisscom side? It seems weird that different systems with
different OS at different customers would all start making wrong tcp
checksums.


Best Regards

Jean-Pierre

-- 
HILOTEC Engineering + Consulting AG - Langnau im Emmental
IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
Tel: +41 34 408 01 00 - https://www.hilotec.com/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog