When my son was younger - maybe 9 or 10 or so, we were on a plane and he was using his phone and I looked over his shoulder and realized he was on the internet... but I hadn't paid for an internet plan. I said, "son, how are you using the internet?" He said, "oh, a kid at school showed me - if you go here" (he opened up the wifi settings where the DHCP assigned IP address is) "and start changing the numbers, eventually the internet will work." Apparently, at the time, on American Airlines, when somebody bought and paid for an internet plan, it gave them an IP address and authorized it to use the internet... if somebody else guessed your IP address (which was pretty easy, it was a 192.168 address) and spoofed it, they could take over your internet connection with no further authorization.
I had to tell him not to do that, but I was kind of proud of him for having the temerity to go for it.
lol, I used to do this all the time at non-free wifi hotspot locations, only I'd start off with a ping sweep of the entire subnet (nmap -sP) in order to get my ARP cache filled with a bunch of potential usable IP/mac addresses on the network. From there, I'd iterate through each one and set the IP & mac address until I found one that would let me through the firewall.
Granted, being a NOC engineer at Wayport (now AT&T WiFi) certainly helped me understand how it all works.
Yes the key to doing this more seamlessly is to spoof both the IP and the MAC so your machines are not constantly fighting with the other person over the ARP table entry.
If any lawyers or FAA employees are reading this I’m genuinely interested in what, if any, legal implications there would be for running nmap mid flight on an airline. Surely once you have spoofed the MAC address and IP of another passenger to gain unauthorized access to the planes LAN you have committed a crime but what about passively scanning?
I used to do this on airplanes and in hotels. I had more success in hotels, because there was less chance the other person was using it at the time and less chance of getting kicked off.
There was another little hack that I used as a little kid. Remember when airlines would sell or rent special headphones to watch inflight movies? The port was just two holes beside each other and the plug was two tubes. Before a flight, I would stop by one of the fast food places in the terminal and grab a handful of straws (preferably ones with a bendy joint). When I was on the plane I would connect the straws by fitting them into each other to create a long straw. Put one end into the port on and the other into your ear and you got free movies with audio!
A few years ago I was on a Southwest flight and had OpenVPN running because I forgot to turn it off. I was able to access the Internet through my tunnel without paying for access. I guess at the time they were only port blocking common ports (80, 443, 53 etc) if you didn't pay. They have since closed that hole.
For this same reason you used to be able to send messages via platforms like whatsapp without internet as well! I don't remember the airline I just remember I hadn't paid for internet but I could message and do a few other things but I couldn't browse the internet.
The state of "open Wi-Fi" security is actually really sad. I'm not aware of an easy way for the airline to actually do better than this!
I suppose they could use Opportunistic Wireless Encryption [1] and bind session authentication to that (i.e. authenticate a given OWE session, not a given MAC address) if the device supports it, as at least modern Apple devices do? But I have no idea how stable an OWE session is; it would be very inconvenient to have to login again every time my device switches between access points.
In any case, I'm sad that this isn't a solved problem yet, and paid Wi-Fi (as well as securing free Wi-Fi) still requires custom and clunky solutions like unreliable captive portals that need to pass through selective traffic (e.g. for 3DS, for payments, sometimes emails for password reset codes etc and more).
A standardized endpoint and API would also be nice, i.e. something to tell the client whether it's connected, restricted (i.e. able to only access a limited set of hosts such as the in-flight map as described in the article), or needs to pay/authenticate (and if so, at which URL). This could then yield an authentication token, to be provided for seamless reconnections for the same session.
There's "Hotspot 2.0" and WPA-EAP (i.e. WPA Enterprise), but these don't really have a good story for "pay via web portal" style usages and are more geared towards wireless carrier operated hotspot networks and corporate scenarios, respectively.
In cases where the Wi-Fi is provided as a value-add or is bought via another channel than the Wi-Fi network itself, I think you can just generate one-time WPA Enterprise credentials, with a QR code to facilitate data entry?
In case of in-flight Wi-Fi, the credentials/QR code can be printed on the boarding pass, or available in the app (the app caches it in advance while it's still on the ground, so when in the air you can use those credentials to connect).
This doesn't cover 100% of use-cases but it would at least cover a big one (a significant amount of public Wi-Fi is "value add" to another service - whether restaurants, hotels, flights, etc where there's an existing channel to provide one-off wi-Fi credentials over), it's a shame nobody deploys this.
What if the captive portal just had a link (or on an IFE screen, a QR code) that connected your phone to a different, WPA2/WPA3 protected, hidden WiFi SSID that was generated exclusively for you? Phones nowadays support joining a passphrase protected WiFi AP via a QR code, so I'd imagine that's doable. The hard part would be finding routers that support >300 different hidden SSIDs, but honestly I would hope that that is technically feasible nowadays.
That way you'd at least have the protection of the WPA GTK.
You can always use an open network to generate passwords for the proper internet connected WPA-EAP network (along with some in-flight multimedia like some carriers do). Extra step for sure but it solves the problem.
PS: I'm a couch expert so I have no idea if there's a problem with this idea.
Isn’t this data meant to be exposed? You can get all this flight status on the Southwest intranet when you’re connected to WiFi as part of the flight status page.
This hack just goes a step further to plot the data over time.
There used to be an app that would scan the ip and mac addresses on the network that were already connected to the internet. You could then change your settings to one of the mac addresses and when they were done you'd get the connection to yourself.
I used to travel a lot for work and just refused to pay for WiFi. This was good in airports and coffeeshops when you still had to pay to connect.
Now it's hardly needed, but I could see how it would be helpful where there's still a cost to connect.
It’s not an app, per se, but a concept of setting your WiFi card into monitor mode and listening to the radio traffic. Kismet is one of the suites that does that.
Love stuff like this, it's how kids get into computers. I used to make minecraft servers for my friends and I to play on when I was 12, which lead to a software engineering career. Sounds like you've got something similar on your hands
A slightly more ethical solution, for those wondering, is SSH tunneling. A lot of gated wifi networks allow SSH traffic through without payment.
I used to spend a lot of time at JFK back when they still charged for WiFi. I watched a lot of Netflix for free by just logging into my router and opening a tunnel to my VPN server.
The LAN here seems relatively small and fixed, i.e., the number of passengers on a flight is known and does not change during flight. The airline could easily assign a unique IP address to each seat (ticket) without using DHCP.
This is generally in contrast to other instances of public Wifi.
I think kids sense wrongness even when the act is deemed victimless, repercussionless, etc. -- it's pretty clear that a thing was achieved that someone tried to prevent, and undermining someone's effort is typically wrong. Tough to think like a kid, though!
This is what I did about 7-8 years ago on flights when I was still a reckless teenager. Would just wait for people to buy the plan, then spoof their Mac address.
There was also a specific airline, although I can't remember which one, which let me in for free without MAC spoofing - by using a Google Cloud VPN I had previously set up. The paywall was essentially blocking all IP ranges except for Google servers for Google Analytics.
This is what I used to do at home when my dad would turn off my internet access (by whitelisting MAC-addresses. Before that he blacklisted MAC-addresses, but I just used the built in way to change it with each connection on windows until he found out.). My mom rarely used her PC so I would just change my address to hers. It worked until she had to use it and at that point none of us could access the internet.
“According to this data, the plane’s altitude was only fluctuating by about 20-30 feet. This is more stable than I expected!”
Autopilots are very good and they are servoing to the pressure altitude.
Many pressure altitude encoders used in modern aircraft (for example to drive altitudes that transponders report to SSR radar or via ADS-B) have 25 ft encoding resolution. That 25ft resolution is likely what is being seen here. Other encoders have 10 ft resolution but 25 ft is very common.
I don't know what sensors are feeding the API from the post, but most passenger jets do broadcast information about the accuracy of their sensed position, including vertical position/altitude. If you click on an aircraft on the map at https://globe.adsbexchange.com/, and scroll the left sidebar all the way to the bottom you'll see a section labeled "Accuracy". ADS-B Exchange doesn't show Rc/v, the vertical position accuracy, but it does show other values. See https://mode-s.org/decode/content/ads-b/7-uncertainty.html for more information.
Pressure encoders, as I said. That's what feeds all aviation altitude data... i.e. anytime you see the word 'altitude' and its not qualified with 'GPS altitude' which is effectively not normally used. ADS-B Out concurrently transmits GPS height about the ellipsoid data as well as pressure altitude data. No use is normally made of the GPS height data. We are discussing pressure altitude data here, that's what aviation works off of. The accuracy and reliability metrics in the ADS-B broadcast you are referencing refers to the GPS data not the pressure transducer/encoder data. In cases of encoder failure being detected a flag is broadcast and the pressure aka baro altitude data field is set to all 0. ADS-B cannot give information about the pressure altitude accuracy or reliability like it does for GPS metrics. It relies on the encoders being better than their +/- 125' accuracy requirement and that's tested for periodically. ADS-B can in principle broadcast 100' or 25' resolution encoders, that info is in the messages. The ones here will be 25'. (I've got a long background with ADS-B related technology, currently helping the FAA out on some niche stuff).
edit: trying to improve clarity/correctness but there is too much to cover here.
For small planes a 20-30 foot range isn’t abnormal for hand flying if you’re paying attention. I’m sure in cruise an airliner is using an autopilot though.
I once had ATC ask if everything was cool on flight following after a hundred foot drop and I was surprised they were paying that much attention. I had forgotten to put my life jacket on before a water transit and while I was putting it on handed it off to my wife who hadn’t taken lessons yet (she later got her license!). It was interesting to see that their tracking was precise enough for them to chime in.
>> Autopilots are very good and they are servoing to the pressure altitude.
It would have been cool to use a phone to record a GPS track with altitude and compare them. Pressure != GPS. Also wonder if there would be distinct jumps in the difference if they reset the pressure based altimeter to a different AWOS.
Not sure how it works in big planes, but in little ones you need to set your altimeter based on the local weather. The weather stations measure barometric pressure at their elevation and "correct it to sea level" you get this corrected reading over the radio and set it in your altimeter so your pressure-based altitude reading is corrected for local weather variations. Just going out flying for an hour the altimeter setting when returning to the same place might be off by a few millibar.
The QHN/Kollsman window setting only affects what is displayed to the wetware. When you strip away all that the autopilot is just servoing to a pressure altitude. But sure if you are flying below the transition altitude and are flying between areas with different QNH settings when you adjust the setting the autopilot will climb or descend as needed because you told it to servo to a different pressure altitude.
There are many EFB (e.g. Foreflight), or log book, or other flight recorders you can use on an iPhone. And some can record the pressure transducer in the iPhone to record an approximate "pressure altitude". e.g. Naviter SeeYou Navigator intended for gliders can do that (but it's not unusual for modern gliders to have an array of sophisticated air data sensors and specialized variometers and flight computers that would feed the app this data over Bluetooth). Popular EFB software Foreflight will not use the iPhone pressure transducer, if you want pressure data there you need to drive that through an external interface like a Sentry ADS-B receiver that has a pressure sensor built into it -- or much better if the aircraft is equipped with ADS-B Out can receive the "own-ship" ADS-B Out broadcast pressure altitude from it's high accuracy encoder). Any in-cabin pressure traducer will be sensitive to the difference between calibrated static pressure and cockpit pressure, things like opening or closing vents, or varying the airspeed significant (and ram air pressure or suction on the cockpit exit vents) can cause observable changes. And when using an iPhone or similar, especially without a great GPS satellite overhead view (e.g. in high wing aircraft) you are likely not to get high-quality GPS altitude data. think best case ~ +/- hundred feet, worse case with little overhead GPS sat view, much worse... but those consumer GPS app is likely to happily display multiple decimal points of precision :-)
You use standard pressure (29.92 inHg) above transition altitude, which, in the United States, is 18,000 feet. Pilots wouldn't be changing the altimeter after climbing past this point, and would start using local values once descending through it again.
Of course, your initial point is still correct: there could be slight variations if using those local settings and getting different values, but you'd only see that below transition altitude.
At high altitude you do this stuff "When you set your altimeter to 29.92, you're flying at standard pressure altitude."
The idea is all the planes use the same setting so the one at FL35 doesn't hit the one at FL36. But those are not exactly 35000 and 36000 feet above sea level.
I guess they got a lot more precise with implementation of Reduced Vertical Separation Minimum (RVSM) - planes had to be separated by 2000 ft and this was reduced in early 2000s to 1000ft
It was probably fairly precise already. To get their license, a private pilot must demonstrate via a checkride the ability to stay within 100 feet of an assigned altitude, even in a steep turn.
I have read somewhere that so much precision could actually be dangerous in some circumstances.
This is because this way, if a pilot goes 3000 ft for instance, it will be exactly 3000 ft, if another pilot also wants to go 3000 ft on a collision trajectory, it will be a guaranteed collision. When altitudes are not that accurate, there is a higher chance it being just a near miss. The solution, I think, was to simply avoid round numbers. So now, it is 2950 ft, 3050 ft,...
I may have the details wrong, but I am quite sure about that problem being seriously considered.
Yes, it's called the navigation paradox, and it mostly came about with the advent of GPS. It's the reason we now have what's called "strategic lateral offset procedure," or SLOP, whereby aircraft on heavily trafficked oceanic routes fly zero, one, or two miles off the centerline, randomly chosen.
When I am on a flight and the flight does not provide the flight information, I am using the OsmAnd, https://osmand.net/, to monitor the flight altitude, speed and direction.
No idea how true it is, but I overheard someone on a flight say that whenever you feel a real sudden jolt on a plan it's really only moving like 2-3ft.
A plane going up and down 20-30 feet seems like it would be very unpleasant. Considering that there's longitude and latitude, isn't it more likely that the altitude is coming from GPS, which is notoriously inaccurate with regards to elevation?
20-30 feet change over what timeframe? The resolution of the chart data in the article is about 30 seconds. While I think the fluctuation is due to the accuracy of instrumentation, 20-30 feet change over the course of a minute seems like nothing.
Planes report pressure altitude via their transponders. 20-30 feet up and down is very normal for an autopilot.
GPS altitude is used for vertical guidance for certain types of GPS approaches (i.e. "LPV" approaches[1]) and requires the airplane's avionics to be equipped with a WAAS[2] receiver that provides accurate altitude information.
When you take off, you're going up at a rate of 500 fpm to 2000 fpm. Even if you go from +1000 fpm to -1000 fpm over the course of several seconds, you aren't going to feel much.
At cruise altitude, you're moving along at 500 mph, which is 777 feet per second. So going from +30 feet to -30 feet in a minute is just an adjustment of only about 5 degrees. You'd barely feel it, even walking down the isle. An acceleration of 33 ft/sec per sec is 1 g.
You experience greater changes in vertical motion on any flight you go on.
Thats funny, I discovered the same thing a few months ago and built a CLI flight tracker[1] that uses the API. I've tried it across a couple of airlines and it worked almost perfectly across all of them, because they were all using the same in flight ISP.
That's cool! I had wanted to make something similar, but I didn't have enough experience with making TUIs to build it without using the internet for reference during the flight. I'm glad to that it's been done though!
Interesting how they chose to make more general `vehicleId` instead of `planeId` or `tailNumber` or something. I wonder if Delta's fleet includes other things that have matching APIs to this one. I also wonder how much of their internal system structure one could learn from the `flightId` if they knew about other systems. It doesn't look like much beyond a composite key of otherwise knowable data, but still interesting.
It'd be interested to make a little HTML page that can query the api for each airline that exposes something like this and give you an in-flight display on your laptop.
I want to see someone build a proxy that uses the free iMessage or WhatsApp allowed connection to send arbitrary data.
Like have a WhatsApp relay set up at home that you are sending messages to and from, from the plane.
Like at a most basic level, send a message of a URL to your home WhatsApp which loads the web page there, and sends the HTML back as a WhatApp message reply so you can render it etc.
Wonder what someone could all do and make work.
edit Guess someone made a TCP relay using WhatApp already, neat.
I've not read the EULA but why not just have an actual IP router?
Pay the signup charge, and also stand up a wifi network. Call it "Foo discounted" if the plane's SSID is "Foo". Put up a captive portal that lets the user claim various "discounts", like veteran, senior, child, etc. No matter what they choose, charge them $2 via a payment page. Once you've been made whole on the service cost, future visitors get a notice that "all discounts have been claimed, please use Foo".
Now you have free internet and all those using your router/portal have $2 internet. The upstream bandwidth is certainly atrocious so you will easily be able to multiplex all the data onto your connection.
Bundle it into a RPi kind of device (has to look finished, like a music player or smth, to get past security) so that you can continue to operate the device even when tray tables have to go up, when you go to the bathroom, etc.
I find it extremely doubtful that the airplane has WIPS or WIDS that will deassociate
connections to your rogue wifi. And after all, are you not allowed to have a LAN party?
I happened to have had a flight a day or two after the first beta of Apple’s Private Relay a year or two ago. I was able to use free WiFi the entire flight. Presumably because whatever they whitelisted for iMessage and/or push notifications covered that as well. They had blocked it before my return flight days later. ¯\_(ツ)_/¯
Instead of “wow, cool” my first reaction is “free messaging is a great perk, if this is abused they will shut it down”. I guess my hacker days are behind me.
Airlines already introduce free WiFi to everyone for free. JetBlue does it, Delta also does it for continental flights. Eventually all will, as there is more competition in the tech and prices drop.
I've noticed that airline wifi doesn't block DNS traffic. You can likely accomplish the same thing with a DNS tunnel like Iodine (https://github.com/yarrick/iodine).
Many years ago, I noticed I could browse the Google Play Store on a flight WiFi without paying for it. No images would load and no apps would download, but I could browse through app listings and read reviews.
Flighty leverages the Apple Push Notification Service (APN), which the iMessage infrastructure also uses. It's why you can receive notifications in flight but can't act on them.
Way back in the day a lot of authenticated wifi firewalls did enable DNS requests to pass through, or at least to resolve using their DNS server, without being authenticated.
Someone smart created a TCP-over-DNS tunneling tool that I had a lot of great experience with, at least for more simple news websites of the day.
But SouthWest will give you a much prettier display of that same data (track your flight, see the current altitude and ETA, and a lot more, like the plane's position on the map) without paying for their WiFi. My guess is that they are using the same data that article writer wrote a program to process. Essentially there is one site you can visit for free and that's where it is.
I was on some US flight recently - maybe Alaskan airlines - and they basically had a LAN box with movies and shows accessible on wifi without internet access
I was just thinking that you could take a picture from the window and then tie the GPS coordinates to the image with the output from that JSON. Kind of handy.
I think the "and" in that sentence used to be implemented as an "or" in the days before everyone's phones had GPS in them. So you'd need to power cycle the device before it'd work again. Now most devices need to hit both limits at the same time before refusing to work.
Readit News
I had to tell him not to do that, but I was kind of proud of him for having the temerity to go for it.
Granted, being a NOC engineer at Wayport (now AT&T WiFi) certainly helped me understand how it all works.
https://github.com/aselvan/scripts/blob/master/macos/free_wi...
There was another little hack that I used as a little kid. Remember when airlines would sell or rent special headphones to watch inflight movies? The port was just two holes beside each other and the plug was two tubes. Before a flight, I would stop by one of the fast food places in the terminal and grab a handful of straws (preferably ones with a bendy joint). When I was on the plane I would connect the straws by fitting them into each other to create a long straw. Put one end into the port on and the other into your ear and you got free movies with audio!
20 years ago, all I saw were dual mono bayonet jacks you'd need an adapter for to plug in normal headphones, but straws would get you nowhere.
I was curious so I searched: https://simpleflying.com/inflight-entertainment-headphones-e... - pneumatic headphones from the 1960s were used on Delta as late as 2003, but electronic headsets debuted on 767 in 1982.
Apparently the dual mono jacks are to discourage people taking the headphones, rather than restricting access to audio.
The state of "open Wi-Fi" security is actually really sad. I'm not aware of an easy way for the airline to actually do better than this!
I suppose they could use Opportunistic Wireless Encryption [1] and bind session authentication to that (i.e. authenticate a given OWE session, not a given MAC address) if the device supports it, as at least modern Apple devices do? But I have no idea how stable an OWE session is; it would be very inconvenient to have to login again every time my device switches between access points.
In any case, I'm sad that this isn't a solved problem yet, and paid Wi-Fi (as well as securing free Wi-Fi) still requires custom and clunky solutions like unreliable captive portals that need to pass through selective traffic (e.g. for 3DS, for payments, sometimes emails for password reset codes etc and more).
A standardized endpoint and API would also be nice, i.e. something to tell the client whether it's connected, restricted (i.e. able to only access a limited set of hosts such as the in-flight map as described in the article), or needs to pay/authenticate (and if so, at which URL). This could then yield an authentication token, to be provided for seamless reconnections for the same session.
There's "Hotspot 2.0" and WPA-EAP (i.e. WPA Enterprise), but these don't really have a good story for "pay via web portal" style usages and are more geared towards wireless carrier operated hotspot networks and corporate scenarios, respectively.
[1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
In case of in-flight Wi-Fi, the credentials/QR code can be printed on the boarding pass, or available in the app (the app caches it in advance while it's still on the ground, so when in the air you can use those credentials to connect).
This doesn't cover 100% of use-cases but it would at least cover a big one (a significant amount of public Wi-Fi is "value add" to another service - whether restaurants, hotels, flights, etc where there's an existing channel to provide one-off wi-Fi credentials over), it's a shame nobody deploys this.
That way you'd at least have the protection of the WPA GTK.
PS: I'm a couch expert so I have no idea if there's a problem with this idea.
This hack just goes a step further to plot the data over time.
I used to travel a lot for work and just refused to pay for WiFi. This was good in airports and coffeeshops when you still had to pay to connect.
Now it's hardly needed, but I could see how it would be helpful where there's still a cost to connect.
I used to spend a lot of time at JFK back when they still charged for WiFi. I watched a lot of Netflix for free by just logging into my router and opening a tunnel to my VPN server.
This is generally in contrast to other instances of public Wifi.
It’s slow, but it works and is a handy “last resort” tool.
Well, if he doesn't know there's anything wrong with it, it's not really temerity.
You told him off for such a small thing? You were impressed but didn’t give encouragement? You are a horrible parent.
Autopilots are very good and they are servoing to the pressure altitude.
Many pressure altitude encoders used in modern aircraft (for example to drive altitudes that transponders report to SSR radar or via ADS-B) have 25 ft encoding resolution. That 25ft resolution is likely what is being seen here. Other encoders have 10 ft resolution but 25 ft is very common.
edit: trying to improve clarity/correctness but there is too much to cover here.
I once had ATC ask if everything was cool on flight following after a hundred foot drop and I was surprised they were paying that much attention. I had forgotten to put my life jacket on before a water transit and while I was putting it on handed it off to my wife who hadn’t taken lessons yet (she later got her license!). It was interesting to see that their tracking was precise enough for them to chime in.
It would have been cool to use a phone to record a GPS track with altitude and compare them. Pressure != GPS. Also wonder if there would be distinct jumps in the difference if they reset the pressure based altimeter to a different AWOS.
Not sure how it works in big planes, but in little ones you need to set your altimeter based on the local weather. The weather stations measure barometric pressure at their elevation and "correct it to sea level" you get this corrected reading over the radio and set it in your altimeter so your pressure-based altitude reading is corrected for local weather variations. Just going out flying for an hour the altimeter setting when returning to the same place might be off by a few millibar.
There are many EFB (e.g. Foreflight), or log book, or other flight recorders you can use on an iPhone. And some can record the pressure transducer in the iPhone to record an approximate "pressure altitude". e.g. Naviter SeeYou Navigator intended for gliders can do that (but it's not unusual for modern gliders to have an array of sophisticated air data sensors and specialized variometers and flight computers that would feed the app this data over Bluetooth). Popular EFB software Foreflight will not use the iPhone pressure transducer, if you want pressure data there you need to drive that through an external interface like a Sentry ADS-B receiver that has a pressure sensor built into it -- or much better if the aircraft is equipped with ADS-B Out can receive the "own-ship" ADS-B Out broadcast pressure altitude from it's high accuracy encoder). Any in-cabin pressure traducer will be sensitive to the difference between calibrated static pressure and cockpit pressure, things like opening or closing vents, or varying the airspeed significant (and ram air pressure or suction on the cockpit exit vents) can cause observable changes. And when using an iPhone or similar, especially without a great GPS satellite overhead view (e.g. in high wing aircraft) you are likely not to get high-quality GPS altitude data. think best case ~ +/- hundred feet, worse case with little overhead GPS sat view, much worse... but those consumer GPS app is likely to happily display multiple decimal points of precision :-)
Of course, your initial point is still correct: there could be slight variations if using those local settings and getting different values, but you'd only see that below transition altitude.
The idea is all the planes use the same setting so the one at FL35 doesn't hit the one at FL36. But those are not exactly 35000 and 36000 feet above sea level.
This is because this way, if a pilot goes 3000 ft for instance, it will be exactly 3000 ft, if another pilot also wants to go 3000 ft on a collision trajectory, it will be a guaranteed collision. When altitudes are not that accurate, there is a higher chance it being just a near miss. The solution, I think, was to simply avoid round numbers. So now, it is 2950 ft, 3050 ft,...
I may have the details wrong, but I am quite sure about that problem being seriously considered.
GPS altitude is used for vertical guidance for certain types of GPS approaches (i.e. "LPV" approaches[1]) and requires the airplane's avionics to be equipped with a WAAS[2] receiver that provides accurate altitude information.
[1] https://en.wikipedia.org/wiki/Localizer_performance_with_ver...
[2] https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System
At cruise altitude, you're moving along at 500 mph, which is 777 feet per second. So going from +30 feet to -30 feet in a minute is just an adjustment of only about 5 degrees. You'd barely feel it, even walking down the isle. An acceleration of 33 ft/sec per sec is 1 g.
You experience greater changes in vertical motion on any flight you go on.
*edit: units
[1]: https://github.com/NalinPlad/OuterFlightTracker
I’m on a flight right now and just went to this URL. Sure enough, it works!
I know this information is available via the wifi portal’s UI, but a JSON blob just hits different.
```
{"timestamp":"2023-09-28T21:57:39Z","eta":"23:45","flightDuration":164,"flightNumber":"DAL992","latitude":47.4557876586914,"longitude":-111.73490905761719,"noseId":"3883","paState":false,"vehicleId":"N883DN","destination":"KMSP","origin":"KSEA","flightId":"N883DN_SF_20230928195737","airspeed":null,"airTemperature":null,"altitude":35273,"distanceToGo":13,"doorState":"Closed","groundspeed":499,"heading":95,"timeToGo":107,"wheelWeightState":"Off"}
```
Apologies for the JSON formatting, I’m on mobile.
[nervously looks out window]
Similar to how I can log into my ASUS router from my home wifi by visiting asusrouter.com.
https://xkcd.com/2170/
Deleted Comment
Like have a WhatsApp relay set up at home that you are sending messages to and from, from the plane.
Like at a most basic level, send a message of a URL to your home WhatsApp which loads the web page there, and sends the HTML back as a WhatApp message reply so you can render it etc.
Wonder what someone could all do and make work.
edit Guess someone made a TCP relay using WhatApp already, neat.
Pay the signup charge, and also stand up a wifi network. Call it "Foo discounted" if the plane's SSID is "Foo". Put up a captive portal that lets the user claim various "discounts", like veteran, senior, child, etc. No matter what they choose, charge them $2 via a payment page. Once you've been made whole on the service cost, future visitors get a notice that "all discounts have been claimed, please use Foo".
Now you have free internet and all those using your router/portal have $2 internet. The upstream bandwidth is certainly atrocious so you will easily be able to multiplex all the data onto your connection.
Bundle it into a RPi kind of device (has to look finished, like a music player or smth, to get past security) so that you can continue to operate the device even when tray tables have to go up, when you go to the bathroom, etc.
I find it extremely doubtful that the airplane has WIPS or WIDS that will deassociate connections to your rogue wifi. And after all, are you not allowed to have a LAN party?
Would this be related to DNS?
https://github.com/aleixrodriala/wa-tunnel
Someone smart created a TCP-over-DNS tunneling tool that I had a lot of great experience with, at least for more simple news websites of the day.
https://analogbit.com/software/tcp-over-dns/
I chose to scrape it for a couple reasons:
1. I wanted see all of the data for the entire flight - that status page only visualizes the current values.
2. It was fun!
https://simonwillison.net/2020/Oct/9/git-scraping/
(US Civilian GPS units are prohibited from working above 60,000 ft above sea level and 1,000 knots due to ITAR munitions export restrictions.)