Problem with port 30104 & Airspy Mini/Odroid XU4


I upgraded from a rtlsdr v3 to an Airspy mini a few days ago and managed to get it running ok using the latest piaware image 3.6.3 following the helpful instructions on this forum:

I found that the RPI3B+ cpu% was getting quite high during peak times so decided to put my Ordroid XU4 into service to see how that would cope, but just cannot get port 30104 to work - always get ‘errno111’ when I connect to FA servers.

I am running Armbian 5.59 Odroidxu4 Debian stretch_next4.14.66 together with piaware and Dump1090-fa add on programs and they work fine when using the rtlsdr so I know that side of things is ok - just fails when using the airspy.

I have tried using both the sudo piaware-config receiver-type ‘relay’ or ‘other’ commands, but still no joy.

command line being used for airspy is:
sudo ./airspy_adsb -c -l 30005:BEAST -l 30001:AVR -g 21 -p -w 4 –d 1 –f1 -x -m12 & which works fine with the airspy mini and sd image 3.6.3 - its running now!!

Any help much appreciated.


With dump1090/piaware running, but before you start airspy_adsb, what does running

sudo netstat -an | grep 30104

look like?

You should see a line like this:

tcp        0      0 *               LISTEN

If you don’t see that, it’s something related to dump1090.

Also, can you prune your command line a bit for testing?

You don’t need the “-l 30005:BEAST -l 30001:AVR” and “-w 4 –d 1 –f1” bit right now. Add in a “-v” and drop the “&” for testing. You’ll see additional airspy_adsb start-up messages that may be helpful.


Is dump1090-fa even running right now after you changed the receiver type?

If it’s not the airspy will not be able to connect to it and that is then the problem.

The kinda unintuitive solution would then be to first make sure dump1090-fa does not use 30005 port (change maybe multiple occurences of 30005 in /etc/default/dump1090-fa to let’s make it 30305 for simplicity).

Then use “piaware-config receiver-type rtlsdr” to switch back to default configuration which is to run dump1090-fa and have it offer data on 30005. But because of the dump1090-fa config change now it will offer data on 30305 and be ignored by piaware. piaware will still look for 30005 and hopefully find airspy offering data there :slight_smile:
so sudo systemctl restart piaware and sudo systemctl restart dump1090-fa.

Now your command line for airspy should work.

(all this presumes that changing the receivertype of piaware to relay or other might make it switch off dump1090-fa assuming it doesn’t need it, meaning you can’t connect to it with airspay to give it data which it will then present on the nice local map)

If this explanation is too complicated i can make try and make it simpler by removing the explanations:

piaware-config receiver-type rtlsdr
change the number 30005 in /etc/default/dump1090-fa to 30305 (maybe more than one occurence in the file)
sudo systemctl restart piaware
sudo systemctl restart dump1090-fa
sudo ./airspy_adsb -c -l 30005:BEAST -g 21 -p -w 4 –d 1 –f1 -x -m12 &

So now i just hope my assumptions are correct and this will work :wink:


I tried sudo netstat -an | grep 30104 and nothing was returned when the airspy was being used in all 3 combinations ie.receiver-type rtlsdr, other and relay.
The only one to return any information was rtlsdr (when being used) as follows:

tcp 0 0* LISTEN
tcp6 0 0 :::30104 :::* LISTEN
tcp6 0 0 ::1:30104 ::1:36676 ESTABLISHED
tcp6 0 0 ::1:36676 ::1:30104 ESTABLISHED

rtlsdr works fine on the Ordroid xu4, but airspy doesn’t - but using a SD image, with alterations as I have done with the add on packages for the Ordroid, works fine with a RPI!!!

I tried your suggestions as well to no avail - still the same result :unamused:

I am at a loss where to try next.

In case it may help, sudo netstat -an | grep 30104 with the airspy/rpi combination returns:

tcp 0 0* LISTEN
tcp 0 1029 ESTABLISHED
tcp6 0 0 :::30104 :::* LISTEN
tcp6 0 0 ::1:30104 ::1:40436 ESTABLISHED
tcp6 0 0 ::1:40436 ::1:30104 ESTABLISHED

Much appreciated for your assistance in trying to solve this.


can you post your /etc/default/dump1090-fa please?

also which program spits out errno 111 and please post that error log.

Just out of curiosity with the airspy use 30004 instead of 30104 in the command line. It should not be a factor but what do i know. (yeah this a dumb idea the error log is more important i think)

Also before starting airspy do: sudo netstat -tulpn | grep 30005
so we can see if some other program is already listening on 30005
if the socket is already used it can’t listen on it.

maybe dump1090 is running instead of dump1090-fa? that’s one of the last things i can think of.


