check FCS ethernet frame CRC-32 online tools - frame

I'm trying to check the FCS of an ethernet frame thanks to tools on different website.
I first used this website:
http://depa.usst.edu.cn/chenjq/www2/software/crc/CRC_Javascript/CRCcalculation.htm and find the next FCS : 0xD4C3C62F (the frame below)
Then, I tried this one : http://www.scadacore.com/field-applications/programming-calculators/online-checksum-calculator/ and I found the correct CRC : 0x7AD56BB3 but nothing of the different kind of CRC-32 (normal, reversed...) correspond to the CRC find on the first website.
Is there any link between algorithms?
Thank you!
Here is the hexadecimal frame (no start of frame) :
000AE6F005A3001234567890080045000030B3FE0000801172BA0A0000030A00000204000400001C894D000102030405060708090A0B0C0D0E0F10111213

Beware of online CRC calculators.
The Ethernet CRC of your string is actually 0xb36bd57a. It is stored in reverse order in the stream, which is why you wrote it incorrectly as 0x7AD56BB3.
There are many CRC definitions, including many 32-bit CRC definitions. See the RevEng catalog for examples. The one you want happens to be called "CRC-32", with this definition.
The "CCITT-32" (a name I have not seen before) being calculated in your first link is some other definition. It does not even appear in the RevEng catalog.

A more descriptive and clear update to #Mark Adler's answer (I am new here so I can't edit or comment)
The CRC you are searching for is called CRC-32/ISO-HDLC.
You can check the following online calculator and check the one named "CRC-32":
https://crccalc.com/
Each CRC32 algorithm has its own parameters for its generation, like polynomial, init,...etc
The IEEE802.3 standard defined the CRC32 algorithm parameters for the FCS field to have the polynomial(0x04c11db7), init/xorIn(0xffffffff), xorout(0xffffffff)

Related

How to decide when to reflect or XOR CRC data?

I found multiple optimal CRC-32 polynomials on the CRC Polynomal Zoo site of Philip Koopman. Now I want to generate a CRC lookup table for one of the polynomials, by using the software pycrc.
To generate a CRC lookup table you have to provide the following information for the choosen polynomial:
Reflected in (boolean)
Reflected out (boolean)
XOR in (hex value)
XOR out (hex value)
For some polynomials I found the above parameters in a specification (for instance a AUTOSAR specification for the polynomial "F4ACFB13"), but what parameters should I choose if there is no specification for a certain polynomial? The Koopman site doesn't seem to provide the recommended parameters to use.
I already tried to find an explanation how to choose these parameters, but I could only find explanations how to implement these parameters and not how to choose them. Most websites recommend searching for specifications describing "common CRC polynomials", because they provide the optimal parameters.
Generally you are trying to match the CRC used in some existing protocol. In that case you need to do the same thing you did for the AUTOSAR CRC: find the specification for the CRC. Or you need to get several examples of messages and correct CRCs and try to reverse-engineer the CRC parameters.
You can find over a hundred CRC definitions here.
If you are creating your own protocol from scratch, then you can select any polynomial, reflection, initial value, and final exclusive-or you like, as well as any byte order of the CRC in the message. I would recommend that the polynomial be chosen with good properties for your message length from Phil's data, and that the initial value of the CRC register, init, not be zero. (If it is zero, then the CRC of any string of zeros will be the same value, that final exclusive-or, regardless of the length.) Also there is no detriment, and it is more aesthetic to pick the initial value and the final exclusive-or to be equal, so that the CRC of an empty sequence is zero.

writing on rfid-Tag and locking block using CoE with IO-Link Master (ifm al1330)

i have got the following issues.
I want to Read/Write on a Rfid-Tag and lock this block afterwards.
I have the following hardware:
AL1330, IFM Io-link Master https://www.ifm.com/mounting/80284123DE.pdf
DTI513, IFM IO-Link Rfid-REader/Writer https://www.ifm.com/mounting/11458695DE.pdf
Beckhoff, PLC CX5230
Rfid-Tag, ICode Slix, https://www.nxp.com/docs/en/data-sheet/SL2S2002_SL2S2102.pdf
I can read the Uid, can write and Read Data Bytes on the RFID.
I fail to lock the Block afterwards. I tried various ways with CoE Communication.
I divide the Problem into 3 steps:
Step 1:
Craft the CMD responsible for the Lock on the Tag.
This is specified in the responsible Norm
this are the Flags
This leads me for example to this Command
Step2 : Calculating the CRC
-For the CRC in the Norm there is one Example (CRC Iso/IEC 13239)
0x22 0x20 0x01 0x23 0x45 0x67 0x89 0xab 0x04 0xe0 0x0b
this command shall lead to CRC BAE3.
My Oscat Lib Block Basic.CRC_Gen with this Parameter returns this value
Same as http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
With more testing, the crc calucaltions differ, and i do not know why and how,
and which one is correct.
Edit:
- More testing and i recognized, the Oscat Library FB Basic.CRC_Gen
fills any Input, shorter than 4 bytes, with 0x00.
- there should be the workaround, to use addressed commands with the optional Uid.
Step3:
Writing the Command with the appended CRC to Tag via CoE
- i use the Beckhoff FBs to access CoE
I can acces the different IDs with Subids and get Results,
so this works
i found the IO-Acyclic Command, which i think is the right one, to issue commands to
the tag
the docu in the AL1330 shows this
I tried a lot of different stuff, but cannot make it happen.
Problem is, i am not sure, if the CMD is correct or not, the CRC is wrong or how to make the Acyclic Command to work.
I tried for days and found no solution.
So i would be very glad for tips and hints in the right direction.
Thanks
I hope i do not violate any rules

