In a couple months, I'll be leaving my current living location. My new location will be very rural, at an elevation of 365 meters ASL... double my present elevation. I'll also have a clear view of the horizon with no obstructions, so it's an excellent place for adsb feeding. That's the good news, but there are concerns. I'll be approximately 130km from the nearest adsbx "feeder" as seen on the MLAT coverage map. What concerns me is that I don't know what the quality/speed of my internet connection will be. I presently have a good high speed broadband connection, but that won't be available at the rural location. I'm wondering what the minimum (speed/connection) requirements are to feed ADSB-X. I don't have any more info (yet) on the type of service or the connection/speed will be, or even if there are "data caps" on that service. It may be that I'll have great coverage of 'craft reception but won't be able to feed the data. :-(
I'm new to this whole thing but from what I have read the data we all send is really small. For instance my FR24 feed is using 50bytes to upload the data and I would imagine the other three I have running won't be much different. All in all as long as you have a connection that's always on such as cable/broadband then I doubt it will matter.
A connection always on... then it sounds like anything other than a "dial-up" connection would work, like DSL for instance. I'll be living 11km from the nearest town (small town) so I'm not sure even DSL will be available to me. Thanks for your info.
Amount of data transferred: yesterday rx 246.06 MiB / tx 1.71 GiB / total 1.95 GiB Apr '19 5.29 GiB / 37.28 GiB / 42.57 GiB ~1250 aircrafts/day, message rate up to 600/sec.
Thanks for the data info MDA. That's more data uploaded than I thought per day. Presently, I'm near a couple major airports... might have something to do with the volume uploaded.
We had it working in Phoenix (KPHX) airspace on a 64kbps iot cell connection. It worked, but it made ssh and remote management tough.
The MLAT client takes much less than feeder. You don't need to feed to view your data, you would just have to setup something like Flightaware's Piaware, which has an easy automated installer for a raspberry pi but will run on any mac or linux box with extra setup. I think there may also be a local web viewer built in to at least one version of dump1090 but the one I tried was broken last I checked and I never bothered with it since I had piaware setup anyway. My receiver is currently processing about 1000 mode s or mode ac messages per second with 60-100 active aircraft. MLAT client is reporting about 16 kbits per second upload. The feeder is taking between 100-150 kbits per second up. Will vary with number of messages of course. Some people get a whole lot more some people don't get much, depends where you are, how clear your view to the sky is and what type of RF receiver setup you have. If the feeder is causing problems you could also manually throttle it somehow by say, dropping every other message, there is so much practically redundant data in the stream you might not even notice. Flightaware's feeder significantly cuts down on the amount of traffic by only sending an update every 10 seconds per aircraft and sending it in a binary format that takes up a lot less space than SBS. Can't really control the data format but instead of having socat send the entire stream you could pipe it through a script that only passes on so many messages.
...... but but $99 value 'enterprise dashboard'. If you are going install anything that doesn't need to feed a site due to Internet connectivity, at least ADSBx custom image has a dashboard and all kinds of goodies. ADSBx image has a built in vector map that doesn't need to talk to Internet. https://www.adsbexchange.com/forum/threads/working-new-adsbexchange-base-image-v1-0.618988/
Yes, I didn't mean to say you could use their feeder to feed exchange verbatim. Just that the general concept of significantly cutting down your upload data rate by not sending every single message can be applied here as well since it just forwards the entire raw stream. If you don't install a sudoers config the backdoor can't do anything because the process runs as an unprivileged user otherwise. But it's definitely pretty terrible that it installs that by default. I even had it. Now removed. Thanks for pointing that out! It's supposedly secured by TLS but what if someone were to break in on their end... and not sure how well, there's good TLS and there's also a whole lot of bad TLS that does nothing. Surely a 0day just waiting to happen
True, that's a better option if you have an arm box handy but I'm running all this on amd64 and if there is a build for that I couldn't find it, and don't have time right now to build put it all together myself, but if I do I'll post the scripts! There's always QEMU I suppose.
Just out of curiosity, could you elaborate? Do you mean the update function you can turn on and off? Pretty sure the commands are hard-coded, maybe take a look at the source code, it's available on github.
Code: % info commands tell socket subst open eof pwd glob list pid exec auto_load_index time unknown eval lassign lrange fblocked lsearch auto_import gets case lappend proc throw break variable llength auto_execok return linsert error catch clock info split array if fconfigure coroutine concat join lreplace source fcopy global switch auto_qualify update close cd for auto_load file append lreverse format lmap unload read package set namespace binary scan apply trace seek zlib while chan flush after vwait dict uplevel continue try foreach lset rename fileevent yieldto regexp lrepeat upvar tailcall encoding expr unset load regsub history interp exit puts incr lindex lsort tclLog string yield Who controlls this shell controlls this pi.
It's a programming language like others are as well. Unless you point to a concrete backdoor to execute arbitrary commands via the server connection you are just hand-waving. Any feed client or any program you install would be a backdoor by your definition. (Granted not every program has a handy permanent connection to a server but that still doesn't mean it's a backdoor) You offer a complete sd-card image, who controls that controls the pi.
Thats why i'm building own images. Just don't like "handy" solutions out of control. Never said "don't install this", just informed about backdoor. Most of users installing ready images are even not changing default passwords so this is really potential security risk.
A backdoor implies that the software is actually programmed to accept an arbitrary command via that server connection. Calling it a backdoor just because it has a connection to a server is misleading in my opinion.
