# start/stop services with dhcpcd

## charles17

No luck here.  With wpa_supplicant and dhcpcd in runlevel boot the interface would not come up. I only get

```
$ su -c "/etc/init.d/dhcpcd start && /etc/init.d/wpa_supplicant start"

Password: 

dhcpcd           | * Starting DHCP Client Daemon ...                                                                                              [ ok ]

wpa_supplicant   | * Starting WPA Supplicant Daemon ...

wpa_supplicant   |Successfully initialized wpa_supplicant

wpa_supplicant   |ioctl[SIOCSIWPMKSA]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWMODE]: Invalid argument

wpa_supplicant   |ioctl[SIOCGIWRANGE]: Invalid argument

wpa_supplicant   |ioctl[SIOCGIWMODE]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWAP]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWESSID]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWENCODEEXT]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWENCODEEXT]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWENCODEEXT]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWENCODEEXT]: Invalid argument

wpa_supplicant   |ioctl[SIOCSIWPMKSA]: Invalid argument  
```

```
$ ifconfig -a

enp2s14: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        inet6 fe80::21a:4bff:fe61:9985  prefixlen 64  scopeid 0x20<link>

        ether 00:1a:4b:61:99:85  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 16  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        loop  txqueuelen 0  (Local Loopback)

        RX packets 2526  bytes 201302 (196.5 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 2526  bytes 201302 (196.5 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sit0: flags=128<NOARP>  mtu 1480

        sit  txqueuelen 0  (IPv6-in-IPv4)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp8s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        inet6 fe80::21b:77ff:feb1:c88e  prefixlen 64  scopeid 0x20<link>

        ether 00:1b:77:b1:c8:8e  txqueuelen 1000  (Ethernet)

        RX packets 13986  bytes 10451263 (9.9 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 13023  bytes 1653377 (1.5 MiB)

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

In /etc/conf.d/net I have 

```
# /etc/conf.d/net:

modules_wlp8s0="wpa_supplicant"

wpa_supplicant_wlp8s0="-Dnl80211"
```

Last edited by charles17 on Wed Sep 10, 2014 12:10 pm; edited 2 times in total

----------

## Dr.Willy

 *charles17 wrote:*   

> No luck here.  With wpa_supplicant and dhcpcd in runlevel boot the interface would not come up. I only get[code]$ su -c "/etc/init.d/dhcpcd start && /etc/init.d/wpa_supplicant start"

 

Some notes:

- I think you don't need to start wpa_supplicant manually, dhcpcd should take care of that

Try stopping both services, kill any leftover wpa_supplicant instances (should there be any) and restart just dhcpcd.

- /etc/conf.d/net is not used (or needed) by dhcpcd or wpa_supplicant

----------

## charles17

No chance.  Removed wpa_supplicant from the runlevels, but still no interface.  Even the wireless LED stays dark.  Should I recompile opnerc with USE=-netifrc?

----------

## Dr.Willy

 *charles17 wrote:*   

> Should I recompile opnerc with USE=-netifrc?

 

I have USE=-netifrc set, but I don't know if you actually have to do that.

Does wpa_supplicant start at all?

----------

## charles17

 *Dr.Willy wrote:*   

> Does wpa_supplicant start at all?

 It does not seem to start automatically. Do I need to put something more in dhcpcd.conf in order to make it start wpa_supplicant?

```
$ cat /etc/dhcpcd.conf 

# A sample configuration for dhcpcd.

# See dhcpcd.conf(5) for details.

# Configure loopback adapter here

interface lo

static ip_address=127.0.0.1/8

# Inform the DHCP server of our hostname for DDNS.

hostname

# Use the hardware address of the interface for the Client ID.

#clientid

# or

# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.

duid

# Persist interface configuration when dhcpcd exits.

persistent

# Rapid commit support.

# Safe to enable by default because it requires the equivalent option set

# on the server to actually work.

option rapid_commit

