git pull hangs

[Marco Morandini]

> 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.

Thank you for your attention,

Marco & Marco