Android पर CDC Ethernet का उपयोग क्यों नहीं किया जा सकता (2023)

• Android की EthernetTracker सेवा केवल उन्हीं network interfaces को पहचानती है जिनका नाम ethX होता है
• Linux का CDC Ethernet driver interface नाम usbX के रूप में बनाता है
• इसी वजह से standard CDC Ethernet devices Android पर अपने-आप सक्रिय नहीं होते
• इसे ठीक करने के लिए उपयोगकर्ता को खुद फोन root करना होगा और config_ethernet_iface_regex मान बदलना होगा
• standard USB Ethernet adapter की जगह, vendor-specific driver वाले कुछ खास chipset products का उपयोग करना ही व्यावहारिक तरीका है

---

परिचय और समस्या का सार

• Android device पर CDC Ethernet के काम न करने का मुख्य कारण interface naming rule है
• सिस्टम स्तर पर USB Ethernet adapter का support है, लेकिन Ethernet menu के सक्रिय होने की शर्तों में सीमाएँ हैं
• compatible chipset की जानकारी पाना कठिन है, और व्यवहार में यह काफी हद तक उपयोगकर्ताओं के बीच की "सुनी-सुनाई बातों" पर निर्भर करता है
• Android भी Linux kernel पर आधारित है, लेकिन केवल kernel settings से सब कुछ तय नहीं होता

USB debugging और ADB सेटअप

• Android device पर USB debugging सक्षम करने के बाद ADB install करना आवश्यक है
• network adapter को test करने के लिए ADB को Wi-Fi के जरिए network mode में बदलना होगा
• commands के माध्यम से वर्तमान kernel version और architecture की जाँच की जा सकती है

kernel version और settings जाँचने का तरीका

• नए फोन (Android 11 और उसके बाद) में GKI(Generic Kernel Image) kernel संरचना होती है
  • Google base kernel build करता है, और manufacturer केवल modules जोड़ता है
  • उस kernel settings file (gki_defconfig) से supported features का पता लगाया जा सकता है
• पुराने फोन में manufacturer द्वारा अलग से दिए गए kernel source में defconfig file ढूँढकर जाँच करनी होती है
• किस्मत अच्छी हो तो /proc/config.gz path से current kernel settings सीधे देखी जा सकती हैं

supported USB Ethernet adapters की पहचान कैसे करें

• अधिकतर संबंधित kernel setting values CONFIG_USB_NET_XXX के रूप में होती हैं
  • y हो तो built-in, m हो तो module के रूप में build (संभवतः उपयोग योग्य), is not set हो तो support नहीं है
• drivers/net/usb/Kconfig file में हर setting value का विवरण देखा जा सकता है
• adapter chipset की जानकारी अब भी स्पष्ट रूप से मिलना दुर्लभ है

CDC Ethernet (Communications Device Class) और Android में उसका व्यवहार

• CDC USB networking standard है, जो EEM/ECM/NCM जैसे कई protocols प्रदान करता है
• Linux, Windows, macOS में standard CDC Ethernet devices बिना अलग driver के अपने-आप पहचाने जाते हैं
• Android में भी kernel level पर संबंधित drivers build किए गए होते हैं
  • उदाहरण: Samsung devices में CONFIG_USB_NET_CDCETHER, EEM, NCM सभी y पर सेट हैं
• फिर भी Ethernet menu सक्रिय नहीं होता

Android का network interface tracking logic

• Android network interface detection के लिए EthernetTracker.java class का उपयोग करता है
• EthernetTracker नया interface आने पर उसके नाम के pattern (regular expression) से match करता है
• यह matching rule resource (config_ethernet_iface_regex) से लिया जाता है
  • default value eth\\d है (eth से शुरू होकर उसके बाद संख्या आने वाले network interfaces ही मान्य हैं)
• kernel द्वारा बनाया गया नाम (usb0) इस pattern से मेल नहीं खाता, इसलिए उसे track और activate करने में अनदेखा कर दिया जाता है

समाधान की सीमाएँ और निष्कर्ष

• इस naming regular expression को उपयोगकर्ता सीधे बदल नहीं सकता (rooting के बिना असंभव)
• परिणामस्वरूप standard CDC Ethernet products जुड़े होने पर भी network menu में उपयोग नहीं किए जा सकते
• इसके विपरीत, vendor या chipset driver के जरिए सीधे registered कुछ adapters ही काम कर पाते हैं
• भले ही Google EEM module जैसे standard support code को kernel में शामिल करे, वास्तविक उपयोग फिर भी संभव नहीं होता
• कम-से-कम regular expression को (eth|usb)\\d में बदल देने से समस्या हल हो सकती है, लेकिन फिलहाल यह वैसा ही बना हुआ है

सारांश