# A list of options to request from the DHCP server.

option domain_name_servers, domain_name, domain_search, host_name

option classless_static_routes

# Most distributions have NTP support.

option ntp_servers

# Respect the network MTU.

# Some interface drivers reset when changing the MTU so disabled by default.

#option interface_mtu

# A ServerID is required by RFC2131.

require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones

slaac private

# A hook script is provided to lookup the hostname if not set by the DHCP

# server, but it should not be run by default.

nohook lookup-hostname
```

----------

## UberLord

 *charles17 wrote:*   

>  *Dr.Willy wrote:*   Does wpa_supplicant start at all? It does not seem to start automatically. Do I need to put something more in dhcpcd.conf in order to make it start wpa_supplicant?

 

wpa_supplicant.conf needs to have ctrl_interface line configured like so:

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

----------

## Dr.Willy

 *charles17 wrote:*   

>  *Dr.Willy wrote:*   Does wpa_supplicant start at all? It does not seem to start automatically. Do I need to put something more in dhcpcd.conf in order to make it start wpa_supplicant?

 

No, you just need to have /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant which comes with the default installation.

What does 

```
ps -A | grep wpa
```

 say?

----------

## charles17

 *UberLord wrote:*   

> wpa_supplicant.conf needs to have ctrl_interface line configured like so:
> 
> ```
> ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
> ```
> ...

 Seems to be equivalent to what I already had in this file, except DIR 

```
$ cat /etc/wpa_supplicant/wpa_supplicant.conf 

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

# ctrl_interface=/var/run/wpa_supplicant

# ctrl_interface_group=wheel

update_config=1

