23 Nov
2010
23 Nov
'10
11:32 p.m.
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.
24 Nov
24 Nov
1:50 p.m.
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.
1:55 p.m.
On 24.11.2010 13:50, Patrick McHardy wrote:
On 23.11.2010 23:32, Erik Tews wrote:
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.
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.
2:30 p.m.
On 24.11.2010 14:12, Erik Tews wrote:
Am Mittwoch, den 24.11.2010, 13:50 +0100 schrieb
Patrick McHardy:
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'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.
2:34 p.m.
On 24.11.2010 14:30, Patrick McHardy wrote:
On 24.11.2010 14:12, Erik Tews wrote:
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, 13:50 +0100 schrieb
Patrick McHardy:
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'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.
2:42 p.m.
Am Mittwoch, den 24.11.2010, 14:34 +0100 schrieb Patrick McHardy:
On 24.11.2010 14:30, Patrick McHardy wrote:
Sorry for that, I still had an old version of wireshark installed.
On 24.11.2010 14:12, Erik Tews wrote:
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, 13:50 +0100 schrieb
Patrick McHardy:
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'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.
5392
days inactive
5393
days old
6 comments
2 participants
participants (2)
-
Erik Tews -
Patrick McHardy