Southwest फ्लाइट में इंटरनेट के बिना WiFi डेटा देखना

 (jamesbvaughan.com)
1 पॉइंट द्वारा GN⁺ 2023-09-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Strange Loop से लौटते समय St. Louis-Oakland की डायरेक्ट फ्लाइट में $8 इंटरनेट पेमेंट फेल होने पर, इन-फ्लाइट WiFi से जुड़े रहते हुए देखा गया कि इंटरनेट के बिना कौन-सा डेटा एक्सेस किया जा सकता है
  • Southwest WiFi पोर्टल के नेटवर्क requests में बार-बार सफल होने वाला current.json endpoint मिला, और इसका response फ्लाइट status page का base data लगता है
  • यह endpoint कुकी या header के बिना भी curl से call किया जा सकता था, और altitude, coordinates, expected arrival time, ground speed, remaining distance, flight progress, satellite connection status आदि लौटाता है
  • इकट्ठा किए गए डेटा से altitude, ETA और ground speed को visualize किया गया; descent segment को छोड़ दें तो altitude में केवल लगभग 20~30 feet के स्तर की fluctuation दिखी
  • यह कोई खास practical खोज नहीं थी, लेकिन इन-फ्लाइट WiFi पोर्टल द्वारा expose किए गए flight status JSON भर से भी flight के दौरान data collection और analysis किया जा सकता है

पेमेंट फेल होने से शुरू हुई इन-फ्लाइट WiFi की पड़ताल

  • Strange Loop से लौटते समय St. Louis-Oakland की डायरेक्ट फ्लाइट में Southwest के इन-फ्लाइट WiFi पोर्टल के जरिए $8 का internet access pass खरीदने की कोशिश की, लेकिन कोई भी payment method स्वीकार नहीं हुआ
  • web page ने मददगार error message नहीं दिखाया, इसलिए browser के network developer tools से failed requests देखे गए
  • failed request में खुद कोई clue मिलना मुश्किल था, लेकिन बार-बार successful होने वाला current.json request ध्यान में आया

current.json ने जो flight status data लौटाया

  • current.json response इन-फ्लाइट WiFi पोर्टल के flight status page को चलाने वाला data लगता है
  • example response में ये values शामिल थीं
    • sat_commlink_portal.status: conn_ok
    • satcomm_status.commlink: active
    • satcomm_status.linkparams: not-stale
    • pcent_flt_complete: flight progress लगने वाली value
    • altVal: current altitude
    • lat, lon: current coordinates
    • dtzone: destination time zone
    • within_us: क्या flight US के अंदर है
    • etad: destination arrival expected time
    • gspdVal: current ground speed
    • ttgc: remaining time लगने वाली value
    • dist_remain: remaining distance
    • actime24: किसी time zone का current time

browser request को curl से reproduce करना

  • browser के “Copy as cURL” feature से endpoint call command जल्दी मिल गई
  • यह feature Firefox और Chromium-based browsers में होता है, और browser द्वारा भेजे गए request को same headers के साथ reproduce करने में useful है
  • experiment में request में शामिल cookies या headers जरूरी नहीं निकले, और नीचे जैसे simple curl call से ही data लिया जा सका
curl 'https://getconnected.southwestwifi.com/current.json'
  • इसके बाद हर 30 सेकंड में data fetch करके log file में जोड़ने वाला loop चलाया गया
watch -n 30 "curl https://getconnected.southwestwifi.com/current.json | jq -c >> flight-logs"

response fields को लेकर बचे सवाल

  • ज्यादातर fields intuitive थे, लेकिन कुछ values का मतलब पक्का नहीं था
    • sat_commlink_portal.status और satcomm_status.commlink में फर्क
    • pcent_flt_complete distance-based है या expected time-based
    • altVal, etad, gspdVal flight के दौरान कितने fluctuate करते हैं
    • actime24 में ac का क्या मतलब है
  • actime24 aircraft की location का current time नहीं, बल्कि destination का current time लगता था, इसलिए ac को “aircraft” के रूप में समझना मुश्किल है