network={
```

But this alone didn't make it work.  I also had to uncomment the last line in /etc/conf.d/wpa_supplicant which was not needed for the old setup.

```
# conf.d file for wpa_supplicant

#

# Please check man 8 wpa_supplicant for more information about the options

# wpa_supplicant accepts.

#

wpa_supplicant_args="-Dnl80211"
```

Finally putting wpa_supplicant again into default runlevel made it work.  At least for wireless.

 *Dr.Willy wrote:*   

> What does 
> 
> ```
> ps -A | grep wpa
> ```
> ...

 After the above mentioned changes, it seems top run well and I get

```
$ ps -A | grep wpa

 2242 ?        00:00:00 wpa_supplicant
```

My question now is, should wpa_supplicant automatically be started by dhcpcd or be in runlevel itself?

----------

## UberLord

 *charles17 wrote:*   

> My question now is, should wpa_supplicant automatically be started by dhcpcd or be in runlevel itself?

 

For a fixed interface, it won't matter.

For a hotplugged interface such as a USB stick, dhcpcd is generally better.

----------

## charles17

 *Dr.Willy wrote:*   

> No, you just need to have /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant which comes with the default installation.

 Somehow it seems to not be triggered.  How could I make sure it works? If possible I'd like to go without having wpa_supplicant in the runlevel.

----------

## UberLord

Edit /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant and add set -x to the top of the file.

Then kill dhcpcd and run it in a console like so

dhcpcd -dB

Copy n paste the output here. That should be enough information to debug.

----------

## charles17

 *UberLord wrote:*   

> dhcpcd -dB

 Here is the output, too much for pasting here, sorry.

----------

## UberLord

```
dhcpcd[3079]: wlp8s0: executing `/lib/dhcpcd/dhcpcd-run-hooks' PREINIT

++ '[' -z '' ']'

++ for x in '/etc/wpa_supplicant/wpa_supplicant-"$interface".conf' /etc/wpa_supplicant/wpa_supplicant.conf '/etc/wpa_supplicant-"$interface".conf' /etc/wpa_supplicant.conf

++ '[' -s /etc/wpa_supplicant/wpa_supplicant-wlp8s0.conf ']'

++ for x in '/etc/wpa_supplicant/wpa_supplicant-"$interface".conf' /etc/wpa_supplicant/wpa_supplicant.conf '/etc/wpa_supplicant-"$interface".conf' /etc/wpa_supplicant.conf

++ '[' -s /etc/wpa_supplicant/wpa_supplicant.conf ']'

++ wpa_supplicant_conf=/etc/wpa_supplicant/wpa_supplicant.conf

++ break

++ : /etc/wpa_supplicant/wpa_supplicant.conf

++ '[' 0 = 1 ']'
```

The last line shows that dhcpcd doesn't think this is a wireless interface.

Here's the code that dhcpcd uses to work it out on Linux : link

Maybe a driver bug?

----------

## charles17

I am too far from understanding the program code in link.  

Could you guide me how to check about a possible driver bug?  What informations do you need?

----------

## UberLord

Well, basically the error condition is that when dhcpcd queries the assigned SSID an error is reported where there should not be one.

Can you post the output of iwconfig?

----------

## charles17

Everything "no wireless extensions."

```
$ /sbin/iwconfig

wlp8s0    no wireless extensions.

lo        no wireless extensions.

sit0      no wireless extensions.

enp2s14   no wireless extensions.
```

----------

## xaviermiller

Take a look at dmesg: is the wireless interface well initialized? does it need a missing firmware? is the rfkill switch OK?

----------

## UberLord

 *charles17 wrote:*   

> Everything "no wireless extensions."
> 
> ```
> $ /sbin/iwconfig
> 
> ...

 

That is why  :Smile: 

Solve this problem (no idea how sorry, XavierMiller's solution seems good) and it should start working.

----------

## charles17

 *XavierMiller wrote:*   

> Take a look at dmesg: is the wireless interface well initialized? does it need a missing firmware? is the rfkill switch OK?

 

From dmesg and lspci I cannot find anything missing.

```
08:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

   Subsystem: Hewlett-Packard Company PRO/Wireless 3945ABG [Golan] Network Connection

   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

   Latency: 0, Cache Line Size: 64 bytes

   Interrupt: pin A routed to IRQ 16

   Region 0: Memory at e8000000 (32-bit, non-prefetchable) [size=4K]

   Capabilities: [c8] Power Management version 2

      Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)

      Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

   Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+

      Address: 0000000000000000  Data: 0000

   Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00

      DevCap:   MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited

         ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-

      DevCtl:   Report errors: Correctable- Non-Fatal- Fatal- Unsupported-

         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+

         MaxPayload 128 bytes, MaxReadReq 128 bytes

      DevSta:   CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-

      LnkCap:   Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us

         ClockPM+ Surprise- LLActRep- BwNot-

      LnkCtl:   ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+

         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

      LnkSta:   Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

   Kernel driver in use: iwl3945

   Kernel modules: iwl3945

```

rfkill is ok, I can start /etc/init.d/wpa_supplicant manually without problems.

----------

## xaviermiller

which version of dhcpcd do you have ? wpa support is starting from version 6.

----------

## UberLord

 *XavierMiller wrote:*   

> which version of dhcpcd do you have ? wpa support is starting from version 6.

 

Irrelevant. If iwconfig won't work, neither will dhcpcd. dhcpcd detected SSID and set the ifwireless flag in version 4.

Have you compiled your kernel with wireless extensions? http://wiki.gentoo.org/wiki/Wifi

----------

## charles17

```
$ emerge -pqv dhcpcd

[ebuild   R   ] net-misc/dhcpcd-6.4.3  USE="ipv6 udev" 
```

```
$ emerge -pqv wpa_supplicant

