tcpdump mailing list archives
Re: DLT for RFtap
From: Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Sat, 12 Sep 2020 14:30:57 +0100
--- Begin Message --- From: Denis Ovsienko <denis () ovsienko info>
Date: Sat, 12 Sep 2020 14:30:57 +0100
On Fri, 11 Sep 2020 16:59:19 +0200 George Hopkins via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:Hello A few years ago there was a request to assign a DLT for RFtap [1]: https://lists.sandelman.ca/pipermail/tcpdump-workers/2016-August/000619.html Somehow some of the messages weren't kept by the archive. As IThere are four messages in the archive page above, which is the same as what I see in the messages the mailing list sent me at the time, so it looks like whatever had made it to the list is there. From the last message contents it looks like some of the discussion could be off-list.understand it, it would only be possible to assign a DLT if the RFtap is tied to an actual link-layer type (e.g. RFtap followed by AX25). Does this assumption still hold? If so, is there an other, recommended way to store such information?Guy had made a point that a variable-structure link level header is a bad idea, that was likely based on his prior experience with other DLTs. I do not have enough experience in this specific area to elaborate on that, but my own observations in similar areas tend to be such that when an encoding allows a human to make a mistake, mistakes will happen, if not in one implementation then in another. So it would make sense to look into this with attention if the goal is to produce a good design. -- Denis Ovsienko
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- DLT for RFtap George Hopkins via tcpdump-workers (Sep 11)
- Message not available
- Re: DLT for RFtap George Hopkins via tcpdump-workers (Sep 12)
- Message not available
- Re: DLT for RFtap Denis Ovsienko via tcpdump-workers (Sep 12)