git pull hangs

[Richard Kimberly Heck]

On 10/27/20 10:44 AM, Marco Morandini wrote:
>> The git server is run by Open Source Labs at Ohio State University. It
>> would be surprising if you were blacklisted there. Have you checked with
>> your IT folks about whether they are prohibiting some traffic?
>
> Apologize for bothering you again about this,
> but we really need an help or a suggestion
> from someone else from the other side of the wall,
> since here we have exhausted the tests we can think of.
>
> The status is as this:
>
> - lyx's git uses the git protocol (port 9418)
> - we can reliably connect to other git servers that use the same port 
> and protocol
>   (e.g.
>    git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>    works flaslessly)
> - lyx is not blacklistd on our side
> - telnetting to git.lyx.org on port 9418 always works
> - we tried, without success, with different operating systems and 
> different git versions
> - the client git log shows a successfull connection to the server:
>
> marco at spark:~> git clone --verbose git://git.lyx.org/lyx
> Cloning into 'lyx'...
> Looking up git.lyx.org ... done.
> Connecting to git.lyx.org (port 9418) ... 140.211.9.84 done.
>
> - what we can observe by sniffing the network traffic is that the 
> tcp-ip connections
>   do works (we correctly receive tcp packets with ACK from server)
> - the last packet that is sent from the client uses the git protocol 
> asking for some repository metadata (or
>   header?). After this the server, after a few seconds (say 20 or30), 
> sends a connection reset
>   (a tcp packet with a reset flag).
>   i.e. after
>
> CLIENT: git-upload-pack /lyxhost=git.lyx.org
> SERVER sends TCP packet with ACK flag
>     we see nothing till the reset
>
>
> What really gets us crazy is that there is a single internal ip from 
> which the connection works with the lyx git server.
> For that working ip after
>
> CLIENT: git-upload-pack /lyxhost=git.lyx.org
> SERVER sends TCP packet with ACK flag
>
> we immediately get a second packet from the server (git protocol) with
>
> 009bb7f632ca1c624e0c81d73d0a03b7d5f8154ab9e5 HEAD multi_ack thin-pack 
> side-band side-band-64k ofs-delta shallow no-progress include-tag 
> multi_ack_detailed
>
> and, after this packets fly back and forth
>
> Assigning that internal ip to different machines (be them 
> windows-based or linux-based) allows them to fetch
> the repository. The nat is the same for the working and not-working 
> internal systems
> (131.175.154.248 , i.e. nat-staff.aero.polimi.it ). However, our 
> network guys are unable to spot any
> difference between the non-working internal addresses and the only one 
> tat works.
>
> It seems that the last packet is somehow malformed, and that the 
> server timeouts.
>
> And now the questions:
>
> would it be possible to get a log from the server on your side?
> Or could you give a look?
> On our side we can make whatever test you may ask for.

I'd be happy to try to help. What logs would be useful, do you think?

Riki