1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Question regarding speed of internet connection required

Discussion in 'Feeding' started by ktb, May 3, 2019.

  1. ktb

    ktb Member

    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. :-(
     
  2. theredguy

    theredguy New Member

    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.
     
  3. ktb

    ktb Member

    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.
     
  4. MDA

    MDA Administrator Staff Member

    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.
     
  5. ktb

    ktb Member

    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.
     
  6. MDA

    MDA Administrator Staff Member

    I don't know if LTE Internet will be available in your new place, in Poland prices are not bad :).
     
  7. ktb

    ktb Member

    I'll have to check and see if it is.
     
  8. James

    James Administrator Staff Member

    It will work on very slow internet. 128Kbps ...
     
  9. ktb

    ktb Member

    128 kbps ... that's good that feeding doesn't require a quick 'net connection.
     
  10. James

    James Administrator Staff Member

    We had it working in Phoenix (KPHX) airspace on a 64kbps iot cell connection. It worked, but it made ssh and remote management tough.
     
  11. paulCIA

    paulCIA New Member

    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.
     
    Last edited: May 17, 2019 at 1:02 AM
  12. MDA

    MDA Administrator Staff Member

    But Flightaware feeder is feeding Flightaware not ADSBx. And installs backdoor on your machine.
     
  13. James

    James Administrator Staff Member

  14. paulCIA

    paulCIA New Member

    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
     
    Last edited: May 17, 2019 at 4:22 PM
  15. paulCIA

    paulCIA New Member

    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.
     
  16. wiedehopf

    wiedehopf New Member

    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.
     
  17. MDA

    MDA Administrator Staff Member

    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.
     
  18. wiedehopf

    wiedehopf New Member

    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.
     
  19. MDA

    MDA Administrator Staff Member

    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.
     
  20. wiedehopf

    wiedehopf New Member

    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.