You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been staring a lot at APRS-IS packet logs lately, and it would seem that there are quite some packets with NUL bytes in them. For example, some radios seem to send packets like this on the RF channel (<0x00> is a byte with a hex 00 value, for example).
Could it perhaps be that direwolf uses C string functions when processing igated packets, and truncates packets at the first occurrence of a 0-value byte?
The APRS-IS often has, for these packets, another intact copy, which has gone through an igate which does not truncate packets like this. It's a bit of a problem if the original packet gets modified at the igate and then there are two copies of it, the original and the modified one.
The text was updated successfully, but these errors were encountered:
Hi,
I've been staring a lot at APRS-IS packet logs lately, and it would seem that there are quite some packets with NUL bytes in them. For example, some radios seem to send packets like this on the RF channel (<0x00> is a byte with a hex 00 value, for example).
KB3FIF-5>SYRU0Y,N3KTX-1*,WIDE1*,N3KTX-4*,WIDE2*:4P<0x00><0x0f>4T<0x00><0x0f>4X<0x00><0x0f>4<0x00>`iZil\c>/]"6N}=
The AGW APRS software also used to send APRS text messages in an unicode encoding which used a lot of NUL bytes.
Now, these example packets have gone through a direwolf igate (the number in the beginning is the unix timestamp when the packet was seen):
1487142080 VK2MP-9>DDE4W0,VK2RHR-1,WIDE1*,WIDE2-1,qAR,VK2GJ-2:4P
1487140366 SA6APY-9>UXRQ81,SA6APY-2,SK4SQ-1,WIDE2*,qAR,SK4KO-10:4P
1487138828 PA5ES-9>UR0PX6,PI1DFT,WIDE1*,WIDE2-1,qAR,PA7DA:4P
Could it perhaps be that direwolf uses C string functions when processing igated packets, and truncates packets at the first occurrence of a 0-value byte?
The APRS-IS often has, for these packets, another intact copy, which has gone through an igate which does not truncate packets like this. It's a bit of a problem if the original packet gets modified at the igate and then there are two copies of it, the original and the modified one.
The text was updated successfully, but these errors were encountered: