Hallo,

also darum geht es:

Ich habe einen Wlan Micro USB Adapter der Fa Belkin. Welcher mit einem RTL8188CUS Chip bestückt ist.
Leider habe ich das Problem das dieser dauernd Verbindungsabrüche mit dem Kernel eigenen Modul "rtl8192cu" fabriziert.
Nach etlichem googlen habe ich auch einen Treiber gefunden allerding war der nur bis Kernelversion 3.0.8.
Egal klassisch make clean, make , make install....
Alles wunderbar rannte wie der Teufel der kleine 🙂

Jetzt nach Update auf Kernelversion 3.7* lässt sich das Modul bauen, aber es funktioniert leider nicht.
% dmesg |tail

 ....

8192cu: Unknown symbol kernel_thread ( err 0 )
Was hat das zu bedeuten und wo könnte ( wenn ich in Stande bin das selbst zu fixen) suchen um den "Schaden" zu beheben ?

Bis zu dieser Lösung wollte ich auf ndiswrapper zurückgreifen, doch das schlägt leider auch fehl.
% pacman -S ndiswrapper

....
Fehler: ndiswrapper: signature from "Thorsten Töppper ............" is unknown trust
Ich dachte mir ein 
 pacman-key --init
Könnte das Problem lösen, tut es aber leider nicht.
Wie kann ich die gefräßige gelbe Kugel dazu überreden das Paketchen doch zu fressen ?


MfG
Hoi,

Kleines Update & push 😉

Was die "kernel_thread" Problematik angeht bin ich zu der Lösung vorgedrungen, das ich es nicht Lösen kann.
Denn dazu wäre Erfahrung im Umbau von *.c Dateien ( Ich nehme mal an die "Hauptprogramm" Dateien von C/C++ ) notwendig.
kernel_thread ist wohl die Process Verwaltung des Kernels, welche als depricated geflagt ist und von kthread_run (kthread.h) abglöst wurde.
Da mir nötige Programmierkenntnisse fehlen werde ich wohl drauf warten müssen dass Realtek nachbessert.
Oder eben das rtl8192cu verbessert wird.


Leider ist das Signaturproblem von ndiswrapper noch nicht gelöst. Hat wirklich niemand nen Tip ?

MfG Macron
21 Tage später

  • [gelöscht]

  • Beitrag Nr. 3
Hi,
ich habe die folgende Version bzgl. des kernel_thread-Problems gepatcht und auch das Belkin Surf N300 hinzugefügt.

Basisversion: RTL8188C_8192C_USB_linux_v3.4.4_4749.20121105
Patch: http://download.devbase.at/rtl8192-kthread.patch

Bei mir scheint der Treiber nun zu funktionieren, habe ihn aber zum ersten Mal installiert und noch nicht viel getestet...
Vielleicht ist der Patch für dich brauchbar!
Grüße,
-Thomas
Hallo Thomas,

Danke für deine Mühe! Werde ich auch bstimmt am WE mal testen.
Allerdings, bitte nimm das nicht persönlich ich kann mir denken das dass doch ein paar Stunden arbeit waren, streuben sich mir etwas die Nackenhaare wenn ich als "Leihe" so Sachen wie:

if(iph->protocol == IPPROTO_UDP) // UDP
 			{
-				struct udphdr *udph = (struct udphdr *)((unsigned int)iph + (iph->ihl << 2));
+				struct udphdr *udph = (struct udphdr *)((unsigned long)iph + (iph->ihl << 2));
 
 				if((udph->source == __constant_htons(CLIENT_PORT))
 					&& (udph->dest == __constant_htons(SERVER_PORT))) // DHCP request
 				{
 					struct dhcpMessage *dhcph =
-						(struct dhcpMessage *)((unsigned int)udph + sizeof(struct udphdr));
+						(struct dhcpMessage *)((unsigned long)udph + sizeof(struct udphdr));
 
 					if(dhcph->cookie == __constant_htonl(DHCP_MAGIC)) // match magic word
 					{
lese. Wie bereits gesagt es ist nichts gegen Dich wirklich, aber könntest Du das für nicht Programmierer wie mich mal erläutern warum das darein muss ?
Anhand des Namens "rtw_br_ext.c" gehe ich mal davon aus das es für den Bridging Modus gedacht ist, richtig ?

Halte mich für Paranoid aber wenn ich schon den Quelltext anschauen darf, dann darf ich auch Zweifel an nem Codeschnipsel hinterfragen 😉

MfG Stephan

  • [gelöscht]

  • Beitrag Nr. 5
Ich habe ein 64-bit-System laufen, daher sind auch alle Zeiger 64 Bit breit. Der Datentyp "unsigned int" ist aber nur 32 Bit breit. Da im betroffenen Code mathematische Operationen auf Zeiger durchgeführt werden und sie daher zwischenzeitlich als Zahlentyp angesprochen werden, sollte dieser Zahlentyp eben auch 64 Bit fassen (eben als "unsigned long"-Typ).
Vielleicht bügelt das der Compiler aus, aber ich würde nicht drauf wetten - Warnings wegen ungenügender Zahlenbreite spuckt er jedenfalls genug aus! Mit meiner Änderung sollten sowohl 32- als auch 64-bit-Systeme laufen.
Grüße,
-Thomas

PS: Habe den Patch nochmal hochgeladen, da programmiertechnisch verschönert. Der generierte Code sollte identisch zu vorher sein.
9 Tage später
Hallo Thomas,

Vielen Dank für Deine Arbeit! Habe heute das Modul mit dem Aktuellen Kernel (3.7.9-2-686) bauen können.
Jetzt läuft der kleine Stick wieder wie der Teufel!

Was ndiswrapper anbelangt muss ich leider sagen das sich keiner ( der baugleichen Stick - Treiber ) zu einem zufriedenstellenden Ergebnis zum laufen bringen lies.
Ich denke aber das dies nicht die Schuld von ndiswrapper ist sondern am "Allerwelts Realtek-Treiber" liegt.

Dein patch funktioniert also prima. Solltest Du an Realtek mailen und gleich mal ne grosse Spende für devbase.at einfordern 😉 Damit würdest bestimmt viele Arch + *buntu User glücklich machen 😃

Deshalb werde ich ( hoffentlich mit deinem Einverständnis ) den Thread umbenennen.


MfG und Lieben Dank Macron
ein Monat später
Hallo,
ich habe mit Freuden dein Skript entdeckt.

Allerdings verstehe ich nicht, warum es funktioniert, da bei mir zum Beispiel der Unterordner "core" fehlt, obwohl ich den identischen Treiber von der Realtek Homepage geladen habe ?
Ich arbeite mit so einem Ministick mit "8192cu" auf einem ARM System (Raspberry) mit archlinux (Kernel 3.6.11). Gepatcht ist meines Wissens da nichts.
Hersteller des Sticks ist in meinem Fall zwar "edimax", das sollte aber eigentlich keine Rolle spielen. Läuft mit "netcfg" problemlos.

Was ich damit sagen will:
Das Zusammenspiel zwischen WLAN-Chips verschiedener Hersteller zwischen router und clients ist nicht immer passend und somit nicht grundsätzlich optimal. Fehler müssen also nicht unbedingt an Treibern liegen.