[OpenWrt-Devel] miniupnpd state loss

Kao Kevin Kevin.Kao at technicolor.com
Wed Oct 15 12:18:53 EDT 2014


Hi,

While Running tests in an openwrt based IP gateway, we noticed  openwrt hotplug restarts the minupnpd when Ethernet link goes up.
The restart results in the miniupnpd lossing its internal state and breaking the upnp GENA (General event notification arch) functions.

Please refer to the following tests for the problem description.

        [wan]


[Device][lan][Gateway]


1.       Have Gateway wan link set to network1 with subnet a1.b1.c1.xx/255.255.255.0

2.       DHCP server in network1 assign Gateway wan IP as a1.b1.c1.01

3.       Device sends SUBSCRIBE for eventSubURL to Gateway

4.       Gateway returns 200 OK

5.       Gateway sends NOTIFY to device with ExternalIPAddress a1.b1.c1.01.

6.       Device sends 200 OK

7.       Bring wan link down

8.       Gateway sends NOTIFY with ExternalIPAddress with  WAN IP 0.0.0.0

9.       Device sends 200 OK

10.   Set the Gateway wan to network2   a2.b2.c2.xx/255.255.255.0

11.   DHCP server in network2 assign Gateway wan IP as a2.b2.c2.02

12.   Gateway sends NOTIFY with ExternalIPAddress a2.b2.c2.02.

13.   Device sends 200 OK

14.   Repeat step 7, bring wan link down

15.   Gateway should send NOTIFY as in step8; but it does not.

16.   Repeat step1, have gateway wan set to network

17.   Gateway should send NOTIFY as in step5; but it does not.

18.   Device sends UNSUBSCRIBE to Gateway

19.   Getway should send 200OK; but it sends 412 instead.





After investigating the cause, we found in between step12 and step13; the gateway miniupnpd receives a SIGTERM signal and restarted. As a result, the new miniupnpd losses the subscription state.

The SIGTERM is initiated  from the hotplug in the following code (in /etc/hotplug.d/iface/50-miniupnpd file)

----------- Original script ------------------------------------------------------------------------------------------------------------

[ -f /var/state/bootnetwork ] && exit 0

/etc/init.d/miniupnpd enabled && [ "$ACTION" = "ifup" ] && {

        local iface

        for iface in $(uci_get upnpd config internal_iface; uci_get upnpd config external_iface); do

                [ "$INTERFACE" = "$iface" ] && /etc/init.d/miniupnpd restart

        done

}

----------- ----------------------------------------------------------------------------------------------------------------------------



Question1: is the restart for miniupnpd is necessary if it has been already running?

Question2:  We add the following code (in the modified section) in the 50-miniupnp to escape the restart if the miniupnpd  service_check passed.

                        It seems the problem goes away. But we are not sure if the solution has no side effects. So, please anyone know this, give us a comment.



----------- Modified script ------------------------------------------------------------------------------------------------------------

[ -f /var/state/bootnetwork ] && exit 0

# add the following 2 lines to avoid miniupnpd restarted if it pass the service check

. /lib/functions/service.sh

service_check /usr/sbin/miniupnpd && exit 0



/etc/init.d/miniupnpd enabled && [ "$ACTION" = "ifup" ] && {

        local iface

        for iface in $(uci_get upnpd config internal_iface; uci_get upnpd config external_iface); do

                [ "$INTERFACE" = "$iface" ] && /etc/init.d/miniupnpd restart

        done

}

----------- ----------------------------------------------------------------------------------------------------------------------------



Thanks

Kevin








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.emz
Type: application/octet-stream
Size: 1619 bytes
Desc: image007.emz
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 395 bytes
Desc: image008.png
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.emz
Type: application/octet-stream
Size: 1751 bytes
Desc: image009.emz
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 545 bytes
Desc: image010.png
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.emz
Type: application/octet-stream
Size: 1636 bytes
Desc: image011.emz
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image012.png
Type: image/png
Size: 340 bytes
Desc: image012.png
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image013.png
Type: image/png
Size: 131 bytes
Desc: image013.png
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image014.emz
Type: application/octet-stream
Size: 2157 bytes
Desc: image014.emz
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image015.png
Type: image/png
Size: 703 bytes
Desc: image015.png
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141015/beaf5b32/attachment-0004.png>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list