flight के दौरान collected data visualization

  • collected data से altitude, ETA, ground speed में बदलाव visualize किए गए

  • altitude changes

    • शुरुआत में यह देखना चाहा गया कि altitude data में कितना noise है
    • overall range बड़ा होने से noise देखना मुश्किल था, और descent segment हटाने के बाद altitude variation लगभग 20~30 feet के स्तर का दिखा
    • इस level की stability उम्मीद से ज्यादा थी, लेकिन normal range या data accuracy पता नहीं थी

  • ETA changes

    • ETA के reasonably stable होने की उम्मीद थी, और initial departure के बाद smooth flight में यह वाकई stable था
    • अगर weather की वजह से landing delay हो, तो ETA धीरे-धीरे बढ़ेगा या end में अचानक jump करेगा—यह सवाल बाकी है

  • ground speed changes

    • ground speed भी उम्मीद के मुताबिक stable था
    • शुरुआत में speed unit MPH दिखाया गया था, लेकिन HN readers ने बताया कि यह value शायद knots है
    • flight की शुरुआत से data collect नहीं हो पाया, इसलिए cruising speed तक पहुंचने वाले segment का curve verify नहीं किया जा सका

निष्कर्ष

  • collected data में कोई खास useful या surprising बात नहीं थी
  • internet access के बिना भी इन-फ्लाइट WiFi पोर्टल द्वारा expose किए गए flight status JSON का इस्तेमाल करके flight के दौरान data collect और analyze किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-29
