Hi folks,
so Lukasz just sent me a little pcap file with some AMS packets in there and my
assumption was correct:
for example in the byte-stream I can see the "flags" being 0x0400 ... However
wireshark read this as unsigned short LE and therefore re-aranged the bytes:
StateFlags: 0x0004
...0 = RESPONSE: Not set
..0. = NO RETURN: Not set
.1.. = ADS COMMAND: Set
0... = SYSTEM COMMAND: Not set
...0 = HIGH PRIORITY COMMAND: Not set
..0. = TIMESTAMP ADDED: Not set
.0.. = UDP COMMAND: Not set
0... = INIT COMMAND: Not set
0... = BROADCAST: Not set
So in above example only one field is true: "ADS COMMAND" ... so if I decode
0x0400 to binary that’s: 0100
So this exactly fits my proposed mspec definition of:
[type 'State'
[simple bit 'initCommand' ]
[simple bit 'updCommand']
[simple bit 'timestampAdded']
[simple bit 'highPriorityCommand' ]
[simple bit 'systemCommand' ]
[simple bit 'adsCommand']
[simple bit 'noReturn' ]
[simple bit 'response' ]
[simple bit 'broadcast' ]
[reserved int 7 '0x0' ]
]
So I strongly object introducing any special endianness "feature" for this (in
this case) ...
we might encounter something where we need it, but for this we don't.
Chris
Am 30.04.20, 23:02 schrieb "Christofer Dutz" :
Hi Lukasz,
I wasn't suggesting to look how WireShark decodes things. Cause I would
assume that they read a short in little endian and then (on the rearranged
bytes) apply some bit checks.
I was more suggesting that you look into the bytes Wireshark shows you and
to check their exact position.
When implementing drivers, I used the Mac's Calculator tool quite often to
see the bits for a given byte value.
In your example I can't see any need for endianness at all ... it's all
just bits and one empty block which forms a full byte together with the first
bit.
As this block doesn't cross any byte boundaries I can't see any problems
with this.
Assuming I understand what you are implying with
[type little endian 'State'
[simple bit 'broadcast' ]
[reserved int 7 '0x0' ]
[simple bit 'initCommand' ]
[simple bit 'updCommand']
[simple bit 'timestampAdded']
[simple bit 'highPriorityCommand' ]
[simple bit 'systemCommand' ]
[simple bit 'adsCommand']
[simple bit 'noReturn' ]
[simple bit 'response' ]
]
Then it should be equal to:
[type 'State'
[simple bit 'initCommand' ]
[simple bit 'updCommand']
[simple bit 'timestampAdded']
[simple bit 'highPriorityCommand' ]
[simple bit 'systemCommand' ]
[simple bit 'adsCommand']
[simple bit 'noReturn' ]
[simple bit 'response' ]
[simple bit 'broadcast' ]
[reserved int 7 '0x0' ]
]
Which also seems to be the exact order how the bits go over the wire ... I
mean ... it doesn't make any sense to put the 7 empty bits in the middle.
Chris
Am 30.04.20, 22:42 schrieb "Łukasz Dywicki" :
Hey Chris and others,
I let this topic to dust and freeze a bit, however I would like to lift
it up again. Since the 0.7 release is now in discussion and ADS is not
ported yet I believe it is reasonable to validate this problem.
As you suggested I've checked wireshark sources to see how they parse
state fragment of AMS header. While I can not read C properly and was
unable to locate actual reading logic, I do see they care about
endianness:
https://github.com/wireshark/wireshark/blob/5cf3fd03f1538b37704d83b6c38b8223f9036108/plugins/epan/ethercat/packet-ams.c#L429
Their frame traversal goes in following order:
- response
- no return
- ads cmd
- system cmd
- high priority
- timestamp add
- udp
- init cmd
- broadcast
When I've tried to model mspec with respect to little endian order, I
end up with following field order:
- init cmd
- udp
- timestamp add
- high priority
- system cmd
- ads cmd
-
