search

williamhemmingsen / LibAPRS_ESP

Fork of LibAPRS for the ESP8266
Other
31 stars 6 forks source link

APRS-ESP8266-IGATE truncates packets with NUL bytes #3

Open hessu opened 7 years ago

hessu commented 7 years ago

Hi,

It seems like processPacket() treats a received APRS packet as a C string. This will cause packets containing NUL bytes to be truncated, and in turn, there will be modified duplicate packets around - the uncorrupted ones and the ones truncated by this software.

https://github.com/williamhemmingsen/LibAPRS_ESP/blob/master/examples/APRS-ESP8266-IGATE/APRS-ESP8266-IGATE.ino#L126

Unfortunately packets containing \0 bytes are fairly common, although they are unexpected by many software. For example, all Kenwood TM-D710 D710A/D710E radios with slightly old firmware send them at power-on sometimes. AGWtracker software can send UTF-16 encoded unicode, where every second byte is a NUL when encoding latin characters (all other new APRS software uses UTF-8). Other bugs and packet corruptions happen too.

For the long story: https://github.com/hessu/aprsc/blob/master/doc/IGATE-HINTS.md#packets-truncated-by-igates-due-to-c-string-handling

Could you please look into fixing this bug, and preferably shut down any igates exhibiting this bug until it is fixed?

Thank you!

williamhemmingsen commented 7 years ago

Hello,

This was a port of the LIBAPRS library for the ESP8266. This Example is just a test of the library. It is not meant as a final solution. If I get the time I will look into the issue as you suggested. But at this time I am busy with other projects. Please feel free to fork the library and make any improvements. I will monitor for pull request.

Regards,

William

hessu commented 7 years ago

Hello,

I am also quite busy with other projects (https://aprs.fi/, https://github.com/hessu/aprsc, family, house), and last night alone I found 3 variations of these bugs (https://github.com/pengi/gr-igate/issues/3 and https://github.com/ampledata/aprs/issues/18), so I would prefer not to start fixing them all. I can submit a simple pull request to highlight the defects, so that the buggy code wouldn't be run live on the APRS network yet, at least not from this fork.

The problem is that some people are now installing this software, and every time a new instance comes up, the amount of corrupted packets on the APRS-IS network increases, which is not good for the network. Causes grief to other software developers and odd results on the receiving display end, confusing users.