Skip to content

iGated packets getting truncated at NUL byte #84

@hessu

Description

@hessu

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions