Adding a second station...

FlightAware ADS-B Flight Tracking
21

So your problem now is that dump20190 is not running, so even if its reporting it has nothing to report.

Check the dump1090 log and see if there is any error messages, did you set your location? You can always check /etc/default/dump1090-mutability settings file has a location set.

In answer to your question, restarting the service or restarting the pi should do the same thing, it should be very rare you need to restart the entire pi - the one I use for dump1090 is usually up for 100+ days at a time.

The only exception would be if your changing kernel drivers for the rtl stick - restarting the service would not affect that but a reboot would (there are other commands to do the same without a reboot but lets not get too sidetracked :wink: )

22

Cheers, WhiteCitadel…

Nope, not messing around with kernals on the stick… :wink:

(Though AFAIR there is some benefit to that re overheating from the INMARSAT guys… :wink: Not doing that here tho ).

K, will look into dump1090.

From memory, doesnt OBJ’s dump1090-mutability replace fA’s dump1090?
I wasnt too worried about dump1090 not running, as it says…


dump1090-mutabi is listening for connections on port 30005.

… so assumed if it’s listening, its working?

I’m obviously wrong in that, so will investigate as you suggest.

Thanks for your help - appreciate it mate :slight_smile: - no idea how this has got so screwed up, it was a clean install of Jo’s ADSBReceiver image I installed about 2 weeks ago! lol
(No disrespect to Jo).

With this 2nd receiver being at my Dads, c350 miles away, and his interest waning at best - I dont have 24/7 access.
I’ll have to get him to port forward 22… :slight_smile:

23

When I exposed port 22 to the internet I had login attempts roughly EVERY hour. They appeared to general opportunity scanning as opposed to a prolonged attacks.
I configured another port for SSH instead of 22 and not seen an attempt for months. Don’t use default password. :slight_smile:

24

If you have to open port 22 - install fail2ban that will use ipchains to blacklist attackers for X time, you will get port scans and attacks immediately if you open port 22 in my experience…

So yes if its another dump1090 running then fine - as long as that instance is reporting… could be a port number issue I suppose… hard to tell without poking around :frowning:

25

Sorry leading you astray, that is to be expected, here is my output:


dump1090 is not running.
faup1090 is running.
piaware is running.
dump1090-muta is listening for connections on port 30005.
faup1090 is connected to port 30005.
piaware is connected to FlightAware.
dump1090-muta is producing data on port 30005.

So seems to be running ok (assume you get the map up ok right?) - and you claimed the piaware by MAC address as support said above?

26

Cheers WhiteCitadel.

Yup, get the Live Dump1090 Map on the UI - works fine.

Even PlaneFinder UI works and confirms as feeding to them.

I’ll get the MAC and update Admins for check (the MAC I gave before was for the Zero I built the SD on, before posting it to my dad for use in his Pi… :blush: :unamused: )

27

@Boab - yes, on my own Pi, I use a completely different port, have it locked down not to accept manual login entries, and to use SSH keys.
Its also set to only accept SSH from the fixed internal IP of my PC.

PITA setting up SSH keys, but it works fine from the PC I set it up on… cant quite figure out how to share the key with other machines, but there you go… :wink:

28

You need to add the key to authorized keys on the other host, have a look at the many guides on the web, example:
https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Transfer_Client_Key_to_Host

29

Cheers @WhiteCitadel, - will take another look.

@FlightAwareAdmin - the MAC of that second station is


Link encap:Ethernet  HWaddr 00:e0:4c:53:44:58

.

Can you confirm that’s showing up on the fA network?

30

Morning gents,

Few more log outputs:


05/24/2016 00:00:11 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:00:42 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:01:32 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:02:02 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:02:52 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:03:23 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:03:34 29528 msgs recv'd from dump1090-mutabi (95 in last 5m); 294$

05/24/2016 00:04:13 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:04:43 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:05:33 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:06:04 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:06:54 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:07:25 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:08:15 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:08:34 29626 msgs recv'd from dump1090-mutabi (98 in last 5m); 295$

05/24/2016 00:08:45 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:09:35 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:10:06 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:10:56 mlat(10964): Beast-format results connection with feed.adsb$

05/24/2016 00:11:26 mlat(10964): Beast-format results connection with feed.adsb$

Statistics: Sun May 22 05:35:37 2016 BST - Sun May 22 06:35:37 2016 BST

Local receiver:

8640266240 samples processed

0 samples dropped

0 Mode A/C messages received

18064177 Mode-S message preambles received

8592147 with bad message format or invalid CRC

8560504 with unrecognized ICAO address

841433 accepted with correct CRC

70093 accepted with 1-bit error repaired

-38.5 dBFS noise floor

-22.6 dBFS mean signal power

-2.4 dBFS peak signal power

280 messages with signal power above -3dBFS

Messages from network clients:

0 Mode A/C messages received

0 Mode S messages received

0 with bad message format or invalid CRC

Odd - everything looks OK from what I can see?

I now have direct SSH to that box - using weaved.com.
Others might find Weaved useful, connects through a 3rd party - but doesnt need any ports manually opening, and security is huge.

