Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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

Created an attachment (id=173053) [details]
initial broadcom sta linux driver ebuild

Created an attachment (id=173054) [details]
patch to build on newer (>=2.6.26) kernels

Created an attachment (id=173055) [details]
patch to fix the vlanmode problem

taken from http://www.cenolan.com/fedora9/

(From update of attachment 173054 [details])
taken from http://www.cenolan.com/fedora9/

(From update of attachment 173055 [details])
taken from http://www.cenolan.com/fedora9/

@mobile: any interest?

Created an attachment (id=174402) [details]
updated ebuild

patch needs to be applied only for kernels >= 2.6.27

Created an attachment (id=176017) [details]
Patch for kernel 2.6.27

Bump in version from previous patch.

Created an attachment (id=176018) [details]
Ebuild for Broadcom-sta version 5.10.27.11

Ebuild to go with the above patch, my fist contribution. 

(From update of attachment 176018 [details])
Forgot to mention this also fixes the VLAN bug, you can use SSH and TELNET. 
Cheers 

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
> 

(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

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

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

Created an attachment (id=176084) [details]
ebuild with proper version string

(From update of attachment 176017 [details])
Posting the same patch with the correct version information

Created an attachment (id=176108) [details]
added the driver version to patch file name

Created an attachment (id=176112) [details]
vlan mode patch for 5.10.27.11 release

Please test this patch out.

(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.

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

Created an attachment (id=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.

(In reply to comment #21)
> Created an attachment (id=176117) [edit] [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.
> 
Thanks for the updated ebuild! Glad we can now support x86 and x86_64.

(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

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

Created an attachment (id=177128) [details]
.12 ebuild

and here's the new ebuild...

Created an attachment (id=177129) [details]
.12 vlanmode-fix patch

watch out for those DOS end-of-line characters!

By the way, 5.10.27.12 seems to work fine without any patch here.

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

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.

(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

Created an attachment (id=178706) [details]
patch for linux-2.6.29

this patch fixes compilation on linux-2.6.29 and works fine for me atm

oh, forgot to mention, lib80211 is required now

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

DaggyStyle,

the patch is to be applied to the driver source itself. Moreover, users of
kernels < 2.6.29 don't need it.

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

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.

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?

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

the vlan mode patch isn't requried anymore on latest drivers

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?

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.

(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

one last question, does it supports scanning for your chip? if so, what is the
chip id?

btw, Broadcom guys released an updated version a few days ago.

Created an attachment (id=179564) [details]
new patch for compilation against 2.6.29

and here's the updated linux-2.6.29 patch for the new release

Created an attachment (id=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.

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

(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.

Created an attachment (id=179630) [details]
Update 5.10.27.14 ebuild

* Use PV instead of MY_PV in patch name.
* Only apply patch for KV_PATCH > 28

> > 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.

(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.

(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'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?

> 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.

Created an attachment (id=179742) [details]
Update 5.10.27.14 ebuild

* Removes conditional application of the 2.6.29 patch

ok, thank's working beside the scanning that returns
Failed to read scan data : Invalid argument

Created an attachment (id=180576) [details]
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

(In reply to comment #57)
> Created an attachment (id=180576) [edit] [details]
> 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.

Created an attachment (id=180679) [details]
broadcom-wl-5.10.27.14-hidden-essid.patch

(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.

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?

(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.

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?

(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
}

(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.

Created an attachment (id=184149) [details]
broadcom-sta-5.10.79.10.ebuild

New release.
Changelog:
 - I only noticed that "module licence" is now specified

Created an attachment (id=184151) [details]
broadcom-sta-5.10.79.10-hidden-essid.patch

The hidden-essid patch. Nothing changed but the line numbers.

Created an attachment (id=184152) [details]
broadcom-sta-5.10.79.10-linux-2.6.29.patch

Untouched, just renamed.

Created an attachment (id=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 

Created an attachment (id=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.

(In reply to comment #70)
> Created an attachment (id=184309) [edit] [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.
> 

isn't that unnecessary patching?

(In reply to comment #71)
> (In reply to comment #70)
> > Created an attachment (id=184309) [edit] [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.
> > 
> 
> isn't that unnecessary patching?
> 

No, but the patch gives no effect older than 2.6.29 because of it uses 'if
preprocessor'.

(In reply to comment #72)
> (In reply to comment #71)
> > (In reply to comment #70)
> > > Created an attachment (id=184309) [edit] [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.
> > > 
> > 
> > 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?

(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)

(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).

(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.

(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.

(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.

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

Created an attachment (id=187456) [details]
updated patch

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

Patch appended.

Nico

tha patch is in cvs. but it occurs oops, bug #265385.

Created an attachment (id=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.

Created an attachment (id=189250) [details]
patch for linux-2.6.30

Please, test.

(In reply to comment #83)
> Created an attachment (id=189250) [edit] [details]
> patch for linux-2.6.30
> 
> Please, test.
> 

It compiles fine with your patch. Thank you. :)

SRC_URI not found anymore, returns 404 :(
only a newer package available now.

broadcom-sta-5.10.91.9 in cvs.
and close this bug.

(In reply to comment #84)
> (In reply to comment #83)
> > Created an attachment (id=189250) [edit] [details]
> > 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'

(In reply to comment #87)
FIXED I had to enable CONFIG_COMPAT_NET_DEV_OPS in kernel config

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.

(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

Created an attachment (id=195182) [details]
a patch to convert the wl driver to net_device_ops (required to build on
2.6.31+)

(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.

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.

(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?

(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.

(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?

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.