How to access net displacements in pyiron

Using pyiron, I want to calculate the mean square displacement of the ions in my system. How do I see the total displacement (i.e. not folded back by periodic boundary conditions) without dumping very frequently and checking when an atom passes over the boundary and gets wrapped?
Try to compare job['output/generic/unwrapped_positions'][-1] and job.structure.positions+job.output.total_displacements[-1]. If they deliver the same values, it's definitely fine both ways. If not, you can post the relevant lines in your notebook here.
I'd like to add a few comments to Jan's answer:
While job['output/generic/unwrapped_positions'] returns the unwrapped positions parsed from the output files, job.output.total_displacements returns the displacement of atoms calculated from each pair of consecutive snapshots. So if an atom moves more than half the box length in any direction, job.output.total_displacements will give wrong coordinates. Therefore, job['output/generic/unwrapped_positions'] is generally more trustworthy, but it is not available in all the codes (since some codes simply do not provide an output for unwrapped positions).
Moreover, if an interactive job is used, it is possible that job.structure.positions does not return the initial positions, i.e. job.structure.positions+job.output.total_displacements won't be initial positions + displacements.
So, in short, my answer to your question would be rather "Use job['output/generic/unwrapped_positions'] and if it's not available, use job.structure.positions+job.output.total_displacements but be aware of potential problems you might be running into."

How do i reverse engineer a known Cyclic Redundancy Check value?

So I have problem finding the CRC value for a series of commands, I already have the CRC values for some of the commands but I need to figure out how they were calculated. After carefully going over the data stream and attempting to calculate the CRC we cannot get the known CRC value and the calculated one to match. I have never calculated a CRC before but I have read multiple papers on it and it seems easy enough, except for the fact that its not working. The manual I have says the polynomial generator is (x^8 + x^7 + X^2 + X^0) and it gives me a unique non zero value of B1 (hex). The full command is A9E40401 (hex) with a CRC of 1E (hex). The process I am currently using involves converting the data stream from hex into binary, using the LSB first rule, inserting FF(hex) into the command to detect extraneous zeros, adding 00(hex) to the end as a place holder and than performing mod2 division, and than I invert it and apply it to the data stream. Either I'm doing something wrong or I missed a step. I am assuming the polynomial I was provided is correct. Any help would be greatly appreciated.
You can try RevEng, which is for exactly this, to determine the CRC parameters from a set of examples.
Then you can use crcany to generate the code.
I feel like an idiot.
When I calculated my CRC I did every step properly except the very last step where you must perform the LSB first rule and than invert the remainder.
I only performed the LSB first rule (thinking that's what was meant by invert).
So with a remainder of 00011101 I got the wrong CRC value (10111000). when I should have gotten 01000111.

Trying to understand nbits value from stratum protocol

I'm looking at the stratum protocol and I'm having a problem with the nbits value of the mining.notify method. I have trouble calculating it, I assume it's the currency difficulty.
I pull a notify from a dogecoin pool and it returned 1b3cc366 and at the time the difficulty was 1078.52975077.
I'm assuming here that 1b3cc366 should give me 1078.52975077 when converted. But I can't seem to do the conversion right.
I've looked here, here and also tried the .NET function BitConverter.Int64BitsToDouble.
Can someone help me understand what the nbits value signify?
You are right, nbits is current network difficulty.
Difficulty encoding is throughly described here.
Hexadecimal representation like 0x1b3cc366 consists of two parts:
0x1b -- number of bytes in a target
0x3cc366 -- target prefix
This means that valid hash should be less than 0x3cc366000000000000000000000000000000000000000000000000 (it is exactly 0x1b = 27 bytes long).
Floating point representation of difficulty shows how much current target is harder than the one used in the genesis block.
Satoshi decided to use 0x1d00ffff as a difficulty for the genesis block, so the target was
0x00ffff0000000000000000000000000000000000000000000000000000.
And 1078.52975077 is how much current target is greater than the initial one:
$ echo 'ibase=16;FFFF0000000000000000000000000000000000000000000000000000 / 3CC366000000000000000000000000000000000000000000000000' | bc -l
1078.52975077482646448605