So, I rebooted my rpi yesterday and suddently I have another “site” with an incorrect location marker that is getting my data. What would cause an rpi to show up as a new site on FA after a reboot?
Radar code is associated to Mac address if you don’t change your Mac address they are only two options, bug in flightware website or your rpi as been hacked
I see. It seems the mac address is different. That seems an awfully strange way to uniquely identify a receiver, since MAC addresses can change (such as with the replacement of bad hardware).
Does piaware have a configuration item where you can just tell it what site ID it is?
Did you change the hardware? The Pis have a hardcoded MAC that shouldn’t change.
You cannot change the MAC/site association on your side (currently). If you want to PM me the exact details I can take a look.
That is true for the on-board Ethernet port.
But, in any case, I think what happened was that the site ID took the MAC address from the wifi dongle even though that was not the default route (the wifi dongle was set up as an AP). All I did was remove the dongle and reboot, and then piaware picked up the MAC of the hardline and my Site ID changed.
You are not alone 
I have had the same issue. Wait 30 days and the new address will be the main one.
piaware explicitly looks for the MAC address of eth0 in sysfs, so unless your wireless dongle is showing up as eth0 (that would be … unusual) that’s not the problem.
If you want your PI to use the old MAC address, you can modify the /boot/cmdline.txt file adding smsc95xx.macaddr=##:##:##:##:##:## to the end of the line. (where ##:##:##:##:##:## = the MAC address you want the PI to use) The problem with doing this is that if you plug the other PI back in to your network without modifying it’s MAC too, you can expect some really odd behavior. If you are not using the ethernet connector at all, it should not be a problem.
Your cmdline.txt will look something like this
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline cgroup_enable=memory rootwait smsc95xx.macaddr=##:##:##:##:##:##
Cheers!
LitterBug
No no, piaware takes the Mac address of the active port : using the eth port then the WiFi generated me 2 different “equipments” in FA. And this is not good, I agree with you.
Obj is the author of the software package. And as he says, piaware looks for the MAC of eth0…
Ah, the internet. 
Bonjour…
github.com/flightaware/piaware/ … t.tcl#L816
It will use other devices if you have no eth0 device at all (and log about it); but all rpis have an eth0 device as far as I know.
Sorry if the thread is too old, but let me just see if I understand: My piaware instance is and always has been connected via the eth0 (ethernet) interface. Soon, I want to change to a wifi dongle since the unit will be mast mounted. Are we saying that the MAC address associated site for identification purposes will not change to the MAC address of the wifi dongle I plan to use? Thus, the stats should be preserved?
Just to complicate this…my piaware/dump1090-mutability is running on a Beaglebone Black.
Cheers, Brian
Are we saying that the MAC address associated site for identification purposes will not change to the MAC address of the wifi dongle I plan to use? Thus, the stats should be preserved?
Yes for raspberry pi. Eth0 MAC is used as the identifier, even if you are wifi connected. Not sure about beagle
Many thanks for your answer! I will report back if there is a difference with a beaglebone.
Cheers, Brian