Le 23 nov. 2017 �� 14:49, Norbert Hartl <norbert@hartl.name> a ��crit :

If you are not confident about the diagnosis that's fine. But then it would be cool to come up with a better one

Sorry but I do not have a better diagnostic than yours today.

and not giving that "works for me ��.

This sentence was just there to add the fact that it is not broken for all people / location. It adds information to help debugging.

It does not mean that, because it works for us, we do not investigate or try to find a solution.

Yesterday, I set up a new file server at Inria to replace files.pharo.org (at least to test if it is better) but I��m still waiting that the network unit open the port 80 to the world ��

Today, I will probably set up a server outside Inria if I have the agreement to do it.

That is not an explanation. Because your assumption would be that externally and internally you use the same system and transport ways. And that is most likely not true.
Just try to find an explanation. Here we go:

- If I download a zip file from files.pharo.org I open a TCP connection from my laptop to files.pharo.org
- TCP has a checksum in the header that is used to check the integrity of each transferred package
- So I can assume that this packet of the one connection was not tampered
- If it counts for a single packet it counts for the whole file
- With all my assumption I can state that I get exactly what the files.pharo.org is sending me

Agree

So what are the possibilities it fails?

- Either the stack beneath hands out the data to the TCP stack delivers corrupt data. That could be the filesystem hence my thought
- Or there is no single connection between my laptop and files.pharo.org. In that case the data would flow over a proxy. But even if I have two connections and for each the integrity check counts then what I said for one connection counts for two and more as well
- If we really decline beliving the filesystem fails (that is less likely if it works inside of inria)
- Is there anything left? Yes, if the proxy modifies the data you can have data integrity on the first connection, then a program that deliberately changes the content and transfers that integer again over the second connection. So it can be broken on the other end.

If we then look at the file we might recognize that it has the ending .zip and this is the file type that transfers most viruses over the net. So we even can imagine what kind of proxy that might be, let's call it a virus checker. That is what I would do in order to narrow the problem.

Thanks for trying to investigate.

At Inria, we have indeed some boxes dedicated to filter network traffic and eliminate spam, viruses. I��m not sure it is used for the outgoing traffic but it is a potential source of problem. I will check with network unit.

By the way, is there a way to have reproducible bad CRC?