From: Chris Vine on
On Tue, 01 Jun 2010 12:19:17 +0200
Martin <no(a)spam.invalid> wrote:

> john(a)wexfordpress.com wrote:
>
> > What I am hoping to see on Slack is an automatic and foolproof
> > wireless connection equivalent to the one I found on Knoppix.
>
> I agree, wireless support out-of-the-box could be better.
>
> > Using
> > 13.0 I did a lot of extra work to get wireless working on the family
> > laptop, and after a while it stopped working.
>
> I have done the same recently. In order to share the effort I put a
> write-up on the web and had it linked to from tuxmobil.org.
>
> http://www.frogge.de/pepper/p50ij/p50ij.html#wlan
>
> It is still not totally end-user-proof as you still have to edit
> config files whenever you move to a new access point with
> authentication. Wicd alone is not the answer.

I don't think your approach is right. The README in the wicd extras
directory tells you to remove any set-up in /etc/rc.inet1.conf and in
my experience if that is done wicd is foolproof. It can also handle
wired ethernet as well as wireless, and any necessary dhcp requests.

If you are using wicd and editing configuration files, you are doing
something wrong.

In any event, it appears the that OP's problem is with the broadcom
drivers rather than configuration.

Chris
From: Jim Diamond on
On 2010-06-01 at 15:56 ADT, Chris Vine <chris(a)cvine--nospam--.freeserve.co.uk> wrote:
> On Mon, 31 May 2010 18:54:24 -0700 (PDT)
> "john(a)wexfordpress.com" <john(a)wexfordpress.com> wrote:
> [snip]
>> Yes Yes, I downloaded wicd and the Broadcom drivers, and after much
>> fiddling got wireless to work for a week or two. Then it stopped
>> working. Just for a test I booted a Knoppix disk. It found wireless
>> right away. So I installed Knoppix to the hard drive. My wife likes it
>> much better than Slackware plus xfce (I wouldn't subject her to KDE4).
>>
>> So I am of the opinion still. Slackware needs a reliable and out-of-
>> the-box wireless setup. Knoppix which is maintained by Klaus Knopper
>> has such a setup. With the increasing number of home wireless networks
>> it is pretty much a necessity.

> I don't agree. I see no reason why Slackware should package up
> proprietary drivers for cheap hardware for suppliers who won't release
> their source code or even adequate specifications.

Here's a reason (which you may not like, but...)
So that people who have systems with such hardware can say
"Slackware just works (TM)".

Yes, with sufficient effort and possibly help, people can get their
hardware working by downloading this or that, re-compiling this or
that, (re-)configuring this or that, and so on.

But is that any different than any package already provided with
Slackware? Not really. For example, if Slackware didn't include
emacs or vim or ..., I'd just d/l it/them and compile it/them and
install it/them myself.

Of course, Pat V (& helpers?) has/have to decide where to draw the
line, and that's fine. But just because he/they choose not to include
some useful (for some people) packages doesn't mean there is *no*
reason to do so.

I just put Slack64 13.1 on my laptop. Besides my hardware for which I
use proprietary drivers (nvidia graphics card), I add a lot of
packages which I need to d/l and compile myself. Is it a big deal?
Well, not in the sense that it is a major difficulty. But it took me
about a day to get everything set up, and if those packages came with
Slackware already, I'd be about a day ahead.

Cheers.
Jim
From: Mike Jones on
Responding to Jim Diamond:

[...]
> I just put Slack64 13.1 on my laptop. Besides my hardware for which I
> use proprietary drivers (nvidia graphics card), I add a lot of packages
> which I need to d/l and compile myself. Is it a big deal? Well, not in
> the sense that it is a major difficulty. But it took me about a day to
> get everything set up, and if those packages came with Slackware
> already, I'd be about a day ahead.


I have a scripted files\slackpkg collection that I run on a fresh install.

Everything done, including customised user accounts, in 7 minutes.

Pre-use reboot optional.

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Dan C on
On Tue, 01 Jun 2010 19:56:21 +0100, Chris Vine wrote:

> On Mon, 31 May 2010 18:54:24 -0700 (PDT) "john(a)wexfordpress.com"
> <john(a)wexfordpress.com> wrote: [snip]
>> Yes Yes, I downloaded wicd and the Broadcom drivers, and after much
>> fiddling got wireless to work for a week or two. Then it stopped
>> working. Just for a test I booted a Knoppix disk. It found wireless
>> right away. So I installed Knoppix to the hard drive. My wife likes it
>> much better than Slackware plus xfce (I wouldn't subject her to KDE4).
>>
>> So I am of the opinion still. Slackware needs a reliable and out-of-
>> the-box wireless setup. Knoppix which is maintained by Klaus Knopper
>> has such a setup. With the increasing number of home wireless networks
>> it is pretty much a necessity.
>
> I don't agree. I see no reason why Slackware should package up
> proprietary drivers for cheap hardware for suppliers who won't release
> their source code or even adequate specifications.
>
> But even if that is wrong, your opinion is not well thought out even on
> that level, because the problem is not just what you think it is. The
> fact of the matter is that the proprietary broadcom driver (the latest
> of which is at
> http://www.broadcom.com/support/802.11/linux_sta.php) does not compile
> against kernel versions 2.6.33 or later.
>
> You would be better advised to complain to broadcom about their not
> releasing their source code rather than complaining that Slackware does
> not provide an out of date kernel and proprietary drivers, or being more
> careful about the hardware you purchase.
>
> However, I will send you a patch which will enable you to compile the
> broadcom driver with 2.6.33 (and so Slackware-13.1) if you wish. But I
> expect you would be better off sticking with Knoppix, as you say.
>
> Alternatively you could use Slackware 13.0 until broadcom catch up. If
> you ran into this problem with Slackware 13.0 then probably you did not
> blacklist the ssb and b43 drivers in a file in modprobe.d, as the
> broadcom documentation tells you to do.
>
> Chris

Just for the record... I tried to compile the Broadcom driver on a new
13.1 install, and it did indeed fail. However, when I do it via the
slackbuild script from slackbuilds.org, it produces an installable
package just fine. Haven't taken the time to analyze the slackbuild
script, but I suspect it is patching the driver during the build
process. Works just fine.


--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he called in an air strike.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg
From: Chris Vine on
On 01 Jun 2010 22:23:01 GMT
Dan C <youmustbejoking(a)lan.invalid> wrote:
[snip]
> Just for the record... I tried to compile the Broadcom driver on a
> new 13.1 install, and it did indeed fail. However, when I do it via
> the slackbuild script from slackbuilds.org, it produces an
> installable package just fine. Haven't taken the time to analyze the
> slackbuild script, but I suspect it is patching the driver during the
> build process. Works just fine.

It does need a patch and it is pretty trivial. The generated
configuration file in the kernel source tree is now in
generated/autoconf.h rather than linux/autoconf.h, which requires
linuxver.h in the broadcom glue code to be patched.

You may find the in-tree b43 driver in 2.6.33 works for you, which means
that you don't have to bother with wl at all. It probably won't work
with a very recent netbook/laptop with a wireless device with 16K
memory area and low power PHY, but with others (including 8K low power
PHY) it will. Be careful with 2.6.34 though: it pretends it works with
such devices (it uses the PIO rather than DMA in order to do so) but it
is painfully slow and in those cases it is much better to use the wl
driver if you don't mind loading proprietary drivers. dmesg will tell
you if it has tried this work-around.

Possibly the OP tried to install the proprietary wl driver over the
in-tree b43 driver, since he made reference to the broadcom driver and
the wireless device once working and then ceasing to do so. That is a
sure way to failure. Or possibly he failed to notice that b43 brings
up the wlan0 interface and wl brings up the eth1 interface. All this
is explained in the documentation, but ...

Chris