Running on other platform?

Hi,
Is it possible to run flight aware software on a non Raspberry pi host, preferably on a linux VM or with a docker container?
If so, what are the downsides to this. I already have a Proxmox cluster setup which I use for lots of other linux VM, LXC etc and would prefer to use that if possible?
Thanks
Mike

Sure. You’ll need to build from source. GitHub - flightaware/piaware_builder: Debian package builder for piaware is a starting point (it’s set up to produce a Debian package, but you should be able to adapt that to whatever you need)

VMs can have problems with reliably doing USB passthrough, which tends to break mlat. You may want to run dump1090, at least, closer to bare metal.

1 Like

Hey, thanks for that. I’ve passed through lots of USB devices in the past and mostly its been ok but I am happy to be proved wrong :slight_smile:
I won’t miss out any features I assume by not using the PI image?

Thanks!

Building yourself is a bit of an endeavor, you could take a look at:
https://sdr-enthusiasts.gitbook.io/ads-b/

Edit: Seems that would mean a VM pretty much as you can’t simply run the docker containers in proxmox … found some possible ways of converting docker containers to LXC containers actually but i have no clue about that.

Please have a look here:

 

2 Likes

I am the author of the thread @abcd567 references. I run my ADS-B inside a LXC container in Proxmox VE. I created a container with a base Debian image and then just ran the install scripts by @abcd567. You will need to blacklist the Linux DVB modules on your host machine (i.e. your Proxmox node) and add a couple lines of custom LXC options to your LXC config in order to pass the USB SDR(s) to the container.

$ cat /etc/pve/lxc/XXX.conf
...[snip]...
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/XXX dev/bus/usb/XXX none bind,optional,create=dir

Substitute the correct USB bus that your SDR is plugged into for the XXX. Note this passes the entire USB bus to the container. You can get more specific, but if you unplug your SDR for some reason it will likely NOT come up in the same place and you’ll need to reboot your host. For that reason I kept it as the entire bus. I plugged in anything I did not want to go to the container on a different USB bus.

The blacklist:

$ cat /etc/modprobe.d/blacklist-rtlsdr.conf 
# Blacklist host from loading modules for RTL-SDRs to ensure they
# are left available for the guest.

blacklist dvb_core
blacklist dvb_usb_rtl2832u
blacklist dvb_usb_rtl28xxu
blacklist dvb_usb_v2
blacklist r820t
blacklist rtl2830
blacklist rtl2832
blacklist rtl2832_sdr
blacklist rtl2838

# This alone will not prevent a module being loaded if it is a
# required or an optional dependency of another module. Some kernel
# modules will attempt to load optional modules on demand, which we
# mitigate here by causing /bin/false to be run instead of the module.
#
# The next time the loading of the module is attempted, the /bin/false
# will be executed instead. This will prevent the module from being
# loaded on-demand. Source: https://access.redhat.com/solutions/41278

install dvb_core /bin/false
install dvb_usb_rtl2832u /bin/false
install dvb_usb_rtl28xxu /bin/false
install dvb_usb_v2 /bin/false
install r820t /bin/false
install rtl2830 /bin/false
install rtl2832 /bin/false
install rtl2832_sdr /bin/false
install rtl2838 /bin/false

This all works very well for me, MLAT included.

Edit: Be sure your network MTU is set to 1500 in your LXC config otherwise you’ll see errors like this:

#Set MTU to 1500 or piaware/mlat-client throw errors:
#
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689): Reconnecting in 30.0 seconds
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689): Lost connection to localhost:30005
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689): struct.error: pack_into requires a buffer of at least 1534 bytes for packing 40 bytes at offset>
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):     STRUCT_SYNC.pack_into(self.buf, self.used,
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):   File "/home/mihanson/piaware_builder/package-bookworm/debian/venv/lib/python3.11/site-package>
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):     self.server.send_sync(ac.even_message, ac.odd_message)
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):   File "/home/mihanson/piaware_builder/package-bookworm/debian/venv/lib/python3.11/site-package>
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):     handler(message, now)
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):   File "/home/mihanson/piaware_builder/package-bookworm/debian/venv/lib/python3.11/site-package>
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):     self.coordinator.input_received_messages(messages)
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):   File "/home/mihanson/piaware_builder/package-bookworm/debian/venv/lib/python3.11/site-package>
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):     self.handle_read()
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):   File "/usr/lib/python3.11/asyncore.py", line 425, in handle_read_event
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):     obj.handle_read_event()
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689):   File "/usr/lib/python3.11/asyncore.py", line 88, in read
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689): Traceback (most recent call last):
#Apr 21 19:38:50 ads piaware[16675]: mlat-client(16689): Unexpected exception on connection to localhost:30005
#Apr 21 19:38:47 ads piaware[16675]: mlat-client(16689): Route MTU changed to 9000