• मुख्य कारण: Android CDC Ethernet standard को नज़रअंदाज़ नहीं करता, बल्कि network interface का नाम regular expression (eth\\d) से मेल न खाने के कारण उसे सक्रिय नहीं करता
• बचाव का तरीका: फोन को root करके config_ethernet_iface_regex मान (eth|usb)\\d आदि में बदलना होगा
• व्यावहारिक विकल्प: standard USB CDC-supported adapter की तुलना में ऐसे products चुनना अधिक यथार्थवादी है जिनमें chipset-specific driver integration स्पष्ट हो
• संरचनात्मक समस्या: user visibility और standard compatibility के लिहाज़ से software upper stack की naming policy की कमी सिस्टम स्तर की सीमा के रूप में सामने आती है

[GN⁺]

Hacker News टिप्पणियाँ

• पिछले कार्यस्थल पर Android डिवाइस और CDC Ethernet adapter को जोड़ने की कोशिश में काफ़ी परेशानी होने के बाद यह लेख लिखा था; बाद में कुछ लोगों से पता चला कि MAC address के एक खास bit को बदलने पर kernel ethX नाम असाइन कर देता है। लेखक ने इसे खुद टेस्ट नहीं किया और न ही पोस्ट में जोड़ा, और अब वे Android डिवाइस लगभग इस्तेमाल भी नहीं करते। साथ ही यह शर्त भी जोड़ी कि यह तरीका तभी काम करेगा जब आप MAC address को नियंत्रित कर सकें.
  • प्रतिक्रिया कि यह जानकारी उनके लिए उपयोगी हो सकती है, और यह कहते हुए कि कौन-सा bit है, उन्होंने संबंधित लिंक साझा किया.
  • उस पोस्ट पर सकारात्मक प्रतिक्रिया व्यक्त की.
• इसे एक दिलचस्प deep-dive article बताया गया; source देखने पर लगता है कि अक्टूबर 2023 में समस्या वाली regex को eth\\d से * में बदला गया था, और अनुमान है कि इससे समस्या हल हो गई। संबंधित code change लिंक दिया गया, साथ ही यह भी कि Android U+ (शायद version 14) से डिफ़ॉल्ट रूप से usb\\d+ और eth%d दोनों शामिल हो गए.
  • बताया गया कि बाद में यह बदलाव इसलिए rollback किया गया क्योंकि "कुछ डिवाइस usbX interface पर tethering करती हैं"; उसके तुरंत बाद इसे फिर से लागू किया गया, लेकिन केवल Android V+ version (नया version) के लिए। rollback लिंक और अंतिम लागू लिंक भी जोड़े गए.
• Android की EthernetTracker service केवल ethX नाम वाले interface को मान्यता देती है—इस बात की कड़ी आलोचना की गई। समझाया गया कि Linux distributions ने यह समस्या 2000 के दशक में ही हल कर ली थी। याद किया गया कि पहले हर driver अपना अलग name prefix इस्तेमाल करता था, इसलिए पूरे system की जाँच करनी पड़ती थी। आज Linux distributions udev जैसे tools से network interface names अपने-आप बदल देती हैं, और यह प्रक्रिया kernel के SIOCSIFNAME ioctl call से चलती है। यह भी जोड़ा गया कि नए kernels में "wlan*" या "wlan%d" जैसे नामों पर अपने-आप नंबर जुड़ जाने की सुविधा भी मिलती है.
• LineageOS commit history देखने पर विश्लेषण किया गया कि यह समस्या ठीक की गई थी, फिर compatibility समस्या के कारण वापस ली गई, और नवीनतम Android versions में फिर से लागू है। commit सामग्री देखकर यह राय भी दी गई कि Google के लोग भी इसमें शामिल दिखते हैं, इसलिए संभव है कि Google के official builds में भी यह लागू हुआ हो.
• लेख की इस पंक्ति—"<i>config_ethernet_iface_regex value बदलने के लिए phone को root करना ही एकमात्र तरीका है</i>"—से सहमति जताते हुए कहा गया कि यह एक और कारण है कि उनके अपने डिवाइस पर root access महत्वपूर्ण है.
  • जवाब में कहा गया कि network traffic को मनचाहे तरीके से bypass किया जा सकता है, और यही सबसे बड़ा कारण है कि user space को superuser permission नहीं दी जानी चाहिए। OEM पर bootloader unlock की अनुमति देने के लिए दबाव बनाने से सहमति जताई गई, लेकिन Android पर root access हमलावर को जो बड़ा attack surface देता है, उसके मुकाबले इसके कोई बहुत ठोस औचित्यपूर्ण उपयोग याद नहीं आते.
• "काम नहीं करता" से क्या मतलब है—यह पूछते हुए कहा गया कि MacBook के लिए USB hub dongle को Android phone में लगाने पर Ethernet port बिना किसी समस्या के काम कर गया था, और cellular modem भी Ethernet device के रूप में पहचान लिया गया था और Android पर ठीक से चला.
  • जवाब दिया गया कि यह समस्या पहले ही ठीक हो चुकी है, और मूल लेख 2 साल पुराना है.
