Re: fetch problem with //pypi.io/packages/source/

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: fetch problem with //pypi.io/packages/source/

s_graf
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 <[hidden email]>
Sent: November 6, 2018 11:19 AM
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: fetch problem with //pypi.io/packages/source/

> From: <[hidden email]>
> 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.

from armv7.txt (3K) Download Attachment
from amd64.txt (10K) Download Attachment