# [Solved] Problem with wpa_supplicant. Or is it dhcp?

## lovelytux

Hey,

the Hardware is  

```
lspci -nn -d 14e4:  =>  BCM4311 802.11b/g WLAN 14e4:4311 
```

 The b43 module is build in Kernel as module ( /lib/module ..., the firmware b43-fwcutter and b43-firmware are build as /lib/firmware .... I need to long to learn it! Thanks at NeddySeagoon

Extract from .config

```
 CONFIG_B43=m

CONFIG_B43_BCMA=y

CONFIG_B43_SSB=y

CONFIG_B43_BUSES_BCMA_AND_SSB=y

# CONFIG_B43_BUSES_BCMA is not set

# CONFIG_B43_BUSES_SSB is not set

CONFIG_B43_PCI_AUTOSELECT=y

CONFIG_B43_PCICORE_AUTOSELECT=y

# CONFIG_B43_PCMCIA is not set

CONFIG_B43_BCMA_PIO=y

CONFIG_B43_PIO=y

CONFIG_B43_PHY_G=y

# CONFIG_B43_PHY_N is not set

CONFIG_B43_PHY_LP=y

# CONFIG_B43_PHY_HT is not set

CONFIG_B43_LEDS=y

CONFIG_B43_HWRNG=y

CONFIG_B43_DEBUG=y

# CONFIG_B43LEGACY is not set

# CONFIG_BRCMSMAC is not set

# CONFIG_BRCMFMAC is not set

# CONFIG_HOSTAP is not set

CONFIG_IPW2100=m

# CONFIG_IPW2100_MONITOR is not set

# CONFIG_IPW2100_DEBUG is not set

CONFIG_IPW2200=m

# CONFIG_IPW2200_MONITOR is not set

# CONFIG_IPW2200_QOS is not set

# CONFIG_IPW2200_DEBUG is not setI use openrc. On runlevel aren't things for network (dhcp ...).
```

wpa_supplicant with 

```
 

/etc/wpa_supplicant/wpa_supplicant.conf

# Allow users in the 'wheel' group to control wpa_supplicant

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

/etc/conf.d/net

modules_wlan0="wpa_supplicant"

config_wlan0="dhcp"
```

... and I copied 

```
cp /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks

```

```
/etc/init.d/dhcpcd start 
```

```
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet6 fe80::e24d:754:6935:307a  prefixlen 64  scopeid 0x20<link>

        ether 00:1c:26:c3:e5:99  txqueuelen 1000  (Ethernet)

        RX packets 812  bytes 114672 (111.9 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 128  bytes 30494 (29.7 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 
```

```
dmesg 
```

```
wlan0: authenticate with 34:81:c4:a1:48:eb

[ 2512.341229] wlan0: send auth to 34:81:c4:a1:48:eb (try 1/3)

[ 2512.344085] wlan0: authenticated

[ 2512.345089] wlan0: associate with 34:81:c4:a1:48:eb (try 1/3)

[ 2512.361941] wlan0: RX AssocResp from 34:81:c4:a1:48:eb (capab=0x431 status=0 aid=1)

[ 2512.362321] wlan0: associated

[ 2512.362425] cfg80211: Calling CRDA for country: DE

[ 2512.383576] b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: 34:81:c4:a1:48:eb
```

```
netstat -nr
```

```
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

0.0.0.0         192.168.1.200   0.0.0.0         UG        0 0          0 enp2s0

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo

127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo

169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 wlan0

192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 enp2s0
```

ping www.google.de don't find google.

Thanks vor help!

lovelytuxLast edited by lovelytux on Fri Jan 29, 2016 9:35 pm; edited 1 time in total

----------

## charles17

The address 169.254.0.0   looks like the AP doesn't accept your NIC.

And btw /etc/conf.d/net  as mentioned above is regardless when you have dhcpcd in a runlevel.

Please pastebin your output from testing.

----------

## lovelytux

Hey,

the AP say the connection is establish.

dhcpcd is not on runlevel at boot time. How do I start wpa_supplicant without dhcpcd? I think dhcpcd starts wpa_supplicant.

lovelytux

----------

## khayyam

 *lovelytux wrote:*   

> dhcpcd is not on runlevel at boot time. How do I start wpa_supplicant without dhcpcd? I think dhcpcd starts wpa_supplicant.

 

lovelytux ... if you're using netifrc (which from the above post it seems you are) then you don't need to start anything other than net.wlan0 ... ignore dhcpcd, wpa_supplicant ... and any suggestions that assumes that what we do now is completely arbitrary (or incomprehensible)[1].

That said, you're 'connected' so the issue is probably your not having name resolution, please check the contents of /etc/resolv.conf ... is there a nameserver defined? Can you ping something using an ip, rather than the address?

```
# ping -c1 204.187.15.12
```

1. rant: it seems that not satisfied with having init all a shambles the same meme is infecting the net stack, yeah, there are various ways you might go about satisfying 'net' but adding in too much complexity (in the form of copying hooks!! or figuring out which component is configured in what way to trigger some action) is a complete ballsup. So, if you have net.{IFACE} and modules="wpa_supplicant" you need to copy some hook? Likely not, but that is far from making the basic provision of networking a simple proposition, and there is too much in the way of parallelism of "alternatives" ... enough already.

best ... khay

----------

## lovelytux

Hey khayyam!

So sorry, please understand, I'm newbie, please folks have pacience. Yes you are right I don't have the overview and I ask me if there a horizont on gentoo for me. But I like gentoo so I don't give up after rant, after rant. Thank you very much for every reply! 

I read ...using_DHCPCD and delete netifrc 

```
emerge -C net-misc/netifrc
```

 and add dhcpcd to runlevel at boot. wlan0 comes up. Unfortunately no answer to ip adress, from gentoo server: 

```
PING 204.187.15.12 (204.187.15.12) 56(84) bytes of data.

From 169.254.14.2: icmp_seq=1 Destination Host Unreachable
```

wpa_supplicant established connection, wherever ....

```

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 169.254.14.2  netmask 255.255.0.0  broadcast 169.254.255.255

        inet6 fe80::e24d:754:6935:307a  prefixlen 64  scopeid 0x20<link>

        ether 00:1c:26:c3:e5:99  txqueuelen 1000  (Ethernet)

        RX packets 227  bytes 44029 (42.9 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 114  bytes 24723 (24.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```

lovelytux

Edit: /etc/resolv.conf is empty

----------

## NeddySeagoon

lovelytux,

It appears that you associated and authenticated correctly.  That's wpa_supplicants job, so it worked.

Addresses in the 169.254.0.0/16 range are link local addresses.

These addresses are not routable.  They are intended for use in Ad Hoc networks only.

They are also self assigned, so we know that your router did not allocate 169.254.14.2 to your WiFi.

Sight of all of your dmesg may be useful.  Please put it onto a pastebin.

----------

## lovelytux

Hey,

here ist dmesg.txt

regard 

lovelytux

----------

## NeddySeagoon

lovelytux,

This is a bad sign.

```
[    7.768856] wl: version magic '4.1.12-gentoo SMP mod_unload PENTIUMII ' should be '4.1.12-gentoo SMP mod_unload 586 '
```

Bits and pieces of your kernel and modules are made for different processors.

That means that even if it looks good, it might not work.

There is only one example here but its quite difficult to only get one part wrong.

Regardless of how it happened, the fix is the same.  Rebuild and reinstall your kernel, starting from the make clean step.

----------

## lovelytux

Hey,

it is a i celeron 530, single core, now i chhose (X) Pentium-II/Celeron(pre-Coppermine), the setting before (X) 586/K5/5x86/6x86/6x86MX . 

make mrproper 

The new kernel with the  new result of dmesg

I'm very, very stunned!!! It is working!! Yea! Thanks!

Now dhcpcd(?) sucks the correct IP-Adress 192.168. .... ping works, all browser works!

 :Laughing: 

Regard

lovelytux

----------

## khayyam

 *lovelytux wrote:*   

> Hey khayyam! So sorry, please understand, I'm newbie, please folks have pacience. Yes you are right I don't have the overview and I ask me if there a horizont on gentoo for me. But I like gentoo so I don't give up after rant, after rant. Thank you very much for every reply!

 

lovelytux ... that rant wasn't directed at you but at what I see as the quagmire of creeping disfunction that is gentoo's 'networking'.

best ... khay

----------

## UberLord

 *khayyam wrote:*   

> 1. rant: it seems that not satisfied with having init all a shambles the same meme is infecting the net stack, yeah, there are various ways you might go about satisfying 'net' but adding in too much complexity (in the form of copying hooks!! or figuring out which component is configured in what way to trigger some action) is a complete ballsup. So, if you have net.{IFACE} and modules="wpa_supplicant" you need to copy some hook? Likely not, but that is far from making the basic provision of networking a simple proposition, and there is too much in the way of parallelism of "alternatives" ... enough already.
> 
> 

 

One reason I introduced the newnet network script a long time ago and encouraged just adding dhcpcd to a runlevel  :Smile: 

You're having you're rant now, I had mine years ago  :Razz: 

----------

## khayyam

 *khayyam wrote:*   

> 1. rant: it seems that not satisfied with having init all a shambles the same meme is infecting the net stack, yeah, there are various ways you might go about satisfying 'net' but adding in too much complexity (in the form of copying hooks!! or figuring out which component is configured in what way to trigger some action) is a complete ballsup. So, if you have net.{IFACE} and modules="wpa_supplicant" you need to copy some hook? Likely not, but that is far from making the basic provision of networking a simple proposition, and there is too much in the way of parallelism of "alternatives" ... enough already.

 

 *UberLord wrote:*   

> One reason I introduced the newnet network script a long time ago and encouraged just adding dhcpcd to a runlevel :)

 