[ebuild   R   ] net-wireless/wpa_supplicant-2.0-r2  USE="qt4 readline ssl wps -ap -dbus -eap-sim -fasteap -gnutls -p2p (-ps3) (-selinux) -smartcard -wimax" 
```

----------

## charles17

 *UberLord wrote:*   

> Have you compiled your kernel with wireless extensions? http://wiki.gentoo.org/wiki/Wifi

 I had not, but after recompiling the kernel with CONFIG_CFG80211_WEXT=y it finally works.

May I propose this should be mentioned at the beginning of this guide because the old setup using net-misc/netifrc does not need wext compatibility.

----------

## xaviermiller

discussion moved from TIP: Complete network stack without net.* scripts

----------

## charles17

Thanks to everybody helping me to make it work

----------

## UberLord

 *charles17 wrote:*   

>  *UberLord wrote:*   Have you compiled your kernel with wireless extensions? http://wiki.gentoo.org/wiki/Wifi I had not, but after recompiling the kernel with CONFIG_CFG80211_WEXT=y it finally works.
> 
> May I propose this should be mentioned at the beginning of this guide because the old setup using net-misc/netifrc does not need wext compatibility.

 

The latest dhcpcd in my Fossil repository no longer needs CONFIG_CFG80211_WEXT=y set in the kernel.

Testers welcome before the next release  :Smile: 

----------

## charles17

 *UberLord wrote:*   

> The latest dhcpcd in my Fossil repository ...

 

was compiling well but could no longer be started during and after next reboot  :Sad:  

```
dhcpcd           | * Starting DHCP Client Daemon ...

dhcpcd           | * start-stop-daemon: failed to start `/sbin/dhcpcd'

dhcpcd           | * Failed to start dhcpcd

dhcpcd           | * ERROR: dhcpcd failed to start
```

So for the moment I had to go back to 6.4.3  :Sad: 

----------

## UberLord

Can you re-try emerging dhcpcd-9999 please? And post the full compile output as well please.

----------

## charles17

Done, pls see pastebin.

----------

## UberLord

Can I ask you to run it under valgrind quickly if it still fails? It might catch a memory error

sudo valgrind dhcpcd -dB

----------

## charles17

```
==1520== Memcheck, a memory error detector

==1520== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.

==1520== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info

==1520== Command: dhcpcd -dB

==1520== 

valgrind:  Fatal error at startup: a function redirection

valgrind:  which is mandatory for this platform-tool combination

valgrind:  cannot be set up.  Details of the redirection are:

valgrind:  

valgrind:  A must-be-redirected function

valgrind:  whose name matches the pattern:      strlen

valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2

valgrind:  was not found whilst processing

valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2

valgrind:  

valgrind:  Possible fixes: (1, short term): install glibc's debuginfo

valgrind:  package on this machine.  (2, longer term): ask the packagers

valgrind:  for your Linux distribution to please in future ship a non-

valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)

valgrind:  that exports the above-named function using the standard

valgrind:  calling conventions for this platform.  The package you need

valgrind:  to install for fix (1) is called

valgrind:  

valgrind:    On Debian, Ubuntu:                 libc6-dbg

valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo

valgrind:  

valgrind:  Cannot continue -- exiting now.  Sorry.
```

 :Sad:  So what would I need to install?

----------

## UberLord

Put this in /etc/portage/package.env

```
sys-libs/glibc  debug.conf
```

And this in /etc/portage/env/debug.conf

```
FLAGS="${CFLAGS} -ggdb"

CXXFLAGS="${CXXFLAGS} -ggdb"

FEATURES="splitdebug"

```

And emerge glibc

----------

## charles17

 *UberLord wrote:*   

> sudo valgrind dhcpcd -dB

 The output is in pastebin.

HTH.

----------

## UberLord

Hmmm, I need more, sorry

Put this in /etc/portage/package.env

```
net-misc/dhcpcd  debug.conf
```

Re-emerge dhcpcd re-test under valgrind please, hopefully there will be more debug to play with  :Smile: 

----------

## charles17

 *UberLord wrote:*   

> Re-emerge dhcpcd re-test under valgrind please, hopefully there will be more debug to play with 

 Next pastebin but not very much different  :Sad: 

----------

## UberLord

It's perfect as it shows where in dhcpcd it's failing.