• शिकायत की गई कि Android बहुत असुविधाजनक तरीके से एक साथ कई network connections की अनुमति नहीं देता। उदाहरण के लिए, internet के बिना WiFi (जहाँ default router भी न हो) और cellular network को एक साथ जोड़ना संभव नहीं। Linux या Windows में यह सामान्य है, लेकिन Android इसे ज़बरदस्ती रोकता है। यहाँ तक कि कई modified versions में अगर आप internet-विहीन WiFi से जुड़े रहना चाहें, तो connection भ्रमित करने वाले तरीके से टूट जाता है; या फिर बस apps के लिए थोड़ा-बहुत काम करने वाला API मिलता है, लेकिन user को ऐसा नियंत्रण नहीं दिया जाता.
  • कहा गया कि iOS भी ऐसा ही है। dashcam से वीडियो लेने के लिए WiFi से जुड़ने पर "इंटरनेट नहीं है, cellular पर स्विच करें?" जैसा popup आता है, और भले ही WiFi पर बने रहने को कहा जाए, अंत में iOS खुद ही CarPlay network पर मजबूरन स्विच कर देता है। यह भी जोड़ा गया कि इसे manually disable करने का विकल्प भी नहीं है.
  • कहा गया कि Windows में भी वास्तव में दो wireless adapters के साथ दो WiFi networks से एक साथ connect नहीं किया जा सकता, कम-से-कम GUI में तो नहीं; terminal से कोशिश नहीं की.
  • इस सीमा को बेहद परेशान करने वाला बताया गया। internet outage के समय phone से diagnosis करने की कोशिश में WiFi पर टिके न रह पाने की दिक्कत साझा की गई। Android की DNS settings को लेकर भी शिकायत की गई कि वे DHCP से नहीं आतीं, आदि कई जटिल समस्याएँ हैं.
  • पश्चिमी Android phone लेकर mainland China में प्रवेश करने का अनुभव और भी असुविधाजनक बताया गया। Android internet connectivity की जाँच Google services से करता है, इसलिए local WiFi पर बार-बार no internet warning आती है। हर बार user को manually तय करना पड़ता है कि connection बनाए रखना है या नहीं.
• सलाह दी गई कि firmware requirements भी ज़रूर जाँचें। कुछ डिवाइस सही तरह पहचान लिए जाने के बावजूद, अगर firmware उपलब्ध न हो तो ifup में fail हो जाते हैं, और Android UI यह स्थिति बिल्कुल नहीं दिखाता; समस्या सिर्फ dmesg logs में नज़र आती है। यह निश्चित नहीं कि CDC devices पर भी ऐसा लागू होता है, लेकिन अनुभव साझा किया गया कि कई USB Ethernet dongles मुख्यतः Realtek और Kawasaki chipsets पर आधारित थे, और कुछ मामलों में firmware की ज़रूरत पड़ती थी। कहा गया कि Android में यह बदलाव शायद हाल का है, लेकिन vanilla AOSP debugging devices पर USB network dongles अच्छी तरह काम करते थे, इसलिए अंदेशा है कि मामला kernel या CDC driver की naming convention का हो सकता है। अंत में फिर सलाह दी गई कि dongle के chipset और firmware आवश्यकता पर ध्यान देना चाहिए.
• कहा गया कि उनके पास 15 से अधिक USB Ethernet adapters हैं, और Realtek, AXIS आदि अलग-अलग chipsets होने के बावजूद सभी बहुत अच्छी तरह काम करते हैं। उनका मानना है कि अगर Linux में driver की ज़रूरत न पड़ने वाले models ले लिए जाएँ, तो वे लगभग सभी OS और BIOS में बिना समस्या चलते हैं.
  • यह जानकारी दी गई कि 2023 में यह issue ठीक कर दिया गया था, और संबंधित Hacker News लिंक साझा किया गया.
  • अतिरिक्त अनुभव साझा किया गया कि Thunderbolt/USB dock से जुड़ा Ethernet adapter pixel 5 और pixel 9 दोनों phones पर अच्छी तरह काम करता था.
• इसे एक परफ़ेक्ट debugging journey बताया गया, और यह दिलचस्प लगा कि सिर्फ एक regex की वजह से पूरे device family ने काम करना बंद कर दिया। हाल में GPT-4 और OpenAI की alignment/escalation system में ऐसी ही संरचनात्मक सीमा से टकराने का अपना अनुभव याद किया गया। बताया गया कि official documentation और logs तक के साथ internal logic को trigger करने की कोशिश की, लेकिन अंततः जो चीज़ इंसान को तर्कसंगत लगती थी, वह internal interface की regex से match न होने के कारण रुक गई। संबंधित रिकॉर्ड अलग लिंक में साझा किया गया, और सिस्टम संरचना या अदृश्य interface boundaries में रुचि रखने वालों से राय माँगी गई.