Roy ... and by which you introduce dual/multi namespacing, does it matter if the paticular initscript is called 'network', 'net', or 'dhcpcd'? All that need happen is that a 'provider' be defined, and a service set in a runlevel, and for the sake of clarity, and simplicity, only one need exist (call it whatever you like, make it a sym-link, whatever). So, regardless of what 'provider' is in use its configured in one namespace, this would avoid the litany of "I added net.wlan0, and wpa_supplicant, and dhcpcd to the runlevel" (a fairly common situation based on there being initscripts so named, and that these initscripts correspond to the 'services' the user expects to be using), or (as in this thread) various advice ("network management using dhcpcd") directed at someone who is clearly using netifrc ... because, well, that's one of the many disperate methods on offer. Further, and as alluded to above, add dhcpcd hooks (for wpa_supplicant, etc) into the mix when netifrc is being used (surely dhcpcd plays no part in configuring wpa_supplicant in the case of netifrc providing net ... but you can see why someone might think they do).

Having one mechanism that supports multiple providers (ie, all the methods currently used to 'provide net') would make use, and support, far less shambolic. 

 *UberLord wrote:*   

> You're having you're rant now, I had mine years ago :P

 

No disrespect intended but I don't think it was well thought out at that time.

best ... khay

----------

## UberLord

