Source packages?

Just to set the record straight: I am not a developer. I can script bash and perl and even some python with a lot of googling, and I can read C as a five-year old can read Shakespere, but I have definitely no insight in the coding requirements that support for different OSes might pose.

With that said, and based on my very limited understanding, I wrote that “I would have imagined that the only hardware that FA needs to support is the radio, while everything else is abstracted by the kernel” and that “CPU idiosyncracies ought to be taken care of by the compiler”. If I’m out of touch with reality on this in principle, please short-circuit me.

On the other hand I am very much aware of “version tension” between different systems. You want to use libxyz-1.2.3 because is provides some very nifty shortcuts for your code, but it is only available in OS/1 and not in OS/2 or OS/3. That is where I suspect that the ugly conditionals come from: a desire to advance the code where it is possible, while still maintaining it functional where advancement is not possible.

If - and only if - I am correct in that, it seems to me that the appropriate course of action is maintaining only one code base, but different versions for different OSes. As in “code-2.0.1 has been released for RedHat Linux, while code-1.8.53 remains the latest version for Sun Unix and SGI Unix”. In other words you start with something very generic, then you incorporate whatever new stuff you want to in later versions, and you just let the OSes choose whether and when they want to enable your newer versions, or stay with your older ones.

Upfront, I do not write code for Flightaware, though from what I have watched and used, it is reliable, simple to install on known systems. Perhaps we can disagree. When code bases split to support different OS systems and use different versions, the code becomes unmanageable and unreliable.

Trying to support just the radio portion is only part of what these codes do. Code systems read inputs, translate/manipulate/convert data, process data, manage data, and output data. Lots more than just connect to the radio. Our little radios and computers are only one nitch of what happens.

The big job is in the servers staying up, injesting and processing thousands of packets each second, verifying the data is usable, and then incorporating it into their system. That is a much bigger job than Piaware/Dump1090 stuff. Kudos to those who work the code, manage the servers and databases. The devil is in the details, and lots of details in ADSB data and codes.

If this is important to you, you go for it. I sincerely hope you can get the results you desire. Best Wishes

1 Like

@zenonp - let it rip brother! Anyone who who is willing to spend the time to make this gig work cleanly on another set of tools should be applauded.

It’s obvious you care about the project. I can’t find a decent argument against it in all honesty. Your time spent should be greatly appreciated.

1 Like

I’m still working on this; I now also have mlat-client and dump978 ready and still need to do tcllauncher and piaware. But I just found out that I am not the first one to embark on this project. GWDG has been distributing piaware rpms for openSuSE since 2017, with the latest build today, just a few hours ago.

1 Like

This is very good news.

I did not attempt to make rpm packages, but did try to build the Linux Binary on Red Hat and Fedora. I succeeded to make & run Linux Binary for dump1090-fa. Also built piaware Linux Binary. However got stuck when tried to run piaware binary. Reason given in this post:

Heh, haste. It happens occasionally to all of us. piaware requires tls, but that has nothing to do with tcl; the two just look similar to the eye.

The piaware feed applications (faup* etc) make encrypted connections to the FA servers. That’s what they need tls for, and it has to be present at build time. On redhattish systems it would probably be provided by openssl-devel and/or gnutls-devel.

Edit: I just read your original post. The error is here:

Checked openssl , found it is already installed:
[abcd@localhost ~]$ sudo dnf install openssl

You needed openssl-devel.

1 Like

Oops!

Great! Thanks for the tips. Coming weekend I will try again.

I agree. To this end, I am thinking of a different path, a virtual appliance by way of virtualbox (or any popular hypervisor du jour) [[<-- debian (or any popular Linux distro) ← qemu ← piaware img (or Raspbian + FA packages)]]. This will allow anyone with x86 to experiment. As you are already considering the Debian community, QEMU should suffice to bring the experience to all Linux community.

Well if you’re competent to run a Debian VM then just compiling from source shouldn’t be hard, there are enough guides on the forum (and even without that it’s not that complicated to figure out).

Docker is all the rage, don’t you know? :slight_smile:
No, but seriously this is some nice stuff:
Guide to ADS B Data Receiving, Decoding and Sharing, Leveraging RTLSDR and Docker · mikenye/docker-readsb Wiki · GitHub

The very concept the OP has been promoting is to have rpm and deb packages available for x86 x64, so that there is no need to build from source code.

You can run an arm VM on an x86 host, so you could just install the piaware image or raspbian + FA repo in a VM and be up and running in no time. One thing I can imagine that could go wrong is USB passthrough, but it has become much better in later years. And then there’s also the question of whether your VM host has pre-defined settings for aarch64 and raspbian; mine (on el7) does not. Anyway, give or take a bit of tweaking, you don’t need a ready image for it.

