s***@telus.net
6 years ago
The attached tcpdump traces are from armv7 and amd64 systems. The problem
on the armv7 system is very reproducible even though the pypi.io site uses
different hosts at random.
It has been many years since I analysed tcp traces and then it was with
wireshark and so my abilities are lacking. However I am suspicious about
the sequence of packets:
21:49:47.217013 op1bsdtest.graf.lan.39119 > 151.101.64.223.https: S
891608003:891608003(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale
6,nop,nop,timestamp 3208818117 0> (DF)
21:49:47.226246 151.101.64.223.https > op1bsdtest.graf.lan.39119: S
3712909619:3712909619(0) ack 891608004 win 28960 <mss 1460,sackOK,timestamp
447678784 3208818117,nop,wscale 9> (DF)
21:49:47.226339 op1bsdtest.graf.lan.39119 > 151.101.64.223.https: . ack 1
win 256 <nop,nop,timestamp 3208818117 447678784> (DF)
21:49:47.312947 op1bsdtest.graf.lan.39119 > 151.101.64.223.https: P
1:210(209) ack 1 win 256 <nop,nop,timestamp 3208818117 447678784> (DF)
21:49:48.254031 151.101.64.223.https > op1bsdtest.graf.lan.39119: S
3712909619:3712909619(0) ack 891608004 win 28960 <mss 1460,sackOK,timestamp
44767904
It looks like far end missed an ack from the arm system.
-----Original Message-----
From: Mark Kettenis <***@xs4all.nl>
Sent: November 6, 2018 11:19 AM
To: ***@telus.net
Cc: ***@spacehopper.org; ***@openbsd.org
Subject: Re: fetch problem with //pypi.io/packages/source/
> From: <***@telus.net>
> Date: Tue, 6 Nov 2018 10:50:20 -0800
>
> Both system are on the same network, hub, router etc. The amd system
> is on Virtualbox on my PC and the arm system is an orangepi one.
>
> >From the arm system:
>
> op1bsdsnap1102#
> op1bsdsnap1102# ftp -d -o /dev/null https://pypi.io/ host pypi.io,
> port https, path , save as /dev/null, auth none.
> Trying 151.101.0.223...
> Requesting https://pypi.io/
I can reproduce this on my Allwinner A20 system (Banana Pi) but on on NXP
i.MX6 (Cubox-i4). That suggests this is a network driver bug.
However, my device is using dwge(4), whereas yours is using dwxe(4) isn't
it? It isn't inconceivable that both drivers have the same bug though,
since the hardware is very similar.
on the armv7 system is very reproducible even though the pypi.io site uses
different hosts at random.
It has been many years since I analysed tcp traces and then it was with
wireshark and so my abilities are lacking. However I am suspicious about
the sequence of packets:
21:49:47.217013 op1bsdtest.graf.lan.39119 > 151.101.64.223.https: S
891608003:891608003(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale
6,nop,nop,timestamp 3208818117 0> (DF)
21:49:47.226246 151.101.64.223.https > op1bsdtest.graf.lan.39119: S
3712909619:3712909619(0) ack 891608004 win 28960 <mss 1460,sackOK,timestamp
447678784 3208818117,nop,wscale 9> (DF)
21:49:47.226339 op1bsdtest.graf.lan.39119 > 151.101.64.223.https: . ack 1
win 256 <nop,nop,timestamp 3208818117 447678784> (DF)
21:49:47.312947 op1bsdtest.graf.lan.39119 > 151.101.64.223.https: P
1:210(209) ack 1 win 256 <nop,nop,timestamp 3208818117 447678784> (DF)
21:49:48.254031 151.101.64.223.https > op1bsdtest.graf.lan.39119: S
3712909619:3712909619(0) ack 891608004 win 28960 <mss 1460,sackOK,timestamp
44767904
It looks like far end missed an ack from the arm system.
-----Original Message-----
From: Mark Kettenis <***@xs4all.nl>
Sent: November 6, 2018 11:19 AM
To: ***@telus.net
Cc: ***@spacehopper.org; ***@openbsd.org
Subject: Re: fetch problem with //pypi.io/packages/source/
> From: <***@telus.net>
> Date: Tue, 6 Nov 2018 10:50:20 -0800
>
> Both system are on the same network, hub, router etc. The amd system
> is on Virtualbox on my PC and the arm system is an orangepi one.
>
> >From the arm system:
>
> op1bsdsnap1102#
> op1bsdsnap1102# ftp -d -o /dev/null https://pypi.io/ host pypi.io,
> port https, path , save as /dev/null, auth none.
> Trying 151.101.0.223...
> Requesting https://pypi.io/
I can reproduce this on my Allwinner A20 system (Banana Pi) but on on NXP
i.MX6 (Cubox-i4). That suggests this is a network driver bug.
However, my device is using dwge(4), whereas yours is using dwxe(4) isn't
it? It isn't inconceivable that both drivers have the same bug though,
since the hardware is very similar.