I have observed this before also. A packet gets lost. You can also visually observe this a different way. Over a ssh session, type ls in a large directory. On all armv7 systems have a "pause" at the end, getting caught up.
> 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 <[email protected]> > Sent: November 6, 2018 11:19 AM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Re: fetch problem with //pypi.io/packages/source/ > > > From: <[email protected]> > > 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.