Not everybody would agree with you :wink:

Debian, Ubuntu, Kali, Fedora, Red Hat, Arch Linux, on Oracle VM on Windows, the USB DVB-T does passthrough, but MLAT still fails.

Kali on WSL2 on Windows 10, the USB does NOT passthrough at all. Dump1090-fa complaints :“no rtl-sdr device found”.

I’m getting too old and krusty I guess - never felt the need to learn what it is or how it works. Containers to make otherwise s̶h̶i̶t̶t̶y̶ bad code work so the M$ coders can retain their jobs, or a fancy sandbox? :shushing_face:

Sorry, couldn’t resist, you set the pins up…

2 Likes

The other day I said that faup uses UDP and @obj corrected me that only the mlat client does. UDP is stateless and, while it obviously can get out and back in through a router, I can imagine that having to get through two ignorant routers, first the host machine of the VM and then also the physical router, doesn’t work and could be the cause of this. Explicitly configuring iptables on the host machine to send incoming mlat packets to the VM could help.

Lol, i’m not a huge docker fan myself.

The VM mlat problem was definitely a USB issue not a UDP issue when I looked at it at the time. UDP is making it out fine. The VM is just dropping a lot of the raw SDR data on the floor (IIRC it was something like 10-15%, in bursts). Enough sample data gets through that reception “works”, but the frequent drops completely ruin mlat timing which relies on being able to reliably count the number of samples received, so you never get clock sync.

Not sure how much has changed in the past few years, but when I was processing live .ts/mpeg streams from satellite through USB in a VM, the Oracle VM (VirtualBox) made a complete mess of the USB stack - it was totally unusable for what I was needing it for (Win7 Host). I moved to VMWare Workstation (still use) and it does a much better job of not randomly dropping packets. I have not tried running FA through VMWare, but it may be worth a shot. FWIW anyhow.

An update:

I put the whole project aside for a few days because (a) I had a lot of other things to do and (b) the piaware package was giving me a lot of grief. Yesterday I took it up again and by now all the rpms build cleanly. This doesn’t mean that they work; of course they don’t and now I’m in the debugging phase. Things like

openat(AT_FDCWD, "/usr/lib64/tcl8.6/tclx8.4/autoload.tcl", O_RDONLY) = 5
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
ioctl(5, TCGETS, 0x7fff1c06d9d0)        = -1 ENOTTY (Inappropriate ioctl for device)
read(5, "#\n# Modified version of the stan"..., 4096) = 2272
read(5, "", 4096)                       = 0
close(5)                                = 0
access("/usr/share/tcl/piaware/main.tcl", R_OK) = -1 ENOENT (No such file or directory)
write(2, "piaware: can't read '/usr/share/"..., 67piaware: can't read '/usr/share/tcl/piaware/main.tcl' (tcllauncher)) = 67
write(2, "\r\n", 2
)                     = 2
close(4)                                = 0
exit_group(254)                         = ?
+++ exited with 254 +++

because that tcllauncher specfile that I swiped from SuSE moved tcllauncher’s basedir from /usr/lib to /usr/share. Anyway, all the FA packages and their external dependencies are here and anyone who wants to help debug is most welcome. All you need is a CentOS 8 VM. Run this as root

dnf install epel-release

cat << EOF > /etc/yum.repos.d/provocation.repo
[provocation]
name=provocation-$releasever
baseurl=http://www.provocation.net/rpms/el8/rpms
gpgcheck=0
enabled=0
EOF

and then install stuff with

dnf --enablerepo=provocation --enablerepo=epel install <package name>

Do not enable the provocation repo by default, because it contains other stuff that conflicts with epel.

The first thing is to iron out pure packaging bugs like the one above. No radio hardware is needed for that. When all the basic applications (tcllauncher, piaware, dump1090, mlat-client) can actually start and run and communicate with each-other, we’ll see about them being able to also do some actual work. I’ve got a new sdr dongle on its way from the UK for that purpose.

This thread is meant for general discussion, not as a bug tracker, so I set up a proper bug tracker here. With a bit of luck and a bit of help we might soon have a nicely packaged x86_64 FA application family.

So this means we can’t run ARM binaries on an x86 VM host, unless this problem is overcome. How long ago was it you did those tests? Did you test any other virtualisation environments, say KVM/qemu or VMware? Do you have any hunch whether the host OS could have anything to do with the packet loss, i.e. whether, all other things equal, running the VM on OS/3 might have worked out better than running it on OS/1?