staging.inyokaproject.org

Ich verwende eine C Library, die mittels ethtool Informationen zu dem von mir übergebenen network interface abfragt, genauer gesagt mittels ioctl(socket, SIOCETHTOOL, &ifr). Erst danach stellt sie eine entsprechende Verbindung über das Interface her und erledigt ihre eigentliche Aufgabe. Jetzt muss ich wlan0 als Netzwerkinterface verwenden. Ethtool scheint nur kabelgebundene Interfaces zu unterstützen und liefert entsprechend nichts zurück, woraufhin die Library ihren Dienst verweigert.

Meine Frage: Ist es möglich, ethtool "vorzugaukeln" das wlan0 kabelgebunden ist, so dass ethtool wlan0 findet?

Ich stelle mir vor, dass ich eine Art virtuelles eth1 konfigurieren könnte, dass alle Befehle und Daten irgendwie an wlan0 "bridged" (weiß nicht, ob das Wort passt) und das von ethtool gefunden wird? Abgesehen von dieser "Vorstellung" habe ich jedoch keinen blassen Schimmer, wie das praktisch funktionieren könnte. Ich bin neuer Ubuntu Nutzer (vorher das verpöhnte Windows) und würde mich daher über detailierte Antworten freuen (mit Terminalbefehlen selber rausfinden kämpfe ich noch sehr, da helfen meine Programmierkenntnisse nur wenig...).

Weitere Infos: - Den Source der Library habe ich und wenn ich da die "gewünschte Antwort" hart reincodiere statt ethtool aufzurufen, funktioniert die Library einwandfrei. Ich muss jedoch mit dem offiziellen Release der Library arbeiten und support von wlan-interfaces wird da nicht so bald reinkommen. - Die Library rekonfiguriert auch die IP, die Subnetzmaske und das Gateway mittels "ip address add" usw in einem bash script, das sie (später) aufruft. Es wäre extrem gut, wenn daraufhin die IP usw. von wlan0 und nicht "nur" von einem eventuellen virtuellen eth1 o.Ä. gesetzt wird. Zur Not kann ich jedoch das script editieren.

langmo schrieb:

Ethtool scheint nur kabelgebundene Interfaces zu unterstützen und liefert entsprechend nichts zurück, ...

Das stimmt so nicht. Es heißt:

... particularly for wired Ether‐
       net devices.

Z. B. hier für wlan0:

:~$ ethtool -S wlan0
NIC statistics:
     rx_packets: 42476
     rx_bytes: 9334303
     rx_duplicates: 74
     rx_fragments: 25002
     rx_dropped: 74
     tx_packets: 3781
     tx_bytes: 464110
     tx_filtered: 0
     tx_retry_failed: 0
     tx_retries: 0
     sta_state: 4
     txrate: 1000000
     rxrate: 58500000
     signal: 192
     channel: 0
     noise: 18446744073709551615
     ch_time: 18446744073709551615
     ch_time_busy: 18446744073709551615
     ch_time_ext_busy: 18446744073709551615
     ch_time_rx: 18446744073709551615
     ch_time_tx: 18446744073709551615

Wifi/VWLAN-Hardware ist nun mal kein Ethernet und wenn Du an einer Wifi/WLAN-Schnittstelle etwas einstellen willst, was es dort nicht gibt, wird es per ethtool natürlich nicht funktionieren.

Die richtige Vorgehensweise wäre natürlich, erst abzufragen, ob die Schnittstelle die jeweilige Einstellung überhaupt unterstützt und erst dann die Einstellung vorzunehmen und/oder die Fehlermeldung von ethtool auszuwerten. Da es neben Ethernet und Wifi/WLAN noch etliche weitere Hardware (und auch virtuelle Schnittstellen) gibt, welche IP-Pakete transportieren können, jede mit ihrem spezifischem Übertragungsprotokoll und natürlich spezifischen Einstellungen, wird eine Fallunterscheidung erforderlich sein. Unterschiedliche Hardware gleich machen zu wollen, ist der falsche Ansatz.

@lubux: Interessant. Bei mir passiert folgendes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

:~ $ ip address
...
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e4:5f:01:aa:e7:f1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.108/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 85777sec preferred_lft 74977sec
    inet6 2a02:8388:6182:e600:9ea5:9a98:33ae:7206/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 1018071sec preferred_lft 413271sec
    inet6 fe80::5065:36f8:d806:a5e7/64 scope link
       valid_lft forever preferred_lft forever
...
~ $ sudo ethtool -S wlan0
no stats available

Ähnliche Ergebnisse habe ich auch des öfteren in diversen Foren gefunden, wobei es hier typischerweise damit erklärt wurde, dass ethtool eben nur Kupfer mag. Habe das nicht hinterfragt, weil das mit meinen Ergebnissen übereinstimmte. Ist vielleicht bei mir irgendwas "falsch" konfiguriert, sodass ethtool mein wlan0 nicht mag?

@kB: Mir sind die Unterschiede zwischen WLAN und Kupfer bewusst. Ich will mit ethtool auch nichts an meiner WLAN Schnittstelle verändern. Eigentlich will ich ethtool überhaupt nicht verwenden. Stattdessen will ich eine andere Software verwenden, die wiederum ethtool verwendet. Diese Software könnte problemlos (->ich habe dies verifiziert) über WLAN funktionieren. Da sie aber ethtool verwendet, um die Geschwindigkeit von interfaces zu ermitteln, und mein wlan0 von ethtool nicht gefunden wird, schmeißt sie einen Fehler. Leider kann ich diese Software nicht verändern und damit auch nicht, dass sie ethtool verwendet. Was ich stattdessen suche ist irgendeine Möglichkeit, der Software vorzugaukeln, dass es sich bei wlan0 um eine schnell genuge Kupferleitung handelt, wenn sie mittels ethtool die Eigenschaften von wlan0 abfragt. Meine Idee war es, ein virtuelles eth1 zu erstellen, das einfach alles von und zu wlan0 weiterleitet. Prinzipiell gibt es hardwarebasierte WLAN Adapter, die ich in den Anschluss von eth0 stecken könnte und das würde das ganze lösen. In dem Fall würde das interface problemlos von ethtool gefunden und als Kupfer identifiziert. Aus Platz, Kosten und Stromverbrauchsgründen (das ganze läuft über Batterie) wäre aber eine softwarebasierte Lösung besser.

Leider ist es nicht möglich, „vorzutäuschen“, dass eine drahtlose Schnittstelle eine kabelgebundene Schnittstelle zu ethtool oder einem anderen Tool ist, das für den Betrieb mit kabelgebundenen Schnittstellen entwickelt wurde. Da die beiden Arten von Schnittstellen unterschiedliche zugrunde liegende Technologien verwenden und unterschiedliche Fähigkeiten haben, ist dies der Fall.

Du kannst das WLAN Interface, z.B. per udev Regel, in eth1 oder irgendwas umbennen. Linux und allen anderen Tools ist der Name vom Interface egal. Dennoch solltest du erkläre was du eigentlich willst, und nicht was dein Weg zum Ziel ist welches wir nicht kennen.