https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4720
--- Comment #2 from oli <oliver@xxxxxxxxxxxxxxxxx> 2010-04-29 02:21:08 PDT ---
(In reply to comment #1)
> It looks like the same old host order/network order issue.
> Wireshark looks at the protocol in network order. If the sender is Little
> Endian this could be the cause. I could not find any mention of the transfer
> order in the referenced web page or how this could be determined from the
> transmission.
The example code and executables that are available from the referenced
web-page are all designed for Win32 and use little-endian byte order. The
application we use implements this too, and is able to communicate with a
number of PLCs that natively run EGD.
You'll see in the example code provided that the timestamp field (and while
only seconds since epoch is used and nano is set to 0) is NOT converted to
big-endian and is left with the host byte order. I guess Wireshark simply isn't
doing a ntohl or equivalent on the time fields - and do excuse my ignorance on
how Wireshark actually does it, I haven't looked at any sources for it.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.