You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an interesting question. I think something that may help answer this question, is laying out a few scenarios of why you would want to compare two packets or two headers for equality.
If we are talking about tracing a conversation across multiple hops, then selected parts of the headers would be the way to go. If we are trying to see if a packet has been altered, I would think the entire packet start-to-finish would need to be perfect match, including CRC if available.
Since there are several scenarios with different goals for equality comparison, would it make since to expose methods that offer these variations in comparisons? Maybe through traits?
Until the dissector matures, I would suggest that equality be defined as a comparison of a vector of slices.
Case 1 would be self[..] == other[..]
Case 2 would be self[..14] == other[..14]
Case 3 would be vec! (self[13..14], self[15..16]) == vec! (other[13..14], other[15..16])
Where is the ip header, for example? The location is dependent on the previous layers. Is it from an untagged packet, a tagged packet, a q-in-q packet, a gre packet, ipip? Is the first ip header of self being compared to the first or second ip header of other?
Is it proper to simply compare two structs, or should that be delegated to a dissector that can properly determine layers?
I think the dissectors themselves should determine the layers. There are instances tho, where a layer later in the dissector chain needs acces to a ealier layer.
We need to decide what it means for an
XHeader
orXPacket
to be equal. There are three possibilities:The text was updated successfully, but these errors were encountered: