# [(not) solved] netifrc configuration per essid not updating

## needMoreFirmware

Hello, I'm trying to setup ifnetrc to connect with three APs, two of them should have a static configuration, and one of them will use dhcp. This seemed to indicate it was possible, this works the first time I bring the interface up, however, whenever I change from one AP to another (manually, through wpa_cli, usually with select_network) my configuation doesn't update, e.g. if I had a static configuration it will stay that static configuration, and if I was using dhcp it will stay dhcp. I am guessing this might have something to do with me connecting and disconnecting from APs manually through wpa_cli, which is what I used to do on Debian and it worked, perhaps I have misunderstood and netifrc does not do this?.

My /etc/conf.d/net looks something like this:

```
modules="wpa_supplicant"

config_harry="192.168.1.123/24"

routes_harry="default via 192.168.1.1"

dns_servers_harry="8.8.8.8"

config_some_ap="192.168.1.231/24"

routes_some_ap="default via 192.168.1.1"

dns_servers_some_ap="8.8.8.8"

config_haruhi="dhcp"
```

Last edited by needMoreFirmware on Sun Apr 01, 2018 12:35 am; edited 2 times in total

----------

## UberLord

You need to use something else as well to tell netifrc that it's associated with a new AP. Use either ifplugd or netplug.

OR, if you use dhcpcd for your DHCP, stop using netifrc and configure the static addresses per ssid in dhcpcd.conf like so

```
profile harry

    static ip_address=192.168.1.123/24

    static routers=192.168.1.1

    static domain_name_servers=8.8.8.8

profile some_ap

    static ip_address=192.168.1.231/24

    static routers=192.168.1.1

    static domain_name_servers=8.8.8.8

```

If no profile is found for the AP, then the default of "do DHCP" will be used.

----------

## needMoreFirmware

 *UberLord wrote:*   

> You need to use something else as well to tell netifrc that it's associated with a new AP. Use either ifplugd or netplug.

 

Thought it'd be something like that, I guess I'll use dhcpcd. Thanks.

----------

## khayyam

 *UberLord wrote:*   

> You need to use something else as well to tell netifrc that it's associated with a new AP. Use either ifplugd or netplug.

 

UberLord, needMoreFirmware, et al ... I'm not sure that is necessary as /etc/wpa_supplicant/wpa_cli.sh is run when CONNECTED/DISCONNECTED and so /etc/init.d/net.${INTERFACE} is started/stoped. That said I'm really unsure of what is causing it not to re-read /etc/conf.d/net and so select the correct settings for essid.

best ... khay

EDIT: corrected s/sure/unsure/Last edited by khayyam on Sat Mar 31, 2018 10:30 am; edited 1 time in total

----------

## UberLord

Awww man.

I am getting so out of touch with Gentoo :/

----------

## needMoreFirmware

 *khayyam wrote:*   

>  *UberLord wrote:*   You need to use something else as well to tell netifrc that it's associated with a new AP. Use either ifplugd or netplug. 
> 
> UberLord, needMoreFirmware, et al ... I'm not sure that is necessary as /etc/wpa_supplicant/wpa_cli.sh is run when CONNECTED/DISCONNECTED and so /etc/init.d/net.${INTERFACE} is started/stoped. That said I'm really unsure of what is causing it not to re-read /etc/conf.d/net and so select the correct settings for essid.
> 
> best ... khay
> ...

 

huh, speaking of, I have set a very basic /etc/dhcpcd.conf:

```

# A sample configuration for dhcpcd.

# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.

#controlgroup wheel

# 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.

# Some non-RFC compliant DHCP servers do not reply with this set.

# In this case, comment out duid and enable clientid above.

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

# Respect the network MTU. This is applied to DHCP routes.

option interface_mtu

# Most distributions have NTP support.

#option ntp_servers

# A ServerID is required by RFC2131.

require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface

#slaac hwaddr

# OR generate Stable Private IPv6 Addresses based from the DUID

slaac private

interface wlp3s0

profile 12:34:56:78:9a:bc

static ip_address=123.456.7.89/24

static routers=123.456.7.1

static domain_name_servers=1.2.3.4

```

And guess what, It still doesn't work!, now as far as I'm aware there is no reason for this config not to work, but it could be a rookie mistake, or perhaps it's something related to wpa_supplicant?

```

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

update_config=1

```

that's my current config, the rest are just the settings for my networks, don't think it has much to do with this issue tho.

Do you think this could somehow have something to do wth my kernel options?, I have noticed I'm getting this when I stop my net service.

```
 * Bringing down interface wlp3s0

 *   Stopping dhcpcd on wlp3s0 ...sending signal TERM to pid 13271

waiting for pid 13271 to exit

 [ ok ]

 *   Stopping wpa_cli on wlp3s0 ... [ ok ]

 *   Stopping wpa_supplicant on wlp3s0 ... [ ok ]

RTNETLINK answers: No such file or directory

Error talking to the kernel

```

----------

## khayyam

 *needMoreFirmware wrote:*   

> 
> 
> ```
> RTNETLINK answers: No such file or directory
> ```
> ...

 

needMoreFirmware ... are you doing some traffic shaping on that interface?

best ... khay

----------

## needMoreFirmware

 *khayyam wrote:*   

>  *needMoreFirmware wrote:*   
> 
> ```
> RTNETLINK answers: No such file or directory
> ```
> ...

 

Not sure what that means, but the answer is probably no.

----------

## khayyam

 *needMoreFirmware wrote:*   

>  *khayyam wrote:*    ... are you doing some traffic shaping on that interface? 
> 
> Not sure what that means, but the answer is probably no.

 

needMoreFirmware ... QoS (quality of service) and such, but ok.

On a closer look you seem to have net.wlp3s0 and dhcpcd in the runlevel, and so when the later comes to stop the interface it has been already been brought down (hence " No such file or directory"). The instruction from UberLord is to "stop using netifrc" and let dhcpcd manage the interfaces exclusively ... and by the above output that doesn't seem to be the case (as dhcpcd is stopped when "bringing down [the] interface").

best ... khay

----------

## needMoreFirmware

 *khayyam wrote:*   

>  *needMoreFirmware wrote:*    *khayyam wrote:*    ... are you doing some traffic shaping on that interface? 
> 
> Not sure what that means, but the answer is probably no. 
> 
> needMoreFirmware ... QoS (quality of service) and such, but ok.
> ...

 

I didn't mix up the wpa_supplicant/dhcpcd services with my net service, this has nothing to do with that.

----------

## khayyam

 *needMoreFirmware wrote:*   

> I didn't mix up the wpa_supplicant/dhcpcd services with my net service, this has nothing to do with that.

 

needMoreFirmware ... I admit I'm not using dhcpcd in such a configuration so I'm just working from what I know, but from the above output I have to ask where openrc is getting "wlp3s0" ("Bringing down interface wlp3s0"). I'm fairly sure this won't be passed from dhcpcd (and /etc/dhcpcd.conf is the only place it'd be defined). Also, as you say "wpa_supplicant/dhcpcd services", you're also starting wpa_supplicant in the runlevel and not using 10-wpa_supplicant.conf (so that dhcpcd also manages this)?

best ... khay

----------

## needMoreFirmware

 *khayyam wrote:*   

> 
> 
> needMoreFirmware ... I admit I'm not using dhcpcd in such a configuration so I'm just working from what I know, but from the above output I have to ask where openrc is getting "wlp3s0" ("Bringing down interface wlp3s0").
> 
> 

 

As far as I'm aware it figures it out from the service name net.wlp3s0, which is a symlink to /etc/init.d/net. EDIT: To clear it up, I'm speaking of the net.wlp3s0 service, the ouput I posted was from my net.wlp3s0 service.

 *khayyam wrote:*   

> 
> 
> Also, as you say "wpa_supplicant/dhcpcd services", you're also starting wpa_supplicant in the runlevel and not using 10-wpa_supplicant.conf (so that dhcpcd also manages this)?
> 
> 

 

I'm not sure what you mean here, yes I'm using both wpa_supplicant and dhcpcd services at the same time (when not using net service), and I don't know what 10-wpa_supplicant.conf is.

----------

## khayyam

 *needMoreFirmware wrote:*   

>  *khayyam wrote:*   [...] from the above output I have to ask where openrc is getting "wlp3s0" ("Bringing down interface wlp3s0"). 
> 
> As far as I'm aware it figures it out from the service name net.wlp3s0, which is a symlink to /etc/init.d/net.

 

needMoreFirmware ... no, because you've already stated net.wlp3s0 isn't in the runlevel. I don't see what comes before but my guess its wpa_supplicant. So, what I assume is happening is that the wpa_supplicant service is stopped and kills dhcpcd, but as dhcpcd is actually managing the interface it does what it is configured to do (bring the interface down) before exiting, subsequently wpa_cli/wpa_supplicant wonders what happend to the interface.

As I said, I don't use dhcpcd this way, but I would expect it to do the right thing if it's similarly in control of starting/stopping wpa_supplicant.

 *needMoreFirmware wrote:*   

>  *khayyam wrote:*   Also, as you say "wpa_supplicant/dhcpcd services", you're also starting wpa_supplicant in the runlevel and not using 10-wpa_supplicant.conf (so that dhcpcd also manages this)? 
> 
> I'm not sure what you mean here, yes I'm using both wpa_supplicant and dhcpcd services at the same time (when not using net service), and I don't know what 10-wpa_supplicant.conf is.

 

I mean that dhcpcd can be configured to start wpa_supplicant (with the use of 10-wpa_supplicant), to do this you would copy /usr/share/dhcpcd/hooks/10-wpa_supplicant to /lib/dhcpcd/dhcpcd-hooks/ and remove wpa_supplicant from the runlevel.

HTH & best ... khay

----------

## khayyam

 *needMoreFirmware wrote:*   

> EDIT: To clear it up, I'm speaking of the net.wlp3s0 service, the ouput I posted was from my net.wlp3s0 service.

 

needMoreFirmware ... and I went by the output you provided, hence my asking where openrc would get 'wlp3s0' if you were using dhcpcd as UberLord instructed (and "not using netifrc"). This is getting to be an exercise in mind reading ...

best ... khay

----------

## needMoreFirmware

Sigh, let's see if we can get this straight.

 *khayyam wrote:*   

>  *needMoreFirmware wrote:*    *khayyam wrote:*   [...] from the above output I have to ask where openrc is getting "wlp3s0" ("Bringing down interface wlp3s0"). 
> 
> As far as I'm aware it figures it out from the service name net.wlp3s0, which is a symlink to /etc/init.d/net. 
> 
> needMoreFirmware ... no, because you've already stated net.wlp3s0 isn't in the runlevel.

 

No, because I was refering to my net (net.wlp3s0) service, which is why I said

 *needMoreFirmware wrote:*   

>  I have noticed I'm getting this when I stop my net service. 

 

The rest of that post was indeed refering to me trying the dhcpcd + wpa_supplicant approach.

 *khayyam wrote:*   

> 
> 
> I mean that dhcpcd can be configured to start wpa_supplicant (with the use of 10-wpa_supplicant), to do this you would copy /usr/share/dhcpcd/hooks/10-wpa_supplicant to /lib/dhcpcd/dhcpcd-hooks/ and remove wpa_supplicant from the runlevel.

 

I didn't know this, I was just starting both the wpa_supplicant and dhcpcd services individually, as instructed here: https://wiki.gentoo.org/wiki/Network_management_using_DHCPCD#Wireless, I will try it soon and see if that works.

----------

## khayyam

 *needMoreFirmware wrote:*   

> No, because I was refering to my net (net.wlp3s0) service, which is why I said "I have noticed I'm getting this when I stop my net service." The rest of that post was indeed refering to me trying the dhcpcd + wpa_supplicant approach.

 

needMoreFirmware ... hence the confusion, and my thinking you have both dhcpcd and net.wlp3s0 in the runlevel. If you're following UberLord's instructions then there should be no "my net service". 

Something else to consider is that the 'interface wlp3s0' configuration in /etc/dhcpcd.conf will also be applied when 'net.wlp3s0' is started, which may cause a similar conflict in interface management I allude to above.

best ... khay

----------

## needMoreFirmware

 *khayyam wrote:*   

> needMoreFirmware ... hence the confusion, and my thinking you have both dhcpcd and net.wlp3s0 in the runlevel. If you're following UberLord's instructions then there should be no "my net service". 

 

You pointed out that even the net.* service should already be working, and since neither the net.* approach nor the dhcpcd approach were working I took a more general approach and tried both methods for the sake of troubleshooting, but lets move on from that.

 *khayyam wrote:*   

> 
> 
> Something else to consider is that the 'interface wlp3s0' configuration in /etc/dhcpcd.conf will also be applied when 'net.wlp3s0' is started, which may cause a similar conflict in interface management I allude to above.

 

That's not the case, as this has happened before mofyfing my dhcpcd.conf

Now, I have just tried using 10-wpa_supplicant as you suggested, dhcpcd properly starts wpa_supplicant, but the same issue still persists, and there is no wpa_supplicant/net.wlp3s0 service enabled/running, let's just get that out of the way.

----------

## khayyam

 *khayyam wrote:*   

> needMoreFirmware ... hence the confusion, and my thinking you have both dhcpcd and net.wlp3s0 in the runlevel. If you're following UberLord's instructions then there should be no "my net service".

 

 *needMoreFirmware wrote:*   

> You pointed out that even the net.* service should already be working, and since neither the net.* approach nor the dhcpcd approach were working I took a more general approach and tried both methods for the sake of troubleshooting, but lets move on from that.

 

needMoreFirmware ... well, I was unsure why conf.d/net wouldn't get re-parsed when wpa_cli.sh recieves DISCONNECTED/CONNECTED, and the specific config for essid applied. Now I think about it it's due to the fact that DISCONNECTED doesn't actually do anything, and CONNECTED will only 'start' the service, which has no effect on a service already started. So, this setup won't work using the basic net.{interface} mechanism ... you would need to use net.{interface}.{runlevel} and then switch runlevels via 'rc' ... if you wanted to take that route.

 *khayyam wrote:*   

> Something else to consider is that the 'interface wlp3s0' configuration in /etc/dhcpcd.conf will also be applied when 'net.wlp3s0' is started, which may cause a similar conflict in interface management I allude to above.

 

 *needMoreFirmware wrote:*   

> That's not the case, as this has happened before mofyfing my dhcpcd.conf

 

You might have made that clear from the outset, because it seemed the error was the result of the config, and not a pre-existing condition. Anyhow, the error generally occurs when something is modifying (or, managing) the interface when something else has done something to make that task impossible (such as bringing the interface down). So, this pre-exists any change to conf.d/net or dhcpcd.conf? 

 *needMoreFirmware wrote:*   

> Now, I have just tried using 10-wpa_supplicant as you suggested, dhcpcd properly starts wpa_supplicant, but the same issue still persists, [...].

 

By "the same issue" you mean the "[n]o such file or directory" error, or that the dhcpcd.conf isn't applied?

 *needMoreFirmware wrote:*   

> [...]and there is no wpa_supplicant/net.wlp3s0 service enabled/running, let's just get that out of the way.

 

To be sure can I see the output of 'rc-status default' (or whatever runlevel these happen to be in).

best ... khay

----------

## needMoreFirmware

 *khayyam wrote:*   

> So, this pre-exists any change to conf.d/net or dhcpcd.conf? 

 

both.

 *khayyam wrote:*   

> By "the same issue" you mean the "[n]o such file or directory" error, or that the dhcpcd.conf isn't applied?

 

the later.

 *khayyam wrote:*   

> To be sure can I see the output of 'rc-status default' (or whatever runlevel these happen to be in).

 

```
Runlevel: default

 sysklogd                                                          [  started  ]

 iptables                                                          [  started  ]

 dhcpcd                                                            [  started  ]

 consolekit                                                        [  started  ]

 local                                                             [  started  ]

```

----------

## khayyam

 *needMoreFirmware wrote:*   

>  *khayyam wrote:*   So, this pre-exists any change to conf.d/net or dhcpcd.conf?  
> 
> both.

 

needMoreFirmware ... ok, in which case is RFKILL enabled in the kernel? ... on second thoughts, pastebin the entire .config.

 *needMoreFirmware wrote:*   

>  *khayyam wrote:*   By "the same issue" you mean the "[n]o such file or directory" error, or that the dhcpcd.conf isn't applied? 
> 
> the later.

 

If you run 'dhcpcd -n wlp3s0' is the configuration then applied, also can we see your current dhcpcd.conf sans comments: egrep '^[^#]' /etc/dhcpcd.conf

 *needMoreFirmware wrote:*   

> 
> 
> ```
> Runlevel: default
> 
> ...

 

ok, and there is nothing in the iptables ruleset that might prevent dhcp traffic to the gateway ... are you doing both ingress/egress filtering perhaps?

best ... khay

----------

## needMoreFirmware

 *khayyam wrote:*   

> 
> 
> needMoreFirmware ... ok, in which case is RFKILL enabled in the kernel? ... on second thoughts, pastebin the entire .config.

 

http://0x0.st/sM2G.txt

 *khayyam wrote:*   

> 
> 
> If you run 'dhcpcd -n wlp3s0' is the configuration then applied, also can we see your current dhcpcd.conf sans comments: egrep '^[^#]' /etc/dhcpcd.conf
> 
> 

 

Nope, same thing.

```

hostname CoplandOS

duid

persistent

option rapid_commit

option domain_name_servers, domain_name, domain_search, host_name

option classless_static_routes

option interface_mtu

require dhcp_server_identifier

slaac private

interface wlp3s0

profile 74:ea:3a:e4:66:f6

static ip_address=192.168.1.21/24

static routers=192.168.1.1

static domain_name_servers=8.8.8.8

```

I hope the problem lies there

 *khayyam wrote:*   

> 
> 
> ok, and there is nothing in the iptables ruleset that might prevent dhcp traffic to the gateway ... are you doing both ingress/egress filtering perhaps?
> 
> 

 

I'm not, but to get it out of the way, the problem persists even after clearing out all of my rules (iptables -F && iptables -X).

----------

## skellr

 *UberLord wrote:*   

> Awww man.
> 
> I am getting so out of touch with Gentoo :/

 

The punishment for that is 20 lashes...

As a Gentoo Dev in a past life, you are allowed to choose between Yuri or Brunhilda to deliver the punishment.

----------

## khayyam

 *needMoreFirmware wrote:*   

> http://0x0.st/sM2G.txt

 

needMoreFirmware ... I think the issue is you have CONFIG_FIRMWARE_IN_KERNEL=y but no CONFIG_EXTRA_FIRMWARE. So what happens is there is a call (via netlink) for that firmware but there is no firmware where it expects (in kernel) and so "No such file or directory". This may cause the rtl8188ee driver to load without firmware (even when it exists in /lib/firmware) and so effect networking. I don't build firmware in kernel, so that is something of a guess ... though it does account for both the error, and the issues with networking. You can either disable this, or add the rtl8188ee firmware to CONFIG_EXTRA_FIRMWARE.

I don't see any obvious issues with the dhcpcd.conf, or elsewhere, so it is probably the above, please test.

HTH & best ... khay

----------

## needMoreFirmware

 *khayyam wrote:*   

>  *needMoreFirmware wrote:*   http://0x0.st/sM2G.txt 
> 
> You can either disable this, or add the rtl8188ee firmware to CONFIG_EXTRA_FIRMWARE.
> 
> 

 

I've done the former, the problem persists.

----------

## khayyam

 *needMoreFirmware wrote:*   

>  *khayyam wrote:*   You can either disable this, or add the rtl8188ee firmware to CONFIG_EXTRA_FIRMWARE. 
> 
> I've done the former, the problem persists.

 

needMoreFirmware ... damn, back to square one. Can you pastebin a dmesg after a boot, also can you enable debug on wpa_supplicant and pastbin the log ... to do this you either need to edit 10-wpa_supplicant or switch back to having wpa_supplicant as a service (with the following config)

```
wpa_supplicant_args="-Dnl80211 -dd -f /var/log/wpa_supplicant.log"
```

Also, can you see the AP? Pastebin the output of the following ...

```
# iw dev wlp3s0 freq $(wpa_cli status | awk -F= '/freq/{print $2}') scan ssid $(wpa_cli status | awk -F= '/^ssid/{print $2}')

# iw dev wlp3s0 station dump
```

... that's assuming you are getting authenticated to the AP, please confirm.

best ... khay

----------

