(Gelöst) broadcom-hybrid-wl auf openSUSE 10.3 (Broadcom "Draft-N" Wireless 14e4:4315)

Status
Für weitere Antworten geschlossen.
O

open susi

New Member
(Gelöst) broadcom-hybrid-wl auf openSUSE 10.3 (Broadcom "Draft-N" Wireless 14e4:4315)

//Edit (RM):

Beitrag abgetrennt von hier:

http://www.pc-forum24.de/suse-treiber/10120-treiber-fuer-broadcom-draft-n-wireless-pci-pcmcia-karten.html

hallo,
nachdem ich nun schon 25 verschiedene versuche unternommen habe mein wlan auf dem hp530 unter linux in gang zu bekommen, bin ich heute wohl am weitesten vorangekommen. ich habe allerdings noch ein problem. das ist die lizens.
ich habe in meinem opensuse 10.3 mit kernel 2.6.22.18-0.2-default das broadcom-hybrid-wl-5.10.27.rm.0.src.rpm mit rpmbuild --rebuild bearbeitet, dann die quelle /usr/src/packages/RPMS/ als installationsquelle hinzugefügt und die pakete:


broadcom-hybrid-wl-5.10.27.6-rm.0.i586.rpm
broadcom-hybrid-wl-kmp-default-5.10.27.6_2.6.22.18_0.2-rm.0.i586.rpm
broadcom-hybrid-wl-kmp-debug-5.10.27.6_2.6.22.18_0.2-rm.0.i586.rpm

installiert. die ausgabe der hartwareinformation sieht eigentlich gut aus:
Code: 
23: PCI 1000.0: 0280 Network controller
  [Created at pci.301]
  UDI: /org/freedesktop/Hal/devices/pci_14e4_4315
  Unique ID: h0vA.Zw5lzS0+r93
  Parent ID: qTvu.4chw4Z9dkyF
  SysFS ID: /devices/pci0000:00/0000:00:1c.1/0000:10:00.0
  SysFS BusID: 0000:10:00.0
  Hardware Class: network
  Model: "Hewlett-Packard Company BCM4310 USB Controller"
  Vendor: pci 0x14e4 "Broadcom"
  Device: pci 0x4315 "BCM4310 USB Controller"
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x137d 
  Revision: 0x01
  Memory Range: 0xf0000000-0xf0003fff (rw,non-prefetchable)
  IRQ: 10 (no events)
  Module Alias: "pci:v000014E4d00004315sv0000103Csd0000137Dbc02sc80i00"
  Driver Info #0:
    Driver Status: wl is not active
    Driver Activation Cmd: "modprobe wl"
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #17 (PCI bridge)
allerdings bringt modprobe wl:
Code: 
FATAL: Error inserting wl (/lib/modules/2.6.22.18-0.2-default/updates/wl.ko): Unknown symbol in module, or unknown parameter (see dmesg)
und dmesg | grep wl:
Code: 
wl: module license 'unspecified' taints kernel.
wl: disagrees about version of symbol ieee80211_get_crypto_ops
wl: Unknown symbol ieee80211_get_crypto_ops
wl: disagrees about version of symbol ieee80211_get_crypto_ops
wl: Unknown symbol ieee80211_get_crypto_ops
wl: disagrees about version of symbol ieee80211_get_crypto_ops
wl: Unknown symbol ieee80211_get_crypto_ops
hmm, scheint irgendwie an der fehlenden lizens zu liegen, aber das package mit der lizens kann ich nicht installieren. hätte das nicht auch im sourcecode sein müssen. die lizens.txt ist jedenfalls da, aber wie bestätige ich die jetzt noch.

ich danke für helfende tips.
 
O

open susi

New Member
AW: Treiber für Broadcom "draft-n" Wireless PCI/PCMCIA(?) Karten

hallo,
sorry für die fehlenden codetags im ersten posting, ich werde das gleich noch ändern.

