Android'de CDC Ethernet neden kullanılamıyor? (2023)

• Android'in EthernetTracker hizmeti yalnızca adı ethX olan ağ arayüzlerini tanır
• Linux'un CDC Ethernet sürücüsü arayüz adını usbX olarak oluşturur
• Bu nedenle standart CDC Ethernet cihazları Android'de otomatik olarak etkinleşmez
• Bunu çözmek için kullanıcının telefonu bizzat root etmesi ve config_ethernet_iface_regex değerini değiştirmesi gerekir
• Gerçekçi yöntem, standart uyumlu bir USB Ethernet adaptörü yerine, satıcıya özgü sürücüsü olan belirli yonga setli ürünleri kullanmaktır

---

Giriş ve sorunun özeti

• Android cihazlarda CDC Ethernet'in çalışmamasının temel nedeni arayüz adlandırma kuralıdır
• Sistem düzeyinde USB Ethernet adaptörünü desteklese de Ethernet menüsünün etkinleşme koşullarında kısıtlar vardır
• Uyumlu yonga seti bilgisine ulaşmak zordur ve pratikte yapı kullanıcılar arasındaki "kulaktan dolma bilgiye" dayanır
• Android de Linux çekirdeği tabanlıdır, ancak her şey yalnızca çekirdek ayarlarıyla belirlenmez

USB hata ayıklama ve ADB ayarı

• Android cihazda USB hata ayıklamayı etkinleştirip ADB kurmak gerekir
• Ağ adaptörünü test etmek için ADB'yi Wi-Fi üzerinden ağ moduna geçirmek gerekir
• Komutlarla mevcut çekirdek sürümü ve mimarisi doğrulanabilir

Çekirdek sürümü ve ayarlarını kontrol etme yöntemi

• Yeni telefonlar (Android 11 ve sonrası) GKI (Generic Kernel Image) çekirdeği yapısını kullanır
  • Google temel çekirdeği derler, üretici ise yalnızca modül ekler
  • Desteklenen özellikler ilgili çekirdek yapılandırma dosyasından (gki_defconfig) görülebilir
• Eski telefonlarda ise üreticinin ayrı sunduğu çekirdek kaynaklarında defconfig dosyasını bulup kontrol etmek gerekir
• Şanslıysanız mevcut çekirdek yapılandırmasını /proc/config.gz yolundan doğrudan da inceleyebilirsiniz

Desteklenen USB Ethernet adaptörleri nasıl kontrol edilir

• İlgili çekirdek ayarlarının çoğu CONFIG_USB_NET_XXX biçimindedir
  • y ise gömülü, m ise modül olarak derlenmiştir (muhtemelen kullanılabilir), is not set ise desteklenmez
• Her ayarın açıklamasına drivers/net/usb/Kconfig dosyasından bakılabilir
• Buna rağmen adaptörün yonga seti bilgisi çoğu zaman hâlâ açık biçimde görünmez

CDC Ethernet (Communications Device Class) ve Android'deki durum

• CDC, USB ağ iletişimi standardıdır ve EEM/ECM/NCM gibi çeşitli protokoller sunar
• Linux, Windows ve macOS'ta standart CDC Ethernet cihazları ek sürücü olmadan otomatik tanınır
• Android'de de çekirdek düzeyinde ilgili sürücüler derlenmiş durumdadır
  • Örnek: CONFIG_USB_NET_CDCETHER, EEM, NCM değerlerinin tümü y olan Samsung cihazlar
• Buna rağmen Ethernet menüsü yine de etkinleşmez

Android'in ağ arayüzü izleme mantığı

• Android, ağ arayüzlerini algılamak için EthernetTracker.java sınıfını kullanır
• EthernetTracker, yeni bir arayüz ortaya çıktığında ad desenine (düzenli ifade) eşleştirme yapar
• Eşleştirme ölçütü kaynaklardan alınan config_ethernet_iface_regex değeridir
  • Varsayılan değer eth\\d'dir (eth ile başlayıp ardından sayı gelen ağ arayüzleri geçerlidir)
• Çekirdeğin oluşturduğu ad (usb0) bu desene uymadığından izleme ve etkinleştirme sırasında yok sayılır

Çözüm kısıtları ve sonuç

• Bu adlandırma düzenli ifadesi kullanıcı tarafından doğrudan değiştirilemez (root olmadan mümkün değildir)
• Sonuç olarak standart CDC Ethernet ürünleri bağlı olsa bile ağ menüsünde kullanılamaz
• Buna karşılık, satıcı veya yonga seti sürücüsüyle doğrudan kaydedilen bazı adaptörler kullanılabilir
• Google, EEM modülü gibi standart destek kodlarını çekirdeğe eklese bile pratikte çalışma mümkün değildir
• Aslında düzenli ifade en azından (eth|usb)\\d olarak değiştirilse sorun çözülecek kadar basittir, ancak şu anda olduğu gibi kalmıştır

Özet

