PySkyWiFi: สร้าง Wi‑Fi ฟรีความเร็วต่ำบนเที่ยวบินระยะไกล

 (robertheaton.com)
1 คะแนน โดย GN⁺ 2024-07-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • PySkyWiFi เป็นการทดลองที่ใช้ฟิลด์โปรไฟล์ของบัญชีสะสมไมล์สายการบินซึ่งเปิดให้เข้าถึงได้แม้ก่อนชำระเงิน เป็นที่เก็บข้อมูลชั่วคราวเพื่อส่งคำขอและคำตอบ HTTP ไปกลับอย่างช้ามากระหว่างเที่ยวบินระยะไกล
  • ต้นแบบแรกเริ่มจากการอัปเดตและโพลฟิลด์ชื่อของบัญชีเพื่อสร้างแชต แล้วต่อยอดเป็นวิธีที่เดมอนฝั่งภาคพื้นอ่านคำขออย่าง STOCKPRICE: APPL แล้วส่งผลลัพธ์กลับมา
  • สถาปัตยกรรมสุดท้ายแบ่งเป็น sky proxy บนเครื่องในเครื่องบิน และ ground daemon บนเครื่องที่เชื่อมต่ออินเทอร์เน็ต โดยส่ง URL ปลายทางผ่านเฮดเดอร์ X-PySkyWiFi ของคำขอ curl ในเครื่อง
  • การส่งข้อมูลทำโดยแบ่งคำขอ HTTP ออกเป็นชังก์เล็ก ๆ แล้วจัดลำดับด้วยเซกเมนต์ DATA, ACK, END และหมายเลขลำดับ 6 หลัก
  • ผู้พัฒนาหลีกเลี่ยงการยิงคำขออัตโนมัติอย่างต่อเนื่องไปยังบัญชีสายการบินจริง และการทดสอบสุดท้ายหยุดอยู่ที่การเรียกหน้าโฮมเพจบล็อกผ่าน GitHub Gist ด้วย curl แล้วรับ HTML กลับมาหลังผ่านไปหลาย分钟

ช่องทางอ้อมที่ค้นพบบนพอร์ทัล Wi‑Fi ก่อนชำระเงิน

  • หน้าเข้าสู่ระบบ Wi‑Fi บนเครื่องบินบังคับให้ชำระเงิน แต่ก่อนชำระเงินก็ยังอนุญาตให้ล็อกอินบัญชีสะสมไมล์สายการบินได้ฟรี
  • เมื่อเห็นฟิลด์ชื่อในหน้าจอแก้ไขโปรไฟล์ จึงมองว่าค่านี้อาจใช้เป็นช่องทางสื่อสารเล็ก ๆ สำหรับรับส่งข้อมูลกับภายนอกได้
  • ตอนแรกตั้งใจจะใช้ Go เป็นภาษาเขียนโปรแกรม แต่เพราะถ้าใช้ Python จะตั้งชื่อเครื่องมือได้ว่า PySkyWiFi จึงเลือก Python
  • ซอร์สโค้ดเผยแพร่ไว้ที่ PySkyWiFi

ต้นแบบ 1: อินสแตนต์เมสเสจจิงจากฟิลด์ชื่อ

  • ไคลเอนต์สองตัวล็อกอินเข้าบัญชีสะสมไมล์สายการบินเดียวกัน แล้วรับส่งข้อความกันด้วยการสลับกันอัปเดตและอ่านฟิลด์ชื่อ
    • ถ้าฝั่งหนึ่งเปลี่ยนชื่อเป็น Hello how are you อีกฝั่งก็จะอ่านค่านี้ได้
    • จากนั้นหากเปลี่ยนเป็น Im fine how are you ฝั่งแรกก็จะเห็นว่าเป็นข้อความตอบกลับ
  • การเปลี่ยนชื่อผ่าน UI โดยตรงยุ่งยาก จึงทำให้เป็นอัตโนมัติด้วยเครื่องมือบรรทัดคำสั่ง
    • เครื่องมือจะล็อกอินเข้าเว็บไซต์และอัปเดตฟิลด์ชื่อของบัญชีทดสอบให้เป็นข้อความ
    • จากนั้นจะโพลฟิลด์ชื่อทุก ๆ ไม่กี่วินาที และเมื่อค่าเปลี่ยนก็จะแสดงออกมาเป็นข้อความตอบจากอีกฝั่ง
  • เพื่อหลีกเลี่ยงการส่งข้อมูลอัตโนมัติไปยังบัญชีสะสมไมล์จริงต่อเนื่องอีก จึงทดสอบเพียงการอัปเดตชื่ออย่างรวดเร็วประมาณ 10 ครั้งและดูว่าผ่านทั้งหมดหรือไม่
    • ผลลัพธ์นี้ชี้ว่าบัญชีดังกล่าวอาจไม่มีการจำกัดอัตราหรือจำนวนคำขอ
  • หลังจากนั้น การพัฒนาต่อทำบน GitHub Gists และไฟล์ในเครื่องเพื่อจำลองหลักการเดียวกัน
    • เพราะพัฒนาแบบวนซ้ำได้เร็วและง่ายกว่าการใช้บัญชีสะสมไมล์สายการบิน

