On Feb 4, 2011, at 12:25 AM, M.Baris Demiray wrote: > In fact this is not what STANAG 5066 Annex H "Implementation Guide and > Notes" section suggests. According to this section and the tests held > by DRA (Defence Research Agency), > > 1) The throughput is not strongly sensitive to frame size > 2) 200 bytes is a good 'compromise' selection for frame size > > Besides, STANAG 5066 has the ability of doing DRC (Data Rate Change) > in accordance with SNR values so what is suggested by that white > paper, I think, is not applicable.
That's somewhat of an implementation detail that shouldn't affect code that tries to dissect those packets. > Precisely. Yet may be a little clarification is needed. You might have > noticed that in my first e-mail I mentioned about DTS (Data Transfer > Sublayer) and that one of our dissector methods has the name > dissect_s5066dts() but now we are talking about MAC layer and all this > may look like a confusion but it is not. As explained in Isode white > paper there are three versions of STANAG 5066. MAC (Medium Access > Control) layer was introduced in Edition 2 (which was later renamed as > Edition 3) and designated to manage HF modem interface that DTS was > designated to do the same before. So is there a publicly-available specification that documents what the packets using this link-layer type look like?- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
