Error uploading ADS-B message

I noted the following error in piaware.out for an eight hour period, then apparently dump1090 crashed. Any ideas why this happened? Could it have anything to do with forwarding data from another Pi to this one?


01/03/2015 01:58:27 error uploading ADS-B message: list must have an even number of elements
...
01/03/2015 09:57:07 error uploading ADS-B message: list must have an even number of elements
01/03/2015 09:58:34 lost connection to faup1090, reconnecting...
01/03/2015 09:58:34 no ADS-B data program is serving on port 30005, next check in 60s


I can answer my own question. The error is caused by forwarding data from another Pi to the one that’s reporting the error. I just did a test and found that the error messages began to show up in /tmp/piaware.out as soon as I started "netcat’ing’ the data from one Pi to the other. Well, back to the drawing board.

Odd. This setup works for me.

It is at least partially related to the compression changes in 1.19 (they don’t handle a badly-formatted FATSV line; previous versions would just blindly upload it)

Exactly what faup1090 or dump1090 version were you using to talk to piaware?

The sending unit is running dump1090-mutability 1.08.2302.14+1mu-7. The receiving Pi is running Piaware 1.19-3 and dump1090 1.09.0608.14.

Am I correct in assuming that if I were running piaware-mutability on the receiving end this wouldn’t be a problem? I’m willing to give that a try.

No, piaware-mutability uses the same code so I wouldn’t expect a change there. I mostly just wanted to narrow down exactly what was generating the FATSV data.

With that version of dump1090 I guess you have this topology:

rtlsdr#1 → dump1090-mutability → dump1090
rtlsdr#2 → dump1090
dump1090 → faup1090
faup1090 → piaware

Which makes it all the more puzzling because faup1090 (which is what’s generating the FATSV output) only has one data connection in this case, regardless of whether your second receiver is feeding into the mix or not.

I’d be interested in seeing sample output from port 10001 while the problem is occuring (“nc -q60 pihostname 10001 </dev/null >output.txt”, and wait 60 seconds) if you don’t mind collecting that.
(The exact format of the output, e.g. location of tab characters, is important so if you can put it on dropbox or similar, verbatim, rather than cut+pasting it, that would be perfect)

Look for a PM.

After some investigation this looks like a bug in FlightAware’s version of dump1090/faup1090 that just happens to be tickled in this case.

Bugfix pull request is here: github.com/flightaware/dump1090_mr/pull/8
(though there are still other bugs in that area…)

dump1090-mutability should be unaffected as I rewrote that area when merging FATSV support.

A possible workaround is to start dump1090 with “–net-fatsv-port 0”.
This disables FATSV support in dump1090 itself and so piaware will run a separate faup1090 which will probably (maybe!) work OK.

The underlying problem is related to uninitialized memory when allocating a new inbound network connection.
faup1090 only creates an inbound data connection once, early during execution, so (through luck) it will probably allocate a zeroed block of memory for that connection and work OK.
dump1090, in contrast, might accept a new inbound connection at any time so it’s more likely to get a reused block of memory and run into problems.

Using obj’s workaround this problem has been fixed. I’m now sharing ads-b data from one Pi running dump1090-mutability to a second Pi running dump1090 and Piaware. Both Pi’s are co-located.