• Temel neden: Android, CDC Ethernet standardını görmezden geldiği için değil, ağ arayüzü adı düzenli ifadeyle (eth\\d) eşleşmediği için bunu etkinleştirmez
• Geçici çözüm: Telefonu root ettikten sonra config_ethernet_iface_regex değerini (eth|usb)\\d gibi bir ifadeyle değiştirmek gerekir
• Pratik seçim: Standart USB CDC destekli adaptörler yerine, yonga setine göre sürücü entegrasyonu net olan ürünleri seçmek daha gerçekçi bir alternatiftir
• Yapısal sorun: Kullanıcı görünürlüğü ve standart uyumluluğu açısından, yazılımın üst katmanındaki adlandırma politikasının yetersizliği sistemsel bir sınırlama olarak ortaya çıkmaktadır

[GN⁺]

Hacker News görüşleri

• Önceki işinde bir Android cihazı CDC Ethernet adaptörüne bağlamaya çalışırken epey uğraştıktan sonra bu yazıyı yazdığını paylaşıyor; sonrasında bazı kişilerden MAC adresindeki belirli bir biti değiştirmenin çekirdeğin ethX adını atamasını sağladığını duyduğunu söylüyor. Bunu kendisinin doğrudan test etmediğini ya da yazıya eklemediğini, bugünlerde de neredeyse hiç Android cihaz kullanmadığını belirtiyor. Ayrıca bu yöntemin yalnızca MAC adresini kontrol edebildiğiniz durumlarda işe yarayacağını ekliyor.
  • Bunun kendisine yardımcı olabileceğini söylüyor; hangi bit olduğunu bulduğunu belirterek ilgili bağlantıyı paylaşıyor.
  • İlgili gönderiye olumlu tepki veriyor.
• Bunun ilginç bir derinlemesine inceleme yazısı olduğunu söylüyor; kaynağa baktığında sorunlu regex'in 2023 Ekim'de eth\\d yerine * olarak değiştiğini ve sorunun bu sayede çözülmüş gibi göründüğünü belirtiyor. İlgili kod değişikliği bağlantısını veriyor ve Android U+ (muhtemelen sürüm 14) ile varsayılan olarak hem usb\\d+ hem de eth%d arayüzlerinin kapsandığını açıklıyor.
  • Bu değişikliğin daha sonra "usbX arayüzü üzerinden tethering yapan cihazlar bulunduğu" için geri alındığını, hemen ardından yalnızca Android V+ sürümlerini destekleyecek şekilde yeniden uygulandığını açıklıyor. Geri alma bağlantısını ve son uygulama bağlantısını da ekliyor.
• Android'in EthernetTracker servisinin yalnızca ethX adı verilen arayüzleri kabul etmesini sert biçimde eleştiriyor; Linux dağıtımlarının bu sorunu zaten 2000'li yıllarda çözdüğünü söylüyor. Eskiden sürücülerin kendi ad öneklerini kullanması nedeniyle tüm sistemi taramak zorunda kalmanın zahmetli olduğunu hatırlatıyor. Günümüzde Linux dağıtımlarının udev gibi araçlarla ağ arayüz adlarını otomatik yeniden adlandırdığını ve bunun çekirdeğin SIOCSIFNAME ioctl çağrısı üzerinden çalıştığını anlatıyor. Modern çekirdeklerin artık wlan* ya da wlan%d gibi adlara otomatik numara ekleme kolaylığı sunduğunu da ekliyor.
• LineageOS commit geçmişine bakıldığında bu sorunun düzeltildiğini, ardından uyumluluk sorunları nedeniyle geri alındığını ve en yeni Android sürümlerinde yeniden uygulandığını analiz ediyor. Commit içeriğine bakılırsa Google çalışanlarının da işin içinde göründüğünü, dolayısıyla resmi Google derlemelerinde de yer almış olabileceğini düşünüyor.
• Yazıdaki "<i>config_ethernet_iface_regex değerini değiştirmek için telefonu root'lamak dışında bir yol yok</i>" cümlesine katılıyor ve bunun, sahip olduğu cihazlarda root yetkisinin önemli olmasının bir başka nedeni olduğunu savunuyor.
  • Ağ trafiğinin keyfi biçimde yönlendirilebilmesi yüzünden kullanıcı alanına superuser yetkisi verilmemesi gerektiğini düşündüğünü söylüyor. OEM'lere bootloader kilidini açmaya izin vermeleri için baskı yapılmasını destekliyor, ancak Android'de root yetkisinin saldırgana sağladığı geniş tehdit alanına kıyasla bunu haklı çıkaracak çok güçlü kullanım örnekleri aklına gelmediğini belirtiyor.
• "Çalışmıyor" denince tam olarak ne kastedildiğini soruyor; MacBook için olan bir USB hub dongle'ı Android telefona taktığında Ethernet portunun sorunsuz çalıştığını, bir hücresel modemin Ethernet cihazı olarak tanınıp Android'de düzgün çalıştığını paylaşıyor.
  • Bu sorunun zaten düzeltildiği, ayrıca asıl makalenin 2 yıl önce yazıldığı bilgisi veriliyor.