I'll see if I can fix this promptly.

----------

## UberLord

Fixed here hopefully:

http://roy.marples.name/projects/dhcpcd/ci/b9e8ea02f33c44e83927d09fd24b014c7c8f0334?sbs=0

Let me know!

----------

## charles17

 *UberLord wrote:*   

> Fixed here hopefully:
> 
> http://roy.marples.name/projects/dhcpcd/ci/b9e8ea02f33c44e83927d09fd24b014c7c8f0334?sbs=0

 

Almost. Startup works but dhcpcd stays "inactive", does not turn "started".  

Again some valgrinded output.

----------

## UberLord

Fixed here:

http://roy.marples.name/projects/dhcpcd/ci/cf0c457f5ea7b3c06789f18ea903f4ebcca77c14?sbs=0

Basically the absence of the SSID attribute just means that the interface is not associated - it's not an error, but I was treating it as such.

Hopefully you're all up and running now  :Smile:  Let me know!

----------

## charles17

 *UberLord wrote:*   

> Hopefully you're all up and running now  Let me know!

 Yes, this time it works, comes up at boot and correctly starts/stops fetchmail.

I will do some more tests for ntpd (net-misc/ntp) later.

EDIT

Regarding ntpd the problem remains as described in bug #52206, regardless if I set rc_ntpd_need="dhcpcd" or  or rc_need="net" * wrote:*   

> # /etc/conf.d/ntpd
> 
> # Options to pass to the ntpd process
> 
> # Most people should leave this line alone ...
> ...

 It simply changes its process id and continues running, sometimes even with 2 process ids.

----------

## UberLord

 *charles17 wrote:*   

>  *UberLord wrote:*   Hopefully you're all up and running now  Let me know! Yes, this time it works, comes up at boot and correctly starts/stops fetchmail.
> 
> I will do some more tests for ntpd (net-misc/ntp) later.
> 
> 

 

 :Smile: 

So dhcpcd now supports nl80211 correctly.

 *Quote:*   

> 
> 
> EDIT
> 
> Regarding ntpd the problem remains as described in bug #52206, regardless if I set rc_ntpd_need="dhcpcd" or  or rc_need="net" * wrote:*   # /etc/conf.d/ntpd
> ...

 

To be clear to our readers, this is a different issue  :Smile: 

I actually added the need in a different way. I'll test my recommended way and I'll get back.

----------

## UberLord

This works fine for me.

Can you post the output of /etc/init.d/ntpd ineed?

----------

## charles17

 *UberLord wrote:*   

>  *charles17 wrote:*    *UberLord wrote:*   Hopefully you're all up and running now  Let me know! Yes, this time it works, comes up at boot and correctly starts/stops fetchmail.
> 
> I will do some more tests for ntpd (net-misc/ntp) later.
> 
>  
> ...

 

Wanted to test this after recompiling my kernel without WEXT.  But cannot get it to work anymore, not even dhcpcd-6.4.3.  Turns out that somehow I've lost my /etc/conf.d/dhcpcd. 

Could you please post me that file?  Why isn't it in portage?Last edited by charles17 on Thu Sep 11, 2014 7:03 pm; edited 1 time in total

----------

## UberLord

Eh? dhcpcd doesn't ship /etc/conf.d/dhcpcd - all the config is in /etc/dhcpcd.conf which is shipped.

----------

## charles17

Sorry for confusion.  I am now on 9999 and kernel has WEXT disabled. Wired connection works fine stopping and restarting the services but wireless doesn't work at all. 

When unplugging the cable, dhcpcd turns and stays [inactive] even though "ps -A | grep wpa" shows that wpa_supplicant is running.

EDIT

My dhcpcd.conf is default without changes.  Anything to adjust here?

----------

## UberLord

I've extensively tested this and made the following change:

http://roy.marples.name/projects/dhcpcd/ci/1cd31e40f9d880fa59cebb5d298eaeb3662b9b46?sbs=0