Why is that over tcp6?
That’s the problem, kill the IPv6.


that’s just piaware connecting to dump1090. that’s not a problem.

why would IPv6 be the problem?
also notice IPv6 is present on the working configuration as well.

But you are right it must be the IPv6, probably the Russians.


Will do when I get back home - VMT for your help :+1:t2:

I’ve tried disabling IPV6, putting piaware in hosts etc to no effect - I feel its got to be something in the OS that’s causing the problem, but no idea what!
Used to program ARM back in the day in machine code, but lost with compiled coding! :zipper_mouth_face:


Saw your comment on another thread - ham radio doesn’t always win - it’s all a learning process :grin::+1:t2:

Andy G0HIX


Instead of disabling IPv6, make IPv4 to have preference.

(1) Open file gai.conf for editing

sudo nano /etc/gai.conf

(2) Scroll down till you see this chunk of code

#    For sites which prefer IPv4 connections change the last line to
#precedence ::ffff:0:0/96  100


(3) Un-comment following line

#precedence ::ffff:0:0/96  100

(4) Save (Ctrl+o), Close (Ctrl+x) and reboot

sudo reboot


Maybe it was “fixed” on Pi3 (maybe not), but I am suspecting it might be something to do with the IPv6 implementation on that specific platform (Armbian 5.59 Odroidxu4 Debian stretch_next4.14.66).
I don’t have IPv6 enabled in router (nor by my ISP).


That is just lighttpd being configured to listen only on IPv6.
Anyway the -c part is not gonna connect via IPv6 because that would be a different address.
But there was some other fault where disabling IPv6 or having IPv6 addresses in the /etc/hosts file actually caused a problem. Don’t remember it specifically though.

Let’s see what the config files and logs hold :wink:


Right, been a busy night/day and here is how I’m doing!!

Tried your idea - still not working :persevere:

Don’t have the logs now, but airspy was reporting connected to port 30104 and then disconnected - kept repeating.
Piaware was reporting the errno111.

In desperation, I re-imaged the OS, loaded up dump1090-mutability and got that working on its own!!

Downloaded the piaware addon for dump1090 and all seems to be working!!! :grinning:

It’s a mystery as to why I can’t get dump1090-fa working as I prefer the look :unamused:

Still willing to try other things to get dump1090-fa working, but will do work on it in the small hours so my numbers don’t get hit so much!!!

Here is netstat result with working airspy/ordroid set up - I’ve disabled IPV6 at set up, but still used @abcd567 suggestion.

ob@odroidxu4:~$ sudo netstat -an | grep 30104
tcp 0 0* LISTEN
tcp 0 1166 ESTABLISHED
tcp6 0 0 :::30104 :::* LISTEN

Step by step how to integrate airspy into existing piaware

yeah if you still had your config file for dump1090-fa that you used when it wasn’t working that would be great lol :slight_smile:

Also that ipv6 is not disabled when a program is listening on it lol. Maybe need to reboot after disabling ipv6?
Hmm i have an idea maybe dump1090 needs to be in net-only mode? Did you set that?
(–net-only in the options)

And what image are you basing all this on?



The only change I made to the piaware config was to change ‘receiver-type’ to other/relay/rtlsdr to see if I could get the add on packages to work, and ‘airspy’ load etc as per the link in my first post - that’s what worked with the RPI.
No other changes made to dump1090-fa as assumed it looked after itself!

I used latest 3.6.3 versions of piaware/dump1090-fa for all tests and now I’m using dump1090-mutability 1.15~dev with piaware 3.6.3.
As I could change the dump1090-mutability settings file I have changed receiver type to ‘none’ and piaware-config to ‘relay’

On setting up the new OS image I set a static ip address for my network (192.168.etc), and disabled IPV6 for APT and system using their config program - maybe it doesn’t do a good job!!!

/etc/hosts file is the default apart from entry for FR24: localhost odroidxu4
::1 localhost odroidxu4 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I did try piaware also when trying dump1090-fa, but didn’t put it back with the new OS image.


Yeah that’s the problem: dump1090-fa settings per default make it listen on 30005 where you want to listen with airpsy and two programs can’t listen on the same port.

Also it’s a good idea to use dump1090-fa in --net-only mode so it doesn’t error out when it doesn’t find the rtl dongle. Also you need to make it NOT listen on 30005 by changing that port.

I’m just wondering which settings are right now working with dump1090-mutability?
Could you post the config file you use?


The only setting I have changed in /etc/default/dump1090-mutability is change DEVICE=“none” from “”

#RTLSDR device index or serial number to use
#If set to “none”, dump1090 will be started in --net-only mode

All other settings are default. sudo /etc/init.d/dump1090-mutability status gives:

