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