| View previous topic :: View next topic |
| Author |
Message |
lovelytux
Tux's lil' helper
Joined: 23 Aug 2013
Posts: 108
|
 Posted: Fri Jan 29, 2016 1:02 pm Post subject: [Solved] Problem with wpa_supplicant. Or is it dhcp? |
 |
|
Hey,
the Hardware is
| Code: | | 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
| Code: | 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 | Code: |
/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 | Code: | cp /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks
|
| Code: | | /etc/init.d/dhcpcd start |
| Code: | 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
|
| Code: | 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 |
| Code: | 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!
lovelytux
Last edited by lovelytux on Fri Jan 29, 2016 9:35 pm; edited 1 time in total |
|
| Back to top |
|
 |
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3685
|
| Posted: Fri Jan 29, 2016 2:33 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
lovelytux
Tux's lil' helper
Joined: 23 Aug 2013
Posts: 108
|
| Posted: Fri Jan 29, 2016 2:50 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Jan 29, 2016 4:17 pm Post subject: |
|
|
| 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?
| Code: | | # 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 |
|
| Back to top |
|
|
lovelytux
Tux's lil' helper
Joined: 23 Aug 2013
Posts: 108
|
| Posted: Fri Jan 29, 2016 7:18 pm Post subject: |
|
|
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 | Code: | | emerge -C net-misc/netifrc |
and add dhcpcd to runlevel at boot. wlan0 comes up. Unfortunately no answer to ip adress, from gentoo server: | Code: | 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 ....
| Code: |
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 |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54850
Location: 56N 3W
|
| Posted: Fri Jan 29, 2016 7:38 pm Post subject: |
|
|
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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
lovelytux
Tux's lil' helper
Joined: 23 Aug 2013
Posts: 108
|
| Posted: Fri Jan 29, 2016 7:55 pm Post subject: |
|
|
Hey,
here ist dmesg.txt
regard
lovelytux |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54850
Location: 56N 3W
|
| Posted: Fri Jan 29, 2016 8:14 pm Post subject: |
|
|
lovelytux,
This is a bad sign.
| Code: | | [ 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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
lovelytux
Tux's lil' helper
Joined: 23 Aug 2013
Posts: 108
|
| Posted: Fri Jan 29, 2016 9:34 pm Post subject: |
|
|
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!
Regard
lovelytux |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Jan 29, 2016 9:44 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Fri Jan 29, 2016 11:44 pm Post subject: |
|
|
| 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 
You're having you're rant now, I had mine years ago 
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jan 30, 2016 8:58 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Mon Feb 01, 2016 11:20 pm Post subject: |
|
|
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?
Either way, that's a just a matter of opinion I happen to disagree with.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Feb 02, 2016 10:13 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Tue Feb 02, 2016 4:59 pm Post subject: |
|
|
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.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
