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@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
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