• Android'in çok can sıkıcı biçimde birden fazla ağı aynı anda bağlamaya izin vermediğinden şikâyet ediyor. Örneğin interneti olmayan bir WiFi'ye (varsayılan router bile yokken) ve hücresel ağa aynı anda bağlanmak istediğinde bunun mümkün olmadığını söylüyor. Linux ya da Windows'ta bunun gayet doğal olduğunu, Android'in ise bunu zorla engellediğini belirtiyor; hatta birçok varyantta interneti olmayan WiFi'de kalmakta ısrar edilirse kafa karıştırıcı biçimde bağlantının kesildiğini ya da yalnızca uygulama düzeyinde kısmen işe yarayan API'ler sunulduğunu, kullanıcının ise bu denetimlere erişiminin kapatıldığını ifade ediyor.
  • iOS'un da benzer olduğunu; araç kamerasından video almak için WiFi'ye bağlandığında "İnternet yok, hücresel ağa geçilsin mi?" açılır penceresinin çıktığını, WiFi'de kalmayı seçse bile sonunda iOS'un kendi kendine CarPlay ağına zorla geçtiğini anlatıyor. Bunu manuel olarak devre dışı bırakma seçeneğinin bile olmadığını ekliyor.
  • Windows'ta da gerçekte iki kablosuz adaptörle iki ayrı WiFi ağına aynı anda bağlanmanın mümkün olmadığını, en azından GUI üzerinden yapılamadığını, terminalden denemediğini söylüyor.
  • Bu kısıtın gerçekten çok sinir bozucu olduğunu söylüyor; internet kesildiğinde telefonla tanı koymaya çalışırken WiFi'de kalamamanın işleri zorlaştırdığını paylaşıyor. Android'in DNS ayarlarını da örneğin DHCP'den almaması gibi karmaşık sorunlardan şikâyet ediyor.
  • Batı pazarına yönelik bir Android telefonla Çin ana karasına girdiğinde bunun daha da can sıkıcı olduğunu anlatıyor. Android'in internet bağlantısını Google hizmetleri üzerinden doğruladığını, bu yüzden yerel WiFi'de her seferinde internet yok uyarısı verdiğini söylüyor. Kullanıcının her defasında bağlantıyı sürdürmek isteyip istemediğini elle onaylamak zorunda kalmasını da ekliyor.
• Firmware gereksinimlerini de mutlaka kontrol etmek gerektiğini söylüyor. Bazı cihazların düzgün algılansa bile gerekli firmware yoksa ifup aşamasında başarısız olduğunu, Android arayüzünün bunu hiç göstermediğini ve sorunun ancak dmesg günlüklerinde görülebildiğini anlatıyor. Bunun CDC cihazları için de geçerli olup olmadığından emin olmadığını, ancak birçok USB Ethernet dongle'ının Realtek ve Kawasaki yongasetleri kullandığını ve firmware gerektiren örnekler gördüğünü paylaşıyor. Bu Android değişikliğinin yeni sayılabileceğini, ancak saf AOSP hata ayıklama cihazlarında USB ağ dongle'larını sorunsuz kullandığını, dolayısıyla sorunun çekirdek ya da CDC sürücüsü tarafındaki adlandırma geleneğiyle ilgili olabileceğini tahmin ediyor. Sonuç olarak dongle'ın yongasetini ve firmware gerekip gerekmediğini dikkate almak gerektiğini söylüyor.
• 15'ten fazla USB Ethernet adaptörüne sahip olduğunu ve Realtek, AXIS gibi farklı yongasetlerine rağmen hepsinin gayet iyi çalıştığını paylaşıyor. Linux'ta sürücü gerektirmeyen modeller edinildiğinde pratikte tüm işletim sistemleri ve BIOS'larda sorunsuz kullanılabildiklerini düşündüğünü söylüyor.
  • Sorunun 2023'te düzeltildiği bilgisini veriyor ve ilgili Hacker News bağlantısını paylaşıyor.
  • Thunderbolt/USB dock üzerindeki Ethernet adaptörünün hem Pixel 5 hem de Pixel 9 telefonda sorunsuz çalıştığını ekliyor.
• Bunun kusursuz bir debugging yolculuğu olduğunu, tek bir regex yüzünden koca bir cihaz ailesinin çalışamaz hale gelmesinin çok ilginç olduğunu söylüyor. Kısa süre önce GPT-4 ve OpenAI'nin alignment/escalation sistemlerinde benzer yapısal sınırlara çarptığı bir deneyimini anımsatıyor. Resmî belgeler ve log'larla iç mantığı tetiklemeye çalıştığını, ama sonunda insana makul görünen şeyin iç arayüzdeki regex'e uymadığı için engellenmiş gibi göründüğünü anlatıyor. İlgili kaydı ayrı bir bağlantıyla paylaşıyor ve sistem mimarisi ya da görünmeyen arayüz sınırlarıyla ilgilenenlerin görüşlerini duymak istediğini söylüyor.