An old station is identified by mac address, and there is no 128 bit id (long id xxxxxxx-xxxx-xxxx-xxxxxxxxxxxx) mentioned on the FA stats page.
However I noted that a 128 bit feeder id is assigned and saved in RPi
pi@piaware:~$ cat /var/cache/piaware/feeder_id
895008aa-1434-4084-4c91-f3dc0abe0e14
I deleted the cache file, and rebooted
pi@piaware:~$ sudo rm /var/cache/piaware/feeder_id
pi@piaware:~$ sudo reboot
Now checked, found a new feeder id is assigned
pi@piaware:~$ cat /var/cache/piaware/feeder_id
837dde67-e5f8-4bbe-8c1f-de874b993f64
I repeted “delete cache file and reboot”, yet another new id was assigned.
The station number did not change by this “feeder-id deleting/new feeder-id creation” game.
What is the purpose of this feeder-id, and why a new one is assigned on deleting current feeder-id?
I also found that old sites are still behaving as before to the mac address spoof. When I spoofed mac address, a new site # was alloted, and the pi started feeding it. When I removed the mac address spoof, the pi started feeding the old site.
Feeder ids are allocated even when the site is using Mac address as the primary identifier so that we can move the existing site to use feeder id without losing the existing site association when the time comes
I upgraded the hardware of my site and can’t configure is to my old feeder-id. It’s an older site recognized by it’s Mac adres. I did find a feeder ID in the old piaware logfiles and tried to configure that. Didn’t work.
Is there anyway I can get my old feeder stats back or is it really history, which would be a bit disappointing.
I added a test-site but this whole configuration exercise left me with 4 feeder sites.
pi@piaware:~$ sudo nano /boot/piaware-config.txt #scroll down to bottom of file and see if you can find a line “feeder-id xxxxxxx-xxxx-xxxx-xxxxxxxxxxxx # updated by fa_piaware_config”. If the line is there, delete this line, and save file. If you dont find this line, close the nano editor.
pi@piaware:~$ sudo nano /etc/piaware.conf #scroll down and see if you can find a line “feeder-id xxxxxxx-xxxx-xxxx-xxxxxxxxxxxx # updated by fa_piaware_config”. If the line is there, delete this line, and save file. If you dont find this line, close the nano editor.
(3) Spoof mac address as follows:
pi@piaware:~$ sudo nano /boot/cmdline.txt #this file has all text in one line. At the end of this line, add one space and add “smsc95xx.macaddr=xx:xx:xx:xx:xx:xx” (without quotes " "), where xx:xx:xx:xx:xx:xx is the mac address you noted from old site’s stat page.
Make sure that there is no line break between existing text and “smsc95xx.macaddr=xx:xx:xx:xx:xx:xx”, else the spoof will not work.
(4) Now reboot the pi for spoof to take effect.
Check your Flightaware stats page.
If you started from a piaware 3.3 sdcard image then upgrading the system packages has left your system in a broken state (see the announcement post in this forum); I suggest reimaging with 3.5.0, which should return you to the correct MAC address & site association.
I re-imaged a new card with the 3.5 Piaware image. I used a spare Pi, perhaps one not seen by FA before, and was assigned a feeder ID. When I got everything set up, I moved this card over to my the Piaware with the rooftop antenna. Let’s call it the production Pi. While it worked, it is seen as the test box and hence a brand new set of stats. That’s not the end of the world of course, but I thought I’d try to correct this. Note that the MAC spoofing in cmdline.txt did not work. i was doing that already since this production Pi isn’t the same one I started with years ago.
I took the feeder ID from the old production system. It has one, even though it was being identified by MAC address at FA. And put that feeder-ID into piaware-config. No love. It failed to sign on to FA. There was an error about invalid feeder ID and user/password. I don’t specify a user/password. I was spoofing the MAC address in cmdline.txt though.
The solution was to add force-macaddress into piaware-config as well as feeder-id. I was able to remove the MAC address spoofing from cmdline.txt. Now it all works and the stats continue under the old system’s identifier at FA.
Note this problem only arises if you use a different Pi to build your setup than you do to normally run it in production.
Hope this helps others who have a similar problem.
@Jranderson777
Since your microSD card was re-imaged with Piaware 3.5.0 image, and finally used in old production Pi, there was no need to spoof or force MAC address.
All you needed to do after sliping-in re-imaged microSD card in old production Pi and powering up, was to delete the feeder_id file in cache, and reboot.
NOTE:
For fresh installs (i. e. re-imaging to Piaware 3.5.0), the mac address spoof / force mac address is not needed for an old Pi already registered with Flight aware.
The MAC address spoof or force mac address may be required for upgrades from Piaware 3.3 (or older) to Piaware 3.5.0.
The Mac address spoof is also needed if you are replacing old Pi with a new Pi and want to retain old station number and it’s stats.
After installing 3.5 you can configure the feeder id as described in the top post via piaware-config, using the feeder id of your current site. You never need to configure FA credentials and those config options are going away soon.