I'm on a Windows machine and I want to run a checksum on the MySQL distribution I just got. It looks like there are products to download, an unsupported Microsoft tool, and probably other options. I'm wondering if there is a consensus for the best tool to use. This may be a really easy question, I've just never run a checksum routine before.
for sure the certutil is the best approach but there's a chance to hit windows xp/2003 machine without certutil command.There makecab command can be used which has its own hash algorithm - here the fileinf.bat which will output some info about the file including the checksum.
Update: I had also checked Is there a built-in checksum utility on Windows 7?, however, that's an old question and does not specifically asks for CRC-32 and Windows 10 may have support for it now. That's why asking this.
TheCheckSumMappedFile function computes a new checksum for the file and returns it in the CheckSum parameter. This function is used by any application that creates or modifies an executable image. Checksums are required for kernel-mode drivers and some system DLLs. The linker computes the original checksum at link time, if you use the appropriate linker switch. For more details, see your linker documentation.
I have a checksum problem on my computer and I know this because I can see it using wireshark. The problem is it only happens when I use Win7 or Vista Business and not with XP pro. I have caputure files and would like for someone to look at them. At first I thought it was my nic and still not sure that its not the nic driver or something related to IPv6. Anyway is there someway to upload files so that anyone can look at them? Am I not seeing a button? thank, Morris the Pat
It sounds like classic checksum offloading to me. I assume those packets are showing up with a black background and red foreground in Wireshark. Let's try this... select View > Coloring Rules, then select Checksum Errors and click Disable. Now... are you seeing any other traffic with the black background/red foreground? Select Analyze > Expert Info Composite. Do you have anything under the Warnings, Notes or Errors section?
Checksum offloading is not an error - it's a feature - seriously though - it just takes the processing requirements away from the stack and puts it on the NIC. Loads of systems ship with checksum offloading enabled.
it's a little bit unclear to me where you've captured the data. Normaly I would agree to Bill that if you've done the trace on the host itself, it might that the OS/Driver uses a feature which is called checksum offloading. If you've done the trace on a mirror or span port of a switch, than I agree, you shouldn't see the checksum errors. In regards to the Ip address you've mentioned it looks that you use private IPs which are natted on the router to your provider. It's quit normal that you also get traffic back, espacially if you use TCP as mentioned. So you'll see also packets flowing in your direction, so your IP is the destination. If I got something wrong, upload a trace and I can have a look to it. May this clarifies things.
I would bet that the NIC is fine and also the driver. The problem what I was thinking about is, that the OS is preparing the outgoing packet/frame. But it leaves the computing intensive thing (calculating the checksum) for the NIC. This is called checksum offloading. Since Wireshark can't capture the packet anymore while it is already pushed to the NIC you have most likely a wrong checksum (random memory values). To verify if you really have a problem, start a trace surf to a page, e.g. www.google.com, than stop the trace. If you see than in the Wireshark main window persistant restransmissions, you may have a problem with your NIC/Driver or your connection to the Internet is bad. If you don't see retransmissions, your NIC does checksum offloading. On some cards you can disable this is under the driver settings, if you really want to get rid of the errors which are most likely no errors. If you can't analyse the trace, upload it somewhere and I'll have a look.
The following is a demonstration showing how a checksum function makes it easy to determine if a file is corrupted or has been altered. Even the slightest error or alteration of a file will result in a radically different checksum:
Assume we are checking Ubuntu 20.04 (ubuntu-20.04-desktop-amd64.iso). You would click the link corresponding to "Ubuntu", then "20.04" (or "Focal"). Then you would open the file SHA256SUMS (or whichever checksum algorithm you are using), Now you can see file names with their associated checksums.
Audacity records in lossless PCM, so you will have to create the checksum after MP3 export from Audacity. There are lots of standalone utilities to do this and some utilities like hex editors include checksum tools.
Gale
certutil -hashfile [path\]filename or to get the md5, just add that as an argument: certutil -hashfile [path\]filename MD5 The tool is built into Windows 7 and above, and Server 2008 and above (at least). Tools like it are included in other OS's, but I'm sharing the above for Windows users. Regardless of what OS you use, for more on why knowing the checksum can be useful (and why comparing file sizes instead may not be enough), and especially with regard to some interesting info about installers for CF2016 and CF11, do read on. Why knowing the checksum is valuable There are at least a couple of uses of knowing/finding the MD5 or SHA-1 checksum for a file. (It's basically a hashing of the file contents into a small string that can be used to determine whether a given file shares the checksum with another file.) You may have noticed that web sites often will offer the checksum value of a file you're about to download, with the intent that you could check that after downloading it--to make sure you got the file they intended you to get. It's been my observation that most folks never bother, but at least now if you want to (but didn't know how, on Windows), you can. (Such tools exist for other OS's, of course. I leave that as an exercise for the interested reader.) Another reason knowing how to easily get the checksum can be when you are wondering if an installer you have is the same one that someone else says they have or used (see below for a real example of such confusion). The file the other person has may have the same name (and could even have the same date and file size) and yet NOT be identical. Getting the checksum is the way to know. (Of course, if you had both files you could do a compare, but this is typically still faster.) Why this can be helpful, especially with CF installers But this can be especially helpful with ColdFusion installers, for a number of reasons. I was helping two different folks today with questions about their CF11 and CF2016 installers (because in both cases, there were different installers over time, even for the same version and OS and bit-level), and it's what prompted me to share that info above with them, and now to create this post. For instance, did you know that with CF2016, there have been 3 installers? The original installer (in early 2016) included the API Manager (which made it a huge 1g plus!, and it did not happen to work yet for Windows 10/Server 2016). Then in Dec 2016, a new installer came out (for all OS's) where they thankfully removed the API Manager, bringing it down to several hundred meg (still to large for some tastes, but that's not the point of this post). Then finally in Apr 2017 yet another installer (for Windows only) was released which DID add support for Windows 10 and Server 2016. So when you are installing CF, it would help to know which installer is which. The names are all the same (for a given version on a given OS and bit level.) Of course, Adobe would typically just put the latest one on their site, but people often had downloaded it in the past and were then using it later, and didn't realize it was not "the same". Or I help people often who install ColdFusion on a new machine using an installer they had used on a previous machine, some years ago. And note that there were different CF11 installers over time, also. One had mistakenly turned on session persistence, for instance, which was corrected by a new installer in Jan 2015. And that blog post about the mistaken CF11 installer update indicates that it was released in Dec 2014, as a replacement of the original CF11 installer from early 2014. It had added update 3, among other things, and in fact these new installers will also come with the latest available ColdFusion and JVM update. That's another reason to know which installer you are using. (Sad that it's been potentially confusing, yes.) Finally, no, Adobe no longer offers the installers for CF2016 or before on their site, now that CF2018 has come out. For those, see the CFMLRepo site, which offers installers back to CF 1.5! BTW, while as of the original writing of this post, it did not have that latest CF2016 installer from Apr 2017 (for Windows 64-bit supporting Windows 10 and Server 2016), I since got it uploaded there. Getting the checksum So again, here's how to get the md5 checksum for that latest CF16 64-bit windows installer I had: certutil -hashfile ColdFusion_2016_WWEJ_win64.exe MD5 In my case, that command above reported: MD5 hash of ColdFusion_2016_WWEJ_win64.exe: bdff136f3aee0f051f7c0818acef1711 CertUtil: -hashfile command completed successfully. Again this is the version of the CF2016 installer for Windows 64-bit which WAS able to install on Windows 10 and Server 2016. If you're doing the check in the same directory as the file, then you can leave off the path, obviously. Also, in some versions of Windows, that final arg (for the kind of hash algorithm) is case-sensitive, so use a capitalized value for maximum reliability (the argument to force a SHA-1 hash would be SHA1, though again that's the default). Use certutil -hashfile /? to see more help and other hash algorithms supported. (For my Windows 10 Pro, the values were MD2, MD4, MD5, SHA1, SHA256, SHA384, and SHA512.) (If somehow this tool doesn't work for you, there are many available free tools you can find to calculate checksums and CRCs, for all operating systems.) Hope all that's helpful. For more content like this from Charlie Arehart: