I accidentally clicked "STOP" instead of "EDIT" and it did just that. For these entries, there SHOULD be a dialog to confirm since the button is next to a frequently used button. In fact, there should be one for each of these items except for EDIT. 
The Interface STOP button does provide a dialog:
- Interface is shutting down…
- Interface is stopping…
- Interface is reconnecting…
- Interface is starting up…
RESTART works for me if I did that. STOP does exactly what it means. EDIT you’re not concerned about. DELETE carries a color coded DELETE warning.
Indeed. But if it's shutting down the actual LAN connection you're actively using to administer the instance it should also carry a confirmation dialog. ie- You're about to disconnect the interface being used to administer the service. Are you sure?"
5 Likes
So you're actually asking for additional logic - to determine that you're attempting to stop the interface in use?
Cool.
BTW, hitting delete queues the removal as an "Unsaved Change" - it doesn't delete it instantly.
What theme are you using?
I did try it because I accidentally hit STOP instead of EDIT and there was no dialog, it just shut me out and I had to reboot the router. I am using the OpenWRT2020 theme, so it's possible the dialog is missing for this theme, but that's the exact dialog I would expect to be there! I just tested it with Bootstrap and OpenWRT themes (on a guest interface I created) and there is no dialog them either.
OpenTomato theme, though it’s not a matter of the theme.
- Snapshot (kernel 6.12) - Using Bootstrap theme:
- Release 23.05.3 on my AP - Using OpenWrt2020 theme:
IIRC, it was in 19.07 as well.
What does ubus call system board return?
I can confirm what OP has stated above, Pressing stop on a active interface will in fact stop it without a confirmation notice.
ubus call system board
{
"kernel": "6.6.86",
"hostname": "wrt",
"system": "ARMv8 Processor rev 4",
"model": "GL.iNet GL-MT6000",
"board_name": "glinet,gl-mt6000",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.1",
"revision": "r28597-0425664679",
"target": "mediatek/filogic",
"description": "OpenWrt 24.10.1 r28597-0425664679",
"builddate": "1744562312"
}
}
What theme: Bootstrap
As I noted in post #2. It really doesn’t make sense to ask Are you sure? for any wan/wan6/wg/guest/. . . Interface. It’s a simple matter when you make a mistake and hit STOP to simply RESTART the respective interface - Done.
Only an Interface that would cause you to be locked out gets a warning confirmation i.e. LAN.
The problem is that it requires additional logic (and that may not be trivial) to determine that this interface is indeed necessary for administrative purposes. For example, maybe you do actually want to stop the lan and you'll use a wireguard interface for management. Maybe the router is already part of a trusted network so the wan is actually used for admin and nothing is connected to the lan. The scenarios are endless. So... the most simplistic logic (is the IP address of the host that is being used to access LuCI on the same subnet as the network that is being stopped?) may fail to sufficiently protect the user from such a mistake.
1 Like
I get the same output as @digital-living.
(root@OpenWrt)-(16:29)
([~])-(0 files): ubus call system board
{
"kernel": "6.6.86",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 4",
"model": "GL.iNet GL-MT6000",
"board_name": "glinet,gl-mt6000",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.1",
"revision": "r28597-0425664679",
"target": "mediatek/filogic",
"description": "OpenWrt 24.10.1 r28597-0425664679",
"builddate": "1744562312"
}
}
I'm still wondering how you got the dialog and nobody else did!
1 Like
The behaviour of pressing stop and the interface actually stops seems like a logical/sane thing to happen right away, The only thing I found not sane or logical was that if I want to delete the interface is I have to click on the Save and Apply button to make it happen.
To me both should be the same either do it right away or wait for me to click the save and apply.
No worries either way I just read the OP and decided to try it after reading some of the posts that said it does ask to confirm when pressing stop when I knew my version of openwrt I am running does not ask and I am also sure it never did even years ago on my old TP-link 4300 does the same thing so I dont think this is new
Oddly you, @digital-living, and myself are all running the same target/sub-target albeit two of you on MT6000 profile on current Release while I am on recent Snapshot using Testing Kernel on an OpenWrt One. It doesn't give rise to the question is this a bug on Current Release on MT6000. I cannot replicate your experience and as I've documented, it works for me.
Grasping at straws, maybe @systemcrash might have a hint, he's been seen in the MT6000 thread and I've seen him on the LuCI Repo.
Deleting an Interface requires different logic where it requires a uci call(s) to actually modify your network config just the same as an Edit. Stopping/Starting an Interface just needs needs an if down or if up without touching your config - seems a rational assumption to me.
1 Like
So in a discussion about a warning for stopping an interface (which appears to work for some users) - a suggestion is made to remove the warning/cache/unsaved change to completely delete an interface instead?
It's an interesting idea...
I'm not sure how user friendly it is to completely wipe a configuration when pressing another of the 4 buttons in the row.
Also, the Save/Apply has been added in most LuCI locations. Do you have an issue everywhere it appears?
Ah, classic. Sawing off the branch you're standing on.
The core interfaces logic handles that dialogue and presents it when it detects that you access it via said interface.
I'm generally against adding more confirmation dialogues and increasing click counts to perform regular operations that can be undone - you should recognise that you are already poking around in a privileged administration interface. Dialogues requiring, or encouraged to have, such confirmations are those where permanent changes are about to occur, like a (file) deletion.
Deleting an interface is a config change ('permanent') whereas up/down is a state change (disappears with a reboot).
2 Likes
I was accessing it via the LAN interface, which I was connected to with a static IP, when I accidentally clicked STOP instead of EDIT and it kicked me out without a warning. So it should have detected that I was connected to LAN but didn't?
This is why I was surprised to see your post about the dialog actually being there. @systemcrash also posted it should appear if connected via the interface that's being manipulated, which I was, so maybe it is a bug on the MT6000.
Check in the detection logic. /usr/libexec/luci-peeraddr.
Here's the contents of /usr/libexec/luci-peeraddr.
#!/bin/sh
NL="
"
function ifaces_by_device() {
ubus call network.interface dump 2>/dev/null | \
jsonfilter -e "@.interface[@.device='$1' || @.l3_device='$1'].interface"
}
function device_by_addr() {
set -- $(ip route get "$1" ${2:+from "$2"} 2>/dev/null)
echo "$5"
}
for inbound_device in $(device_by_addr "$REMOTE_ADDR" "$SERVER_ADDR"); do
inbound_devices="$inbound_device"
inbound_interfaces=""
for iface in $(ifaces_by_device "$inbound_device"); do
inbound_interfaces="${inbound_interfaces:+$inbound_interfaces$NL}$iface"
for peeraddr in $(uci get "network.$iface.peeraddr"); do
for ipaddr in $(resolveip -t 1 "$peeraddr" 2>/dev/null); do
for peerdev in $(device_by_addr "$ipaddr"); do
for iface in $(ifaces_by_device "$peerdev"); do
inbound_devices="${inbound_devices:+$inbound_devices$NL}$peerdev"
inbound_interfaces="${inbound_interfaces:+$inbound_interfaces$NL}$iface"
done
done
done
done
done
done
inbound_devices="$(echo "$inbound_devices" | sort -u | sed ':a;N;$!ba;s/\n/", "/g')"
inbound_interfaces="$(echo "$inbound_interfaces" | sort -u | sed ':a;N;$!ba;s/\n/", "/g')"
cat <<JSON
{
"remote_addr": "$REMOTE_ADDR",
"server_addr": "$SERVER_ADDR",
"inbound_devices": [ ${inbound_devices:+\"$inbound_devices\"} ],
"inbound_interfaces": [ ${inbound_interfaces:+\"$inbound_interfaces\"} ]
}
JSON