Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 248450 - New ebuild: net-wireless/broadcom-sta
Summary: New ebuild: net-wireless/broadcom-sta
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: MATSUU Takuto (RETIRED)
URL: http://www.broadcom.com/support/802.1...
Whiteboard: sunrise suggested
Keywords: EBUILD
: 306989 320483 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-23 18:25 UTC by Nico Schlömer
Modified: 2011-08-08 03:57 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
initial broadcom sta linux driver ebuild (broadcom-sta-5.10.27.6.ebuild,773 bytes, text/plain)
2008-11-23 18:26 UTC, Nico Schlömer
Details
patch to build on newer (>=2.6.26) kernels (broadcom-build-fix.patch,3.29 KB, patch)
2008-11-23 18:26 UTC, Nico Schlömer
Details | Diff
patch to fix the vlanmode problem (broadcom-vlanmode-fix.patch,1.15 KB, patch)
2008-11-23 18:27 UTC, Nico Schlömer
Details | Diff
updated ebuild (broadcom-sta-5.10.27.6.ebuild,773 bytes, text/plain)
2008-12-06 12:25 UTC, Nico Schlömer
Details
Patch for kernel 2.6.27 (broadcom-2.6.27.patch,3.36 KB, patch)
2008-12-21 03:43 UTC, Vito Louis Sansevero
Details | Diff
Ebuild for Broadcom-sta version 5.10.27.11 (broadcom-sta-5.10.27.11.ebuild,743 bytes, text/plain)
2008-12-21 03:46 UTC, Vito Louis Sansevero
Details
ebuild with proper version string (broadcom-sta-5.10.27.11.ebuild,836 bytes, text/plain)
2008-12-21 20:29 UTC, Nico Schlömer
Details
added the driver version to patch file name (broadcom-build-fix-5_10_27_11.patch,3.36 KB, patch)
2008-12-21 22:56 UTC, Vito Louis Sansevero
Details | Diff
vlan mode patch for 5.10.27.11 release (broadcom-vlanmode-fix-5_10_27_11.patch,1.14 KB, patch)
2008-12-21 22:59 UTC, Vito Louis Sansevero
Details | Diff
Updated ebuild for x86/amd64 (broadcom-sta-5.10.27.11.ebuild,939 bytes, text/plain)
2008-12-22 01:27 UTC, William Johansson
Details
.12 ebuild (broadcom-sta-5.10.27.12.ebuild,847 bytes, text/plain)
2009-01-02 17:56 UTC, Nico Schlömer
Details
.12 vlanmode-fix patch (broadcom-vlanmode-fix-5_10_27_12.patch,1.11 KB, patch)
2009-01-02 17:57 UTC, Nico Schlömer
Details | Diff
patch for linux-2.6.29 (broadcom-sta-5.10.27.12-linux-2.6.29.patch,4.63 KB, patch)
2009-01-16 16:42 UTC, Christoph Mende (RETIRED)
Details | Diff
new patch for compilation against 2.6.29 (broadcom-sta-5.10.27.14-linux-2.6.29.patch,4.25 KB, patch)
2009-01-24 16:10 UTC, Christoph Mende (RETIRED)
Details | Diff
ebuild for 5.10.27.14 (broadcom-sta-5.10.27.14.ebuild,855 bytes, text/plain)
2009-01-24 20:57 UTC, chris salch
Details
Update 5.10.27.14 ebuild (broadcom-sta-5.10.27.14.ebuild,940 bytes, patch)
2009-01-25 02:47 UTC, chris salch
Details | Diff
Update 5.10.27.14 ebuild (broadcom-sta-5.10.27.14.ebuild,854 bytes, text/plain)
2009-01-26 03:18 UTC, chris salch
Details
hidden SSID fix (broadcom-wl-5.10.27.6-hidden-essid.patch,358 bytes, patch)
2009-02-01 18:07 UTC, Chris Nolan
Details | Diff
broadcom-wl-5.10.27.14-hidden-essid.patch (broadcom-wl-5.10.27.14-hidden-essid.patch,404 bytes, patch)
2009-02-02 10:45 UTC, Balazs Nemeth
Details | Diff
broadcom-sta-5.10.79.10.ebuild (broadcom-sta-5.10.79.10.ebuild,914 bytes, text/plain)
2009-03-06 18:09 UTC, Balazs Nemeth
Details
broadcom-sta-5.10.79.10-hidden-essid.patch (broadcom-sta-5.10.79.10-hidden-essid.patch,400 bytes, patch)
2009-03-06 18:10 UTC, Balazs Nemeth
Details | Diff
broadcom-sta-5.10.79.10-linux-2.6.29.patch (broadcom-sta-5.10.79.10-linux-2.6.29.patch,4.25 KB, patch)
2009-03-06 18:11 UTC, Balazs Nemeth
Details | Diff
modified ebuild (broadcom-sta-5.10.79.10.ebuild,949 bytes, text/plain)
2009-03-07 08:04 UTC, DaggyStyle
Details
net-wireless/broadcom-sta-5.10.79.10.ebuild (broadcom-sta-5.10.79.10.ebuild,1.00 KB, text/plain)
2009-03-08 02:55 UTC, MATSUU Takuto (RETIRED)
Details
updated patch (broadcom-sta-5.10.79.10-wl_iw_v2.patch,719 bytes, patch)
2009-04-06 13:27 UTC, Nico Schlömer
Details | Diff
broadcom-sta-5.10.79.10-r1 build log on 2.6.30-rc3 (net-wireless:broadcom-sta-5.10.79.10-r1:20090423-123101.log,3.49 KB, text/plain)
2009-04-23 13:38 UTC, Balazs Nemeth
Details
patch for linux-2.6.30 (broadcom-sta-5.10.79.10-linux-2.6.30.patch,468 bytes, patch)
2009-04-23 17:24 UTC, Viktor Ashirov
Details | Diff
a patch to convert the wl driver to net_device_ops (required to build on 2.6.31+) (hybrid-portsrc-x86_32-v5_10_91_9-convert_to_net_device_ops.diff,1.26 KB, patch)
2009-06-19 16:21 UTC, Tomáš Szépe
Details | Diff
replace mc_list handling with netdev_for_each_mc_addr (wl_linux.c.diff,1.05 KB, patch)
2010-05-23 11:00 UTC, Alessandro Suardi
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Schlömer 2008-11-23 18:25:28 UTC
hi,

sometime in summer this year, broadcom has issued its first real linux driver for BCM4311-, BCM4312-, BCM4321-, and BCM4322-based hardware. i tried it to get rid of ndiswrapper on my bcm4328, and things worked out pretty well, so i thought i write the stub of an ebuild.

so far it's 'works for me'-proof, and i'm also sure a couple of things are not done appropriately. so, please comments!

points that certainly require more input:
1.) how to deliver (and flag) broadcom's very own licence? (comes with the tarball).
2.) there are 32-bit and 64-bit versions. how to deal with it? are *two* separate ebuild necessary?
3.) build_params is somewhat unclean now, at least i haven't seen '-C' anywhere else. how to use it properly?

cheers,
nico

Reproducible: Always
Comment 1 Nico Schlömer 2008-11-23 18:26:15 UTC
Created attachment 173053 [details]
initial broadcom sta linux driver ebuild
Comment 2 Nico Schlömer 2008-11-23 18:26:40 UTC
Created attachment 173054 [details, diff]
patch to build on newer (>=2.6.26) kernels
Comment 3 Nico Schlömer 2008-11-23 18:27:19 UTC
Created attachment 173055 [details, diff]
patch to fix the vlanmode problem

taken from http://www.cenolan.com/fedora9/
Comment 4 Nico Schlömer 2008-11-23 18:27:37 UTC
Comment on attachment 173054 [details, diff]
patch to build on newer (>=2.6.26) kernels

taken from http://www.cenolan.com/fedora9/
Comment 5 Nico Schlömer 2008-11-23 18:27:59 UTC
Comment on attachment 173055 [details, diff]
patch to fix the vlanmode problem

taken from http://www.cenolan.com/fedora9/
Comment 6 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-11-24 22:45:24 UTC
@mobile: any interest?
Comment 7 Nico Schlömer 2008-12-06 12:25:11 UTC
Created attachment 174402 [details]
updated ebuild

