Results 1 to 9 of 9

Thread: Mal wieder ein Broadcom Thread

  1. #1

    Default Mal wieder ein Broadcom Thread

    Hallo liebe Community,

    mal wieder ein nerviges Broadcom Chipsatz Problem und ein hartnäckiger User, der dieses Problem trotzdem beheben möchte um endlich Wifi auf seinen Laptop nutzen zu können.
    Dann fangen wir mal mit der Beschreibung des Problems an.

    Ich habe mir vor kurzem einen Acer Travelmate P246 Series zugelegt. Bevor ich openSUSE 13.2 installierte, befand sich Windows 7 auf dem Laptop als Hauptbetriebssystem. So blöd es auch von mir war, ich informierte mich vor dem Kauf nicht nach dem Wifi Chipsatz und daher stehe bzw. sitze ich vor dem Problem.
    Verbaut ist ein Broadcom BCM43142 Chipsatz, nach gründlicher Recherche anscheinend der verfluchteste Chipsatz unter den Broadcom's. Ich habe mich viel im WWW über die Treiber Installation informiert, auch bezüglich dieses speziellen Chipsatzes und bin dann auf eine mögliche Problembehebung getroffen, die mir endlich meine Wifi Funktion geben soll.

    Ich ging wie folgt vor:

    uname -a
    Linux linux-p53o.site 3.16.7-24-desktop #1 SMP PREEMPT Mon Aug 3 14:37:06 UTC 2015 (ec183cc) x86_64 x86_64 x86_64 GNU/Linux
    lspci -v
    04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
    Subsystem: Acer Incorporated [ALI] Device 0871
    Flags: bus master, fast devsel, latency 0, IRQ 63
    I/O ports at 3000 [size=256]
    Memory at b0600000 (64-bit, non-prefetchable) [size=4K]
    Memory at b0400000 (64-bit, prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [70] Express Endpoint, MSI 01
    Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
    Capabilities: [d0] Vital Product Data
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Virtual Channel
    Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
    Capabilities: [170] Latency Tolerance Reporting
    Kernel driver in use: r8169
    Kernel modules: r8169

    05:00.0 Network controller: Broadcom Corporation BCM43142 802.11b/g/n (rev 01)
    Subsystem: Lite-On Communications Inc Device 6645
    Flags: bus master, fast devsel, latency 0, IRQ 19
    Memory at b0500000 (64-bit, non-prefetchable) [size=32K]
    Capabilities: [40] Power Management version 3
    Capabilities: [58] Vendor Specific Information: Len=78 <?>
    Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [d0] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [13c] Virtual Channel
    Capabilities: [160] Device Serial Number 00-00-49-ff-ff-19-d0-53
    Capabilities: [16c] Power Budgeting <?>
    Kernel driver in use: wl
    Kernel modules: bcma, wl
    Yast -> Software Repositories -> Add -> Community Repositories -> Packman
    und dies hinzugefügt.

    zypper se broadcom
    Loading repository data...
    Reading installed packages...

    S | Name | Summary | Type
    --+-----------------------------------+-------------------------------------------------------+-----------
    i | broadcom-wl | Wireless driver for Broadcom 43xx series of chips | package
    | broadcom-wl | Wireless driver for Broadcom 43xx series of chips | srcpackage
    | broadcom-wl-debugsource | Debug sources for package broadcom-wl | package
    | broadcom-wl-kmp-default | Wireless driver for Broadcom 43xx series of chips | package
    | broadcom-wl-kmp-default-debuginfo | Debug information for package broadcom-wl-kmp-default | package
    i | broadcom-wl-kmp-desktop | Wireless driver for Broadcom 43xx series of chips | package
    | broadcom-wl-kmp-desktop-debuginfo | Debug information for package broadcom-wl-kmp-desktop | package
    | broadcom-wl-kmp-pae | Wireless driver for Broadcom 43xx series of chips | package
    | broadcom-wl-kmp-pae-debuginfo | Debug information for package broadcom-wl-kmp-pae | package
    | broadcom-wl-kmp-xen | Wireless driver for Broadcom 43xx series of chips | package
    | broadcom-wl-kmp-xen-debuginfo | Debug information for package broadcom-wl-kmp-xen | package
    zypper install broadcom-wl
    zypper install broadcom-wl-kmp-desktop
    reboot
    .... fertig..... und sie da, mein Wifi Chipsatz wurde erkannt und ich konnte Wifi endlich aufmeinem Laptop nutzen.
    Anscheinend habe ich mich in dem moment etwas zu früh gefreut. Nachdem ich mich mit meinem Heimnetz verbinde, bekomme ich kontinuierlich Wifi Drops in absolut unterschiedlichen Zeitspannen. Ich hatte dann folgende Ideen, an welchen Problemen es vllt. liegen könnte:

    1. Vielleicht erkennt mein System nun den Wifi Chipsatz, kann aber jedoch durch eventuell mangelnde Treiber die Verbindung nicht halten?

    dmesg
    [ 229.841919] SFW2-INext-DROP-DEFLT IN=wlp5s0 OUT= MAC= SRC=fe80:0000:0000:0000:d253:49ff:fe19:6de2 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=84 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=44
    [ 353.473594] cfg80211: Calling CRDA to update world regulatory domain
    [ 353.477127] cfg80211: World regulatory domain updated:
    [ 353.477130] cfg80211: DFS Master region: unset
    [ 353.477131] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
    [ 353.477133] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
    [ 353.477135] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
    [ 353.477136] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
    [ 353.477137] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
    [ 353.477138] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
    [ 353.477140] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
    [ 353.477141] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
    [ 353.477142] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
    [ 357.947702] SFW2-INext-DROP-DEFLT IN=wlp5s0 OUT= MAC= SRC=fe80:0000:0000:0000:d253:49ff:fe19:6de2 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=84 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=44
    [ 358.185108] wl0: link up (wlp5s0)
    [ 361.774625] cfg80211: Calling CRDA to update world regulatory domain
    [ 361.776824] cfg80211: World regulatory domain updated:
    [ 361.776828] cfg80211: DFS Master region: unset
    [ 361.776829] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
    [ 361.776831] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
    [ 361.776832] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
    [ 361.776834] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
    [ 361.776835] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
    [ 361.776836] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
    [ 361.776837] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
    [ 361.776838] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
    [ 361.776840] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
    [ 366.430322] wl0: link up (wlp5s0)
    [ 376.440824] wl0: link down (wlp5s0)
    [ 376.440922] cfg80211: Calling CRDA to update world regulatory domain
    [ 376.444806] cfg80211: World regulatory domain updated:
    [ 376.444810] cfg80211: DFS Master region: unset
    [ 376.444812] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
    [ 376.444815] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
    [ 376.444817] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
    [ 376.444819] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
    [ 376.444821] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
    [ 376.444823] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
    [ 376.444824] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
    [ 376.444826] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
    [ 376.444828] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
    2. Kann es sein, dass ich noch etwas vergessen habe zu installieren an treibern, damit der Wifi Chipsatz flüssig laufen kann? z.B. finde ich noch weitere Installationsmöglichkeiten unter der Eingabe von "zypper se b43".
    Oder kann es sein, dass sich die Treiber, mit irgendeiner vorherigen Installation und Versuche meinen Wifi Chipsatz funktionstüchtig zu machen, irgendwie beißen? z.B. "b43-fwcutter"?

    3. Es gibt einfach keine Lösung und ich muss mir eine Alternative überlegen. z.B. ob mein Laptop einen weiteren PCI-Anschluss hat, an dem man eine andere Wifi Karte anschließen kann oder ob die momentane Wifi Karte ausbaubar und ersetzbar ist. Falls das auch nicht hilft, muss wohl ein Wifi to USB Stick her, aber das wäre eine wirklich unschöne Lösung, mit der ich mich auch nicht wirklich zufrieden geben könnte.


    Jetzt seid ihr gefragt, könnt ihr mir helfen?

    Mfg,
    Itchyro

    EDIT:
    Ich habe noch einen Auszug aus den installierten Pakete:

    rpm -qa -last | less
    broadcom-wl-kmp-desktop-6.30.223.248_k3.16.7_24-6.1.x86_64 Wed Sep 23 20:53:32 2015
    broadcom-wl-6.30.223.248-6.1.x86_64 Wed Sep 23 20:52:41 2015
    kernel-default-3.16.7-24.1.x86_64 Wed Sep 23 20:52:17 2015

  2. #2

    Default Re: Mal wieder ein Broadcom Thread

    Quote Originally Posted by itchyro View Post
    So blöd es auch von mir war, ich informierte mich vor dem Kauf nicht nach dem Wifi Chipsatz und daher stehe bzw. sitze ich vor dem Problem.
    Naja, ist auch nicht unbedingt immer so einfach.
    Meine Freundin hat sich neulich einen USB-Adapter gekauft, und trotzdem ich hier am Rechner sitzte und wir telefonisch im Kontakt waren, hab ich ihr blöderweise trotzdem zum Kauf eines nicht unterstützten Sticks geraten (die Auswahl im Geschäft wo sie war war aber auch nicht sonderlich groß, und anhand der Typenbezeichnung des Sticks ists auch nicht immer einfach den tatsächlich verwendeten Chip rauszufinden...).
    Mit ndiswrapper und dem Windows Treiber hab ich den aber auch unter Linux zum Laufen gebracht...

    Verbaut ist ein Broadcom BCM43142 Chipsatz, nach gründlicher Recherche anscheinend der verfluchteste Chipsatz unter den Broadcom's.
    Laut https://wireless.wiki.kernel.org/en/users/drivers/b43 wird der zwar nicht vom Kernel unterstützt, aber der proprietäre broadcom-wl Treiber sollte eigentlich (lt. derselben Seite) funktionieren...

    Die notwendigen Pakete hast du ja schon installiert, also sollte es ja eigentlich klappen.

    Aus deiner Ausgabe sehe ich, dass du (neulich) den kernel-default installiert hast, broadcom-wl-kmp aber nur für kernel-desktop.
    Welchen Kernel verwendest du eigentlich, bzw. welche hast du installiert?
    Code:
    uname -a
    rpm -qa kernel*
    Evtl. würds ja helfen, einfach nur kernel-default wieder zu deinstallieren bzw. im Bootmenü unter "Erweiterte Optionen"/"Advanced Options" den kernel-desktop auszuwählen, der obwohl des Namens der eigentliche Default Kernel ist?

    b43-fwcutter oder b43-firmware wird nichts helfen, da der Chip ja nicht vom Open-Source b43 Treiber unterstützt wird.
    "Beißen" können sich die aber auch nicht, da du ja das Paket "broadcom-wl" installiert hast, was das laden von b43 verhindert.

    Ein anderes Problem das ich mir vorstellen könnte: Evtl. ist ja Wicked aktiv, bzw. laufen beide Netzwerkdienste, Wicked und NetworkManager.
    Starte mal YaST und geh nach Netzwerkgeräte->Netzwerkeinstellungen->Globale Optionen. Schalte dort auf NetworkManager.
    Falls das bereits aktiv ist, probier vielleicht auch mal auf Wicked umzustellen, dann YaST erneut starten und wieder auf NetworkManager schalten.

  3. #3

    Default Re: Mal wieder ein Broadcom Thread

    Hallo wolfi,

    erst ein Mal vielen Dank für die raketenschnelle Antwort. :-)

    Windows Treiber unter Linux um einen Wifi to USB Stick zu nutzen... noch nie davon gehört, interessant *g*

    Ja, auf dieser Wiki-Seite war ich auch schon und habe dort die gleichen Infos entnommen. Jedoch hielt mich dies nicht vom ausprobieren ab. Anscheinend sogar fast erfolgreich gewesen.

    Um ehrlich zu sein, verwundert mich das selbst mit dem kernel-default. Ich hatte kurzzeitig mal den broadcom-wl-kmp-default installiert gehabt, weil ich dachte, dies könnte das Problem der Drops sein, aber da lag ich auch falsch. Warum sich jetzt ein installiertes Paket mit kernel-default ohne broadcom etc davor dort befindet, weiß ich auch nicht. Oder ist dies das selbe und ich bin gerade einfach nur zu blöd?

    uname -a

    rpm -qa kernel*

    uname -a
    Linux linux-p53o.site 3.16.7-24-desktop #1 SMP PREEMPT Mon Aug 3 14:37:06 UTC 2015 (ec183cc) x86_64 x86_64 x86_64 GNU/Linux

    rpm -qa kernel*
    kernel-firmware-20141122git-5.1.noarch
    kernel-desktop-3.16.6-2.1.x86_64
    kernel-default-3.16.7-24.1.x86_64
    kernel-desktop-3.16.7-24.1.x86_64
    Kernel-Desktop ist doppelt installiert bzw vorhanden mit zwei unterschiedlichen Versionen? Warum und woher? Habe ich da gepfuscht? *g*

    Wenn ich in YaST von Network-Manager-Dienst auf Wicked umstelle, kann ich die Wifi Karte bearbeiten. MUSS ich da zwingend etwas konfigurieren oder anpassen? Eigentlich nicht, oder?

    Mfg,
    Itchyro

    EDIT: Hier noch einmal ein Beispiel der Drops:
    ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=764 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=48 time=790 ms
    64 bytes from 8.8.8.8: icmp_seq=7 ttl=48 time=788 ms
    64 bytes from 8.8.8.8: icmp_seq=8 ttl=48 time=13.8 ms
    64 bytes from 8.8.8.8: icmp_seq=11 ttl=48 time=530 ms
    64 bytes from 8.8.8.8: icmp_seq=12 ttl=48 time=22.2 ms
    64 bytes from 8.8.8.8: icmp_seq=14 ttl=48 time=548 ms
    64 bytes from 8.8.8.8: icmp_seq=18 ttl=48 time=456 ms
    64 bytes from 8.8.8.8: icmp_seq=19 ttl=48 time=13.5 ms
    64 bytes from 8.8.8.8: icmp_seq=22 ttl=48 time=542 ms
    64 bytes from 8.8.8.8: icmp_seq=23 ttl=48 time=24.9 ms
    64 bytes from 8.8.8.8: icmp_seq=26 ttl=48 time=540 ms
    64 bytes from 8.8.8.8: icmp_seq=27 ttl=48 time=37.4 ms
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ping: sendmsg: Network is unreachable
    ^C
    --- 8.8.8.8 ping statistics ---
    70 packets transmitted, 13 received, 81% packet loss, time 69003ms
    rtt min/avg/max/mdev = 13.533/390.518/790.055/307.773 ms
    Nach einer gewissen Zeit, werde ich dann aus dem Netz gekickt und werde zu einer neuen Passworteingabe aufgefordert. Danach geht das ganze wieder von vorne los.

  4. #4

    Default Re: Mal wieder ein Broadcom Thread

    Quote Originally Posted by itchyro View Post
    Windows Treiber unter Linux um einen Wifi to USB Stick zu nutzen... noch nie davon gehört, interessant *g*
    Ja, das ist evtl. möglich.
    https://de.opensuse.org/SDB:Wireless-Ndiswrapper

    Ein nativer Treiber ist aber normalerweise zu bevorzugen.

    Um ehrlich zu sein, verwundert mich das selbst mit dem kernel-default. Ich hatte kurzzeitig mal den broadcom-wl-kmp-default installiert gehabt, weil ich dachte, dies könnte das Problem der Drops sein, aber da lag ich auch falsch. Warum sich jetzt ein installiertes Paket mit kernel-default ohne broadcom etc davor dort befindet, weiß ich auch nicht. Oder ist dies das selbe und ich bin gerade einfach nur zu blöd?
    kernel-default (oder kernel-desktop) ist der Linux Kernel, also das eigentliche Betriebssystem.
    broadcom-wl-kmp-xxx ist der Broadcom-Treiber, der zum verwendeten Kernel passen muss.

    Wenn du broadcom-wl-kmp-default isntallierst, zieht das auch automatisch den kernel-default mit.
    Für kernel-desktop benötigst du aber broadcom-wl-kmp-desktop.

    Prinzipiell ists kein Problem, mehrere Kernel installiert zu haben. Du kannst im Bootmenü unter "Erweiterte Optionen"/"Advanced Options" die zusätzlichen auswählen.
    Allerdings musst du eben für jeden installierten Kernel-Typ auch den/die Treiber installieren, sonst sind sie eben nicht vorhanden...
    Außerdem brauchen die unterschiedlichen Kernel natürlich auch Platz auf der Festplatte.

    Wie gesagt, normalerweise wird kernel-desktop verwendet, bei kernel-default sind ein paar Einstellungen anders. Z.B. unterstützt der 32bit kernel-default kein PAE (also mehr als 4GiB RAM), funktioniert dadurch aber auch auf älteren CPUs.
    (bei 64bit ist aber glaub ich eh fast kein Unterschied, deswegen wird grade überlegt, den kernel-desktop rauszuschmeißen und nur mehr einen kernel-default anzubieten...)

    Kernel-Desktop ist doppelt installiert bzw vorhanden mit zwei unterschiedlichen Versionen? Warum und woher? Habe ich da gepfuscht? *g*
    Nein, das ist normal.
    Bei einem Kernel-Update wird immer der ältere Kernel auch behalten. So kannst du immer noch den älteren booten (sh. oben) falls das Update Probleme auf deiner Hardware macht.

    Wenn ich in YaST von Network-Manager-Dienst auf Wicked umstelle, kann ich die Wifi Karte bearbeiten. MUSS ich da zwingend etwas konfigurieren oder anpassen? Eigentlich nicht, oder?
    Wenn du Wicked verwendest, musst du die Verbindung in YaST konfigurieren. Bei NetworkManager ist das irrelevant, da zählt nur die Knfiguration von NetworkManager.

    Allerdings gabs mal das Problem (vor allem bei Upgrades), dass evtl. beide laufen und die selben Netzwerkschnittstellen verwalten, was natürlich keine gute Idee ist.
    Ein Umschalten in YaST sollte das "beheben" und somit als Fehlerursache ausschließen.

    Nach einer gewissen Zeit, werde ich dann aus dem Netz gekickt und werde zu einer neuen Passworteingabe aufgefordert. Danach geht das ganze wieder von vorne los.
    Hm, könnte ein Problem mit der Energieverwaltung sein.
    Allerdings ist mir sowas mit dem proprietären Broadcom Treiber nicht bekannt.

    Momentan bin ich da jetzt allerdings auch etwas ratlos. Werd mal schauen ob ich was dazu finde.
    Du könntest aber mal den kernel-default probieren (dazu musst du aber auch broadcom-wl-kmp-default installieren), also den im Bootmenü auswählen. Wer weiß, vielleicht läufts da ja besser?

    Und Wicked anstelle von NetworkManager wäre evtl. auch einen Versuch wert, sowie Abschalten von IPv6 in YaST->Netzwerkgeräte->Netzwerkeinstellungen->Globale Optionen.
    Last edited by wolfi323; 24-Sep-2015 at 06:15.

  5. #5

    Default Re: Mal wieder ein Broadcom Thread

    Hallo wolfi,

    vielen Dank, dass du dich so intensiv mit meinem Problem auseinander setzt und mir so viele Informationen gibst. Finde ich Klasse, lob an dich! :-)

    ... und tada!

    Problemlösung:
    Quote Originally Posted by wolfi323 View Post

    Und Wicked anstelle von NetworkManager wäre evtl. auch einen Versuch wert, sowie Abschalten von IPv6 in YaST->Netzwerkgeräte->Netzwerkeinstellungen->Globale Optionen.
    Ich muss den Networkmanager deaktivieren und Wicked benutzen, dann funktioniert die Verbindung einwandfrei ohne Probleme.

    ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=24.9 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=15.5 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=48 time=11.4 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=48 time=12.3 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=48 time=14.4 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=48 time=14.1 ms
    64 bytes from 8.8.8.8: icmp_seq=7 ttl=48 time=12.7 ms
    64 bytes from 8.8.8.8: icmp_seq=8 ttl=48 time=13.7 ms
    64 bytes from 8.8.8.8: icmp_seq=9 ttl=48 time=19.8 ms
    64 bytes from 8.8.8.8: icmp_seq=10 ttl=48 time=16.7 ms
    64 bytes from 8.8.8.8: icmp_seq=11 ttl=48 time=14.7 ms
    64 bytes from 8.8.8.8: icmp_seq=12 ttl=48 time=12.7 ms
    64 bytes from 8.8.8.8: icmp_seq=13 ttl=48 time=24.2 ms
    64 bytes from 8.8.8.8: icmp_seq=14 ttl=48 time=17.5 ms
    64 bytes from 8.8.8.8: icmp_seq=15 ttl=48 time=16.7 ms
    64 bytes from 8.8.8.8: icmp_seq=16 ttl=48 time=14.7 ms
    64 bytes from 8.8.8.8: icmp_seq=17 ttl=48 time=15.5 ms
    64 bytes from 8.8.8.8: icmp_seq=18 ttl=48 time=12.0 ms
    64 bytes from 8.8.8.8: icmp_seq=19 ttl=48 time=14.9 ms
    64 bytes from 8.8.8.8: icmp_seq=20 ttl=48 time=24.7 ms
    64 bytes from 8.8.8.8: icmp_seq=21 ttl=48 time=22.8 ms
    64 bytes from 8.8.8.8: icmp_seq=22 ttl=48 time=21.7 ms
    64 bytes from 8.8.8.8: icmp_seq=23 ttl=48 time=12.8 ms
    64 bytes from 8.8.8.8: icmp_seq=24 ttl=48 time=11.7 ms
    64 bytes from 8.8.8.8: icmp_seq=25 ttl=48 time=14.8 ms
    ^C
    --- 8.8.8.8 ping statistics ---
    25 packets transmitted, 25 received, 0% packet loss, time 24042ms
    rtt min/avg/max/mdev = 11.415/16.328/24.976/4.177 ms
    Das heißt jetzt aber auch, dass ich jede neue zukünftige Wlan-Verbindung auf der Wifi-Karte konfigurieren muss. Ich will ja jetzt nicht gleich meckern, nachdem wir endlich eine Problemlösung gefunden haben, aber da wir jetzt den Fehler schon so genau lokalisieren konnten, gibt es dafür auch eine Lösung?

    Auf jeden Fall bin ich schon mal glücklich, dass ich überhaupt die WLAN-Karte benutzen kann und das auch noch ohne Probleme.

    Vielen Dank nochmal. :-)

  6. #6

    Default Re: Mal wieder ein Broadcom Thread

    Quote Originally Posted by itchyro View Post
    Problemlösung:


    Ich muss den Networkmanager deaktivieren und Wicked benutzen, dann funktioniert die Verbindung einwandfrei ohne Probleme.
    "Gut".
    Das zeigt zumindest, dass der Treiber an sich einwandfrei funktioniert.
    Scheinbar hat NetworkManager also ein Problem (oder wpa_supplicant).

    Das heißt jetzt aber auch, dass ich jede neue zukünftige Wlan-Verbindung auf der Wifi-Karte konfigurieren muss. Ich will ja jetzt nicht gleich meckern, nachdem wir endlich eine Problemlösung gefunden haben, aber da wir jetzt den Fehler schon so genau lokalisieren konnten, gibt es dafür auch eine Lösung?
    Tja, keine Ahnung.
    Du solltest vielleicht mal NetworkManager beenden mit "sudo systemctl stop NetworkManager", und dann manuell in einem Terminalfenster starten
    ("sudo NetworkManager -d").
    Die Ausgaben wenn die Verbindung abbricht wären evtl. interessant.

    Hast du die Ethernetverbindung oder evtl. Bluetooth zur gleichen Zeit aktiv?
    Ich kann mich erinnern dass das schon mal bei jemandem Probleme gemacht hat.

    Ansonsten hilft wohl nur ein Bugreport, denke ich.

    Als Alternative könntest du auch wicd ausprobieren, denke ich:
    http://software.opensuse.org/package/wicd
    Allerdings hab ich damit auch keine Erfahrung.
    Last edited by wolfi323; 25-Sep-2015 at 02:54.

  7. #7

    Default Re: Mal wieder ein Broadcom Thread

    Hallo wolfi,

    nun melde ich mich auch mal wieder hier im Thread.
    Als ich den Wicked-Dienst anstatt den Network Manager konfigurierte, sprach ich ja von einem Erfolgserlebnis bezüglich der WLAN-Geschichte. Leider war ich da zu vor eilig, denn nach einem Neustart funktionierte es nicht mehr !? Ich weiß nicht warum, keine Ahnung... Seitdem habe ich einiges in der letzten Zeit an Szenarien durchgeführt:

    1. NetworkManager manuell neugestartet.
    2. NetworkManager gelöscht und nur Wicked ausprobiert.
    3. WICD installiert.
    4. Neu aufgesetzt.
    5. Erneut alles installiert.

    Alles ohne Erfolg... ich weiß so langsam nicht mehr weiter mit diesen Drops. Ich denke, dass ich mich damit abfinden muss ohne die WIFI-Karte zu arbeiten. Mir gehen auch so langsam die Ideen aus und auch die Lust, mich noch weiter mit diesem lästigen Thema auseinander zu setzen, schwindet auch immer mehr. Kannst du dir dazu was denken, warum das jetzt überhaupt nicht mehr funktioniert?

    Grüße,
    Itchyro

  8. #8

    Default Re: Mal wieder ein Broadcom Thread

    Hallo,

    hat keiner mehr eine Idee?

    Grüße,
    Itchyro

  9. #9

    Default AW: Mal wieder ein Broadcom Thread

    Ich habe in einem Forum für eine andere Distribution den Tip gelesen das Powermanagment für die WLAN-Karte abzuschalten, vielleicht bringt es ja was. https://forums.mageia.org/de/viewtop...&t=2626#p28992

    Mein Realtek-Chipsatz läuft mit Wicked, mit dem Networkmanager habe habe ich mein WLAN noch nicht zum laufen gebracht.
    Gruß
    Alf

    openSuse 13.2 KDE

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •