Hello,
> The pseudo-header is 16 bytes long; the 2 bytes at an offset of 14 from
> the beginning of the header are a big-endian number which must have the
> value 0x0030, the first 2 bytes of the header are a big-endian number
> that gives an indication of the direction on which the packet is going,
> and the byte at an offset of 6 from the beginning of the header is a
> value that combines with the previous value to indicate whether this is
> a user-to-network or network-to-user packet.
> Use a direction value of 4, and:
> for user-to-network packets, give the byte at an offset of 6 a value of 0;
This would be our addition to the packet,
00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 30
> for network-to-user packets, give the byte at an offset of 6 a value of 1.
00 04 00 00 00 01 00 00 00 00 00 00 00 00 00 30
> You might either have to change your hardware or your driver in order to
> get it to add those extra 16 bytes at the beginning of each frame.
I think we can do it in our read mechanism muwis_read(), for now.
> NOTE: as I indicated in my reply on tcpdump-workers, if you use DLT_LAPD
> without any extra pseudo-header, the LAPD dissector won't know whether a
> frame is user-to-network or network-to-user; if that's a problem, you'll
> have to either use
DLT_LINUX_LAPD and the pseudo-header described above,
> or will have to create your own pseudo-header and ask for a new
> DLT_LAPD_PHDR DLT_ value (DO NOT use DLT_LAPD with a pseudo-header!).
If above works fine we will not use DLT_LAPD