Hi!
After installing latest snapshot r8576-731a12ad83 on GL-MT300N-V2 "wifi down"
shuts down the wireguard interface.
Any suggestions for this issue?
Robert
Can you share some details about your configuration? Is the wireguard interface somehow related to the wifi? Is the wlan0 involved in the routing path, is it somehow bridged wirth wireguard etc.?
The lan is bridged with wifi.
wg0 has its own interface and ip-adresses with routes to it (not bridged):
192.168.6.0/24 dev wg0 proto static scope link
192.168.111.0/24 dev wg0 proto kernel scope link src 192.168.111.2
192.168.111.1 dev wg0 proto static scope link
so nothing special.
i can "reactivate" wireguard by hand ( with wg and ip commands ) and its working.
shuting down wifi with:
uci set wireless.@wifi-device[0].disabled=1; uci commit wireless
keeps wireguard alive
wifi down
shuts down the wireguard interface.
with:
git checkout "
git rev-list master -n 1 --first-parent --before=2018-11-08"
"wifi down" works as expected.
I don't think that's the case (at least not as simple as you think). I think it involves having enough entropy to bring up an encrypted interface on an embedded device. Some devices get entropy from WiFi ambient noise on the band in the atmosphere. Do the following experiment:
Run this command WHILE WIFI IS UP and AFTER YOU BRING WIFI DOWN AND WG STOPS:
cat /proc/sys/kernel/random/entropy_avail
Provide the numbers given.
the numbers are around 2970 with or without wifi.
So, to be clear...this didn't happen running 18.06.1?
(Moving to the For Developers section.)
Great sorry for inconvenience!!!
To be sure i just flashed 18.06.1 and realized the same error.
Don't know why it worked previosly.
but nevertheless it's strange that "wifi down" causes the error and "uci set ..." does not.
That's why i thought that could be a bug.
Guess the easiest way to find the misconfiguration will be to set up from scratch.
Sorry again and thank you for help!
1 Like