ต้นแบบ 2: ดึงข้อมูลภายนอกผ่านเดมอนภาคพื้น

  • ขั้นต่อไปคือรันเดมอนบนคอมพิวเตอร์ที่เชื่อมต่ออินเทอร์เน็ตบนภาคพื้นหรือในคลาวด์
  • เดมอนจะโพลฟิลด์ชื่อของบัญชีสะสมไมล์สายการบินอย่างต่อเนื่อง เพื่อมองหาคำขอแบบมีโครงสร้างที่ส่งมาจากเครื่องบิน
    • ตัวอย่าง: STOCKPRICE: APPL
    • ตัวอย่าง: SCORE: MANUNITED
  • เมื่อพบคำขอใหม่ เดมอนจะพาร์สค่านั้น ดึงข้อมูลจาก API ที่เกี่ยวข้อง แล้วส่งกลับไปยังฝั่งเครื่องบินผ่านบัญชีสะสมไมล์สายการบิน
  • ตั้งแต่ขั้นนี้เป็นต้นไป ระบบจึงทำได้มากกว่าแชตธรรมดา และสามารถค้นหาข้อมูลแบบเรียลไทม์อย่างราคาหุ้นหรือผลกีฬาสดได้

สถาปัตยกรรมเต็มรูปแบบด้วย sky proxy และ ground daemon

  • PySkyWiFi เป็นโปรโตคอลคล้าย TCP/IP ที่ยัดคำขอ HTTP ทั้งหมดเข้าไปในบัญชีสะสมไมล์สายการบิน จากนั้นคอมพิวเตอร์ภาคพื้นจะทำคำขอ HTTP จริง แล้วอัปโหลดคำตอบกลับมาด้วยวิธีเดียวกัน
  • มีองค์ประกอบสองส่วน
    • sky proxy: พร็อกซีที่รันบนแล็ปท็อปในเครื่องบิน
    • ground daemon: เดมอนที่รันบนคอมพิวเตอร์ที่บ้านหรือในคลาวด์ซึ่งเชื่อมต่ออินเทอร์เน็ต
  • ก่อนใช้งานต้องรัน ground daemon ก่อน จากนั้นเมื่อเชื่อมต่อ Wi‑Fi บนเครื่องบินแล้วจึงรัน sky proxy บนแล็ปท็อป
  • ผู้ใช้ส่งคำขอ HTTP ไปยังพร็อกซีในเครื่องด้วยเครื่องมืออย่าง curl
    • ตัวอย่าง: curl localhost:1234 -H "X-PySkyWiFi: example.com"
    • URL ปลายทางจริงจะใส่ไว้ในเฮดเดอร์กำหนดเอง X-PySkyWiFi
  • ground daemon จะลบเฮดเดอร์ X-PySkyWiFi ออก แล้วใช้ค่านี้ในการกำหนดเส้นทางไปยังเว็บไซต์เป้าหมาย
    • เนื้อหาคำขอและเฮดเดอร์อื่น ๆ จะถูกส่งต่อไปตามเดิม
  • เมื่อทุกอย่างเสร็จสิ้น ผู้ใช้จะได้รับคำตอบ HTTP เหมือนคำขออินเทอร์เน็ตทั่วไป แต่ตามสภาพเครือข่ายบนเครื่องบิน คำขออาจค้างอยู่หลาย分钟และมีความเร็วเพียงไม่กี่ไบต์ต่อวินาที

ชังก์, ACK และการส่ง HTTP ไปกลับด้วยบัญชีที่สอง

  • sky proxy รับคำขอจาก curl แล้วแบ่งคำขอ HTTP ทั้งหมดออกเป็นชังก์
    • เพราะปริมาณข้อมูลที่ใส่ในฟิลด์ชื่อของบัญชีสะสมไมล์สายการบินได้ในครั้งเดียวมีน้อย
  • ชังก์แต่ละชิ้นจะถูกเขียนลงในฟิลด์ชื่อของบัญชีสะสมไมล์สายการบินบัญชีแรกตามลำดับ
  • ground daemon จะโพลบัญชีไปเรื่อย ๆ และเมื่อพบชังก์ใหม่ก็จะอ่านออกมา พร้อมทิ้งการยืนยันการรับข้อมูลไว้ว่าส่งชังก์ถัดไปได้แล้ว
  • เมื่อประกอบคำขอ HTTP ทั้งหมดกลับมาได้ ground daemon ก็จะส่งคำขอจริงออกสู่อินเทอร์เน็ต
  • คำตอบ HTTP จะเดินย้อนกลับด้วยขั้นตอนเดียวกัน
    • ground daemon แบ่งคำตอบออกเป็นชังก์แล้วส่งกลับ
    • เพื่อให้การติดตั้งใช้งานง่ายขึ้น ชังก์คำตอบจะใช้บัญชีสะสมไมล์สายการบินบัญชีที่สอง
    • sky proxy จะอ่านชังก์เหล่านี้ ประกอบกลับเป็นคำตอบ HTTP และส่งคืนให้การเรียก curl เดิม

แยกบทบาทของ transport layer และ network layer

  • ลอจิกการสื่อสารของ PySkyWiFi แบ่งเป็นtransport layer และ network layer
  • transport layer เป็นผู้ตัดสินว่าจะส่งข้อมูลอะไรและส่งตามลำดับใด
    • วิธีแบ่งข้อความยาวออกเป็นชังก์เล็ก ๆ
    • วิธีบอกว่าฝั่งรับพร้อมรับชังก์ถัดไปแล้ว
    • มีบทบาทคล้าย TCP แบบหลวม ๆ
  • network layer เป็นผู้เขียนและอ่านข้อมูลจริงตามที่ transport layer กำหนดไว้ลงในสโตเรจ
    • สโตเรจอาจเป็นบัญชีสะสมไมล์สายการบิน, ไฟล์ในเครื่อง หรือโปรไฟล์ Discord ก็ได้
  • การแยกเช่นนี้ทำให้รองรับแพลตฟอร์มสะสมไมล์ของสายการบินใหม่ได้ง่าย
    • แค่ทำ network layer ใหม่ ส่วน transport layer ใช้ของเดิมได้
    • network layer สำหรับทดสอบสามารถอ่านเขียนไฟล์ในเครื่องแทนบัญชีสะสมไมล์สายการบินได้

