Windows to Linux and vice-versa
c...@netcom.co.uk
and on Windows from Linux, and some of it works and some of it doesn't.
The Windows box is Windows 7 64-bit, running the standard binary package
of 32-bit Mercurial. The Linux box is a recent 32-bit linux. Both machines
are running Mercurial 1.9.2, both are on the same network, and neither have
firewalls enabled. Each machine can ping the other and mount the other's
exported Samba directories.
With "hg serve" running on the Windows box, viewing http://windows_ip:8000
on the Linux box shows the Mercurial project, ie. acts correctly, and
so does "hg clone http://windows_mac". (I used IPv4 addresses to rule out
name lookup problems).
With "hg serve" running on the Linux box viewing the Mercurial project still
works, but "hg clone" fails with (among other errors) getaddrinfo failed.
Checking the exchange protocol with Wireshark the failing sequence is:
SYN Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_PERM=1
RST,ACK Seq=1 ACK=1 Win=0 Len=0
This challenge/response is repeated three times, and the connection fails.
The successful sequence is:
SYN Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1
SYN,ACK Seq=0 ACK=1 Win=8192 Len=0 MSS=1460 WS=8 SACK_PERM=1
and then the rest of the transfer proceeds normally.
I'm out of my depth debugging the TCP/IP protocol. Does anyone know a
way around this glitch, whatever it is. (I can edit python files, if
there's a solution involving a patch to Mercurial.)
Thanks - Will
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial
Martin Geisler
> I've been trying to access Mercurial archives on Linux from Windows,
> and on Windows from Linux, and some of it works and some of it
> doesn't.
>
> The Windows box is Windows 7 64-bit, running the standard binary
> package of 32-bit Mercurial. The Linux box is a recent 32-bit linux.
> Both machines are running Mercurial 1.9.2, both are on the same
> network, and neither have firewalls enabled. Each machine can ping the
> other and mount the other's exported Samba directories.
Okay, then you have network connectivity. Just for completeness: it's
fine that you mention it, but Mercurial can push/pull between any
combination of CPU architectures.
> With "hg serve" running on the Windows box, viewing
> http://windows_ip:8000 on the Linux box shows the Mercurial project,
> ie. acts correctly, and so does "hg clone http://windows_mac". (I used
> IPv4 addresses to rule out name lookup problems).
>
> With "hg serve" running on the Linux box viewing the Mercurial project
> still works, but "hg clone" fails with (among other errors)
> getaddrinfo failed.
Okay -- it's always a good idea to show us the errors in such a
sitation. Otherwise we'll have to guess what exact command you typed and
what errors you got.
So let me guess... :-) You say you can see the "Mercurial project" from
both machines. By that I assume you see a page like this
that shows the recent commits? What you see it "hgweb", the built-in
webserver started with "hg serve".
If you can see that, then you can also clone the repositories. Use the
exact same URL as you use in your browser. Above, you wrote that you can
see the project at
Listening on port 8000 is the default behavior of "hg serve", so this
sounds good. But then you write that you can clone
That sounds weird -- you should be able to clone http://windows_ip:8000,
but I don't know what windows_mac is? The MAC address of the machine?
In any case -- if you can see hgweb in your browser, then you can also
clone that same URL with the command line client.
--
Martin Geisler
Mercurial links: http://mercurial.ch/
c...@netcom.co.uk
> c...@netcom.co.uk writes:
>
>> I've been trying to access Mercurial archives on Linux from Windows,
>> and on Windows from Linux, and some of it works and some of it
>> doesn't.
>>
>> The Windows box is Windows 7 64-bit, running the standard binary
>> package of 32-bit Mercurial. The Linux box is a recent 32-bit linux.
>> Both machines are running Mercurial 1.9.2, both are on the same
>> network, and neither have firewalls enabled. Each machine can ping the
>> other and mount the other's exported Samba directories.
>
> Okay, then you have network connectivity. Just for completeness: it's
> fine that you mention it, but Mercurial can push/pull between any
> combination of CPU architectures.
>
Yes, I mentioned it because it may be Mercurial's problem, or it may
be a problem with the underlying Python.
>> With "hg serve" running on the Windows box, viewing
>> http://windows_ip:8000 on the Linux box shows the Mercurial project,
>> ie. acts correctly, and so does "hg clone http://windows_mac". (I used
>> IPv4 addresses to rule out name lookup problems).
>>
>> With "hg serve" running on the Linux box viewing the Mercurial project
>> still works, but "hg clone" fails with (among other errors)
>> getaddrinfo failed.
>
> Okay -- it's always a good idea to show us the errors in such a
> sitation. Otherwise we'll have to guess what exact command you typed and
> what errors you got.
>
> So let me guess... :-) You say you can see the "Mercurial project" from
> both machines. By that I assume you see a page like this
>
> http://selenic.com/hg/
>
> that shows the recent commits? What you see it "hgweb", the built-in
> webserver started with "hg serve".
>
Yes, I couldn't recall the name of the page - actually it's formally
known as the log page, it seems.
> If you can see that, then you can also clone the repositories. Use the
> exact same URL as you use in your browser. Above, you wrote that you can
> see the project at
>
> http://windows_ip:8000
>
> Listening on port 8000 is the default behavior of "hg serve", so this
> sounds good. But then you write that you can clone
>
> http://windows_mac
>
> That sounds weird -- you should be able to clone http://windows_ip:8000,
> but I don't know what windows_mac is? The MAC address of the machine?
>
windows_mac is a misprint for windows_ip - sorry.
> In any case -- if you can see hgweb in your browser, then you can also
> clone that same URL with the command line client.
>
Well, no, I can't, and the Wireshark traces show why. What I don't know
is what's causing the SYN/ACK failure in one case, and not in the other,
given that view the log page works in both cases.
Matt Mackall
> Quoting Martin Geisler <m...@lazybytes.net>:
>
> > c...@netcom.co.uk writes:
> >
> >> I've been trying to access Mercurial archives on Linux from Windows,
> >> and on Windows from Linux, and some of it works and some of it
> >> doesn't.
> >>
> >> The Windows box is Windows 7 64-bit, running the standard binary
> >> package of 32-bit Mercurial. The Linux box is a recent 32-bit linux.
> >> Both machines are running Mercurial 1.9.2, both are on the same
> >> network, and neither have firewalls enabled. Each machine can ping the
> >> other and mount the other's exported Samba directories.
> >
> > Okay, then you have network connectivity. Just for completeness: it's
> > fine that you mention it, but Mercurial can push/pull between any
> > combination of CPU architectures.
> >
> Yes, I mentioned it because it may be Mercurial's problem, or it may
> be a problem with the underlying Python.
I can say with confidence that it's neither. Mercurial and Python's
underlying interaction with TCP sockets and resolver libraries is both
extremely generic and time-tested. If the issue isn't at the HTTP or SSL
certificate levels, it's definitely not our problem.
My suspicion is you have something like a personal firewall on your
Windows box that's quietly refusing outgoing connections by 'weird
programs' like Mercurial.
Both your browser and the hg client speak HTTP to the same port on
server. For that to break, something on the client must be
distinguishing between the two before a packet even leaves your box.
(Crucially, you didn't tell us which host was running Wireshark. I
assume it's on the Windows side. My theory is that if you run it on the
Linux side, you'll never see the packets arrive.)
--
Mathematics is the supreme nostalgia of our time.
Scott Palmer
On 2011-09-28, at 4:09 PM, Matt Mackall wrote:
>
> My suspicion is you have something like a personal firewall on your
> Windows box that's quietly refusing outgoing connections by 'weird
> programs' like Mercurial.
>
> Both your browser and the hg client speak HTTP to the same port on
> server. For that to break, something on the client must be
> distinguishing between the two before a packet even leaves your box.
>
> (Crucially, you didn't tell us which host was running Wireshark. I
> assume it's on the Windows side. My theory is that if you run it on the
> Linux side, you'll never see the packets arrive.)
Could it be a proxy server?
Scott
Matt Mackall
> On 2011-09-28, at 4:09 PM, Matt Mackall wrote:
>
> >
> > My suspicion is you have something like a personal firewall on your
> > Windows box that's quietly refusing outgoing connections by 'weird
> > programs' like Mercurial.
> >
> > Both your browser and the hg client speak HTTP to the same port on
> > server. For that to break, something on the client must be
> > distinguishing between the two before a packet even leaves your box.
> >
> > (Crucially, you didn't tell us which host was running Wireshark. I
> > assume it's on the Windows side. My theory is that if you run it on the
> > Linux side, you'll never see the packets arrive.)
>
> Could it be a proxy server?
Not terribly likely, as a proxy would generally not discriminate between
a browser and the hg client (ie based on User-Agent:)
In this case we can already rule that out: TCP SYN packets aren't being
acknowledged, which means the TCP pipe is never opened, which means no
part of the request is actually transmitted, which means that a server
or proxy has no way to distinguish two programs on the same client.
--
Mathematics is the supreme nostalgia of our time.
Matt Schulte
>
> On 2011-09-28, at 4:09 PM, Matt Mackall wrote:
>
>>
>> My suspicion is you have something like a personal firewall on your
>> Windows box that's quietly refusing outgoing connections by 'weird
>> programs' like Mercurial.
>>
>> Both your browser and the hg client speak HTTP to the same port on
>> server. For that to break, something on the client must be
>> distinguishing between the two before a packet even leaves your box.
>>
>> (Crucially, you didn't tell us which host was running Wireshark. I
>> assume it's on the Windows side. My theory is that if you run it on the
>> Linux side, you'll never see the packets arrive.)
Are you actually entering the IP address of the host into the clone
command? Not using the Windows box's net name or anything like that
but specifically:
hg clone http://192.168.1.whatever:8000
or whatever the IP address of the host happens to be?
Matt Schulte
c...@netcom.co.uk
No, Wireshark is on the Linux box. The SYN packets arrive at the Linux
box and are summarily rejected with RST. The Windows setup has the firewall
off, there's no firewall on the router, and the Linux box doesn't have
a firewall (poor Linux box).
And I'm using IP addresses, so it shouldn't be a name resolution problem.
(And in fact both machines know each-others name.)
Hmmm. Scuffling around in the lower levels of Python/TCPIP does not seem
appealing, or productive.
Will
Matt Mackall
> Quoting Matt Mackall <m...@selenic.com>:
>
> > On Wed, 2011-09-28 at 20:55 +0100, c...@netcom.co.uk wrote:
> >
> > My suspicion is you have something like a personal firewall on your
> > Windows box that's quietly refusing outgoing connections by 'weird
> > programs' like Mercurial.
> >
> > Both your browser and the hg client speak HTTP to the same port on
> > server. For that to break, something on the client must be
> > distinguishing between the two before a packet even leaves your box.
> >
> > (Crucially, you didn't tell us which host was running Wireshark. I
> > assume it's on the Windows side. My theory is that if you run it on the
> > Linux side, you'll never see the packets arrive.)
>
> No, Wireshark is on the Linux box. The SYN packets arrive at the Linux
> box and are summarily rejected with RST.
Well that simply doesn't happen if you're talking to a listening port on
a box with no firewall.
Confirm that all of the following match:
a) the port on the hg serve command line
b) the port hg serve claims to be listening at
c) the port the application is listening at according to 'netstat -tnap'
d) the port you try to talk to in your browser
e) the port seen in the Wireshark trace
Also confirm that the -source- IP addresses on both the browser trace
and the hg client trace agree.
And lastly, check that you're not running a firewall on the Linux box
without knowing it by running iptables -L (as root) and confirming that
all of the tables are empty and have a default policy of ACCEPT.
> The Windows setup has the firewall
> off, there's no firewall on the router, and the Linux box doesn't have
> a firewall (poor Linux box).
Every major Linux distribution has shipped a kernel with complete
firewall support since the 90s. Whether it's enabled by default or not
is another story.
> And I'm using IP addresses, so it shouldn't be a name resolution problem.
> (And in fact both machines know each-others name.)
You don't get the getaddrinfo errors you mentioned earlier unless the
resolver libraries are involved (and fail!).
> Hmmm. Scuffling around in the lower levels of Python/TCPIP does not seem
> appealing, or productive.
Again, it's extremely unlikely you've discovered a Mercurial or Python
socket-handling bug. That code is boring and extremely widely used.
Finding a bug here is about as likely as discovering a dinosaur fossil
at the supermarket.
It's a network configuration problem (or possibly a command-line thinko)
local to you.
--
Mathematics is the supreme nostalgia of our time.
c...@netcom.co.uk
> Well that simply doesn't happen if you're talking to a listening port on
> a box with no firewall.
>
> Confirm that all of the following match:
>
> a) the port on the hg serve command line
> b) the port hg serve claims to be listening at
> c) the port the application is listening at according to 'netstat -tnap'
> d) the port you try to talk to in your browser
> e) the port seen in the Wireshark trace
>
> Also confirm that the -source- IP addresses on both the browser trace
> and the hg client trace agree.
>
> And lastly, check that you're not running a firewall on the Linux box
> without knowing it by running iptables -L (as root) and confirming that
> all of the tables are empty and have a default policy of ACCEPT.
>
>> The Windows setup has the firewall
>> off, there's no firewall on the router, and the Linux box doesn't have
>> a firewall (poor Linux box).
>
> Every major Linux distribution has shipped a kernel with complete
> firewall support since the 90s. Whether it's enabled by default or not
> is another story.
>
Thanks for the ideas - I can't get access to a Windows box for another week
or so, but I'll try them then. I'm developing stuff (PyGTK) for Windows on
the Linux box, so I really need the Linux => Windows connection to work.
I've also found some ideas on Google for problems at the Windows end. Since
a couple of Linux LiveDVDs show the same behaviour, I'm tending towards a
Windows glitch of some sort.
Thanks again - Will