Hacker News की टिप्पणियां

  • मेरा बेटा जब करीब 9–10 साल का था, तो मैंने उसे विमान में फोन पर इंटरनेट इस्तेमाल करते देखा। मैंने कभी इंटरनेट शुल्क नहीं दिया था, इसलिए पूछा कि वह इसे कैसे इस्तेमाल कर रहा है।
    उसने कहा कि स्कूल के एक दोस्त ने बताया था कि Wi-Fi settings में DHCP-assigned IP address के अंक बदलते रहो तो काम हो जाता है। उस समय American Airlines शायद सिर्फ paid users के IP को allow करती थी, इसलिए अगर कोई दूसरा 192.168 range का IP सही अनुमान लगाकर impersonate कर ले, तो बिना अतिरिक्त authentication के connection ले सकता था।
    मैंने उसे ऐसा न करने को कहा, लेकिन कोशिश करने की उसकी हिम्मत पर थोड़ा गर्व भी हुआ।

    • पुराने paid Wi-Fi hotspots पर मैं भी अक्सर कुछ ऐसा ही करता था।
      पहले nmap -sP से पूरे subnet का ping sweep करके ARP cache में काम के IP/MAC addresses भरता था, फिर एक-एक करके IP और MAC address बदलकर वह combination ढूंढता था जो firewall पार कर जाए।
      Wayport (अब AT&T WiFi) में NOC engineer के तौर पर काम करने से इसका ढांचा समझने में मदद मिली।
    • विमानों और होटलों में मैंने यही तरीका इस्तेमाल किया, और होटलों में सफलता की संभावना ज्यादा थी।
      क्योंकि इस बात की संभावना कम होती थी कि कोई दूसरा उसी समय उसे इस्तेमाल कर रहा होगा, और connection कटने की संभावना भी कम थी।
      बचपन में एक और छोटा hack भी किया था: जब airlines in-flight movies के लिए खास earphones बेचती या किराए पर देती थीं, तब port में साथ-साथ दो छेद होते थे और plug दो tubes जैसा होता था।
      boarding से पहले terminal के fast-food outlet से कुछ straws, हो सके तो bendable straws, ले लेता था और उन्हें जोड़कर एक लंबा straw बना लेता था। एक सिरा port में और दूसरा कान पर रखने से मुफ्त movie audio सुनाई देता था।
    • कुछ साल पहले Southwest flight में मैं OpenVPN बंद करना भूल गया था, और बिना शुल्क दिए भी tunnel के जरिए इंटरनेट access कर पाया।
      उस समय लगता है non-paying users के लिए सिर्फ common ports (80, 443, 53 वगैरह) ही block किए जाते थे; बाद में वह loophole बंद कर दिया गया।
    • वाकई हैरान कर देने वाला किस्सा है।
      open Wi-Fi security की स्थिति सच में काफी अफसोसजनक है, और मुझे यह भी साफ नहीं दिखता कि airlines इसे इससे कहीं आसान तरीके से बेहतर कैसे कर सकती हैं।
      अगर device support करे तो Opportunistic Wireless Encryption [1] इस्तेमाल करके authentication को किसी खास MAC address के बजाय किसी खास OWE session से बांधा जा सकता है, लेकिन OWE session कितना stable रहता है, यह मुझे नहीं पता।
      अगर हर access point बदलने पर दोबारा login करना पड़े, तो यह बहुत असुविधाजनक होगा।
      अफसोस है कि paid Wi-Fi या free Wi-Fi security अभी भी सुलझी हुई समस्या नहीं है, और payment, 3DS, password reset email जैसे selective traffic को pass करने देने वाले unreliable captive portals जैसे custom temporary workarounds अब भी जरूरी हैं।
      अच्छा हो अगर कोई standard endpoint और API हों जिससे client जान सके कि वह currently connected है, restricted है, या payment/authentication चाहिए; और authentication token लेकर उसी session में सहज रूप से reconnect कर सके।
      Hotspot 2.0 और WPA-EAP (WPA Enterprise) मौजूद हैं, लेकिन वे क्रमशः carrier-operated hotspot networks और enterprise environments के लिए ज्यादा बने हैं, इसलिए “web portal से payment” वाले use case में वे ठीक से fit नहीं बैठते।
      [1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
    • पुराने समय में ऐसे apps होते थे जो पहले से इंटरनेट से जुड़े network के IP और MAC address scan कर देते थे।
      settings को उनमें से किसी एक MAC address पर बदल दो, तो मूल user के खत्म करने के बाद वह connection अकेले इस्तेमाल कर सकते थे।
      business trips के दौरान मैं Wi-Fi fee देने से मना करता था, और जब airports और coffee shops अभी paid access लेते थे, तब यह काफी काम आता था।
      अब इसकी लगभग जरूरत नहीं पड़ती, लेकिन जहां अभी भी access fee लगती है, वहां यह मददगार हो सकता है।

  • “इस डेटा के मुताबिक विमान की ऊँचाई सिर्फ़ करीब 20–30 फीट ही ऊपर-नीचे हुई। उम्मीद से ज़्यादा स्थिर है!”
    ऑटोपायलट बेहद अच्छा होता है और barometric altitude के आधार पर servo control करता है
    आधुनिक विमानों के कई barometric altitude encoder, जैसे वे डिवाइस जो transponder द्वारा SSR radar या ADS-B पर रिपोर्ट की जाने वाली ऊँचाई को drive करते हैं, 25 फीट की encoding resolution रखते हैं
    यहाँ जो दिख रहा है, वह भी शायद वही 25 फीट resolution है; 10 फीट resolution वाले encoder भी होते हैं, लेकिन 25 फीट बहुत आम है

    • लेख में बताए गए API को कौन-सा sensor data मिलता है, यह नहीं पता, लेकिन ज़्यादातर यात्री विमान अपनी detect की गई position की accuracy, यहाँ तक कि vertical position/altitude accuracy भी broadcast करते हैं
      https://globe.adsbexchange.com/ मैप पर किसी विमान पर क्लिक करके left sidebar को सबसे नीचे तक scroll करें, तो “Accuracy” section दिखेगा
      ADS-B Exchange vertical position accuracy यानी Rc/v नहीं दिखाता, लेकिन बाकी values दिखाता है
      अधिक जानकारी के लिए https://mode-s.org/decode/content/ads-b/7-uncertainty.html देखें
    • छोटे विमान में ध्यान से manual flying करते समय 20–30 फीट की range असामान्य नहीं है
      cruise के दौरान यात्री विमान तो जाहिर है autopilot इस्तेमाल करते होंगे
      पहले flight following मिल रही थी, तब करीब 100 फीट नीचे चला गया तो controller ने पूछा कि सब ठीक है क्या; यह देखकर हैरानी हुई कि वे इतनी बारीकी से देख रहे थे
      पानी के ऊपर वाले segment से पहले life jacket पहनना भूल गया था, और पहनते समय controls अपनी पत्नी को दे दिए थे, जिसने तब तक flight lessons नहीं लिए थे
      बाद में मेरी पत्नी ने भी license ले लिया, और यह बात दिलचस्प लगी कि ATC tracking इतनी precise है कि बीच में intervene कर सके
    • अच्छा होता अगर फोन से altitude सहित GPS track record करके तुलना की जाती
      pressure और GPS अलग होते हैं, और यह भी जानना दिलचस्प होगा कि barometric altimeter को किसी दूसरे AWOS setting पर reset करने से फर्क साफ़ jump की तरह दिखता है या नहीं
      बड़े विमान इसे कैसे करते हैं, पता नहीं, लेकिन छोटे विमानों में local weather के हिसाब से altimeter set करना पड़ता है
      weather station अपनी altitude पर pressure measure करके उसे “sea level के हिसाब से corrected” value के रूप में radio पर बताता है, और इसे altimeter में डालकर local weather changes के कारण barometric altitude reading को correct किया जाता है
      एक घंटे की flight करके उसी जगह लौटें, तब भी altimeter setting कुछ millibar तक बदल सकती है
    • RVSM लागू होने के बाद यह शायद कहीं ज़्यादा precise हो गया होगा
      विमानों के बीच vertical separation standard 2000 फीट था, जिसे 2000 के दशक की शुरुआत में घटाकर 1000 फीट कर दिया गया
    • मैंने कहीं पढ़ा था कि कुछ स्थितियों में बहुत ज़्यादा precision उल्टा खतरनाक हो सकती है
      उदाहरण के लिए, अगर pilot 3000 फीट पर जाता है तो वह ठीक 3000 फीट पर होगा, और कोई दूसरा pilot भी collision path पर 3000 फीट चाहता है, तो टक्कर पक्की हो सकती है
      अगर altitude कम accurate हो, तो ज़्यादा संभावना है कि मामला near miss तक ही रहे
      समाधान शायद round numbers से बचकर 2950 फीट, 3050 फीट जैसे numbers इस्तेमाल करना था
      details गलत हो सकती हैं, लेकिन यह काफी पक्का है कि इस समस्या पर गंभीरता से विचार किया गया था

  • कुछ महीने पहले मैंने भी यही चीज़ खोजी और इस API का इस्तेमाल करके एक CLI flight tracker बनाया
    इसे कुछ airlines पर test किया, और वे सभी वही in-flight internet provider इस्तेमाल कर रही थीं, इसलिए यह लगभग perfect चला
    [1]: https://github.com/NalinPlad/OuterFlightTracker

    • बढ़िया
      मैं भी कुछ ऐसा ही बनाना चाहता था, लेकिन flight के दौरान internet से reference लिए बिना TUI बनाने जितना अनुभव नहीं था
      फिर भी अच्छा लगा कि यह पहले से बना हुआ है

  • Delta फ़्लाइट में वही डेटा पाने का तरीका यह है

    $ curl https://wifi.delta.com/api/flight-data | jq  

    {  
"timestamp": "2023-07-11T14:54:41Z",  
"eta": "17:48",  
"flightDuration": 278,  
"flightNumber": "DAL786",  
"latitude": 39.723472595214844,  
"longitude": -97.1514205932617,  
"noseId": "3879",  
"paState": false,  
"vehicleId": "N879DN",  
"destination": "KPDX",  
"origin": "KATL",  
"flightId": "N879DN_SF_20230711121358",  
"airspeed": null,  
"airTemperature": 24,  
"altitude": 33922,  
"distanceToGo": 179,  
"doorState": "Closed",  
"groundspeed": 442,  
"heading": -73,  
"timeToGo": 174,  
"wheelWeightState": "Off"  
}

    एक दिलचस्प टुकड़ा भी है

    $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=";, .latitude, ",", .longitude' | tr -d '\n'; echo  
https://maps.google.com/?q=40.5615234375,-101.2824478149414
    • jq की string interpolation सुविधा इस्तेमाल करें तो इसे और सरल बनाया जा सकता है 
      $ curl -s https://wifi.delta.com/api/flight-data | jq -r '"https://maps.google.com/?q=\(.latitude),\(.longitude)"'
    • अभी विमान के अंदर इस URL पर जाकर देखा, और यह सच में काम करता है
      यह जानकारी Wi-Fi पोर्टल UI में भी दिखती है, लेकिन JSON के ढेर के रूप में देखने का एहसास अलग है 
      {"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"}
      मोबाइल पर हूँ, इसलिए JSON formatting के लिए क्षमा करें
    • अगर ताज़ी हवा चाहिए हो तो अच्छा होता कि POST request से दरवाज़ा खोल पाते
    • planeId या tailNumber के बजाय ज़्यादा सामान्य vehicleId इस्तेमाल करने का चुनाव दिलचस्प है
      सोचता हूँ कि क्या Delta के operating equipment में ऐसी API वाले और भी किसी तरह के साधन हैं
      यह भी जिज्ञासा है कि दूसरे internal systems को जानने वाला कोई व्यक्ति flightId से system architecture के बारे में कितना अनुमान लगा सकता है
      ऊपर से देखने पर तो यह उपलब्ध डेटा से बनी composite key से ज़्यादा कुछ नहीं लगता, फिर भी दिलचस्प है
    • "airspeed": null
      बेचैनी में खिड़की के बाहर देखने का मन होता है

  • मैं देखना चाहूँगा कि कोई मुफ्त iMessage या WhatsApp-allowed connection का उपयोग करके arbitrary data भेजने वाला proxy बनाए
    जैसे घर पर WhatsApp relay खड़ा कर दें और विमान से message भेजें-लें
    सबसे basic रूप में शायद URL घर के WhatsApp पर भेजें, घर से webpage load हो और HTML WhatsApp reply में वापस भेज दिया जाए ताकि उसे render किया जा सके
    जिज्ञासा है कि कितना कुछ चलाया जा सकता है
    लगता है किसी ने पहले ही WhatsApp पर TCP relay बनाया है, यह बढ़िया है

    • https://github.com/aleixrodriala/wa-tunnel
    • Terms of service नहीं पढ़े हैं, लेकिन सोचता हूँ कि क्या बस एक असली IP router रख देना संभव नहीं होगा
      subscription का खर्च दें और Wi-Fi network भी चला दें
      अगर plane SSID “Foo” है तो उसका नाम “Foo discounted” रखें, और captive portal में veterans, seniors, children जैसे कई “discounts” चुनने को दें
      कोई भी option चुनें, payment page पर 2 डॉलर ले लें
      service cost वसूल हो जाने के बाद आगे आने वालों को “सभी discounts खत्म हो चुके हैं, कृपया Foo इस्तेमाल करें” दिखा दें
      तो मैं मुफ्त internet इस्तेमाल करूँगा, और router/portal users 2 डॉलर वाला internet इस्तेमाल करेंगे
      upstream bandwidth निश्चित रूप से खराब होगी, इसलिए सारे data को मेरी एक connection पर multiplex करना भी आसान होगा
      इसे RPi जैसे device में डालें, लेकिन security screening पार करने के लिए यह music player जैसा finished product दिखना चाहिए, और tray table ऊपर करनी पड़े या restroom जाना पड़े तब भी चलता रहना चाहिए
      लगता है विमान में rogue Wi-Fi connection काटने वाला WIPS या WIDS होने की संभावना बहुत कम है
      वैसे भी LAN party प्रतिबंधित तो नहीं है, है न
    • 1–2 साल पहले Apple Private Relay का पहला beta आने के एक-दो दिन बाद मैंने flight ली थी, और पूरी flight में मुफ्त Wi-Fi इस्तेमाल कर पाया
      शायद iMessage या push notifications के लिए allowlist में डाली गई destinations में वह भी शामिल हो गया था
      कुछ दिन बाद return flight से पहले ही इसे block कर दिया गया था
    • “वाह, cool” से पहले मेरे मन में “free messaging अच्छा perk है, लेकिन abuse हुआ तो वे इसे बंद कर देंगे” आया
      लगता है hacker days बीत चुके हैं
    • मैंने देखा है कि airline Wi-Fi DNS traffic block नहीं करता
      Iodine(https://github.com/yarrick/iodine) जैसे DNS tunnel से भी कुछ ऐसा ही किया जा सकने की संभावना काफी है

  • Southwest वही डेटा एक ज़्यादा सुंदर स्क्रीन पर दिखाता है
    Wi-Fi शुल्क दिए बिना भी flight tracking, मौजूदा altitude, arrival का अनुमानित समय, map पर position जैसी बहुत-सी जानकारी देखी जा सकती है
    शायद यह वही डेटा इस्तेमाल करता है जिसके लिए लेखक ने processing program बनाया था, और मूल रूप से यह ऐसा है मानो एक site मुफ्त में visit की जा सकती हो

    • हाँ, बिल्कुल ऐसा ही है
      इस डेटा को visualize करने वाला एक शानदार status page मुफ्त में देखा जा सकता है
      फिर भी इसे scrape करने की दो वजहें थीं
      पहली, status page सिर्फ current values दिखाता है, इसलिए पूरे flight data को देखना चाहता था
      दूसरी, यह मज़ेदार था
    • हाल की एक अमेरिकी flight में, शायद Alaska Airlines रही होगी, internet access के बिना भी Wi-Fi पर movies और TV shows देखने के लिए एक local LAN box था
    • “Portal page खोलने की कोशिश करने पर plane data इतना सारा वापस क्यों आ रहा है?” वाली जिज्ञासा दूर हो गई

  • इस लेख का spirit अच्छा है
    लेखक शायद इस जानकारी को Git scraping भी कर सकता था
    https://simonwillison.net/2020/Oct/9/git-scraping/

  • लगा कि window के बाहर की photos लेकर उस JSON output के GPS coordinates को image से जोड़ा जा सकता है
    काफी उपयोगी लगता है

    • अगर camera app में location permission on रखी जाए तो image के EXIF data में coordinates आ जाते हैं
      अमेरिकी civilian GPS devices को ITAR military exports restrictions के कारण समुद्र तल से 60,000 feet से ऊपर और 1,000 knots से ज़्यादा पर काम करने से प्रतिबंधित किया गया है

  • अगर aircraft data और ADS-B data की तुलना करनी हो, तो यह original post लेखक की flight लगती है
    https://www.flightaware.com/live/flight/SWA2340/history/2023...

    • संभव है कि ADS-B data source और इस API का data source कम-से-कम उन्हीं instruments और flight systems से calculated हो
    • यही सही flight है
      अच्छा idea है, अफसोस कि मेरे दिमाग में नहीं आया

  • दिलचस्प बात है
    लेकिन क्या किसी और को वह time format खटक नहीं रहा
    यह अजीब choice लगती है, और time zone offset वाले ISO 8601 जैसे ज़्यादा standard format की उम्मीद थी
    "time": "Sun Sep 24 22:02:19 2023"

    • मुझे भी कुछ ऐसा ही लगा
      लगता है इस system को design करने वाले ने server पर time को flight की location के हिसाब से दिखने वाली localized representation में convert कर दिया, और client-side logic के बिना सीधे web UI में डालना चाहा
    • यह ctime द्वारा इस्तेमाल होने वाले default format जैसा दिखता है
      underlying backend के बारे में clue भी हो सकता है
      https://cplusplus.com/reference/ctime/ctime/