https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4299
Guy Harris <guy@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Platform|Other |All
OS/Version|Linux (other) |All
--- Comment #10 from Guy Harris <guy@xxxxxxxxxxxx> 2009-12-07 11:22:22 PST ---
> ARP Header: I don't know about the details. The value of 280 is widely used in the SocketCAN code. I'll ask the guys about.
Linux uses ARPHRD_ values internally as its network link-layer type values.
Not all of them necessarily correspond to values that actually appear in ARP
packets (in fact, I suspect *most* of them don't correspond to values that
actually appear in ARP packets). Unless ARP is used in CAN, the ARP dissector
shouldn't be modified.
> From the libpcap point of view, there are always 16 bytes captured, cause of the size of struct can_frame. There is no truncation of the packet cause of it's content. Would be possible to do so, but I think libpcap should pass exactly what it receives.
Only if what it receives either corresponds to what's on the wire or to other
relevant data; if the extra data at the end of the packet is just random
padding or zero padding or something such as that, there's not much use in
putting it into the capture. (Why doesn't the SocketCAN code in the kernel
provide packets of the appropriate length, rather than providing fixed-length
packets and a separate length field?)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.