First, a little background info:
This is a Compaq Presario 2500 with a Broadcom BCM94306MP (chipset BCM4306). I’m running OpenSuse 12.1, with the b43legacy driver. I did have to apply a general fix for the wireless card to interact with the system at all, though I can’t link to it now since I can’t view any other web pages. Which brings me to the weird part.
I’ve been able to connect with and use other wireless networks with no problem since that fix. This particular network is one I just started sharing with my neighbors, with their permission and their password, and it’s the one I intend to use at home. The quirk about it is that this website (opensuse.org) seems to be the only one I can access with any program, on this network. Updates, terminal, browser, you name it. I couldn’t even access the git site from terminal when I tried lwfinger’s SPROM fix.
Also I should mention, often when it starts up, it doesn’t detect this particular network right away - I have to disable and reenable wireless before it detects and logs on to the network.
Thanks for looking at this, everyone. The nature of the problem means that if I want help from anywhere else on the web, I’m going to have to trek through the snow first.
On 01/21/2012 05:26 PM, librarychair wrote:
>
> First, a little background info:
>
> This is a Compaq Presario 2500 with a Broadcom BCM94306MP (chipset
> BCM4306). I’m running OpenSuse 12.1, with the b43legacy driver. I did
> have to apply a general fix for the wireless card to interact with the
> system at all, though I can’t link to it now since I can’t view any
> other web pages. Which brings me to the weird part.
>
> I’ve been able to connect with and use other wireless networks with no
> problem since that fix. This particular network is one I just started
> sharing with my neighbors, with their permission and their password, and
> it’s the one I intend to use at home. The quirk about it is that this
> website (opensuse.org) seems to be the only one I can access with any
> program, on this network. Updates, terminal, browser, you name it. I
> couldn’t even access the git site from terminal when I tried lwfinger’s
> SPROM fix.
That should not have been needed. We found all the models that were affected by
this problem, and put special quirks into the driver. In addition, all the
models that had the problem used b43, not b43legacy.
> Also I should mention, often when it starts up, it doesn’t detect this
> particular network right away - I have to disable and reenable wireless
> before it detects and logs on to the network.
>
> Thanks for looking at this, everyone. The nature of the problem means
> that if I want help from anywhere else on the web, I’m going to have to
> trek through the snow first.
When you start the network, and while it has not yet been detected, issue the
command ‘sudo /usr/sbin/iwlist scan’. Does the network show there? It may be
that your neighbors AP is beaconing very slowly, or it is not responding to the
probes from b43legacy.
When the network is connected, please post the output of these two commands
/sbin/route -n
cat /etc/resolv.conf | grep -v \#
For that last one, it would be best to copy and paste.
Here’s the output of those two commands:
~> /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
~> cat /etc/resolv.conf | grep -v #
search site
nameserver 192.168.7.254
I honestly have very little idea of what any of this means. I’m good at following instructions though, I guess.
And, I didn’t get off the ground with the SPROM fix since the shell wouldn’t connect to the git server, so nothing’s been done except install the git, make and gcc libraries… which somehow were able to download just fine.
On 01/21/2012 07:26 PM, librarychair wrote:
>
> Here’s the output of those two commands:
>
> ~> /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags
> Metric Ref Use Iface
> 0.0.0.0 192.168.1.1 0.0.0.0 UG
> 0 0 0 wlan0
> 192.168.1.0 0.0.0.0 255.255.255.0 U
> 2 0 0 wlan0
In the future, please post computer between code tags. You can use Advanced
Editing, or start with
and end with
. That will keep the data
aligned, and keep the wiki from converting data into smilies.
~> cat /etc/resolv.conf | grep -v #
search site
nameserver 192.168.7.254
I honestly have very little idea of what any of this means. I’m good at
following instructions though, I guess.
In the routing table, the second line tells wlan0 how to access addresses in the
192.168.1.X domain. The first, the one with the UG flags, says that any other IP
number is accessed through 192.168.1.1. With these two rules, the system knows
how to route to any IP address.
Your /etc/resolv.conf is most likely wrong. In most setups using NAT (Network
Address Translation), the local nameserver has the same address as the router.
Thus, I would have expected the nameserver line to be ‘nameserver 192.168.1.1’.
I would try ‘sudo rm /etc/resolv.conf’, and reboot. Does that help?
If that does not, edit /etc/resolv.conf, remove the nameserver line, and add two
new ones
nameserver 8.8.8.8
nameserver 8.8.4.4
Those are the public nameservers operated by Google, and they work extremely well.
On 2012-01-22 02:26, librarychair wrote:
>
> Here’s the output of those two commands:
Please post using code tags. It is almost unreadable. Advanced editor, #.
> ~> cat /etc/resolv.conf | grep -v #
> search site
> nameserver 192.168.7.254
The name server is not in your local network (192.168.1.*), you can not
reach it. Correct that.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Apologies for my improper code display and general noobliness. Thank you, lwfinger, for helping me with this. The Google nameservers are working beautifully.