กติกาการส่งข้อมูลด้วย DATA, ACK, END

  • การเชื่อมต่อสำหรับส่งข้อมูลของ PySkyWiFi ประกอบด้วยไปป์สองเส้น
    • แต่ละไคลเอนต์มีไปป์ SEND สำหรับเขียน และไปป์ RECV สำหรับอ่าน
    • สามารถใช้บัญชีสะสมไมล์สายการบินเป็นไปป์ได้
  • ไคลเอนต์ PSWF ในช่วงเวลาใดเวลาหนึ่งจะอยู่ได้แค่โหมดส่งหรือโหมดรับอย่างใดอย่างหนึ่ง
    • ถ้าอยู่ในโหมดส่ง จะมองไม่เห็นข้อมูลที่อีกฝั่งส่งมา
    • ถ้าอยู่ในโหมดรับ แม้จะส่งข้อมูลไป อีกฝั่งก็จะยังไม่เห็น
    • จึงไม่ใช่การรับส่งสองทางได้ตลอดเวลาแบบ TCP
  • ข้อความยาวจะถูกส่งด้วยเซกเมนต์ DATA, ACK, END
    • DATA: ประกอบด้วยตัวอักษร D, หมายเลขลำดับที่เติมให้ครบ 6 หลัก และข้อมูลชังก์จริง
    • ตัวอย่าง: D000451adline": "Mudslide in Wigan causes m
    • ACK: ประกอบด้วยตัวอักษร A และหมายเลขลำดับ 6 หลักที่ใช้ยืนยัน
    • ตัวอย่าง: A000451
    • END: ใช้อักขระ E ตัวเดียวเพื่อบอกจบข้อความ
  • ผู้ส่งจะส่ง DATA แล้วรอจนกว่าจะได้รับ ACK ของหมายเลขลำดับนั้น
    • เมื่อได้รับ A000451 ก็จะถือว่าชังก์ 000451 ถูกประมวลผลแล้ว และส่งชังก์ 000452 ต่อไป
  • เมื่อฝั่งรับเห็น END ก็จะถือว่าข้อความจบ แล้วสลับบทบาทผู้ส่งกับผู้รับ

อินเทอร์เฟซการติดตั้งใช้งาน network layer

  • network layer มีอินเทอร์เฟซเรียบง่ายสำหรับเขียนและอ่านข้อมูลจากสโตเรจ
  • มีโอเปอเรชันบังคับสองอย่าง
    • send(msg: str): เขียน msg ลงในสโตเรจ
    • recv() -> str: อ่านข้อความจากสโตเรจ
  • ในการติดตั้งใช้งานแบบอิงบัญชีสะสมไมล์สายการบิน โอเปอเรชันสองอย่างนี้ก็คือการเขียนและอ่านฟิลด์ชื่อของบัญชี
  • ยังมีพร็อพเพอร์ตีบังคับอีกสองตัว
    • sleep_for: เวลาหน่วยวินาทีที่ transport layer จะรอระหว่างการโพลไปป์ RECV
    • segment_data_size: จำนวนตัวอักษรที่ใส่ได้ในหนึ่งเซกเมนต์
  • sleep_for สามารถตั้งให้ต่ำได้ในการติดตั้งใช้งานทดสอบอย่างไฟล์ในเครื่อง แต่ในการติดตั้งใช้งานกับบัญชีสะสมไมล์สายการบินต้องตั้งอย่างน้อยหลายวินาทีเพื่อไม่ให้ส่งคำขอไปยังเซิร์ฟเวอร์ปลายทางมากเกินไป
  • segment_data_size ต้องเท่ากับขนาดสูงสุดของฟิลด์ในบัญชีสะสมไมล์ที่ใช้งาน โดยตัวอย่างนี้อยู่ที่ประมาณ 20 ตัวอักษร
  • ยังมีฮุกเสริมสองตัว
    • connect_send(): ถูกเรียกตอนเริ่มต้นไปป์ SEND และในการติดตั้งใช้งานกับบัญชีสะสมไมล์อาจใช้ล็อกอินด้วยชื่อผู้ใช้และรหัสผ่านเพื่อรับคุกกี้
    • connect_recv(): ถูกเรียกตอนเริ่มต้นไปป์ RECV

ไอเดียเรื่องการเข้ารหัส base26 และการเพิ่มแบนด์วิดท์

  • ฟอร์ม HTML ของบัญชีสะสมไมล์สายการบินอาจไม่ยอมให้ใส่อักขระที่ไม่ใช่ตัวอักษรในชื่อ
    • Stephen อาจผ่านได้
    • GET /data?id=5 อาจถูกปฏิเสธ
  • เพื่อหลีกเลี่ยงปัญหานี้ network layer จึงอาจต้องเข้ารหัสเซกเมนต์เป็นbase26ก่อนเขียนลงบัญชีสะสมไมล์สายการบิน
    • base26 แทนสตริงโดยใช้เฉพาะตัวอักษร A ถึง Z
    • แนวคิดคือแปลงสตริงไบต์เป็นตัวเลขก้อนใหญ่ แล้วแสดงผลเหมือนเลขฐาน 26 ด้วยอักษร A~Z
    • ตัวอย่าง: b26_encode("Hello world") จะคืนค่า CZEZINADXFFTZEIDPKM
  • transport layer ไม่จำเป็นต้องรู้เรื่องการเข้ารหัสนี้
    • network layer จะแปลงไบต์เป็น base26 ตอนเขียน และแปลงกลับเป็นไบต์ตอนอ่าน
  • base26 ทำให้สตริงยาวขึ้นมากและลดแบนด์วิดท์
    • หากใช้ base52 ซึ่งใช้ทั้งตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก สตริงอาจสั้นลงได้ แต่เรื่องนี้ถูกเก็บไว้เป็นการปรับปรุงในเวอร์ชัน 2
  • แบนด์วิดท์ยังเพิ่มได้ด้วยการขยายขนาดเซกเมนต์
    • แม้หนึ่งฟิลด์จะเก็บได้เพียง 20 ตัวอักษร แต่ถ้าเขียนพร้อมกัน 5 ฟิลด์ ฟิลด์ละ 20 ตัวอักษร ก็จะส่งเซกเมนต์ 100 ตัวอักษรได้ในคำขอเดียว
    • ฝั่งรับก็สามารถอ่านทั้ง 5 ฟิลด์ในคำขอเดียวแล้วนำมาต่อกันใหม่ได้