Can be a bit slow (at least the free tier) but would recommend as a quick alternative to piling on your own, local security etc etc.

Have mailed fA support with the MAC of that box - really cant see what else it can be, though I do have a sneaky suspicion it’ll turn out to be something obvious!

31

Somewhat limited range due to the receiver

a) Being “only” in an upper, south facing window
b) 100ft cliff directly behind my dads to the north :wink:

Still, shows dump1090’s working…

https://docs.google.com/drawings/d/1p7CwiM8O0U50SNxdqrSFwPxSsgidtLQaXT3lp1Rnsco/pub?w=960&h=720

And Performance stats (No amp, will get sat amp and psu in shortly):

https://docs.google.com/drawings/d/1nTmyz7VbYXKwQ5RBNxcnZeaupgZ9K7_Qc-NkP_LtPQU/pub?w=960&h=720

And PlaneFinder web UI, showing live feed (so it’s not a network connection issue)

https://docs.google.com/drawings/d/13mFlxsLQaD-676mQtbXdKV_CLanykcycaI5a5Uwh_6k/pub?w=960&h=720

32

Grasping at straws here, but FWIW…

a) The original MAC is discussed with fA admin was for my pi zero, the one I built the SD image on.
Have since updated with the correct MAC of dad’s pi.

b) When I was building the SD card, I set the receiver location as dads, but then was obviously running it (for a couple of hours) from my place c350 miles away…
Of course, this showed the receiver location being 350 miles south, but with aircraft up near me…
Any chance this “incorrect data” could have got the receiver banned or other wise confused? (Bearing in mind it’s now on a different MAC?)

c) When I tested my own Zero some months ago, as it was a new MAC to my usual Pi2, it showed up as a second receiver… (NB - im not using that Zero now).
AFAIR, a second receiver tab should show up under the map, along side the current receiver ID, in fA stats?

d) Shouldnt be an issue - but this second station is running on a Pi Zero… AFAIR, Zero’s have been successfully used and tested for fA?

33

Hmmm, according to the Feeder map, fA doesnt know about that second receiver?..
(It’s actually in the SSE of the Island, Ventnor).

https://docs.google.com/drawings/d/1qlZcb4HwO_rEmnVTfqVoEL1xxesmuhIiZo8NKWnoHDY/pub?w=960&h=720

34

Looks like a duplicate MAC address.

35

Really? Would never have thought to look for that…

Now you mention it, I do recall something about Orange Pi’s having duplicate MACs (not directly related, but possible).

I’d have thought the Pi’s werent made so cheaply as to have that issue (unlike the oPi’s) , BUT, because the Zero has not native NIC, it’s running off the micro usb into a USB hub / RJ45 connector.

Me and dad have the same hub/Rj45 product (obv not the same instance) - a cheap Chinese thing that cost c£4.
That said, my own Zero / Rj45 doodah isnt in use at the moment (though I did use this to set the card up), so it wont be a dup live MAC between those devices, but could be duplicated in the wider “device-world”?

Without an onboard NIC, would the MAC be coming from the connector or (presumably) based on the Zero’s serial number, as with the oPi’s?

My Zero MAC: 24:3c:20:05:bf:3a
Dad’s Zero MAC: 00:e0:4c:53:44:58

So perhaps not that…?

36

piaware uses the mac address of eth0 if present. On a Zero there is no built-in eth0 but if you have a USB eth0 it’ll use that MAC. It never looks directly at the Pi serial number.

It looks like the 00:e0 MAC is colliding with another user who presumably has the same type of dongle and the manufacturer is not good about making them unique.
You will probably have to override that MAC.

37

OK - think we’ve got it here…

Just got a response from fA admins (thanks!) saying that that MAC of my dad’s zero had been traced to a feed from Latvia!

So, in the “wider-device” world of Zero’s looks like they are duplicating MACs.
Based on this, I believe dad’s PI has been “kicked off” the network, as a prior feeder has that MAC…

That might be a useful word of warning for anyone else trying to use a Zero…

Am in email comms with fA admin, will post any outcome…

38

Thanks @Obj - you were right!

Agree and understand the MAC being set from the dongle, have seen a few methods of manually setting the MAC, which will hopefully over ride that duplicated one.

How to “choose” a unique MAC though?

39

Got any ancient network cards in a box? Some 10/100 with thick ethernet your not using - copy that. If you use an old card/machine you control - no chance of conflict (You hope).

Its not the Pi Zero that’s the problem in you case, but the cheap dongle that’s eth0 that has a duplicate…

40

Thanks @whitecitadel, might try that…

Trying to identify dads Zero on the fA network, wanted to use his public IP to help track it down…

Got an email from dad with one public IP, then a few hours (!) later with a new one…

(Usual, non-commercial IP’s do change, but not that quickly!)

I asked dad if he’d rebooted the router, and apparently he reboots the router to get a different IP so “his surveys” will let him retake the survey… :unamused: :imp:
Gahh!

Unless fA can think of a way of identifying the receiver without a unique MAC (though will try what you suggest @whiteCitadel - great idea :slight_smile: ) , I may just give the Pi to someone else on the Island…