Code: 
# find /lib/modules/$(uname -r) -iname "*ieee80211*"
/lib/modules/2.6.22.18-0.2-default/kernel/net/ieee80211
/lib/modules/2.6.22.18-0.2-default/kernel/net/ieee80211/ieee80211.ko
/lib/modules/2.6.22.18-0.2-default/kernel/net/ieee80211/ieee80211_crypt_tkip.ko
/lib/modules/2.6.22.18-0.2-default/kernel/net/ieee80211/ieee80211_crypt.ko
/lib/modules/2.6.22.18-0.2-default/kernel/net/ieee80211/ieee80211_crypt_wep.ko
/lib/modules/2.6.22.18-0.2-default/kernel/net/ieee80211/softmac/ieee80211softmac.ko
/lib/modules/2.6.22.18-0.2-default/kernel/net/ieee80211/ieee80211_crypt_ccmp.ko
/lib/modules/2.6.22.18-0.2-default/weak-updates/net/ieee80211
/lib/modules/2.6.22.18-0.2-default/weak-updates/net/ieee80211/ieee80211_crypt.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt_tkip.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt_wep.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt_ccmp.ko
 
Rain_Maker

Rain_Maker

Administrator
Teammitglied
AW: Treiber für Broadcom "draft-n" Wireless PCI/PCMCIA(?) Karten

Mal ein kleiner Hinweis.

Sätze, die ich absichtlich mit dem einem "Wichtig" davor versehe und in roter Fettschrift in ein Posting setze, sind besonders wichtig.

Und jetzt lies Dir das erste Posting dieses Threads und auch den verlinkten Thread in linuxforen.de noch mal durch.

Ach ja, und schmeiss den kernel-debug samt aller "*irgendwas*-kmp-debug"-Pakete raus, diese sind überflüssig, Du verwendest schließlich kernel-default.

Greetz,

RM
 
O

open susi

New Member
AW: Treiber für Broadcom "draft-n" Wireless PCI/PCMCIA(?) Karten

Nun ja, ich habe das zuvor gelesen und auch ernst genommen. Ich habe vorher die Pakete:

compat-wireless-kmp-default und
b43-compat-wireless-firmware sowie
b43legacy-firmware im Yast wieder deinstalliert.

Außerdem habe ich Ndiswrapper gleich mal mit deinstalliert und den entsprechenden Ordner leer gemacht und nochmal im Yast überprüft, daß bcm43xx- Sachen deinstalliert sind und diese extra noch in die Blacklist eingetragen, so, wie es in der http://www.broadcom.com/docs/linux_sta/README.txt beschrieben ist.

Dann habe ich neu gebootet und angefangen das Paket zu bearbeiten.

Wenn da jetzt immernoch etwas davon drin ist, wie bekomme ich das weg?
Was habe ich vergessen, bzw. falsch gemacht?
 
Rain_Maker

Rain_Maker

Administrator
Teammitglied
AW: Treiber für Broadcom "draft-n" Wireless PCI/PCMCIA(?) Karten

open susi schrieb:
Nun ja, ich habe das zuvor gelesen und auch ernst genommen. Ich habe vorher die Pakete:

compat-wireless-kmp-default und
b43-compat-wireless-firmware sowie
b43legacy-firmware im Yast wieder deinstalliert.
Zum Vergrößern anklicken....
Wenn das so wäre, dann dürfte es diese Dateien hier
Code: 
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt_tkip.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt_wep.ko
/lib/modules/2.6.22.18-0.2-default/updates/net/ieee80211/ieee80211_crypt_ccmp.ko
nicht mehr geben.

Oder wurde da auch von Hand mit compat-wireless rumgebastelt?

Irgendwo müssen die Dateien ja her kommen und bevor ich hier sage "lösche dies oder das" will ich das sicher wissen.

//Edit:

Ich trenne das hier mal ab, da es offensichtlich kein Problem der bereitgestellten Pakete ist.
 
O

open susi

New Member
AW: broadcom-hybrid-wl auf openSUSE 10.3 (Broadcom "Draft-N" Wireless 14e4:4315)