Edit #2:
I forgot that you will also need a udev rule on your host (Proxmox node) to make the SDR world read/writable. There’s a way to map a proper user into the LXC, but it was confusing to me and I don’t need this to be ultra secure, I chose the easy way.

$ cat /etc/udev/rules.d/99-ads-receiver.rules 
# Set the correct permissions for LXC access of the SDR receiver
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idProduct}=="2838", ATTRS{idVendor}=="0bda", ATTR{serial}=="00000162", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idProduct}=="2832", ATTRS{idVendor}=="0bda", ATTR{serial}=="00001090", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idProduct}=="2832", ATTRS{idVendor}=="0bda", ATTR{serial}=="00000978", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idProduct}=="2838", ATTRS{idVendor}=="0bda", ATTR{serial}=="00001090", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idProduct}=="2838", ATTRS{idVendor}=="0bda", ATTR{serial}=="00000978", MODE="0666"
1 Like

Wow, thanks so much for the great info! And hello to another Proxmox user :slight_smile:

Well I have news, I spent the last couple of hours on and off getting things working. I gave up on Ubuntu 24.04 LTS and went for a 22.04 LTS VM instead. I didnt go the LXC route as I had issues in the past passing through some devices but your notes may clear this up, if I do go down that route in future, so thank you! I built both the deb packages for piaware and dump1090, had some problems with tcl-tls_1.7.22-2 but found that on github and downloaded and built.
I have literally just plugged in the usb and found the web page on port 8080, so far very impressed.

Unsure how well my aerial is working at this point, its a ham tri band colinear for 144/432/1200 Mhz, so its not ideally tuned for 1090, we shall see!
Not done any other tweaks or checks as yet.

Thanks again,
Mike

2 Likes

If you use automated install scripts at my Github page, these scripts will built piaware, dump1090-fa, & dump978-fa on Ubuntu 24.04 LTS without any trouble. However piaware will be built without fa-malt-client, so it will lack mlat support.

The reason for not building fa-mlat-client is that the Ubuntu 24.04 uses python3.12, while current mlat-client source-code is NOT compatable to python3.12 . As a result attempt to build piaware resuts in failure.

The script at my Github site detects OS version, and if it finds Ubuntu 24.04, it skips the steps to build fa-mlat-client, thereby successfully compiling & installing piaware, but of course without fa-mlat-client.

2 Likes

Glad you got things up and running Dirky123. I have been toying with Nobel trying to find a workaround here and there as well as of late and have also found no joy. For me disabling MLAT is a no go and applaud your move “back” to Jammy instead. It is the choice I would have made if not for Debian. :slight_smile:

BTW as far as multiplatform/architecture installs go I recently revived an old project life forced me to neglect for some time. Now that I have the time once again things have been moving at a quick pace and things look to be nearly back in order. If you ever need to get a non Raspberry Pi or Raspberry Pi system for that matter up and running from scratch in little time, check it out. The ADS-B Receiver Project

1 Like

 

Welcome back Joe Prochazka. Glad to see you after a long gap.

Glad to know that you have now revived your “adsb receiver project”

1 Like

Thanks abcd567.
Glad to see you still active in the community helping people out!

1 Like

If you’re using a VM anyhow, there is a proxmox image available for https://adsb.im/
Depends how much customization you’re looking for you could also just run this inside a VM: https://sdr-enthusiasts.gitbook.io/ads-b/

If you only want to run piaware and don’t mind the compiling and everything, no real need for that.
But if you wanted to send data to more aggregators it is quite handy.

3 Likes