Building faup1090


#1

Hi,

I’m trying to build faup1090 from source, so that I can upload to flioghtaware from my existing dumnp1090 install.
I’m doing this on a 32 bit linux machine running Mint 17

I’m failing with the below errors:



git clone https://github.com/flightaware/dump1090_mr.git
cd dump1090_mr/
make -f makefaup1090
gcc -O2 -g -Wall -W `pkg-config --cflags librtlsdr`  -c faup1090.c
gcc -O2 -g -Wall -W `pkg-config --cflags librtlsdr`  -c anet.c
gcc -O2 -g -Wall -W `pkg-config --cflags librtlsdr`  -c interactive.c
gcc -O2 -g -Wall -W `pkg-config --cflags librtlsdr`  -c mode_ac.c
gcc -O2 -g -Wall -W `pkg-config --cflags librtlsdr`  -c mode_s.c
gcc -O2 -g -Wall -W `pkg-config --cflags librtlsdr`  -c net_io.c
net_io.c: In function ‘modesFreeClient’:
net_io.c:174:5: warning: suggest parentheses around assignment used as truth value -Wparentheses]
     } else if (c->service = Modes.fatsvos) {
     ^
gcc -g -o faup1090 faup1090.o anet.o interactive.o mode_ac.o mode_s.o net_io.o coaa1090.obj `pkg-config --libs librtlsdr` -lpthread -lm 
/usr/bin/ld: coaa1090.obj: Relocations in generic ELF (EM: 40)
/usr/bin/ld: coaa1090.obj: Relocations in generic ELF (EM: 40)
/usr/bin/ld: coaa1090.obj: Relocations in generic ELF (EM: 40)
/usr/bin/ld: coaa1090.obj: Relocations in generic ELF (EM: 40)
/usr/bin/ld: coaa1090.obj: Relocations in generic ELF (EM: 40)
/usr/bin/ld: coaa1090.obj: Relocations in generic ELF (EM: 40)
coaa1090.obj: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
make: *** [faup1090] Error 1


Any suggestions…?


#2

coaa1090.obj is only provided as a pre-compiled ARM object file. When you say “32 bit Linux”, I assume that means you are using Intel x86?


#3

Oops, yeah, the linker reference to coaa1090.obj is not necessary. If you’ll git pull the FA dump1090_mr, that’s been removed.

Also it does an include of the Debian buildflags.mk which makes make take a lot longer to start up but should compile with the preferred flags for building packages on Debian. Please let us know if you get an error or anything because of that.


#4

Yes - the machine is an HP microserver running Mint, and receiving ADS-B through a USB TV tuner and a homemade antennae.

The machine is already running dump1090, which Ideally I’d like to leave untouched

On my machine, I can open a socket to port 30002 and see data streaming past,
or port 30003 and see slightly more readable info in the following format:



MSG,5,111,11111,484558,111111,2014/08/26,20:39:54.738,2014/08/26,20:39:54.724,,19500,,,,,,,0,,0,0


On port 3005 I get what looks like raw data, much of it in hex, streaming past - which I think is what your uploader needs.

I pulled faup1090 from git again and this time it built fine.

Initially I got the slightly cryptic:



faup1090: error opening the listening port 10001 (FlightAware TSV output): Success


I have tried running this on a virtual pi, which sort of works…but is a bit messy

It’s strange that it compiles fine, but doesn’t seem able to create the TCP server

I’ll see if I can have a look at the code, but I’m no software engineer :slight_smile:


#5

OK…

I agve up on faup1090, and instead used the form of dump1090 from FlightAware

That built fine. piAware /almost/ built fine, and worked after help from this thread:

discussions.flightaware.com/pos … ml#p150291

Now I seem to be running, and if I telnet to port 1001 I see data:



clock	1409520700	hexid	4CA894	ident	RYR32QF 	squawk	7442	alt	23825	speed	373	airGround	A	lat	51.61824	lon-0.55656	heading	349
clock	1409520700	hexid	471F4A	ident	WZZ1UT  	squawk	5665	alt	10775	speed	325	airGround	A	lat	51.75617	lon-0.09460	heading	97


piaware status gives me:



dump1090 is running.
faup1090 is not running.
piaware is running.
dump1090 is listening for connections on port 30005.
dump1090 is listening for connections on port 10001.
piaware is connected to port 10001.
piaware is connected to FlightAware.
dump1090 is producing data on port 30005.
dump1090 is producing data on port 10001.


However, whilst running paaware seems to work, it would appear that no data is actually being sent to FlightAware:



08/31/2014 21:23:28 ****************************************************
08/31/2014 21:23:28 piaware version 1.9 is running, process ID 15185
08/31/2014 21:23:28 your system info is: Linux nas 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 athlon i686 GNU/Linux
08/31/2014 21:23:33 connecting to FlightAware eyes.flightaware.com/1200
08/31/2014 21:23:33 FlightAware server SSL certificate validated
08/31/2014 21:23:33 encrypted session established with FlightAware
08/31/2014 21:23:38 ADS-B data program 'dump1090' is listening on port 30005, so far so good
08/31/2014 21:23:38 i see dump1090 serving on port 10001
08/31/2014 21:23:38 connecting to dump1090 on port 10001...
08/31/2014 21:23:38 piaware is connected to dump1090 on port 10001
08/31/2014 21:23:43 periodically_check_adsb_traffic: dump1090 is listening for connections on FA-style port 10001
08/31/2014 21:23:44 piaware received a message from the ADS-B source!
08/31/2014 21:24:33 connecting to FlightAware eyes.flightaware.com/1200
08/31/2014 21:24:33 FlightAware server SSL certificate validated
08/31/2014 21:24:33 encrypted session established with FlightAware
08/31/2014 21:24:44 166 msgs recv'd from dump1090; 0 msgs sent to FlightAware
........
.....
...
.



#6

I saw the git repository had been updated overnight, so I tried the latest code:



09/01/2014 06:13:08 ****************************************************
09/01/2014 06:13:08 piaware version 1.9 is running, process ID 27324
09/01/2014 06:13:08 your system info is: Linux nas 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 athlon i686 GNU/Linux
09/01/2014 06:13:19 connecting to FlightAware eyes.flightaware.com/1200
09/01/2014 06:13:19 FlightAware server SSL certificate validated
09/01/2014 06:13:19 encrypted session established with FlightAware
09/01/2014 06:13:30 ADS-B data program 'dump1090' is listening on port 30005, so far so good
09/01/2014 06:13:30 i see dump1090 serving on port 10001
09/01/2014 06:13:30 connecting to dump1090 on port 10001...
09/01/2014 06:13:30 piaware is connected to dump1090 on port 10001
09/01/2014 06:13:40 periodically_check_adsb_traffic: dump1090 is listening for connections on FA-style port 10001
09/01/2014 06:13:40 piaware received a message from the ADS-B source!
09/01/2014 06:13:40 *******************************************
09/01/2014 06:13:40 LOGIN FAILED: status 'error': reason 'mac missing from row'
09/01/2014 06:13:40 please correct this, possibly using piaware-config
09/01/2014 06:13:40 to set valid Flightaware user name and password.
09/01/2014 06:13:40 piaware will now exit.
09/01/2014 06:13:40 You can start it up again using 'sudo /etc/init.d/piaware start'


This seems fairly key:



09/01/2014 06:13:40 LOGIN FAILED: status 'error': reason 'mac missing from row'


Looking at the source, it is hardcoded to use eth0

I have no eth0 - only an eth1.

Editing the file fa_adept_client.tcl to use eth1, now I have:



09/01/2014 06:13:19 FlightAware server SSL certificate validated
09/01/2014 06:13:19 encrypted session established with FlightAware
09/01/2014 06:13:30 ADS-B data program 'dump1090' is listening on port 30005, so far so good
09/01/2014 06:13:30 i see dump1090 serving on port 10001
09/01/2014 06:13:30 connecting to dump1090 on port 10001...
09/01/2014 06:13:30 piaware is connected to dump1090 on port 10001
09/01/2014 06:13:40 periodically_check_adsb_traffic: dump1090 is listening for connections on FA-style port 10001
09/01/2014 06:13:40 piaware received a message from the ADS-B source!
09/01/2014 06:13:40 *******************************************
09/01/2014 06:13:40 LOGIN FAILED: status 'error': reason 'mac missing from row'
09/01/2014 06:13:40 please correct this, possibly using piaware-config
09/01/2014 06:13:40 to set valid Flightaware user name and password.
09/01/2014 06:13:40 piaware will now exit.
09/01/2014 06:13:40 You can start it up again using 'sudo /etc/init.d/piaware start'


This seems fairly key:



09/01/2014 06:13:40 LOGIN FAILED: status 'error': reason 'mac missing from row'


Looking at the source for fa_adept_client.tcl, it is hardcoded to use eth0:



set macFile /sys/class/net/eth0/address


I have no eth0 - only an eth1. Changing that seems to have worked:



09/01/2014 06:26:57 logged in to FlightAware as user dbrb2
09/01/2014 06:26:57 piaware has successfully sent several msgs to FlightAware!
09/01/2014 06:27:47 handle_alive_message: server is sending alive messages, we will expect them
09/01/2014 06:27:57 278 msgs recv'd from dump1090; 277 msgs sent to FlightAware


Might be useful if this could be configured as a parameter?