I don't directly support OpenRC related stuff anymore (note the retired flag)

However, OpenRC has always supported the provided keyword

dhcpcd provides net

network provides net

net.wlan0 provides net

unbound needs net

Or did I mis-understand

 *khayyam wrote:*   

> 
> 
>  *UberLord wrote:*   You're having you're rant now, I had mine years ago  
> 
> No disrespect intended but I don't think it was well thought out at that time.

 

The rant or the code?  :Smile: 

Either way, that's a just a matter of opinion I happen to disagree with.

----------

## khayyam

 *UberLord wrote:*   

> Or did I mis-understand

 

Roy ... I think so, yes. While 'provides', 'needs', etc, are good underlying mechanisms they require the user understand what they do, that understanding often isn't there, and as 'net' might be provided in various ways a unified namespace would save the confusion. So, its not simply about the available mechanisms but how they are exposed to the user.

So for example, 'net.${IFACE}', 'wpa_supplicant', or 'dhcpcd', can be used in isolation but 'net.${IFACE}' may involve the use of 'dhcpcd' and 'wpa_supplicant' ... not, however, the services under init.d as they operate in a different namespace. It's no surprise that users might be confused about that fact, or about 10-wpa_supplicant.sh, as though they may be using wpa_supplicant and dhcpcd the use of them is exposed in conflicting ways.

As we see above the OP confuses (as per the instructions in the news item) the "use of" 10-wpa_supplicant with the use of wpa_supplicant, and/or net.${IFACE}, not knowing that 10-wpa_supplicant is exclusively the domain of dhcpcd and shouldn't be used in their particular use case.

It would seem to me far less confusing if one namespace for 'net' existed, this could then be configured (ie, via a symlink, or parameter) to use the desired method. All users requiring 'net' have this in the runlevel, and the services that provide net are then only exposed via the symlink/parameter (rather than as duplicate namespaces/services under init.d).

 *UberLord wrote:*   

>  *khayyam wrote:*    *UberLord wrote:*   You're having you're rant now, I had mine years ago :P 
> 
> No disrespect intended but I don't think it was well thought out at that time. 
> 
> The rant or the code? :)

 

I'm tempted to say both ;) ... but no, what I mean to say it that there shouldn't be services that are either doing the same thing, or operate in the same namespace. So, if one service 'starts' net, there there shouldn't be a conflicting service that also does the same.

 *UberLord wrote:*   

> Either way, that's a just a matter of opinion I happen to disagree with.

 

OK, well, perhaps you had given it a lot of thought, but I don't think the existence of dual/multi namespacing is a good outcome. I'm not blaming anyone, or deriding your work.

best ... khay

----------

## UberLord

Ah, right, I see what you mean.

A lot of the design was scoped by my knowledge and experience at the time.

This has improved (I hope!) a lot over the years.

In my defence, net.eth0 has started dhcpcd before I even found Gentoo.

I coded dhcpcd so it could just be added to a runlevel because udev royally ****ed me over with changing interface names and because I couldn't find a good solution to hotplugging interfaces. Because of the latter, dhcpcd started wpa_supplicant because upstream rejected my patches to allow wpa_supplicant to hotplug itself.

Fast forward to today where I removed dhcpcd starting wpa_supplicant due to too many (and rightly so) complaints and I'm making a second attempt at getting wpa_supplicant upstream to allow hotplugging. I have a patch ready to submit, just waiting for my last round to be accepted (no reason why they shouldn't be, but upstream has been silent for a few weeks now).

So there's some history to chew on.

 *Quote:*   

> It would seem to me far less confusing if one namespace for 'net' existed, this could then be configured (ie, via a symlink, or parameter) to use the desired method. All users requiring 'net' have this in the runlevel, and the services that provide net are then only exposed via the symlink/parameter (rather than as duplicate namespaces/services under init.d).

 

One init script to rule them all.

Well, actually this is the route I ended up going down.

OpenRC supplies one network script to bring up lo which can you can modify for anything else.

You then bring other init scripts to the party - dhcpcd, wpa_supplicant, etc.

However, net.* still exists and sadly the current politik is to keep it, but then what do I care.

I retired from Gentoo dev.

----------

