In commit e1ec2d2b9e7f7692a4ff88a0361bbcdbe34f0d99 (proto-shell: extend race 
condition avoidance), changes were made to prevent notifications from the proto 
handler during teardown.
According to the comments, this was done to avoid the shell proto state being 
reset to S_IDLE and the interface hanging in IFS_TEARDOWN state.
These changes unfortunately also prevent netifd from being notified of the 
errors (proto_shell_notify_error) that actually caused the teardown.
This is for instance an issue when the protocol is ppp and e.g.  PAP/CHAP 
authentication fails.
Since proto_shell_notify_error does not touch the proto state, it seems like a 
good idea to at least allow these notifications in teardown state.
The attached patch accomplishes this.

Signed-off-by: Hans Dedecker <dedec...@gmail.com>
Signed-off-by: Joeri Barbarien <joeri.barbar...@gmail.com>
---
 proto-shell.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/proto-shell.c b/proto-shell.c
index 98f5e52..7a3e148 100644
--- a/proto-shell.c
+++ b/proto-shell.c
@@ -688,6 +688,7 @@ proto_shell_notify(struct interface_proto_state *proto, 
struct blob_attr *attr)
 {
        struct proto_shell_state *state;
        struct blob_attr *tb[__NOTIFY_LAST];
+       uint32_t action;
 
        state = container_of(proto, struct proto_shell_state, proto);
 
@@ -695,10 +696,13 @@ proto_shell_notify(struct interface_proto_state *proto, 
struct blob_attr *attr)
        if (!tb[NOTIFY_ACTION])
                return UBUS_STATUS_INVALID_ARGUMENT;
 
-       if (state->sm == S_TEARDOWN || state->sm == S_SETUP_ABORT)
+       action = blobmsg_get_u32(tb[NOTIFY_ACTION]);
+
+       /* allow proto_shell_notify_error even in S_TEARDOWN or S_SETUP_ABORT 
states */
+       if (action != 3 && (state->sm == S_TEARDOWN || state->sm == 
S_SETUP_ABORT))
                return UBUS_STATUS_PERMISSION_DENIED;
 
-       switch(blobmsg_get_u32(tb[NOTIFY_ACTION])) {
+       switch(action) {
        case 0:
                return proto_shell_update_link(state, attr, tb);
        case 1:
-- 
1.7.9.5
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to