patch needs to be applied only for kernels >= 2.6.27
Comment 8 Vito Louis Sansevero 2008-12-21 03:43:20 UTC
Created attachment 176017 [details, diff]
Patch for kernel 2.6.27

Bump in version from previous patch.
Comment 9 Vito Louis Sansevero 2008-12-21 03:46:21 UTC
Created attachment 176018 [details]
Ebuild for Broadcom-sta version 5.10.27.11

Ebuild to go with the above patch, my fist contribution.
Comment 10 Vito Louis Sansevero 2008-12-21 03:54:08 UTC
Comment on attachment 176018 [details]
Ebuild for Broadcom-sta version 5.10.27.11

Forgot to mention this also fixes the VLAN bug, you can use SSH and TELNET. 
Cheers
Comment 11 Nico Schlömer 2008-12-21 15:28:26 UTC
hi vito,
is it possible that the latest patch is actually the same as the one that was submitted before?
cheers,
nico
Comment 12 Vito Louis Sansevero 2008-12-21 19:26:41 UTC
(In reply to comment #11)
> hi vito,
> is it possible that the latest patch is actually the same as the one that was
> submitted before?
> cheers,
> nico
> 

(In reply to comment #11)
> hi vito,
> is it possible that the latest patch is actually the same as the one that was
> submitted before?
> cheers,
> nico
> 
Hi Nico, 

The previous patch would not apply for me. The only thing that changed was line numbers and I could not get patch to apply. Is there something I missed?

vito

***** broadcom-build-fix.patch *****

====================================

PATCH COMMAND:	 patch -p0 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch

====================================
patching file src/wl/sys/wl_iw.c
Hunk #1 FAILED at 931.
Hunk #2 FAILED at 944.
Hunk #3 FAILED at 952.
Hunk #4 FAILED at 970.
Hunk #5 FAILED at 978.
Hunk #6 FAILED at 989.
Hunk #7 FAILED at 1003.
Hunk #8 FAILED at 1012.
8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej
====================================

PATCH COMMAND:	 patch -p1 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch

====================================
patching file src/wl/sys/wl_iw.c
Hunk #1 FAILED at 931.
Hunk #2 FAILED at 944.
Hunk #3 FAILED at 952.
Hunk #4 FAILED at 970.
Hunk #5 FAILED at 978.
Hunk #6 FAILED at 989.
Hunk #7 FAILED at 1003.
Hunk #8 FAILED at 1012.
8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej
====================================

PATCH COMMAND:	 patch -p2 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch

====================================
patching file src/wl/sys/wl_iw.c
Hunk #1 FAILED at 931.
Hunk #2 FAILED at 944.
Hunk #3 FAILED at 952.
Hunk #4 FAILED at 970.
Hunk #5 FAILED at 978.
Hunk #6 FAILED at 989.
Hunk #7 FAILED at 1003.
Hunk #8 FAILED at 1012.
8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej
====================================

PATCH COMMAND:	 patch -p3 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch

====================================
patching file src/wl/sys/wl_iw.c
Hunk #1 FAILED at 931.
Hunk #2 FAILED at 944.
Hunk #3 FAILED at 952.
Hunk #4 FAILED at 970.
Hunk #5 FAILED at 978.
Hunk #6 FAILED at 989.
Hunk #7 FAILED at 1003.
Hunk #8 FAILED at 1012.
8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej
====================================

PATCH COMMAND:	 patch -p4 -p1 -E < /home/vito/src/overlays/macbook-pro/net-wireless/broadcom-sta/files/broadcom-build-fix.patch

====================================
patching file src/wl/sys/wl_iw.c
Hunk #1 FAILED at 931.
Hunk #2 FAILED at 944.
Hunk #3 FAILED at 952.
Hunk #4 FAILED at 970.
Hunk #5 FAILED at 978.
Hunk #6 FAILED at 989.
Hunk #7 FAILED at 1003.
Hunk #8 FAILED at 1012.
8 out of 8 hunks FAILED -- saving rejects to file src/wl/sys/wl_iw.c.rej
Comment 13 Nico Schlömer 2008-12-21 19:32:38 UTC
hi vito,

oh no, i'm sorry, *i* missed something, and that is broadcom's actually having updated the driver. the two patches change in fact the same things, just for the different driver versions.

-- thanks for updating anyway!

cheers,
nico
Comment 14 Nico Schlömer 2008-12-21 20:27:48 UTC
hi,

uhm, i had another look at the ebuild and modified it a bit such that the version number gets properly reflected everywhere and the ebuild can potentially just be copies from version to version.

the patches would need a naming scheme there, too; it's now <name-of-the-patch>-<version-number-with-underscores>.patch.

oh, and i believe the vlan-patch needs updating as well! i'm having issues with that right now, so i'd be cool if you could just quickly do that, vito!

cheers,
nico
Comment 15 Nico Schlömer 2008-12-21 20:29:03 UTC
Created attachment 176084 [details]
ebuild with proper version string
Comment 16 Vito Louis Sansevero 2008-12-21 22:55:11 UTC
Comment on attachment 176017 [details, diff]
Patch for kernel 2.6.27

Posting the same patch with the correct version information
Comment 17 Vito Louis Sansevero 2008-12-21 22:56:59 UTC
Created attachment 176108 [details, diff]
added the driver version to patch file name
Comment 18 Vito Louis Sansevero 2008-12-21 22:59:00 UTC
Created attachment 176112 [details, diff]
vlan mode patch for 5.10.27.11 release

Please test this patch out.
Comment 19 Vito Louis Sansevero 2008-12-21 23:01:03 UTC
(In reply to comment #14)
> hi,
> 
> uhm, i had another look at the ebuild and modified it a bit such that the
> version number gets properly reflected everywhere and the ebuild can
> potentially just be copies from version to version.
> 
> the patches would need a naming scheme there, too; it's now
> <name-of-the-patch>-<version-number-with-underscores>.patch.
> 
> oh, and i believe the vlan-patch needs updating as well! i'm having issues with
> that right now, so i'd be cool if you could just quickly do that, vito!
> 
> cheers,
> nico
> 

New patches posted, I suppose if this works good we should consolidate both patches in to one patch. Let me know how the vlan patch works for you.
Comment 20 Nico Schlömer 2008-12-21 23:12:30 UTC
hmm, i got some issues here with my patch/diff configuration (they always pull in ^M at the end of the line), so the patches don't apply properly for me -- however, by looking at it, i'm sure everything you submitted is correct. *thanks* vito!

merry christmas and happy holidays, too; see you next year on bugs.gentoo.org!
cheers,
nico
Comment 21 William Johansson 2008-12-22 01:27:01 UTC
Created attachment 176117 [details]
Updated ebuild for x86/amd64

Haha, I just wrote an ebuild tonight without searching bugzilla. I don't think I'll do that again...

This should make it compile on x86 (afaik), there is only a little change in the SRC_URI.
Comment 22 Vito Louis Sansevero 2008-12-22 16:08:56 UTC
(In reply to comment #21)
> Created an attachment (id=176117) [edit]
> Updated ebuild for x86/amd64
> 
> Haha, I just wrote an ebuild tonight without searching bugzilla. I don't think
> I'll do that again...
> 
> This should make it compile on x86 (afaik), there is only a little change in
> the SRC_URI.
> 
Thanks for the updated ebuild! Glad we can now support x86 and x86_64.
Comment 23 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-12-30 17:05:11 UTC
(this is an automated message based on filtering criteria that matched this bug)

Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manor. There are simply too many new packages.

Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. 
So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =)

Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. 

Thanks,
On behalf of the Gentoo Sunrise Team,
Jeremy.

[1]: http://www.gentoo.org/proj/en/sunrise/
[2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Comment 24 Nico Schlömer 2009-01-02 16:46:32 UTC
hi everyone and happy 2009!

i just figured out why the patches refused to build for me, reason is: from the .11 version of their driver, broadcom source files ship with DOS end-of-line characters instead of unix ones. geeeez...

i'll poke them right away about it.

the good thing is that they issued an update to .12 on new year's eve *including* the build patch, so we don't need to bother about that one anymore.

i'll try to fix up a dos-end-of-line patch for the vlanmode and submit as soon as possible.

cheers,
nico
Comment 25 Nico Schlömer 2009-01-02 17:56:07 UTC
Created attachment 177128 [details]
.12 ebuild

and here's the new ebuild...
Comment 26 Nico Schlömer 2009-01-02 17:57:03 UTC
Created attachment 177129 [details, diff]
.12 vlanmode-fix patch

watch out for those DOS end-of-line characters!
Comment 27 Andrey Vihrov 2009-01-06 09:19:58 UTC
By the way, 5.10.27.12 seems to work fine without any patch here.
Comment 28 Nico Schlömer 2009-01-06 09:47:02 UTC
ah, okay.
well, the only patch the applies in the latest ebuild is the vlanmode patch anyway, as taken from

http://www.cenolan.com/broadcom-wl/

-- quite honestly, i don't even know what this thing improves. anyone got experience with that?

cheers,
nico
Comment 29 Andrey Vihrov 2009-01-06 11:31:55 UTC
Like #10 says, it (at least) used to workaround problems with SSH and telnet behind a NAT. With the december version, I no longer need that, as things work out of box.
Comment 30 chris salch 2009-01-08 04:28:07 UTC
(In reply to comment #26)
(In reply to comment #25)

This ebuild and patch appears to be working very nicely for me on amd64.

Thanks,
chris
Comment 31 Christoph Mende (RETIRED) gentoo-dev 2009-01-16 16:42:48 UTC
Created attachment 178706 [details, diff]
patch for linux-2.6.29

this patch fixes compilation on linux-2.6.29 and works fine for me atm
Comment 32 Christoph Mende (RETIRED) gentoo-dev 2009-01-16 16:43:16 UTC
oh, forgot to mention, lib80211 is required now
Comment 33 DaggyStyle 2009-01-17 13:44:36 UTC
do one needs to apply the patch to the kernel? is there a chance it is part of a kernel sources that is in the tree or even in an overlay that has tuxonice
Comment 34 Andrey Vihrov 2009-01-17 13:52:23 UTC
DaggyStyle,

the patch is to be applied to the driver source itself. Moreover, users of kernels < 2.6.29 don't need it.
Comment 35 Bob Raitz 2009-01-20 09:33:11 UTC
When trying broadcom-sta-5.10.27.12.ebuild, I came up with the following error:


***** broadcom-vlanmode-fix-5_10_27_12.patch *****

==================================================

PATCH COMMAND:	 patch -p0 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch

==================================================
patching file src/wl/sys/wl_iw.c
patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig	2009-01-02 17:54:21.000000000 +0100

==================================================

PATCH COMMAND:	 patch -p1 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch

==================================================
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- src/wl/sys/wl_iw.c.orig	2009-01-02 17:53:01.000000000 +0100
|+++ src/wl/sys/wl_iw.c	2009-01-02 17:53:20.000000000 +0100
--------------------------
No file to patch.  Skipping patch.
patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig	2009-01-02 17:54:21.000000000 +0100

==================================================

PATCH COMMAND:	 patch -p2 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch

==================================================
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- src/wl/sys/wl_iw.c.orig	2009-01-02 17:53:01.000000000 +0100
|+++ src/wl/sys/wl_iw.c	2009-01-02 17:53:20.000000000 +0100
--------------------------
No file to patch.  Skipping patch.
patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig	2009-01-02 17:54:21.000000000 +0100

==================================================

PATCH COMMAND:	 patch -p3 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch

==================================================
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- src/wl/sys/wl_iw.c.orig	2009-01-02 17:53:01.000000000 +0100
|+++ src/wl/sys/wl_iw.c	2009-01-02 17:53:20.000000000 +0100
--------------------------
No file to patch.  Skipping patch.
patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig	2009-01-02 17:54:21.000000000 +0100

==================================================

PATCH COMMAND:	 patch -p4 -g0 -E --no-backup-if-mismatch < /usr/local/portage/net-wireless/broadcom-sta/files/broadcom-vlanmode-fix-5_10_27_12.patch

==================================================
missing header for unified diff at line 3 of patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- src/wl/sys/wl_iw.c.orig	2009-01-02 17:53:01.000000000 +0100
|+++ src/wl/sys/wl_iw.c	2009-01-02 17:53:20.000000000 +0100
--------------------------
No file to patch.  Skipping patch.
patch: **** malformed patch at line 11: --- src/wl/sys/wl_linux.c.orig	2009-01-02 17:54:21.000000000 +0100

Comment 36 Bob Raitz 2009-01-20 09:53:34 UTC
I tried the ebuild without the patch, and it worked. Nice! 

It's not the fastest driver, but it sure does connect solidly. It's also not the b43. Yay.
Comment 37 DaggyStyle 2009-01-20 10:09:42 UTC
ok, let me see if I go it right, I use kernel 2.6.28, all I need to do it download the 5.10.27.12 ebuild and that's it?
Comment 38 Nico Schlömer 2009-01-20 10:48:22 UTC
that's right, plus right now the ebuild requires the vlanmode-fix patch. it's not quite clear to me, however, if this is actually of any use (see comment #29).

cheers,
nico
Comment 39 Christoph Mende (RETIRED) gentoo-dev 2009-01-20 11:13:15 UTC
the vlan mode patch isn't requried anymore on latest drivers
Comment 40 DaggyStyle 2009-01-20 16:17:39 UTC
card is identified :) thanks, one more thing, the device created is eth1, I've tried to set it to wlan0 in udev but it won't change and won't fully load, how can I change it to wlan0 correctly?
Comment 41 Andrey Vihrov 2009-01-20 16:28:59 UTC
Add something like

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:5f:07:d5:b8", ATTR{type}=="1", KERNEL=="eth*", NAME="wlan0"

to /etc/udev/rules.d/70-persistent-net.rules.

And, I think these questions are not really on-topic.
Comment 42 DaggyStyle 2009-01-20 17:47:24 UTC
(In reply to comment #41)
> Add something like
> 
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:22:5f:07:d5:b8", ATTR{type}=="1", KERNEL=="eth*",
> NAME="wlan0"
> 
> to /etc/udev/rules.d/70-persistent-net.rules.
> 
> And, I think these questions are not really on-topic.
> 


sorr, your right, my fault
Comment 43 DaggyStyle 2009-01-23 16:51:03 UTC
one last question, does it supports scanning for your chip? if so, what is the chip id?
Comment 44 Andrey Vihrov 2009-01-24 11:21:01 UTC
btw, Broadcom guys released an updated version a few days ago.
Comment 45 Christoph Mende (RETIRED) gentoo-dev 2009-01-24 16:10:04 UTC
Created attachment 179564 [details, diff]
new patch for compilation against 2.6.29

and here's the updated linux-2.6.29 patch for the new release
Comment 46 chris salch 2009-01-24 20:57:12 UTC
Created attachment 179581 [details]
ebuild for 5.10.27.14

I've updated the ebuild.  Would it make more sense to name the patches like 5_10_27_14 as the ebuild is replacing '.' with '_' in MY_PV?

* dropped the vlanmode patch
* pulled in linux 2.6.29 patch (It applies but I'm running 2.6.28 so I can't really do anything but say it doesn't break the earlier version)
* updated ebuild to new version and changes in download naming scheme.
Comment 47 Nico Schlömer 2009-01-25 00:47:11 UTC
hi,

cool to see so many people interested in the build! thanks chris in particular for the updated ebuild.

for the patch name, i personally feel like we should take the underscore notation, it seems a little unlinuxish to me. anyway, we still got ${PV} for the version with the dots, so why not replace this in the ebuild? the same goes for the "2.6.29" which may be replaced by "${KV}".

i'd also vote for enclosing the patch application itself into "if [[ ${KV_PATCH} -gt 28 ]] ; then" or something like that. i mean, christoph very carefully wrapped  up the .patch with many "if kernel such-and-such", but hey, you don't always want to check the whole for that, right?

what do you think?

cheers,
nico
Comment 48 chris salch 2009-01-25 02:45:11 UTC
(In reply to comment #47)
> hi,
> 
> cool to see so many people interested in the build! thanks chris in particular
> for the updated ebuild.
> 
> for the patch name, i personally feel like we should take the underscore
> notation, it seems a little unlinuxish to me. anyway, we still got ${PV} for
> the version with the dots, so why not replace this in the ebuild? 

Good point.  It does make more sense to do it that.

> the same goes
> for the "2.6.29" which may be replaced by "${KV}".

This feels brittle to me, what happens when kernel version 2.6.30 comes out?  While the patch might still be appropriate and functional there ebuild would need to be adjusted or the a copy of the patch file would need to be created.  Of course the same can be said of a new version of the broadcom-sta driver and the opposite condition could also be true (the patch fails in a latter version).

> 
> i'd also vote for enclosing the patch application itself into "if [[
> ${KV_PATCH} -gt 28 ]] ; then" or something like that. i mean, christoph very
> carefully wrapped  up the .patch with many "if kernel such-and-such", but hey,
> you don't always want to check the whole for that, right?

This makes sense, there is no reason to apply the patch for earlier versions of the kernel.  I'll update the ebuild as such.

Chris S.
Comment 49 chris salch 2009-01-25 02:47:33 UTC
Created attachment 179630 [details, diff]
Update 5.10.27.14 ebuild

* Use PV instead of MY_PV in patch name.
* Only apply patch for KV_PATCH > 28
Comment 50 chris salch 2009-01-25 04:44:16 UTC
> > the same goes
> > for the "2.6.29" which may be replaced by "${KV}".
> 
> This feels brittle to me, what happens when kernel version 2.6.30 comes out? 
> While the patch might still be appropriate and functional there ebuild would
> need to be adjusted or the a copy of the patch file would need to be created. 
> Of course the same can be said of a new version of the broadcom-sta driver and
> the opposite condition could also be true (the patch fails in a latter
> version).

As a clarification, I don't like the idea of creating a dependency between the naming of a patch and the version of currently running/installed software that could be different from install to install.  That just sounds like a maintenance nightmare.
Comment 51 Andrey Vihrov 2009-01-25 07:44:14 UTC
(In reply to comment #47)

> i'd also vote for enclosing the patch application itself into "if [[
> ${KV_PATCH} -gt 28 ]] ; then" or something like that. i mean, christoph very
> carefully wrapped  up the .patch with many "if kernel such-and-such", but hey,
> you don't always want to check the whole for that, right?

I'd say it's more logical to have one generic source (produced from the Broadcom source and the patch) that compiles for all kernels. Also, these checks occur at compile time and do not introduce runtime penalty.
Comment 52 Christoph Mende (RETIRED) gentoo-dev 2009-01-25 20:23:01 UTC
(In reply to comment #49)
> * Only apply patch for KV_PATCH > 28

what andrey said, we usually don't like it when patches are only applied in some situations, I've written the patch like that on purpose, it's supposed to be applied even if the code won't be used
Comment 53 DaggyStyle 2009-01-25 21:33:30 UTC
I've sent broadcom an mail about the driver and two issues that I've noticed, this is what I've got is response:

Broadcom is currently evaluating our support strategy for Linux users. As the chipset supplier, Broadcom provides Linux support to our customers - the manufacturers of wireless devices - that ultimately provide products to end customers, such as wireless LAN vendors, cable modem vendors, and notebook providers. It is up to these manufacturers to provide Linux client support to their end customers. Broadcom does not make a Linux client version available for end users at this time, however this may change in the future. In the meantime, please contact the manufacturer of your wireless device for Linux drivers. Linux support for certain products may also be available from Linuxant, and third party provider at http://www.linuxant.com/driverloader/

Regards,
Broadcom Support Team

Name: Dagg Stompler
Subject: Web Site Feedback/Support Request - 54g Wireless LAN - Linux Drivers
Email Address: stompdagger1@yahoo.com

Feedback:
hello, I'm running linux has a main system, I have a broadcom wireless card, the id is 0c:00.0 0280: 14e4:4315  Network controller: Broadcom Corporation BCM4312 802.11b/g  (rev 01)

I've tried the broadcom-sta driver but when I load the module and try to watch information on the adapter using the command iwconfig this is what I see:
eth1      IEEE 802.11  Nickname:""
          Access Point: Not-Associated

when the output should be like this:
eth1      IEEE 802.11g  ESSID:off/any
          Mode:Managed  Frequency:2.462 GHz  Access Point: Not-Associated
          Bit Rate:54 Mb/s  Tx-Power:24 dBm
          RTS thr:2347 B  Fragment thr:2346 B
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0  Missed beacon:0

plus, when I try to scan for networks, I get an error saying that the device doesn't support scanning
I wanted to know are these bugs or features not implemented yet?

thanks.

now I ask, what kind of a response is this?
Comment 54 chris salch 2009-01-26 03:13:16 UTC
> I've tried the broadcom-sta driver but when I load the module and try to watch
> information on the adapter using the command iwconfig this is what I see:
> eth1      IEEE 802.11  Nickname:""
>           Access Point: Not-Associated
> 
> when the output should be like this:
> eth1      IEEE 802.11g  ESSID:off/any
>           Mode:Managed  Frequency:2.462 GHz  Access Point: Not-Associated
>           Bit Rate:54 Mb/s  Tx-Power:24 dBm
>           RTS thr:2347 B  Fragment thr:2346 B
>           Power Management:off
>           Link Quality:0  Signal level:0  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0  Missed beacon:0
> 
> plus, when I try to scan for networks, I get an error saying that the device
> doesn't support scanning
> I wanted to know are these bugs or features not implemented yet?
> 

Aside from the response that Broadcom gave you, I would suggest trying iwconfig and scanning as root.  Both of these functions appear to work perfectly well when run as root but not when run as a common user.  I'm not sure why though.


(In reply to comment #52)
> (In reply to comment #49)
> > * Only apply patch for KV_PATCH > 28
> 
> what andrey said, we usually don't like it when patches are only applied in
> some situations, I've written the patch like that on purpose, it's supposed to
> be applied even if the code won't be used
> 

I'll correct that and resubmit.


Comment 55 chris salch 2009-01-26 03:18:30 UTC
Created attachment 179742 [details]
Update 5.10.27.14 ebuild

* Removes conditional application of the 2.6.29 patch
Comment 56 DaggyStyle 2009-01-27 06:33:27 UTC
ok, thank's working beside the scanning that returns
Failed to read scan data : Invalid argument
Comment 57 Chris Nolan 2009-02-01 18:07:09 UTC
Created attachment 180576 [details, diff]
hidden SSID fix

Hi from the Fedora maintainer for broadom-wl. 

Thought you might want this patch which allows the driver to associate with hidden SSID networks using Network Manager [1]. 

Also, thank you for the 2.6.29 build patch - very useful!

[1] http://worldofxor.blogspot.com/2008/12/it-works-broadcom-official-wireless.html
Comment 58 Balazs Nemeth 2009-02-02 10:44:15 UTC
(In reply to comment #57)
> Created an attachment (id=180576) [edit]
> hidden SSID fix
> 
> Hi from the Fedora maintainer for broadom-wl. 
> 
> Thought you might want this patch which allows the driver to associate with
> hidden SSID networks using Network Manager [1]. 
> 
> Also, thank you for the 2.6.29 build patch - very useful!
> 
> [1]
> http://worldofxor.blogspot.com/2008/12/it-works-broadcom-official-wireless.html
> 

patch need to be changed a bit (eof characters) but it works. I haven't tested it yet. I'll upload the modified version.
Comment 59 Balazs Nemeth 2009-02-02 10:45:22 UTC
Created attachment 180679 [details, diff]
broadcom-wl-5.10.27.14-hidden-essid.patch
Comment 60 Chris Nolan 2009-02-02 11:00:13 UTC
(In reply to comment #58)
> 
> patch need to be changed a bit (eof characters) but it works. I haven't tested
> it yet. I'll upload the modified version.
> 

My bad, I haven't had chance to test it yet either. I am now hearing that the hidden SSID problem _may_ have been fixed in 5.10.27.12 but I don't see any fix in the code so it is possible that they fixed it within the binary blob? Need to test *.12 or *.14 with and without the patch to see if hidden SSID works.

Hope you don't mind me jumping in on this ticket - I feel that as we have no access to upstream devs for this module then the more we can communicate and share fixes/patches between distros the better. I am trying to feed fixes upstream via Canonical but even they say they don't have great access to broadcom.
Comment 61 DaggyStyle 2009-02-02 12:58:26 UTC
quick question, I don't seem to see a ebuild that apples the patch, is there a one in the list or I need to modify the ebuild?
Comment 62 Balazs Nemeth 2009-02-13 07:49:25 UTC
(In reply to comment #61)
> quick question, I don't seem to see a ebuild that apples the patch, is there a
> one in the list or I need to modify the ebuild?
> 

I made a modified ebuild in my local overlay. I didn't upload it.
The only change was to add an "epatch" line.
Comment 63 Bob Raitz 2009-02-14 01:07:24 UTC
I tried the latest broadcom*14 ebuild with 2.6.29-rc3-zen1, and firstly, it failed. After I modified the ebuild as below, it would finish. However, on reboot, I was dropped into the middle of Kernel-panic-opolis. The kernel panic was directly related to the wireless module, and happened as soon as its module was autoprobed.

BEGIN>>>

# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

inherit linux-mod

DESCRIPTION="Broadcom's IEEE 802.11a/b/g/n hybrid Linux device driver."
HOMEPAGE="http://www.broadcom.com/support/802.11/linux_sta.php"

MY_PV="$(replace_all_version_separators _)"

SRC_BASE="http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86"
SRC_URI="
	x86?	( ${SRC_BASE}_32-v${MY_PV}.tar.gz )
	amd64?	( ${SRC_BASE}_64-v${MY_PV}.tar.gz )"

LICENSE="broadcom"
KEYWORDS="~amd64 ~x86"
IUSE=""

#CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP"#having the CONFIG_CHECK here insures ebuild failure when using a .29 kernel.

S="${WORKDIR}"

MODULE_NAMES="wl(net/wireless)"
MODULESD_WL_ALIASES=("wlan0 wl")


src_unpack() {
	unpack ${A}
	
	epatch "${FILESDIR}/broadcom-sta-${PV}-linux-2.6.29.patch"
	CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP" #When placed *after* patching, the ebuild finishes.

}

src_compile() {
	BUILD_PARAMS="-C ${KV_OUT_DIR} M=${S}"
	BUILD_TARGETS="wl.ko"
	linux-mod_src_compile
}

END>>>>>>

Should I also post this as an attachment?
Comment 64 Christoph Mende (RETIRED) gentoo-dev 2009-02-14 08:23:33 UTC
(In reply to comment #63)

it works that way because it's completely wrong. the check is done in pkg_setup, so if you define CONFIG_CHECK in src_unpack, it'll be ignored. the correct way would be to use conditional checks based on the correct config options (I already said we need lib80211 on 2.6.29):

pkg_setup() {
if kernel_is ge 2 6 29; then
CONFIG_CHECK="LIB802111"
else
CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP"
fi
linux-info_pkg_setup
}
Comment 65 Bob Raitz 2009-02-14 19:17:36 UTC
(In reply to comment #64)
> (In reply to comment #63)
> 
> it works that way because it's completely wrong. the check is done in
> pkg_setup, so if you define CONFIG_CHECK in src_unpack, it'll be ignored. the
> correct way would be to use conditional checks based on the correct config
> options (I already said we need lib80211 on 2.6.29):
> 
> pkg_setup() {
> if kernel_is ge 2 6 29; then
> CONFIG_CHECK="LIB802111"
> else
> CONFIG_CHECK="IEEE80211 IEEE80211_CRYPT_TKIP"
> fi
> linux-info_pkg_setup
> }
> 

That's not the bothersome part for me. The bothersome part is having the kernel panic. That's what I'd like fixed.

Comment 66 Balazs Nemeth 2009-03-06 18:09:12 UTC
Created attachment 184149 [details]
broadcom-sta-5.10.79.10.ebuild

New release.
Changelog:
 - I only noticed that "module licence" is now specified
Comment 67 Balazs Nemeth 2009-03-06 18:10:47 UTC
Created attachment 184151 [details, diff]
broadcom-sta-5.10.79.10-hidden-essid.patch

The hidden-essid patch. Nothing changed but the line numbers.
Comment 68 Balazs Nemeth 2009-03-06 18:11:29 UTC
Created attachment 184152 [details, diff]
broadcom-sta-5.10.79.10-linux-2.6.29.patch

Untouched, just renamed.
Comment 69 DaggyStyle 2009-03-07 08:04:38 UTC
Created attachment 184198 [details]
modified ebuild

previous ebuild patched the code with the 2.6.29 patch even if it wasn't a 2.6.29 kernel so I've added a if condition which will apply the patch only if the kernel is 2.6.29
Comment 70 MATSUU Takuto (RETIRED) gentoo-dev 2009-03-08 02:55:18 UTC
Created attachment 184309 [details]
net-wireless/broadcom-sta-5.10.79.10.ebuild

Clean up.
${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29.

I'll commit this ebuild to official portage tree.
Comment 71 DaggyStyle 2009-03-08 06:17:39 UTC
(In reply to comment #70)
> Created an attachment (id=184309) [edit]
> net-wireless/broadcom-sta-5.10.79.10.ebuild
> 
> Clean up.
> ${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29.
> 
> I'll commit this ebuild to official portage tree.
> 

isn't that unnecessary patching?
Comment 72 MATSUU Takuto (RETIRED) gentoo-dev 2009-03-10 00:42:37 UTC
(In reply to comment #71)
> (In reply to comment #70)
> > Created an attachment (id=184309) [edit]
> > net-wireless/broadcom-sta-5.10.79.10.ebuild
> > 
> > Clean up.
> > ${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29.
> > 
> > I'll commit this ebuild to official portage tree.
> > 
> 
> isn't that unnecessary patching?
> 

No, but the patch gives no effect older than 2.6.29 because of it uses 'if preprocessor'.
Comment 73 DaggyStyle 2009-03-10 06:48:37 UTC
(In reply to comment #72)
> (In reply to comment #71)
> > (In reply to comment #70)
> > > Created an attachment (id=184309) [edit]
> > > net-wireless/broadcom-sta-5.10.79.10.ebuild
> > > 
> > > Clean up.
> > > ${P}-linux-2.6.29.patch works even if your kernel version is less than 2.6.29.
> > > 
> > > I'll commit this ebuild to official portage tree.
> > > 
> > 
> > isn't that unnecessary patching?
> > 
> 
> No, but the patch gives no effect older than 2.6.29 because of it uses 'if
> preprocessor'.
> 

so the if I've added is actually been done?
Comment 74 Christoph Mende (RETIRED) gentoo-dev 2009-03-10 08:35:45 UTC
(In reply to comment #69)
> previous ebuild patched the code with the 2.6.29 patch even if it wasn't a
> 2.6.29 kernel so I've added a if condition which will apply the patch only if
> the kernel is 2.6.29 
> 

It's already been said that you must not do that... and if you did, you'd have to check for >= 2.6.29, not = 2.6.29 (ge instead of eq)

(In reply to comment #70)
> Clean up.

While you're at it, please replace those two epatches with one (it takes >=1 argument)
Comment 75 Cosmin Giradu 2009-04-02 11:44:53 UTC
(In reply to comment #63)
> I tried the latest broadcom*14 ebuild with 2.6.29-rc3-zen1, and firstly, it
> failed. After I modified the ebuild as below, it would finish. However, on
> reboot, I was dropped into the middle of Kernel-panic-opolis. The kernel panic
> was directly related to the wireless module, and happened as soon as its module
> was autoprobed.

Also panic here. Kernel was built from sys-kernel/gentoo-sources:2.6.29, lib80211 enabled. Modules compiles and installs ok but I've got a kernel pannic when I tried to use the wl module.

The kpanic however does not occur when loading the module (module loads with a "(wl): not using net_device_ops yet" warning, but does not issue any error).

After that, when trying to bring the link up, I get the infamous kernel panic. I couldn't copy the panic message entirely but what I could get from it was:

EIP at: wl_txflowcontrol+0x3c/0x80

This, in my opinion, looks more like an upstream bug than a but related to packaging the sta, or anything related to the patches. If I'm wrong please correct me (and the ebuild/patches).
Comment 76 chris salch 2009-04-02 12:43:27 UTC
(In reply to comment #75)
> (In reply to comment #63)
> > I tried the latest broadcom*14 ebuild with 2.6.29-rc3-zen1, and firstly, it
> > failed. After I modified the ebuild as below, it would finish. However, on
> > reboot, I was dropped into the middle of Kernel-panic-opolis. The kernel panic
> > was directly related to the wireless module, and happened as soon as its module
> > was autoprobed.
> 
> Also panic here. Kernel was built from sys-kernel/gentoo-sources:2.6.29,
> lib80211 enabled. Modules compiles and installs ok but I've got a kernel pannic
> when I tried to use the wl module.
> 
> The kpanic however does not occur when loading the module (module loads with a
> "(wl): not using net_device_ops yet" warning, but does not issue any error).
> 
> After that, when trying to bring the link up, I get the infamous kernel panic.
> I couldn't copy the panic message entirely but what I could get from it was:
> 
> EIP at: wl_txflowcontrol+0x3c/0x80
> 
> This, in my opinion, looks more like an upstream bug than a but related to
> packaging the sta, or anything related to the patches. If I'm wrong please
> correct me (and the ebuild/patches).
> 

I've seen a similar kernel panic when attempting to connect to the wireless network where I work.  From what I can tell, this is related to configurations of networks.  My system at home works fine but I was getting a panic within seconds of connecting to wireless where I work.  Unfortunately, I have not idea which network characteristic is the cause.
Comment 77 chris salch 2009-04-02 14:23:36 UTC
(In reply to comment #76)
> 
> I've seen a similar kernel panic when attempting to connect to the wireless
> network where I work.  From what I can tell, this is related to configurations
> of networks.  My system at home works fine but I was getting a panic within
> seconds of connecting to wireless where I work.  Unfortunately, I have not idea
> which network characteristic is the cause.
> 

It would appear that the particular issue I was seeing is not a problem any longer.  There may be a related issue though.
Comment 78 Cosmin Giradu 2009-04-02 14:51:19 UTC
(In reply to comment #77)
> (In reply to comment #76)
> > 
> > I've seen a similar kernel panic when attempting to connect to the wireless
> > network where I work.  From what I can tell, this is related to configurations
> > of networks.  My system at home works fine but I was getting a panic within
> > seconds of connecting to wireless where I work.  Unfortunately, I have not idea
> > which network characteristic is the cause.
> > 
> 
> It would appear that the particular issue I was seeing is not a problem any
> longer.  There may be a related issue though.
> 

I wasn't saying anything about connecting to any network. I was just talking about "ip link set eth<X> up". That's where I get the panic.
Comment 79 Nico Schlömer 2009-04-06 12:45:44 UTC
Hi,

seems like Broadcom published a patch on their page 

http://www.broadcom.com/docs/linux_sta/wl_iw_v2.patch

which looks quite ~similar~ to what we provide as broadcom-sta-5.10.79.10-wl_iw.patch. Has anyone had a look at this already?

Cheers,
Nico
Comment 80 Nico Schlömer 2009-04-06 13:27:01 UTC
Created attachment 187456 [details, diff]
updated patch

Alright, I tried it now myself and it indeed fixes some `ioctl[SIOCGIWSCAN]: Invalid argument` errors for me.

Patch appended.

Nico
Comment 81 MATSUU Takuto (RETIRED) gentoo-dev 2009-04-07 23:16:37 UTC
tha patch is in cvs. but it occurs oops, bug #265385.
Comment 82 Balazs Nemeth 2009-04-23 13:38:42 UTC
Created attachment 189238 [details]
broadcom-sta-5.10.79.10-r1 build log on 2.6.30-rc3

broadcom-sta-5.10.79-10-r1 doesn't compile on 2.6.30-rc3

it seems that it tries to include net/ieee80211.h. however 2.6.29 patch was already applied.
Comment 83 Viktor Ashirov 2009-04-23 17:24:05 UTC
Created attachment 189250 [details, diff]
patch for linux-2.6.30

Please, test.
Comment 84 Balazs Nemeth 2009-04-23 20:02:52 UTC
(In reply to comment #83)
> Created an attachment (id=189250) [edit]
> patch for linux-2.6.30
> 
> Please, test.
> 

It compiles fine with your patch. Thank you. :)
Comment 85 emerald 2009-05-02 23:33:04 UTC
SRC_URI not found anymore, returns 404 :(
only a newer package available now.
Comment 86 MATSUU Takuto (RETIRED) gentoo-dev 2009-05-03 01:25:44 UTC
broadcom-sta-5.10.91.9 in cvs.
and close this bug.
Comment 87 Krzysiek Bielicki 2009-06-12 21:37:10 UTC
(In reply to comment #84)
> (In reply to comment #83)
> > Created an attachment (id=189250) [edit]
> > patch for linux-2.6.30
> > 
> > Please, test.
> > 
> 
> It compiles fine with your patch. Thank you. :)
> 
I cannot compile on 2.6.30.
make: Entering directory `/usr/src/linux-2.6.30'
  CC [M]  /var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.o
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c: In function 'wl_if_setup':
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:233: error: 'struct net_device' has no member named 'open'
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:234: error: 'struct net_device' has no member named 'stop'
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:235: error: 'struct net_device' has no member named 'hard_start_xmit'
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:236: error: 'struct net_device' has no member named 'get_stats'
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:237: error: 'struct net_device' has no member named 'set_mac_address'
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:238: error: 'struct net_device' has no member named 'set_multicast_list'
/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.c:239: error: 'struct net_device' has no member named 'do_ioctl'
make[1]: *** [/var/tmp/portage/net-wireless/broadcom-sta-5.10.91.9-r1/work/src/wl/sys/wl_linux.o] Error 1
make: *** [wl.ko] Error 2
make: Leaving directory `/usr/src/linux-2.6.30'

Comment 88 Krzysiek Bielicki 2009-06-13 19:55:14 UTC
(In reply to comment #87)
FIXED I had to enable CONFIG_COMPAT_NET_DEV_OPS in kernel config
Comment 89 Alessandro Suardi 2009-06-18 09:54:59 UTC
Just a heads-up, somewhere between 2.6.30-git8 (which is ok) and 2.6.30-git11 CONFIG_COMPAT_NET_DEV_OPS has been removed from the mainline kernel and this driver obviously does not compile anymore.
Comment 90 Cosmin Giradu 2009-06-18 12:34:41 UTC
(In reply to comment #89)
> Just a heads-up, somewhere between 2.6.30-git8 (which is ok) and 2.6.30-git11
> CONFIG_COMPAT_NET_DEV_OPS has been removed from the mainline kernel and this
> driver obviously does not compile anymore.
> 

It's still there (in 2.6.30-gentoo-r1)

Device Drivers ---> Network Device Support ---> Enable older network device API compatibility
Comment 91 Tomáš Szépe 2009-06-19 16:21:35 UTC
Created attachment 195182 [details, diff]
a patch to convert the wl driver to net_device_ops (required to build on 2.6.31+)
Comment 92 Alessandro Suardi 2009-06-19 23:17:19 UTC
(In reply to comment #90)
> (In reply to comment #89)
> > Just a heads-up, somewhere between 2.6.30-git8 (which is ok) and 2.6.30-git11
> > CONFIG_COMPAT_NET_DEV_OPS has been removed from the mainline kernel and this
> > driver obviously does not compile anymore.
> > 
> 
> It's still there (in 2.6.30-gentoo-r1)
> 
> Device Drivers ---> Network Device Support ---> Enable older network device API
> compatibility
> 

I mentioned very specific versions, clearly a bit ahead of where gentoo currently is. You can find them on http://www.kernel.org ...

Thanks Tomas for the patch (I had come up with the same patch myself ;) - btw I applied the same to 5.10.79 since 5.10.91 drops association and loses packets too easily for me on 2.6.30-git14. Will try again 5.10.91 in later kernels or when I complete the move to Fedora 11 from my current Fedora 10 x86_64 (I'm not trolling, I found this bug while looking into the problems I had and thought I'd post a warning). Keep up the good work.
Comment 93 D W 2009-06-21 20:15:18 UTC
Just wanted to make a note in case anyone else has trouble:
It seems in 2.6.30 vanilla, the only way to build the lib80211_crypt_* modules is to build the hostap driver.  The Kconfig doesn't allow these modules to be selected on their own even if lib80211 is selected.  I was going crazy trying to get it to work with my WPA access point until I figured this out.
Comment 94 DaggyStyle 2009-07-20 12:34:56 UTC
(In reply to comment #54)
> > I've tried the broadcom-sta driver but when I load the module and try to watch
> > information on the adapter using the command iwconfig this is what I see:
> > eth1      IEEE 802.11  Nickname:""
> >           Access Point: Not-Associated
> > 
> > when the output should be like this:
> > eth1      IEEE 802.11g  ESSID:off/any
> >           Mode:Managed  Frequency:2.462 GHz  Access Point: Not-Associated
> >           Bit Rate:54 Mb/s  Tx-Power:24 dBm
> >           RTS thr:2347 B  Fragment thr:2346 B
> >           Power Management:off
> >           Link Quality:0  Signal level:0  Noise level:0
> >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
> >           Tx excessive retries:0  Invalid misc:0  Missed beacon:0
> > 
> > plus, when I try to scan for networks, I get an error saying that the device
> > doesn't support scanning
> > I wanted to know are these bugs or features not implemented yet?
> > 
> 
> Aside from the response that Broadcom gave you, I would suggest trying iwconfig
> and scanning as root.  Both of these functions appear to work perfectly well
> when run as root but not when run as a common user.  I'm not sure why though.
tried it now, scanning is possible via root. is there a fix for scanning via normal user?
one more thing, I need /etc/init.d/net.eth1 has root for it to work, so the scanning will occur and if there is a known wireless network in range that is configured in /etc/conf.d/net then a connection will occur, am I right?
Comment 95 Christoph Mende (RETIRED) gentoo-dev 2009-07-20 12:43:54 UTC
(In reply to comment #94)
> tried it now, scanning is possible via root. is there a fix for scanning via
> normal user?

No, that's how iwconfig works. From the iwlist manual:
Triggering  scanning  is  a privileged operation (root only) and normal users can only read left-over scan results.
Comment 96 DaggyStyle 2009-07-20 20:01:15 UTC
(In reply to comment #95)
> (In reply to comment #94)
> > tried it now, scanning is possible via root. is there a fix for scanning via
> > normal user?
> 
> No, that's how iwconfig works. From the iwlist manual:
> Triggering  scanning  is  a privileged operation (root only) and normal users
> can only read left-over scan results.
> 
what about my second question? there shouldn't be any problems running my current net config, right?
Comment 97 DaggyStyle 2009-07-20 20:12:03 UTC
another question, when I load the driver, knemo (I use kde) shows that the card is connected when there isn't any network, is it a driver issue or can it be resolved by configuration somehow? in essence, I want the card not to assume it is connected when it isn't.
Comment 98 Alessandro Suardi 2009-12-13 13:47:11 UTC
Another heads-up :)

Shortly after mainline 2.6.32-git1, the kernel wireless infrastructure has changed and the 5.10.91.9.3 driver will not build anymore.

You will need to:

 1. replace in the 5.10.91.9.3 sources all occurrences of CONFIG_WIRELESS_EXT with CONFIG_CFG80211_WEXT

 2. select *in your kernel* support for some unrelated wireless driver that, via Kconfig, SELECTs CONFIG_WEXT_PRIV - that symbol isn't user-selectable


Discussion available here (full thread not yet archived as I write, should appear in its entirety soon):

 http://lkml.org/lkml/2009/12/12/137
Comment 99 DaggyStyle 2009-12-13 15:00:51 UTC
(In reply to comment #98)
> Another heads-up :)
> 
> Shortly after mainline 2.6.32-git1, the kernel wireless infrastructure has
> changed and the 5.10.91.9.3 driver will not build anymore.
> 
> You will need to:
> 
>  1. replace in the 5.10.91.9.3 sources all occurrences of CONFIG_WIRELESS_EXT
> with CONFIG_CFG80211_WEXT
> 
>  2. select *in your kernel* support for some unrelated wireless driver that,
> via Kconfig, SELECTs CONFIG_WEXT_PRIV - that symbol isn't user-selectable
> 
> 
> Discussion available here (full thread not yet archived as I write, should
> appear in its entirety soon):
> 
>  http://lkml.org/lkml/2009/12/12/137
> 

e.g. it is a 33 issue, right?
Comment 100 Alessandro Suardi 2009-12-13 16:33:35 UTC
(In reply to comment #99)

> e.g. it is a 33 issue, right?

This issue will appear in 2.6.33 if you only use release kernels (ie, no -git or -rc sources), yes.

Comment 101 MATSUU Takuto (RETIRED) gentoo-dev 2010-03-12 18:04:11 UTC
*** Bug 306989 has been marked as a duplicate of this bug. ***
Comment 102 Bob Raitz 2010-03-13 09:22:15 UTC
(In reply to comment #100)
> (In reply to comment #99)
> 
> > e.g. it is a 33 issue, right?
> 
> This issue will appear in 2.6.33 if you only use release kernels (ie, no -git
> or -rc sources), yes.
> 

Any hint of a fix yet?
Comment 103 DaggyStyle 2010-03-13 09:34:09 UTC
why not use the latest in portage?
I have 2.6.33 and the latest in portage have no problems.
Comment 104 Bob Raitz 2010-03-13 09:42:50 UTC
(In reply to comment #103)
> why not use the latest in portage?
> I have 2.6.33 and the latest in portage have no problems.
> 

I haven't seen an update to my ebuild, and I know it craps out every time. I suppose I can give it another shot and see if it works now. It hasn't since .33 hit.
Comment 105 Bob Raitz 2010-03-13 09:46:25 UTC
Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's the error:

* Found kernel source directory:
 *     /usr/src/linux
 * Found kernel object directory:
 *     /lib/modules/2.6.33-zen1/build
 * Found sources for kernel version:
 *     2.6.33-zen1
 * Checking for suitable kernel configuration options...
 *   CONFIG_WIRELESS_EXT:	 is not set when it should be.
 *   CONFIG_WEXT_PRIV:	 is not set when it should be.
 * Please check to make sure these options are set correctly.
 * Failure to do so may cause unexpected problems.
 * Once you have satisfied these options, please try merging
 * this package again.
 * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed:
 *   Incorrect kernel configuration options


I'd say that's a fairly cut and dried kind of issue.
Comment 106 David Pyke 2010-03-13 13:48:53 UTC
(In reply to comment #105)
> Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's
> the error:
> 
>  * Checking for suitable kernel configuration options...
>  *   CONFIG_WIRELESS_EXT:        is not set when it should be.
>  *   CONFIG_WEXT_PRIV:   is not set when it should be.
>  * Please check to make sure these options are set correctly.
>  * Failure to do so may cause unexpected problems.
>  * Once you have satisfied these options, please try merging
>  * this package again.
>  * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed:
>  *   Incorrect kernel configuration options

Yep, you haven't set up your kernel correctly.  The ebuild can't do that, you have to.
Comment 107 Bob Raitz 2010-03-13 21:13:38 UTC
(In reply to comment #106)
> (In reply to comment #105)
> > Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's
> > the error:
> > 
> >  * Checking for suitable kernel configuration options...
> >  *   CONFIG_WIRELESS_EXT:        is not set when it should be.
> >  *   CONFIG_WEXT_PRIV:   is not set when it should be.
> >  * Please check to make sure these options are set correctly.
> >  * Failure to do so may cause unexpected problems.
> >  * Once you have satisfied these options, please try merging
> >  * this package again.
> >  * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed:
> >  *   Incorrect kernel configuration options
> 
> Yep, you haven't set up your kernel correctly.  The ebuild can't do that, you
> have to.
> 

Really? Show me where these settings exist.

# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_DEFAULT_PS is not set
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_CFG80211_WEXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=y
# CONFIG_LIB80211_DEBUG is not set
# CONFIG_MAC80211 is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

As far as I can tell, I have what I need set up. I see no options for the settings that are causing the issues. If you can tell where these settings hide, please do. I'd really like to be able to use the broadcom-sta with .33.
Comment 108 Alessandro Suardi 2010-03-15 22:23:51 UTC
(In reply to comment #107)

> As far as I can tell, I have what I need set up. I see no options for the
> settings that are causing the issues. If you can tell where these settings
> hide, please do. I'd really like to be able to use the broadcom-sta with .33.

I don't know about how Gentoo implemented the solution - but please have a
 look at my description of the issue at comment #98 (maybe you just need to
 select another wireless driver in addition to the broadcom-sta as I did when
 I logged my heads-up to this bug).
Comment 109 DaggyStyle 2010-03-16 04:36:31 UTC
(In reply to comment #107)
> (In reply to comment #106)
> > (In reply to comment #105)
> > > Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's
> > > the error:
> > > 
> > >  * Checking for suitable kernel configuration options...
> > >  *   CONFIG_WIRELESS_EXT:        is not set when it should be.
> > >  *   CONFIG_WEXT_PRIV:   is not set when it should be.
> > >  * Please check to make sure these options are set correctly.
> > >  * Failure to do so may cause unexpected problems.
> > >  * Once you have satisfied these options, please try merging
> > >  * this package again.
> > >  * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed:
> > >  *   Incorrect kernel configuration options
> > 
> > Yep, you haven't set up your kernel correctly.  The ebuild can't do that, you
> > have to.
> > 
> 
> Really? Show me where these settings exist.
> 
> # CONFIG_NET_PKTGEN is not set
> # CONFIG_HAMRADIO is not set
> # CONFIG_CAN is not set
> # CONFIG_IRDA is not set
> # CONFIG_BT is not set
> # CONFIG_AF_RXRPC is not set
> CONFIG_WIRELESS=y
> CONFIG_WEXT_CORE=y
> CONFIG_WEXT_PROC=y
> CONFIG_CFG80211=y
> # CONFIG_NL80211_TESTMODE is not set
> # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
> # CONFIG_CFG80211_REG_DEBUG is not set
> # CONFIG_CFG80211_DEFAULT_PS is not set
> # CONFIG_CFG80211_DEBUGFS is not set
> CONFIG_WIRELESS_OLD_REGULATORY=y
> CONFIG_CFG80211_WEXT=y
> CONFIG_WIRELESS_EXT_SYSFS=y
> CONFIG_LIB80211=y
> # CONFIG_LIB80211_DEBUG is not set
> # CONFIG_MAC80211 is not set
> # CONFIG_WIMAX is not set
> # CONFIG_RFKILL is not set
> # CONFIG_NET_9P is not set
> 
> As far as I can tell, I have what I need set up. I see no options for the
> settings that are causing the issues. If you can tell where these settings
> hide, please do. I'd really like to be able to use the broadcom-sta with .33.
> 

you need to findout what is blocking it, run make menuconfig, hit the / key, search for the relevant config and look at its depends
Comment 110 Bob Raitz 2010-03-16 18:21:34 UTC
(In reply to comment #109)
> (In reply to comment #107)
> > (In reply to comment #106)
> > > (In reply to comment #105)
> > > > Yeppers... it craps out with 2.6.33-zen1, or plain old 2.6.33 for me. Here's
> > > > the error:
> > > > 
> > > >  * Checking for suitable kernel configuration options...
> > > >  *   CONFIG_WIRELESS_EXT:        is not set when it should be.
> > > >  *   CONFIG_WEXT_PRIV:   is not set when it should be.
> > > >  * Please check to make sure these options are set correctly.
> > > >  * Failure to do so may cause unexpected problems.
> > > >  * Once you have satisfied these options, please try merging
> > > >  * this package again.
> > > >  * ERROR: net-wireless/broadcom-sta-5.60.48.36 failed:
> > > >  *   Incorrect kernel configuration options
> > > 
> > > Yep, you haven't set up your kernel correctly.  The ebuild can't do that, you
> > > have to.
> > > 
> > 
> > Really? Show me where these settings exist.
> > 
> > # CONFIG_NET_PKTGEN is not set
> > # CONFIG_HAMRADIO is not set
> > # CONFIG_CAN is not set
> > # CONFIG_IRDA is not set
> > # CONFIG_BT is not set
> > # CONFIG_AF_RXRPC is not set
> > CONFIG_WIRELESS=y
> > CONFIG_WEXT_CORE=y
> > CONFIG_WEXT_PROC=y
> > CONFIG_CFG80211=y
> > # CONFIG_NL80211_TESTMODE is not set
> > # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
> > # CONFIG_CFG80211_REG_DEBUG is not set
> > # CONFIG_CFG80211_DEFAULT_PS is not set
> > # CONFIG_CFG80211_DEBUGFS is not set
> > CONFIG_WIRELESS_OLD_REGULATORY=y
> > CONFIG_CFG80211_WEXT=y
> > CONFIG_WIRELESS_EXT_SYSFS=y
> > CONFIG_LIB80211=y
> > # CONFIG_LIB80211_DEBUG is not set
> > # CONFIG_MAC80211 is not set
> > # CONFIG_WIMAX is not set
> > # CONFIG_RFKILL is not set
> > # CONFIG_NET_9P is not set
> > 
> > As far as I can tell, I have what I need set up. I see no options for the
> > settings that are causing the issues. If you can tell where these settings
> > hide, please do. I'd really like to be able to use the broadcom-sta with .33.
> > 
> 
> you need to findout what is blocking it, run make menuconfig, hit the / key,
> search for the relevant config and look at its depends
> 

Or I could just say, "screw it" and go for the b43. Since it is clear that the symbols the ebuild are looking for are symbols that don't exist, or that have to be fixed to point to the right option, as per the article listed a few places above this one, I'm not going to mess with this anymore. 

Since I can run the b43 with one kernel, and broadcom-sta with the kernels that will allow it to work, I don't need to pull my hair out trying to find symbols that don't exist.

And I'm not going to, either. B43 works...hurray! Broadcom-sta, not so much...no great loss as far as I can see.
Comment 111 MATSUU Takuto (RETIRED) gentoo-dev 2010-05-20 02:45:00 UTC
*** Bug 320483 has been marked as a duplicate of this bug. ***
Comment 112 Alessandro Suardi 2010-05-23 10:57:49 UTC
Usual heads-up :)

Somewhere between 2.6.34-git4 and 2.6.34-git8 (and hence something Gentoo will see in 2.6.35), there have been changes in the netdev area which make 5.60.48.36 broadcom-sta unbuildable again.

I'm attaching what I used to make it compile (and work, as I'm typing from a 2.6.34-git8 with my patched broadcom-sta driver) - it might be the right thing, or it might not, I tried to mimic changes made in other wireless drivers... WorksForMe anyway, maybe people with better understanding of the netdev changes will be able to come up with a more appropriate fix.

Note - my #if LINUX_VERSION_CODE has < 2.6.34; it should really be <= 2.6.34, because changes will see the light in 2.6.35 - but if I did that, 2.6.34-git8 would still try to build with older code and fail.

Cheers, --alessandro
Comment 113 Alessandro Suardi 2010-05-23 11:00:12 UTC
Created attachment 232555 [details, diff]
replace mc_list handling with netdev_for_each_mc_addr
Comment 114 Guy Fontaine 2010-05-30 16:30:44 UTC
Was able to emerge net-wireless/broadcom-sta-5.60.48.36 against 2.6.34-gentoo, Funtoo testing.
Comment 115 Balazs Nemeth 2010-05-30 19:06:24 UTC
(In reply to comment #114)
> Was able to emerge net-wireless/broadcom-sta-5.60.48.36 against 2.6.34-gentoo,
> Funtoo testing.
> 

Same here. Gentoo 'almost' stable :)
The kernel modul works fine.
Comment 116 Allan Gottlieb 2010-06-23 18:45:28 UTC
(In reply to comment #114)
> Was able to emerge net-wireless/broadcom-sta-5.60.48.36 against 2.6.34-gentoo,
> Funtoo testing.

Similar results with net-wireless/broadcom-sta-5.60.48.36-r1.  Perhaps
the ebuild msg should be changed since, for me, it is not
CONFIG_CFG80211_WEXT that needs to be set but CONFIG_WIRELESS_EXT.

The same workaround (setting PRISM54) worked.
Comment 117 Niels Dettenbach 2011-07-23 11:18:05 UTC
Dear all,

i'm currently try to upgrade from kernel 2.6.39-gentoo (where sta works fine) to 2.6.39-gentoo-r3 or 3.0.0-gentoo.

broadcom-sta get's build fine as usual - but if i load wl i did not get any dmesg output nor device to see anymore.

Tried original broadcom-sta sources from broadcom too (incl. patch) which gives the same effect.

Hardware is a MacBookPro 6,1 with a lspci:
03:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01)

which usually loads under older kernels as:
[   64.000758] wl 0000:03:00.0: PCI INT A disabled
[   69.121343] wl 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[   69.121354] wl 0000:03:00.0: setting latency timer to 64
[   69.245802] wl 0000:03:00.0: eth1: Features changed: 0x00004800 -> 0x00004000
[   69.250017] eth1: Broadcom BCM4353 802.11 Hybrid Wireless Controller 5.100.82.38

If i boot older kernels with the former broadcom-sta installed the device gets loaded as usual for me.


Any idea?


many thanks for your time.

cheers,


Niels.
http://www.syndicat.com