I don't know if this is Pi specific, I assume it's just standard Debian.
I'm using Raspbian Stretch.
Suppose I have a working wireless connection.
I can change wireless configuration in /etc/wpa_supplicant/wpa_supplicant.conf to remove the working details and then use "wpa_cli reconfigure" to take effect. Except that I remain connected to the wifi that I no longer have settings for, and cannot force it to disconnect.
What is the correct way to force the change to have effect other than reboot?
On a related note, how do I change the IP configuration for the cabled network and have that take effect? Making changes to /etc/dhcpcd.conf works after a reboot but I can't reliably make it work without rebooting. (Restarted dhcpcd will add a new IP address, but won't remove old ones and doesn't seem to let me revert to DHCP reliably either.)
In both cases, making a connection seems easier than dropping one.
Mark
On 12/12/17 18:44, Mark Rogers wrote:
I don't know if this is Pi specific, I assume it's just standard Debian.
I'm using Raspbian Stretch.
Suppose I have a working wireless connection.
I can change wireless configuration in /etc/wpa_supplicant/wpa_supplicant.conf to remove the working details and then use "wpa_cli reconfigure" to take effect. Except that I remain connected to the wifi that I no longer have settings for, and cannot force it to disconnect.
What is the correct way to force the change to have effect other than reboot?
On a related note, how do I change the IP configuration for the cabled network and have that take effect? Making changes to /etc/dhcpcd.conf works after a reboot but I can't reliably make it work without rebooting. (Restarted dhcpcd will add a new IP address, but won't remove old ones and doesn't seem to let me revert to DHCP reliably either.)
In both cases, making a connection seems easier than dropping one.
Mark
OK, so you're headless, so I'm assuming connection via ssh (or telnet). So if you sucessfully stop the network, you'll lose your connection. So the first thing to do is start a SCREEN session. In case you don't know, screen is a command you can install (with sudo apt-get install screen), and when you run it, it creates a new command window within the current terminal, but you can "detatch" from it. The big advantage is, if you lose your ssh session for some reason, the screen will continue to run and you can re-attach to it.
so run
screen
Then I what springs to mind is ifup and ifdown which bring up and take down the network interface respectively, similar to what was discussed here: https://askubuntu.com/questions/441619/how-to-successfully-restart-a-network...
So, if you put this on one line. sudo ifdown eth0 && *sudo* ifup eth0
replace eth0 with the name of the interface, wireless or wired. Screen will protect you from the loss of the ssh connection, and the && will execute the second command if the first one succeeds, so if the network goes down, the network should be brought up again.
ifup and ifdown may have been replaced by newer commands, or may not be installed by default. Some commands seem to have been replaced by the newer general purpose "IP" command.
Regarding the IP address, is this any use? https://www.computerhope.com/issues/ch001078.htm
Also, if you have a dhcp server, even though the client is releasing the IP address, it could be that the dhcp server sees the same machine reconnecting to it, and says "I'll give you the same ip address as you're already in my lease table", so the ip address may not change. I have certainly experienced this behaviour with dnsmasq before. If that's the case, you have to persuade your dhcp server to release or expire the address leases.
Hope that helps.
Steve
ps. to re-attach to a screen session, just type screen -r. If you have multiple screen sessions running it will list them, and you can do screen -r 1234 (where 1234 is the number at the begining of the long screen name). If there is just one screen session, you will automatically reattach. To manually temporarily detatch, use ctrl-A, D. Or type exit to close the screen.
On 12 December 2017 at 21:53, steve-ALUG@hst.me.uk wrote:
OK, so you're headless, so I'm assuming connection via ssh (or telnet).
Actually what I'm trying to achieve is that it happens via a script (new settings put onto a USB key, which is read automatically and settings updated accordingly). The update process works fine except that a reboot is often needed to take effect.
During testing I frequently connect the Pi to a TV and keyboard if needed, although the reality is that I often do it via SSH and don't lose the connection because it doesn't work.
Anecdotally, what seems to be the case is that new addresses get picked up but old ones don't die. So if I have a DHCP connection via Ethernet and set a static IP then restart dhcpcd, I get a new static IP but remain connected on the old DHCP address. If I change to a different static IP then the new one gets added but the old one remains too. (ifconfig doesn't reflect this accurately.)
Similarly, if I have wifi settings and an active connection, then remove the wifi settings and do wpa_cli reconfigure, then I remain connected until after a reboot.
Then I what springs to mind is ifup and ifdown which bring up and take down the network interface respectively, similar to what was discussed here: https://askubuntu.com/questions/441619/how-to-successfully-restart-a-network...
$sudo ifdown eth0 ifdown: Unknown interface eth0
(ifconfig lists my interfaces as eth0, lo and wlan0. ifdown wlan0 has same effect.)
However, Googling that suggests that "sudo ifconfig eth0 down" is a better alternative and that does seem to work better (subject to a bit more testing!)
Also, if you have a dhcp server, even though the client is releasing the IP address, it could be that the dhcp server sees the same machine reconnecting to it, and says "I'll give you the same ip address as you're already in my lease table", [...]
That bit I'm fine with. It's when switching from DHCP to static and I end up with both addresses or something else inconsistent happens that I have a problem with!
I think really what I'm trying to find out is how I'm supposed to restart networking to take new settings into account, then I can see what isn't working and debug it accordingly. Back in the day I used to use "sudo /etc/init.d/networking restart" but that (and the systemd equivalents) no longer seem to achieve anything useful.
On 13 December 2017 at 10:56, Mark Rogers mark@more-solutions.co.uk wrote:
However, Googling that suggests that "sudo ifconfig eth0 down" is a better alternative and that does seem to work better (subject to a bit more testing!)
OK...
Focussing on wlan0 as that's what I'm most interested in.
I did have wireless configuration in wpa_supplicant.conf (and therefore had an IP address on wlan0) which I have removed.
$ sudo wpa_cli reconfigure $ ifconfig [...] wlan0: [...] inet 192.168.1.32 netmask 255.255.255.0 broadcast 192.168.1.255 [...]
$iwconfig wlan0 IEEE 802.11 ESSID:off/any Mode:Managed Access Point: Not-Associated Retry short limit:7 RTS thr:off Fragment thr:off Power Management:on $sudo ifconfig wlan0 down && sudo ifconfig wlan0 up $ifconfig [...] wlan0: [...] inet 192.168.1.32 netmask 255.255.255.0 broadcast 192.168.1.255 [...]
In other words the Pi insists on retaining that IP even though the wifi connection is down. (I can't ping .32 from outside the Pi, and assuming eth0 is down I can't ping anything from the Pi either.)
Frustratingly, if eth0 and wlan0 are both up (with wlan0 in this non-connected-but-has-ip state) then I cannot use eth0 - it looks like wlan0 is taking precedence for routing even though it's not working.
On 13 December 2017 at 11:25, Mark Rogers mark@more-solutions.co.uk wrote:
In other words the Pi insists on retaining that IP even though the wifi connection is down. (I can't ping .32 from outside the Pi, and assuming eth0 is down I can't ping anything from the Pi either.)
In case anyone is interested, and/or for anyone finding this in the archives, I've distilled this into a much shorter description and started a thread on the RPi forums: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=199860
On 13/12/17 14:13, Mark Rogers wrote:
In case anyone is interested, and/or for anyone finding this in the archives, I've distilled this into a much shorter description and started a thread on the RPi forums: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=199860
I was going to suggest you ask there. I'm afraid I've reached the end of my knowledge.
Good luck!
Steve