dump1090-mutability.service - LSB: dump1090 daemon (mutability variant)
Loaded: loaded (/etc/init.d/dump1090-mutability; generated; vendor preset: enabled)
Active: active (running) since Fri 2018-09-21 12:37:48 UTC; 6h ago
Docs: man:systemd-sysv-generator(8)
Process: 1146 ExecStart=/etc/init.d/dump1090-mutability start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/dump1090-mutability.service
└─1183 /usr/bin/dump1090-mutability --net-only --ppm 0 --fix --lat 50.87779 --lon -0.7869 --max-range 360 --net-ri-port 30001 --net-ro-port 30002 --net-bi-port 30004,30104 --net-bo-port 30005 --net-sbs-port 30003 --net-hear…et

Sep 21 12:37:47 odroidxu4 systemd[1]: Starting LSB: dump1090 daemon (mutability variant)…
Sep 21 12:37:48 odroidxu4 systemd[1]: Started LSB: dump1090 daemon (mutability variant).

sudo /etc/init.d/piaware status gives:

● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2018-09-21 12:37:47 UTC; 6h ago
Main PID: 1134 (piaware)
CGroup: /system.slice/piaware.service
├─1134 /usr/bin/piaware -p /run/piaware/ -plainlog -statusfile /run/piaware/status.json
├─1233 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type auto --results beast,connect,localhost:30104 --results beast,listen,30105 --results ext_basestation,listen,30106 --no-modeac-result…20
└─1244 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 50.878 --lon -0.787

Sep 21 18:58:22 odroidxu4 piaware[1134]: 282559 msgs recv’d from dump1090-mutab (3140 in last 5m); 282559 msgs sent to FlightAware
Sep 21 19:03:22 odroidxu4 piaware[1134]: 285725 msgs recv’d from dump1090-mutab (3166 in last 5m); 285725 msgs sent to FlightAware
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Receiver status: connected
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Server status: synchronized with 524 nearby receivers
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Receiver: 1707.2 msg/s received 338.2 msg/s processed (20%)
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Server: 0.5 kB/s from server 0.0kB/s TCP to server 4.6kB/s UDP to server
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Results: 208.1 positions/minute
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Aircraft: 27 of 39 Mode S, 79 of 109 ADS-B used
Sep 21 19:08:22 odroidxu4 piaware[1134]: 288946 msgs recv’d from dump1090-mutab (3221 in last 5m); 288946 msgs sent to FlightAware
Sep 21 19:13:22 odroidxu4 piaware[1134]: 292181 msgs recv’d from dump1090-mutab (3235 in last 5m); 292181 msgs sent to FlightAware

Hope this is of help :+1:


It kinda helps.

You are using port 30005 double right now. Don’t know why it would even work.
For some reason that works with dump1090-mutability and not with dump1090-fa. Not sure why but using 30005 twice as a listen port is WRONG and if you want to use dump1090-fa you need to change that.

In one of my first posts i suggested changing 30005 to 30305 in /etc/default/dump1090-fa but i guess that didn’t reach you :slight_smile:

can you do a netstat -tulpn | grep 30005?
i’d like to know which program is listening on 30005 :stuck_out_tongue_winking_eye:

Maybe airspy just doesn’t open the port 30005 if it’s already used.
airspy connects to dump1090 sends it the beast data and piaware then connects to dump1090 and gets the data that way.

Is mlat working right now? Not sure if that is even possible with airspy.


Yes, I did try changing 30005 to 30305 in /etc/default/dump1090-fa but unfortunately it didn’t work - port 30005 has always seemed to connect OK - might take a go or two, but connects - its 30104 which has seemed to cause the problems by connecting and being disconnected which just repeats.

netstat -tulpn | grep 30005 returns:

root@odroidxu4:~# netstat -tulpn | grep 30005
tcp 0 0* LISTEN 1140/airspy_adsb
tcp6 0 0 :::30005 :::* LISTEN 1183/dump1090-mutab

Yes, Mlat is working like a charm - Multilateration (MLAT): Supported / Enabled (synchronized with 518 nearby receivers)
[2018-09-21 20:52 BST] mlat-client(1233): Results: 205.3 positions/minute

Also did port 30104 to see if that shows you anything!

root@odroidxu4:~# netstat -tulpn | grep 30104
tcp 0 0* LISTEN 1183/dump1090-mutab
tcp6 0 0 :::30104 :::* LISTEN 1183/dump1090-mutab


There’s no need for airspy_adsb to listen on any port. Don’t use any “-l” command. It just needs to feed to the stock 1090-fa or 1090-mut on port 30104 using the “-c” command.

This! Piaware will handle the MLAT and other chores. Airspy does nothing but feed decoded signals to dump1090.