ช่องทางปรับปรุงจาก HTTP CONNECT และการทดสอบสุดท้าย

  • หากใช้ HTTP CONNECT requests แทนการรับส่งคำขอ HTTP แบบแมนนวล PySkyWiFi ก็อาจสร้างอุโมงค์ข้อมูลที่ดีกว่าได้
  • CONNECT เป็นวิธีที่พร็อกซี HTTP ส่วนใหญ่ใช้กัน และถ้าใช้แนวทางนี้ PySkyWiFi จะทำงานได้เหมือนพร็อกซีระดับระบบและรองรับคำขอจากเบราว์เซอร์ด้วย
  • เมื่อใช้ CONNECT แล้ว PySkyWiFi จะเจรจาการเชื่อมต่อ TLS กับเว็บไซต์ปลายทางโดยตรง ทำให้ทราฟฟิกที่ผ่านบัญชีสะสมไมล์สายการบินถูกเข้ารหัส
  • ข้อเสียคือภาระการติดตั้งใช้งานจะมากขึ้นมาก
  • ในการทดสอบสุดท้าย มีการทำ tunneling ข้อมูลผ่าน GitHub Gist เพื่อโหลดหน้าโฮมเพจของบล็อกด้วย curl และได้รับคำตอบ HTML กลับมาหลังจากผ่านไปหลาย分钟

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-10
ความคิดเห็นบน Hacker News

  • เมื่อหลายสิบปีก่อน คู่สมรสของผมใช้ ข้อความ Google Voice โดยอ่านและตอบจากกล่องจดหมาย Gmail ได้โดยตรง แต่เพราะไม่ชอบโทรศัพท์มือถือ จึงพก Kindle Keyboard รุ่นเก่าที่มี 3G ไม่จำกัดติดตัวไปด้วย
    เบราว์เซอร์แบบง่าย ๆ ของ Kindle เปิดหน้า Gmail แบบสเปกต่ำได้ จึงใช้เหมือนอุปกรณ์ SMS ที่ไม่มีค่าบริการรายเดือนได้ ปัญหาเดียวคือการแจ้งเตือนข้อความใหม่
    ดังนั้นหลังจาก jailbreak แล้วตอนแรกตั้งใจจะใส่ตัวนับไว้บนหน้าจอหลัก แต่ก็นึกได้ว่าน่าจะวางตัวนับไว้ข้างชื่ออุปกรณ์ Kindle ซึ่งเปลี่ยนได้จากบัญชี Amazon
    ผมให้เซิร์ฟเวอร์ที่บ้านใช้ browser automation ล็อกอินเข้า Amazon แล้วเปลี่ยนชื่ออุปกรณ์เป็น My Kindle (x) โดย x คือจำนวนข้อความ Google Voice ที่ยังไม่ได้อ่าน และ Kindle จะอัปเดตชื่อบนหน้าจอหลักภายใน 1 นาที ใช้งานได้ดีอยู่หลายปี

    • เท่าที่จำได้ บิล AT&T ของ Kindle 3G นั้นมหาศาลมาก
      จำได้ว่าแค่ลดข้อมูลลงไม่กี่ไบต์ก็ประหยัดได้ระดับราวล้านดอลลาร์
    • เคยให้เพื่อนร่วมงานที่กำลังจะเดินทางยืม Kindle Keyboard ไป แล้วมันถูกขโมยที่เม็กซิโก
      ตอนนั้นมันคงแทบจะเป็น Kindle ที่ยังใช้งานได้รุ่นเก่าที่สุดแล้ว ดังนั้นโจรน่าจะหยิบไปเพราะมันอยู่ในกระเป๋าเฉย ๆ
      ภายหลังผมเจอ Kindle Keyboard ราคา 20 ดอลลาร์ที่ตลาดนัดอีกเครื่อง แต่ 6 เดือนต่อมาแบตเตอรี่ก็ตาย และยังเก็บเครื่องไว้อยู่ เลยสงสัยว่าค่าแบตเตอรี่ทดแทนจะเท่าไร
    • 3G ฟรี นั่นยอดเยี่ยมจริง ๆ
      ใช้ Gmail ผ่านเบราว์เซอร์ได้แบบเฉียดฉิว และผมยังทำเว็บไซต์ Zork ที่เป็นมิตรกับ Kindle ให้เลือกเล่นเกมข้อความจาก zmachine ROM หลายตัวได้ด้วย
      พอถูกนำไปแนะนำในเว็บไซต์ข่าวบางแห่งก็ได้รับเสียงตอบรับอยู่พอสมควร
    • ผมก็ทำแบบนี้เหมือนกัน
      ถึงจะไม่มีการเชื่อมระบบอันชาญฉลาดที่เปลี่ยนชื่อ Kindle แต่ก็เคยใช้ Keyboard Kindle ที่มี 3G ไม่จำกัดส่งข้อความอยู่พักหนึ่ง
    • ก่อนซื้อสมาร์ตโฟน ผมใช้ Kindle Keyboard นำทาง ตอนขับรถทางไกล
      พอจะรันเว็บไซต์ Google Maps ได้แบบฝืน ๆ

  • สมัยก่อนผมนั่งเรือเฟอร์รีประมาณ 20 ชั่วโมงจากอิตาลีไปกรีซ มี Wi-Fi แบบเสียเงินที่ใช้อินเทอร์เน็ตผ่านดาวเทียม แต่ผมไม่อยากจ่าย
    การเข้าถึง Stripe เพื่อชำระเงินถูกเปิดไว้ และปรากฏว่าสามารถเข้าหน้าทั้งหมดของ stripe.com ได้ รวมถึงเอกสารสำหรับนักพัฒนา ผมเลยเริ่มดาวน์โหลดรูปซ้ำ ๆ เพื่อผลาญแบนด์วิดท์
    แล้วก็นึกขึ้นได้ว่าเพื่อให้ Stripe ทำงาน ต้องเข้าถึง Fastly CDN ได้ และ Reddit ก็ใช้ Fastly เช่นกัน พอเชื่อมต่อไปที่ Stripe แล้วเปลี่ยน HTTP Host header เป็น reddit.com ก็เข้า Reddit ได้
    รูปภาพใช้ไม่ได้เพราะ i.redd.it ไม่ได้อยู่บน Fastly แต่พอผูก old.reddit.com กับ IP Fastly ของ Stripe ใน /etc/hosts แล้วเมิน TLS error น่ากลัว ๆ ก็ล็อกอินได้ด้วย

    • เป้าหมายที่ได้รับความเสียหายจากการดาวน์โหลดเอกสารหลายกิกะไบต์แบบนั้น มีโอกาสสูงว่าจะเป็น ผู้โดยสารบนเครื่องบิน ที่จ่ายเงินใช้บริการนั้น
      ถ้าการเชื่อมต่อช้าลงจนพวกเขาไม่ซื้ออีก บริษัทผู้ให้บริการก็เสียหายด้วย และยังอาจเพิ่มต้นทุนแบนด์วิดท์อัปโหลดของ Stripe ได้อีก
      ส่วนผมเอง แม้แต่บนเครือข่ายเซลลูลาร์ก็พยายามหลีกเลี่ยงการดาวน์โหลด เพราะกลัวจะส่งผลกระทบไม่ดีต่อคนรอบข้าง
    • ผมไม่แน่ใจว่าการทำแบบนั้นได้อะไรขึ้นมากันแน่
      การทดลองทางปัญญาเพื่อสำรวจว่าจากการเชื่อมต่อที่ถูกบล็อกจะเข้าถึงอะไรได้บ้างนั้นพอเข้าใจได้ แต่การจงใจผลาญแบนด์วิดท์ก็คล้ายกับเปิดก๊อกน้ำในห้องน้ำสาธารณะทิ้งไว้ให้เสียน้ำ หรือทำให้ชักโครกตันจนล้น
    • นั่นคือ domain fronting และตอนนี้ CDN รายใหญ่ทั้งหมดบล็อกไว้แล้ว
      https://en.wikipedia.org/wiki/Domain_fronting
    • คราวหน้าคงเปิดน้ำในโรงแรมทิ้งไว้เพื่อสั่งสอนพวกเขา เพราะบังอาจให้บริการแบบเสียเงินสินะ
    • ผมสงสัยว่าทำไมสัญชาตญาณแรกต่อบริการที่ไม่อยากจ่ายเงินใช้ ถึงเป็นการ ใช้ฟังก์ชันในทางที่ผิดหรือทำให้เสื่อมประสิทธิภาพ

  • เมื่อไม่กี่สัปดาห์ก่อน ผมพาลูก ๆ ไปส่งเข้าคลาสที่ห้างและพยายามใช้ Wi-Fi ฟรี ล็อกอินจากแล็ปท็อปสำเร็จ แต่ขึ้นว่าใช้อินเทอร์เน็ตไม่ได้
    เมื่อตรวจสอบ default gateway ก็พบว่าเชื่อมไปยังโมเด็ม Cisco และเห็นเครื่องมือวินิจฉัยกับรายการอุปกรณ์ที่เชื่อมต่ออยู่ แต่การเชื่อมต่ออินเทอร์เน็ตถูกปิดอยู่
    ผมใช้มือถือค้นหารุ่น พบว่าบัญชีผู้ดูแลระบบใช้หมายเลขซีเรียล และรหัสผ่านเว้นว่างไว้ พร้อมมีรูปแบบตัวอย่างด้วย ซึ่งชื่อของอุปกรณ์หนึ่งในรายการที่เชื่อมต่อก็ดูตรงกับรูปแบบนั้นพอดี
    ผมจึงล็อกอินเข้าไปตามนั้น เปิด ปุ่มอินเทอร์เน็ต และ 15 วินาทีต่อมามันก็กลายเป็นสีเขียว จากนั้นตั้งรหัสผ่านอุปกรณ์ใหม่ด้วย

    • ครั้งหนึ่งตอนผมไปเยี่ยมครอบครัว เคยเชื่อมต่อ Wi-Fi ของเพื่อนบ้านที่ไม่ได้ป้องกัน เพื่อจะเข้า VPN ของบริษัท
      VPN เชื่อมต่อไม่ได้ และเพราะเข้าเราเตอร์ได้ง่าย ๆ ผมเลยเปลี่ยน การตั้งค่า MTU แล้วมันก็ทำงานปกติทันที

  • การแฮ็ก แบบนี้เท่และผมชอบในความหมายดั้งเดิมของคำจริง ๆ
    แต่พอลองตรวจสอบล่าสุด ดูเหมือนว่าใน skywifi การ resolve DNS ทั่วโลกทำงานได้ตามปกติแม้ไม่จ่ายเงิน และบนเที่ยวบินที่ผมนั่ง ก็น่าจะใช้ iodine tunnel แบบทั่วไปได้เลย
    https://github.com/yarrick/iodine

    • เมื่อหลายปีก่อน ผมเคยรัน บริการ iodine สาธารณะที่ใครก็เชื่อมต่อได้
      เพื่อหลีกเลี่ยงรายงานการใช้งานในทางที่ผิด ผมให้ทราฟฟิกขาออกของเซิร์ฟเวอร์ผ่าน Tor และยังเก็บล็อกว่าใช้งานได้บนเครือข่ายรถไฟ โรงแรม สนามบินใดบ้าง รวมถึงให้บริการโปรโตคอล tunneling อื่น ๆ ด้วย
      เป็นโปรเจกต์ที่สนุกอยู่พักหนึ่ง และน่าจะปล่อยให้มันรันต่อไป
      ทุกวันนี้ DNS tunneling ยากขึ้นอีกหน่อย เพราะ DNS server บางตัว โดยเฉพาะ Google จะสุ่มตัวพิมพ์เล็ก/ใหญ่ของคำขอ DNS ทำให้ encoding บางแบบพังหนัก
    • เมื่อ 6 ปีก่อน iodine ใช้ได้บน Wi-Fi ของสายการบินอื่น
      แนวคิดและหลักการน่าสนุก แต่ด้วยความเร็วแล้วแทบไม่มีประโยชน์ในการใช้งานจริง เว้นแต่อาจจะเอาไว้รันเมสเซนเจอร์อะไรสักอย่างบน UDP ;-)
    • ถ้าไฟร์วอลล์อนุญาต DNS อยู่แล้ว ก็ใช้ WireGuard บน UDP/53 ไปเลยโดยไม่ต้องไปยุ่งกับตัวโปรโตคอล DNS ไม่ใช่หรือ?

  • “ผมลืมชาร์จหูฟัง แล้ว Limp Bizkit ก็เริ่มดังออกมาจากลำโพงโน้ตบุ๊ก โชคดีที่คนอื่นบนเครื่องดูเหมือนไม่ได้สนใจ ทุกคนเลยสนุกไปด้วยกัน”
    คนแบบนี้ขาด มารยาทพื้นฐานในที่สาธารณะ
    คนรอบข้างหลายคนคงรำคาญแน่ ๆ แต่อาจเป็นคนสุภาพเกินกว่าจะบอกว่าอย่าบังคับให้คนอื่นต้องฟังเสียงรบกวนที่ไม่จำเป็น

    • ถ้าผู้เขียนเขียนว่า “นี่เป็นการเสียดสีครับ” การเสียดสีก็พังทันที
    • ผมอ่านว่าเป็นมุกตลก
      เพราะคนที่ไม่มีมารยาทพื้นฐานแบบนี้มีเยอะมาก เลยคิดว่าเป็นมุกที่ตลก และอย่างน้อยผู้เขียนก็คงไม่ได้เป็นคนแบบนั้นจริง ๆ
    • มุกไม่ได้ตลกเท่าไร แต่ก็เข้ากับหัวข้อของบทความ
      มันแสดงภาพของแฮ็กเกอร์ที่มองความเป็นไปได้ของอินเทอร์เน็ตฟรีว่าเป็นโอกาสที่ลงมือทำได้ และต่อมาก็เว้นระยะด้วยท่าทีว่าไม่ได้เป็นคนที่จะเอาระบบสายการบินไปใช้ในทางที่ผิดจริง ๆ ดังนั้นโทนช่วงต้นจึงดูเป็นอุปกรณ์เชิงสำนวน
    • ดูเหมือนสิ่งที่มนุษย์เรียกว่า “อารมณ์ขัน”
    • หวังว่าจะเป็นมุกอย่างที่คนอื่นว่า
      ถ้าไม่ใช่ ก็เป็นพฤติกรรมที่เสียมารยาทและไร้น้ำใจมาก

  • สงสัยว่ามีแค่ผมหรือเปล่าที่พอขึ้นเครื่องทีไรก็เหนื่อยตลอด จนทำอะไรไม่ได้นอกจากหลับตารอให้ถึงปลายทาง
    แค่คิดจะหยิบโน้ตบุ๊กหรือหนังสือออกมาก็หมดแรงแล้ว เสียงก็เยอะ และไม่มีหูฟังตัดเสียงรบกวนเลยยิ่งมีสมาธิยาก
    กว่าจะออกจากบ้าน ผ่านรถไฟ·รถราง·ด่านตรวจความปลอดภัย ก็ใช้เวลาอย่างน้อย 2 ชั่วโมงแล้ว อาหารไม่ดีต่อสุขภาพในสนามบินก็ไม่ได้ช่วยอะไร
    สภาพอากาศก็มีอยู่ครึ่งปีที่ร้อนหรือหนาวเกินไป และกระเป๋าเป้ 10 กก. ทำให้เหงื่อออกตลอด สุดท้ายพออยู่บนเครื่องก็ไม่เหลืออารมณ์จะทำอะไร

    • ผมมี ADHD ในผู้ใหญ่ ที่ทำงานจะมีสมาธิยากกว่า แต่บนเครื่องบินหรือสถานที่วุ่นวายอื่น ๆ กลับจดจ่อได้เหมือนเลเซอร์
      ฟังดูสวนทางกับสัญชาตญาณ แต่เคยได้ยินว่าสมอง ADHD จำนวนมากทำงานแบบนี้ และเวลาบนเครื่องบินเป็นช่วงที่ผมทำงานได้มีประสิทธิผลที่สุด
    • เมื่อก่อนเคยพยายามหยิบโน้ตบุ๊กออกมาทำอะไรสักอย่าง แต่หลังจาก ระยะห่างระหว่างที่นั่ง แคบลง ก็ยากจริง ๆ ที่จะหยิบของที่ใหญ่กว่าแท็บเล็ตออกมา
      ต้องวางพาดบนตัก หรือถ้าคนข้างหน้าปรับเอนเบาะ จอก็เสี่ยงแตก ซึ่งเพื่อนร่วมงานผมเคยเจอจริงเมื่อไม่กี่ปีก่อน
      เดี๋ยวนี้ผมแค่หยิบ iPad กับหูฟังตัดเสียงรบกวนออกมาดูหนังหรือรายการทีวี
    • ไม่ใช่แค่คุณคนเดียว
      ร่างกายผมก็ตอบสนองแบบเดียวกัน และผมคิดว่าเกี่ยวกับ ปริมาณออกซิเจนในอากาศที่ลดลง
      ปัญหาไม่ใช่เสียง แต่เป็นเรื่องอากาศ ส่วนหูฟังตัดเสียงรบกวนก็ได้ผลดีจริง ๆ
      แต่ก็มีคนที่ไม่ได้รับผลกระทบเลยและทำงานที่มีประโยชน์บนเครื่องบินได้จริง ๆ
    • ผมตรงกันข้ามเลย
      ไม่ว่าจะเหนื่อยหรืออดนอนแค่ไหน บนเครื่องบินผมก็หลับไม่ลงและไม่รู้สึกง่วง เลยทำให้เที่ยวบินข้ามมหาสมุทรแอตแลนติกทรมานยิ่งขึ้น และถ้าเพื่อนร่วมทางหลับได้ 8 ชั่วโมง ก็ยังรู้สึกเหมือนถูกล้อด้วยซ้ำ
    • ไม่ใช่แค่คุณคนเดียว
      ระหว่างบินหัวผมจะมึนตื้อมากจนต้องหลับตาไปจนกว่าจะลงจอด และต่อให้พยายามอ่านหนังสือหรือทำงาน ผ่านไป 5–10 นาทีสมองก็ปิดเครื่อง
      แปลกที่ อาหารบนเครื่อง ทำให้ท้องอืดทุกครั้ง จนต้องกินยาทันทีหลังลงจอด
      น่าสนใจว่าตอนที่ได้นั่งชั้นธุรกิจสองครั้ง ผมยังอ่านหนังสือได้อยู่บ้างก่อนสมองจะปิด
      บนรถไฟทางไกล ถ้านั่งหันหน้าไปตามทิศทางการเดินทาง ผมทำงานได้ง่ายกว่าจริง ๆ แต่ถ้ารถไฟค่อนข้างแน่น สมองก็กลับมาปิดอีก

  • พอเห็นเรื่องการส่งราคาหุ้น คะแนนกีฬา สภาพอากาศ อะไรพวกนี้ ก็ทำให้นึกถึงฟีเจอร์ที่ Google เคยให้บริการผ่าน บริการข้อความ SMS
    ก่อนซื้อสมาร์ตโฟนเครื่องแรก ผมใช้มันเยอะมาก ส่ง W[ZIP code] ไปที่ 46645(GOOGL) แล้วมันจะตอบสภาพอากาศกลับมาทาง SMS
    stock:[symbol] ก็ใช้ได้ และยังมีฟีเจอร์อื่น ๆ อีกหลายอย่างที่ตอนนี้จำไม่ได้แล้ว
    แน่นอนว่า Google ปิดบริการไปแล้ว แต่ระหว่างที่ยังอยู่ มันเจ๋งทีเดียว

    • สมัยที่ยังเขียน PHP ผมเคยทำบอต Twitter ชื่อ SongBuddy สำหรับค้นหาเพลงจากท่อนเนื้อร้อง
      โครงสร้างคือส่งเนื้อร้องสองสามบรรทัดผ่าน SMS DM ที่ Twitter รองรับในตอนนั้น แล้วบอตจะค้นหา " lyrics" ใน Google แยกผลลัพธ์ออกมา แล้วส่งศิลปินกับชื่อเพลงกลับทาง SMS
      มันทำงานไม่ได้ดีนัก แต่ผมก็ภูมิใจพอสมควร
    • เว็บไซต์แปลงอัตราแลกเปลี่ยนที่ผมใช้มีอาจารย์คนหนึ่งเป็นคนดูแล และถึงมันน่าจะรันอยู่บนเครื่อง Pentium III ที่ซ่อนอยู่ใต้บันไดมหาวิทยาลัย แต่ก็อยู่รอดมาหลายสิบปีแล้ว และดูเหมือนจะอยู่ไปได้ตลอดชีวิต
    • ผมทำ อินเทอร์เฟซ SMS↔ChatGPT ด้วย Twilio และอินสแตนซ์ AWS
      ด้วยเหตุนี้ ผมจึงถาม ChatGPT ได้จากทุกที่บนโลกผ่านอุปกรณ์สื่อสารผ่านดาวเทียมพกพา inReach Mini 2 และการถามได้แม้อยู่กลาง Death Valley ก็รู้สึกดีทีเดียว
    • ผมใช้บริการนั้นตลอดตอนใช้มือถือฝาพับ
      การพิมพ์คำค้น Google ใช้เวลานาน และอาจต้องรอ 1–2 นาทีกว่าผลลัพธ์จะกลับมา แต่ก็ดีกว่าไม่มี
      ส่วนใหญ่ใช้ค้นหาที่อยู่ของสถานที่ที่อยากไป แล้วเอาไปใส่ใน TomTom ยุคสมัยเปลี่ยนไปมากจริง ๆ
    • อยากรู้เหมือนกันว่านั่นเป็นช่วงไหน
      ราวปี 1995 ตอนทำงานที่บริษัทวิจัยโทรคมนาคมซึ่งเป็นบริษัทลูกของ Ericsson ผมเคยคิดไอเดียแบบนี้ขึ้นมา และตัวอย่างเด่น ๆ คือ การอัปเดตสถานะเที่ยวบิน
      ตอนนั้นไม่มีใครจินตนาการว่า P2P messaging ที่ต้องกดปุ่มตัวเลขหลายครั้งเพื่อป้อนตัวอักษรหนึ่งตัวจะได้รับความนิยมขนาดนั้น ดังนั้นในสภาพที่ข้อมูลบนเว็บยุคแรกเริ่มเพิ่มขึ้น บริการข้อมูลจึงดูเหมือนการใช้งานที่ดีที่สุด
      Teletext ก็ยังมีอยู่ และยังมีโปรเจกต์แยกต่างหากที่ดึงข้อมูลจากมันด้วย
      แต่พอคิดดูว่า สุดท้ายพวกเราที่เข้าถึง SMS ได้กับคนทั่วไปเอามันไปใช้ทำอะไรกัน ก็เป็นเรื่องน่าสนใจ

  • น่าสนใจที่ผู้เขียนเข้าใกล้ TCP บนฟิลด์แก้ไขร่วมกันแบบนามธรรม มากทีเดียว
    ตัวมันเองก็อาจเป็นเครื่องมือที่เจ๋งมากได้
    ถ้าออกแบบในระดับสูงแค่ว่าทั้งสองฝั่งจะอ่านและเขียนทรัพยากรที่ใช้ร่วมกันอย่างไร ก็พอจินตนาการถึงพร็อกซีที่จัดการส่วนที่เหลือทั้งหมดแล้วให้บริการเป็น SOCKS proxy ได้

    • เท่าที่รู้ เคยมีการทำ TCP/IP บน DNS เพื่อใช้อินเทอร์เน็ตฟรีจากฮอตสปอตสนามบิน Boingo แบบเสียเงินมาแล้ว
      สุดท้ายเมื่อ Wi‑Fi ฟรีกลายเป็นมาตรฐาน เรื่องนี้ก็ไม่ใช่อะไรพิเศษอีกต่อไป และตอนนี้ก็ขยับมาเป็นสงคราม Wi‑Fi ฟรีบนเครื่องบิน
      ท้ายที่สุด Wi‑Fi บนเครื่องบินก็คงฟรีทุกที่ และหลายสายการบินก็ทำแบบนั้นแล้ว
    • ผมคิดเรื่องนี้มาหลายปีแล้ว ตั้งแต่ผู้ให้บริการมือถือในประเทศของเราเริ่มโฆษณา “WhatsApp ไม่จำกัด” ในแพ็กเกจที่จำกัดปริมาณข้อมูล
      อาจใช้ได้แค่ข้อความ ไม่ได้รูปหรือวิดีโอ แต่ก็น่าจะเพียงพอสำหรับการท่องเว็บทั่วไป

  • เมื่อไม่กี่ปีก่อน อธิการบดีของมหาวิทยาลัยเราเคยพูดทำนองว่า “เกมส่งผลต่อการเข้าเรียน” แล้วตัดสินใจบล็อก เครือข่าย LAN หลัง 22:00 น.
    วิธีที่ใช้คือบล็อกทราฟฟิกทั้งหมดที่เข้าออกตามที่อยู่ IP แต่ไม่ได้บล็อก TCP เอง และตอนนั้นก็ลืม IPv6 ซึ่งแม้จะไม่ใช่ของใหม่มากแล้วไปเสียสนิท
    ดังนั้นผมจึงทำแอปแชต P2P ง่าย ๆ ที่ทำงานผ่าน IPv6 และปัญหาเดียวก็คือต้องแชร์ที่อยู่ IPv6 ให้เพื่อน ๆ แล้วให้เก็บไว้ในรายชื่อติดต่อ
    มันทำงานได้ดี แต่ภายหลังผมก็พบว่าการทำ tunneling ไปยังคอมพิวเตอร์นอกเครือข่ายนั้นง่ายกว่ามาก

  • นี่ดูเหมือนเป็นตัวอย่างที่แทบสมบูรณ์แบบ ซึ่งทำให้นึกถึงบทความเรื่อง มาเขียนซอฟต์แวร์ไร้ประโยชน์กันให้มากขึ้น และการถกเถียงต่อเนื่องบน HN
    มันเปลี่ยนชีวิตไหม? คงไม่
    กระบวนการสร้างและสำรวจมันสนุกไหม? แทบจะแน่นอน
    เราควรสร้างสิ่งแบบนี้ให้มากขึ้น
    https://ntietz.com/blog/write-more-useless-software/
    https://news.ycombinator.com/item?id=37911900