On my dual interface Gentoo box, simulated by issuing "ifconfig eth0 down" rather than pulling cables or unplugging the AP.

wired up, wireless up == all started

wired up, wireless down == all started

wired down, wireless down == dhcpcd inactive and net dependant services scheduled

wired down, wireless up == all started

wired down, wireless down == dhcpcd inactive and net dependant services scheduled

wired up, wireless down == all started

wired up, wireless up == all started

Please note that wpa_supplicant will remain running at all times so it can attempt to bring the wireless interface back up by associating with an AP.

dhcpcd will never stop it.

Does this match what you see?

----------

## charles17

No, it's another problem. 

```
$ su -c "ifconfig wlp8s0 up"

Password: 

SIOCSIFFLAGS: Operation not possible due to RF-kill

$ /usr/sbin/rfkill list

0: phy0: Wireless LAN

        Soft blocked: no

        Hard blocked: yes

```

And the button stopped working.  I have to check what's wrong here.

----------

## UberLord

Well the software thinks the hardware off button on your wireless is on..

If it's off, well good luck fixing it!

For the time being I'll consider your dhcpcd issue solved until I hear back  :Smile: 

----------

## charles17

 *UberLord wrote:*   

> For the time being I'll consider your dhcpcd issue solved until I hear back 

 Thanks for all your help and for investing your time!!

----------

## charles17

 *UberLord wrote:*   

> 
> 
> So dhcpcd now supports nl80211 correctly.

 

Sorry to say, no.  I've got my rfkill issues solved and did several tests, without WEXT and with. 

With WEXT enabled everything works perfectly.  Dependant services are stopped when wireless is rfkilled or when the access point goes down, and they get restarted when connection is back. Wireless interface goes down when eth0 is plugged and comes up again when unplugged.

With WEXT disabled in the kernel, the wireless interface (according to "ifconfig -a") is up when unplugged and not rfkilled and wpa_gui shows the interface but does not connect.  In "rc-config show" dhcpcd remains "[inactive]".

I'm looking forward to your next release in portage, regardless if needs wext or not.

----------

## charles17

Another valgrind -v dhcpcd -dB with wext disabled.

The interface seems to be up but dhcpcd will not get started *Quote:*   

> $ ifconfig -v wlp8s0
> 
> wlp8s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
> 
>         ether xxxxxxxxxx  txqueuelen 1000  (Ethernet)
> ...

 

----------

## UberLord

UP means the admin (you) or an administrative program (dhcpcd) has marked the interface as UP.

If the RUNNING flag is there too then it can be used, otherwise there is a problem with the link such as no carrier.

Check the status of wpa_supplicant like so

```
wpa_cli status
```

----------

## charles17

 *Quote:*   

> $ wpa_cli status
> 
> Selected interface 'wlp8s0'
> 
> wpa_state=DISCONNECTED
> ...

 

----------

## UberLord

There we go, you need to fix wpa_supplicant connecting.

dhcpcd cannot do this for you  :Smile: 

----------

## charles17

Thanks for advice.  How could I analyse in order to get a useful error message?

wpa_supplicant is compiled like: *Quote:*   

>  * Found these USE flags for net-wireless/wpa_supplicant-2.0-r2:
> 
>  U I
> 
>  - - ap        : Add support for access point mode
> ...

 

----------

## UberLord

Run wpa_cli in a terminal to see why it's not connecting.

My guess is the wpa_supplicant.conf isn't configured correctly - maybe an invalid key.

----------

## charles17

Continied in the new topic wpa_supplicant trouble.

----------

## charles17

 *charles17 wrote:*   

> No, it's another problem. 
> 
> ```
> $ su -c "ifconfig wlp8s0 up"
> 
> ...

 Simple reason, worth to notice.  This laptop (Compaq nc 6320) has a physical rfkill button with blue LED, but also it receives "Hard blocked: yes" when the ethernet is plugged.

----------

