Tag Info

Hot answers tagged

18

There is probably a zillion reasons why one should check the md5sum but a few do come to my mind: Malicious activity - your ISO could have been tampered with on the way from the server The page itself is spoofed (its best to have the md5sums signed as well :) ) Broken download (despite TCP error correction) (check this out) ISO burnt incorrectly And it ...


15

As has been noted by others, there are many possibilities for data corruption where any checksum at the transport layer cannot help, such as corruption happening already before the checksum is calculated at the sending side, a MITM intercepting and modifying the stream (data as well as checksums), corruption happening after validating the checksum at the ...


5

There are several reasons to verify the checksum of a file downloaded via HTTP: Ensuring you received the entire file Some clients, such as Firefox, may treat an interrupted connection as a successful download, leaving you with a truncated file but claiming it downloaded OK Ensuring you received the correct file e.g. a buggy, compromised or malicious ...


5

TCP/IP does guarantee data integrity*. But it does not guarantee that 100% of a file has been downloaded. There can be many reasons why this could happen. For example: It is possible that you can mount an ISO that misses one or two bytes somewhere in the middle. You won't have a problem with it until you need one or two particular files that are corrupt. ...


4

The TCP checksum is only 16 bits. This means that, in the absence of other checksums, one out of every 65536 corrupted packets will be accepted as non-corrupted. If, for example, you were downloading an 8GB DVD image across a noisy link with a 1% corruption rate, you'd expect 81 undetectably-corrupted packets. MD5 is a much larger checksum, at 128 bits. ...


3

There is no problem. This is normal and expected behaviour. The reason for the packet loss is that UDP doesn't have any congestion control. In tcp when congestion control algorithms kick in, it will tell the transmit end to slow down the sending in order to maximise throughput and minimise loss. So this is entirely normal behaviour for UDP actually. UDP ...


1

In general, every machine that acts as a TCP server, especially with short-lived connections (e.g. serving a web site), would benefit. And the higher the connection latency, the higher the benefit as IW10 would reduce the amount of round-trips initially. IW10 would also help faster recovery in case of packet losses in comparison to IW3. The Load Balancer ...


1

Padding with zeroes is the only valid TCP header padding that I know of. (Not with F's. See RFC 793 dated 1981!) It has been this way for a long time. Windows XP did this as well. The only reason why your copy of Windows XP would not be doing this (that I can think of) is because of your NIC drivers. Make sure you're using the best network card drivers.


1

I very strongly suspect that the problem is this line in the qemu host's iptables -t nat -L -n -v: 76 6384 MASQUERADE all -- * * 10.10.15.0/24 !10.10.15.0/24 This is causing original (ie, not return-half) traffic from hadoop2 to driver to be NATted to 10.10.15.1. You could test this hypothesis by exempting just the traffic ...


1

I notice lots of interesting answers but there is a last thing to consider:Two Generals' Problem The two generals problem and the Byzantine Generals problem consider specifically the implications of transferring information reliably through unreliable channels. Checksums are just another layer of "increasing reliability", and one with a very slim chance ...


1

Daniel, Depending on the tool you are using for the ISO Download per say. If it is Say Firefox.. It may show the file download. However you may not have the full ISO intact. If you burn it then try to use it, information may be missing. This happens time to time on different webservers hosting files. It is a good practice to at least compare the file ...



Only top voted, non community-wiki answers of a minimum length are eligible