Ja, es war so, daß das compat-wireless-Paket die Ordner /updates/drivers/*
und /updates/net/* unter
/lib/modules/2.6.22.15-x.x-default/* angelegt hatte, Weil ich dachte das müsste doch im Pfad meiner Kernelversion stehen, hatte ich diese in /lib/modules/2.6.22.18-0.2-default/* kopiert und beim entfernen des compat-wireless-Paketes nicht mehr daran gedacht. Das war das Problem.
Jetzt habe ich die Ordner */drivers/* und */net/* aus /lib/modules/2.6.22.18-0.2-default/* wieder entfernt, auch wurden dadurch in /lib/modules/2.6.22.18-0.2-default/weak-updates/*
die beiden Ordner angelegt, die Vernüpfungen auf die Inhalte der vorher genannten Order enthielten. Auch diese habe ich entfernt.

Nachdem ich nun die ganze Prozedur rpmbuild --rebuild... noch einmal wiederholt habe, geht alles, als wär es eine Selbstverständlichkeit.

Nochmal Danke für die Hilfe.
Ich werde bestimmt noch oft in diesem Forum herumstöbern.
 
Rain_Maker

Rain_Maker

Administrator
Teammitglied
AW: broadcom-hybrid-wl auf openSUSE 10.3 (Broadcom "Draft-N" Wireless 14e4:4315)

open susi schrieb:
Weil ich dachte das müsste doch im Pfad meiner Kernelversion stehen, hatte ich diese in /lib/modules/2.6.22.18-0.2-default/* kopiert und beim entfernen des compat-wireless-Paketes nicht mehr daran gedacht.
Zum Vergrößern anklicken....
Dazu eine kleine Anmerkung warum dies nicht notwendig ist.

Bei extern gebaute Kernelmodulen "überleben" diese ein Kernelupdate innerhalb einer minor-Version (2.6.X)*, den Rest erledigen dann die "module-init-tools".

Das Prinzip dahinter ist denkbar einfach, wenn man die extern gebauten Kernelmodule nur ins "richtige" Verzeichnis installieren lässt, namentlich in das Verzeichnis "/lib/modules/*Kernelversion*/updates".

(BTW: Für händisch gebaute Module funktioniert das übrigens witzigerweise auch ohne spezielles Kernelmodul-Paket, wenn man das/die fertige(n) Modul(e) nach /lib/modules/*Kernelversion*/updates installiert.)

Der "Update-Mechanismus" ist dabei denkbar einfach, ein "Postinstall"-Script des neuen Kernelpaketes setzt für alle Module in /lib/modules/*alte-Kernelversion*/updates Symlinks nach /lib/modules/*neue-Kernelversion*/weak-updates/ und fertig ist die Laube.

Die module-init-tools sorgend dafür (das gilt im Übrigen distributionsübergreifend!), daß Module aus den beiden "update"-Verzeichnissen bevorzugt geladen werden (bei Modulen selben Namens, falls z.B. das im Kernel befindliche Modul einen Bug hat bzw. das extern gebaute Modul im Update-Verzeichnis eine HW unterstützt, die das interne Modul noch nicht kennt, Stichwort "Backport").

Simpel und zuverlässig, einmal externes Modul installieren und bis zum nächsten Distributionsupdate (Ausnahme, siehe *) hat man keinen Ärger mehr.

Und abschließend dann noch etwas zu der geäußerten Annahme es wäre ein Lizenzproblem:

Code: 
wl: module license 'unspecified' taints kernel.
Da der Treiber nicht einer der freien und "erlaubten" Lizenzen unterliegt (er ist proprietär), ist diese Warnmeldung "normal".

Alle "unfreien" Kernelmodule, welche in den Kernel geladen werden, führen dazu, daß der Kernel als "beschmutzt" (tainted) markiert wird.

Diese Maßnahme ist z.B. dann wichtig, wenn man mit dem Kernel irgendwelche Probleme hat, da dann der erste Schrit sein wird, daß man die "beschmutzenden" Module entladen soll.

Treten danach die Probleme immer noch auf, so können die Kernelentwickler erst jetzt etwas mit den Kernelmeldungen anfangen, da so Wechselwirkungen mit den Modulen, die die Entwickler nicht debuggen können (dies kann eben dann nur der Hersteller) ausgeschlossen sind.

Treten die Probleme nach dem Entladen der "Fremdmodule" nicht mehr auf, so ist es kein Kernelfehler und nur der Hersteller kann in diesem Fall den Fehler beheben.

=> Licht aus.

Greetz,

RM

*Sofern keine ABI-Änderungen innerhalb einer minor-Version vorgenommen wird, was jedoch bei "stable"-Kerneln der absolute Ausnahmefall ist, allerdings ist das z.B. bei 2.6.22 geschehen und betraf natürlich alle Distributionen, die diesen Kernel verwendeten, also z.B. *Buntu 7.10 und openSUSE 10.3, siehe z.B: hier und hier http://www.pc-forum24.de/suse-updates/8285-kernelupdates-fuer-opensuse-10-2-10-3-unbedingt-lesen.html
 
Status
Für weitere Antworten geschlossen.
Oben