Hi
I spotted two small problems with libpcap:
* Preables for received PP frames are missing, the dedected.org tools used to include the preamble as well. This can easily be fixed by adding a default preamble if the kernel doesn't report the preamble to the userspace. * The slottime wraps around at 2^12 and not at 2^11 as it used to wrap around with the dedected.org tools. I am not sure about the best solution here, one could also use the full 16 bits for the time which are available in the header.
On 23.11.2010 23:32, Erik Tews wrote:
Hi
I spotted two small problems with libpcap:
* Preables for received PP frames are missing, the dedected.org tools used to include the preamble as well. This can easily be fixed by adding a default preamble if the kernel doesn't report the preamble to the userspace.
I guess the kernel should report it, at least with double simplex bearers the sender can't be determined based on the slot number.
* The slottime wraps around at 2^12 and not at 2^11 as it used to wrap around with the dedected.org tools. I am not sure about the best solution here, one could also use the full 16 bits for the time which are available in the header.
I'm not sure what you're referring to here. The slot numbers are in the range of 0-23.
Generally I think the header format should be revamped:
- we don't need the fake ethernet addresses - the preamble should use 5 bytes for the case of a prolonged preamble - the RSSI shouldn't use the raw COA values but defined units - the multiframe number should be added - the RF-band and/or specific frequency should be added. Using the RF-band is probably the more flexible way. - drift for received packets could be added
additionally we could optionally ignore S-field errors in the driver and indicate them in the frame header.
The easiest way to make these changes is probably to add a new link type for the new header and have wireshark etc. deal with that.
On 24.11.2010 13:50, Patrick McHardy wrote:
On 23.11.2010 23:32, Erik Tews wrote:
Hi
I spotted two small problems with libpcap:
* Preables for received PP frames are missing, the dedected.org tools used to include the preamble as well. This can easily be fixed by adding a default preamble if the kernel doesn't report the preamble to the userspace.I guess the kernel should report it, at least with double simplex bearers the sender can't be determined based on the slot number.
* The slottime wraps around at 2^12 and not at 2^11 as it used to wrap around with the dedected.org tools. I am not sure about the best solution here, one could also use the full 16 bits for the time which are available in the header.I'm not sure what you're referring to here. The slot numbers are in the range of 0-23.
Generally I think the header format should be revamped:
- we don't need the fake ethernet addresses
- the preamble should use 5 bytes for the case of a prolonged preamble
- the RSSI shouldn't use the raw COA values but defined units
- the multiframe number should be added
- the RF-band and/or specific frequency should be added. Using the RF-band is probably the more flexible way.
- drift for received packets could be added
One more thing - for good measure we should also somehow indicate whether/which half slots are used, the slot number alone is not enough for that.
additionally we could optionally ignore S-field errors in the driver and indicate them in the frame header.
The easiest way to make these changes is probably to add a new link type for the new header and have wireshark etc. deal with that.
On 24.11.2010 14:12, Erik Tews wrote:
Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb Patrick McHardy:
I'm not sure what you're referring to here. The slot numbers are in the range of 0-23.
Thats the Slot-Time, bytes 18 and 19, they used to be in range 0-2047 if I am not mistaken, now they are in range 0-4095.
Still not sure what this would indicate. I see nothing of this sort in the coa_syncsniff.c code, byte 18 is 0, byte 19 contains the RSSI.
On 24.11.2010 14:30, Patrick McHardy wrote:
On 24.11.2010 14:12, Erik Tews wrote:
Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb Patrick McHardy:
I'm not sure what you're referring to here. The slot numbers are in the range of 0-23.
Thats the Slot-Time, bytes 18 and 19, they used to be in range 0-2047 if I am not mistaken, now they are in range 0-4095.
Still not sure what this would indicate. I see nothing of this sort in the coa_syncsniff.c code, byte 18 is 0, byte 19 contains the RSSI.
I see what you mean - it's the slot number, but in network byte order. The range is 0-23.
Am Mittwoch, den 24.11.2010, 14:34 +0100 schrieb Patrick McHardy:
On 24.11.2010 14:30, Patrick McHardy wrote:
On 24.11.2010 14:12, Erik Tews wrote:
Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb Patrick McHardy:
I'm not sure what you're referring to here. The slot numbers are in the range of 0-23.
Thats the Slot-Time, bytes 18 and 19, they used to be in range 0-2047 if I am not mistaken, now they are in range 0-4095.
Still not sure what this would indicate. I see nothing of this sort in the coa_syncsniff.c code, byte 18 is 0, byte 19 contains the RSSI.
I see what you mean - it's the slot number, but in network byte order. The range is 0-23.
Sorry for that, I still had an old version of wireshark installed.
-
Erik Tews -
Patrick McHardy