Daisuke, this tip is fantastic -- thank you! I changed one of our Pantou devices to use this fix in addition to the one below, and we have not had any disconnects or other issues with it for more than 50 hours (I was still seeing occasional disconnects even with the workaround I previously suggested below).
I think "--inactivity-probe=90" is absolutely the right change.... Yiannis, it might make sense to consider adding this to the default image? many thanks, Andrew On Apr 19, 2013, at 12:09 PM, Daisuke Kotani wrote: > Hi, > > I heard that Trema team had also tried to solve a similar issue > (interoperability between Trema and OpenWRT), and they says that > one workaround is to add --inactivity-probe=90 to the ofprotocol command-line > on the switch. > A modified version of /lib/openflow/ofprotocol.sh in OpenWRT > can be found at https://gist.github.com/kazuyas/2016918 > > I hope this can help you > > (13/04/20 0:39), Andrew Ferguson wrote: >> hi Adria, >> >> unfortunately, yes, this problem has been seen before on the Pantou >> firmware. I don't know that anyone has determined a root cause. >> >> there are a couple workarounds: >> >> 1) have your controller send periodic ECHO_REQUEST's to the switch, >> rather than wait for the switch to send them. for example, Pox has an >> openflow.keepalive module for this purpose: >> https://github.com/noxrepo/pox/blob/betta/pox/openflow/keepalive.py >> >> 2) I have found that adding: --verbose=vconn:file:dbg >> --log-file="/dev/null" to the ofprotocol command-line on the switch >> can help. however, this doesn't seem to work for everyone, so it might >> just be my own situation. :-) >> >> if you want more background, here are some previous threads: >> https://mailman.stanford.edu/pipermail/openflow-discuss/2012-October/003742.html >> https://mailman.stanford.edu/pipermail/openflow-discuss/2012-June/003372.html >> >> >> make sense? let me know if you have any questions. >> >> >> cheers, >> Andrew >> >> >> >> >> On Apr 19, 2013, at 10:05 AM, adria sole wrote: >>> I have done logread -f in telnet of the openwrt: >>> >>> result is: >>> ... >>> Jan 1 02:25:38 OpenWrt daemon.err ofprotocol: >>> 00657|rconn|ERR|tcp:192.168.1.20:6633 <http://192.168.1.20:6633/>: no >>> response to inactivity probe after 15 seconds, disconnecting >>> Jan 1 02:25:38 OpenWrt user.info <http://user.info/> sysinit: Jan 01 >>> 02:25:38|00657|rconn|ERR|tcp:192.168.1.20:6633 >>> <http://192.168.1.20:6633/>: no response to inactivity probe after 15 >>> seconds, disconnecting >>> Jan 1 02:25:38 OpenWrt user.info <http://user.info/> sysinit: Jan 01 >>> 02:25:38|00658|rconn|INFO|tcp:192.168.1.20:6633 >>> <http://192.168.1.20:6633/>: connection dropped >>> Jan 1 02:25:38 OpenWrt daemon.notice ofprotocol: >>> 00658|rconn|INFO|tcp:192.168.1.20:6633 <http://192.168.1.20:6633/>: >>> connection dropped >>> Jan 1 02:25:40 OpenWrt user.info <http://user.info/> sysinit: Jan 01 >>> 02:25:39|00659|rconn|INFO|tcp:192.168.1.20:6633 >>> <http://192.168.1.20:6633/>: connecting... >>> Jan 1 02:25:41 OpenWrt daemon.notice ofprotocol: >>> 00659|rconn|INFO|tcp:192.168.1.20:6633 <http://192.168.1.20:6633/>: >>> connecting... >>> Jan 1 02:25:41 OpenWrt user.info <http://user.info/> sysinit: Jan 01 >>> 02:25:39|00660|rconn|INFO|tcp:192.168.1.20:6633 >>> <http://192.168.1.20:6633/>: connected >>> Jan 1 02:25:41 OpenWrt daemon.notice ofprotocol: >>> 00660|rconn|INFO|tcp:192.168.1.20:6633 <http://192.168.1.20:6633/>: >>> connected >>> ... >>> >>> >>> 2013/4/19 adria sole <adrias...@gmail.com <mailto:adrias...@gmail.com>> >>> >>> Hi, I have some trouble with linksys wrt54gl, I have installed >>> pantou firmware >>> (http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT), >>> and nox (https://github.com/noxrepo/nox) branch verity. >>> >>> I have established openflow dialog, but after 2 request/reply >>> messages my router sends a TCP reset connection, and after that >>> starts another time with (SYN/SYN ACK) Hello;Features/Features >>> Reply;2Request/Reply and another time resets.. >>> >>> Does anyone know why? What can I do? >>> >>> Terminal: >>> ... >>> 01559|connection|WARN:rx error (Connection reset by peer) >>> 01560|connection_manager|WARN:connected: 192.168.1.20:6633 >>> <http://192.168.1.20:6633/><->192.168.1.1:58541 >>> <http://192.168.1.1:58541/> >>> 01561|openflow-datapath|DBG:recv 8 >>> 01562|openflow-datapath|DBG:received ofp_hello >>> 01563|openflow-datapath|WARN:Negotiated OpenFlow version 0x01 >>> 01564|openflow-datapath|DBG:sending ofp_hello >>> 01565|openflow-datapath|DBG:sending ofp_features_request >>> 01566|openflow-datapath|DBG:sending ofp_set_config >>> 01567|openflow-datapath|DBG:sent 8 remaining 0 20 >>> 01568|openflow-datapath|DBG:sent 20 remaining 0 0 >>> 01569|openflow-datapath|DBG:recv 224 >>> 01570|openflow-datapath|DBG:received ofp_features_reply >>> 01571|openflow-datapath|DBG:recv 8 >>> 01572|openflow-datapath|DBG:received ofp_echo_request >>> 01573|openflow-datapath|DBG:sending ofp_echo_reply >>> 01574|openflow-datapath|DBG:sent 8 remaining 0 0 >>> 01575|openflow-datapath|DBG:recv 8 >>> 01576|openflow-datapath|DBG:received ofp_echo_request >>> 01577|openflow-datapath|DBG:sending ofp_echo_reply >>> 01578|openflow-datapath|DBG:sent 8 remaining 0 0 >>> 01579|openflow-datapath|DBG:recv 8 >>> 01580|openflow-datapath|DBG:received ofp_echo_request >>> 01581|openflow-datapath|DBG:sending ofp_echo_reply >>> 01582|openflow-datapath|DBG:sent 8 remaining 0 0 >>> 01583|connection|WARN:rx error (Connection reset by peer) >>> 01584|connection_manager|WARN:connected: 192.168.1.20:6633 >>> <http://192.168.1.20:6633/><->192.168.1.1:58542 >>> <http://192.168.1.1:58542/> >>> 01585|openflow-datapath|DBG:recv 8 >>> 01586|openflow-datapath|DBG:received ofp_hello >>> 01587|openflow-datapath|WARN:Negotiated OpenFlow version 0x01 >>> 01588|openflow-datapath|DBG:sending ofp_hello >>> 01589|openflow-datapath|DBG:sending ofp_features_request >>> 01590|openflow-datapath|DBG:sending ofp_set_config >>> 01591|openflow-datapath|DBG:sent 8 remaining 0 20 >>> 01592|openflow-datapath|DBG:sent 20 remaining 0 0 >>> 01593|openflow-datapath|DBG:recv 224 >>> 01594|openflow-datapath|DBG:received ofp_features_reply >>> 01595|openflow-datapath|DBG:recv 8 >>> 01596|openflow-datapath|DBG:received ofp_echo_request >>> 01597|openflow-datapath|DBG:sending ofp_echo_reply >>> 01598|openflow-datapath|DBG:sent 8 remaining 0 0 >>> 01599|openflow-datapath|DBG:recv 8 >>> 01600|openflow-datapath|DBG:received ofp_echo_request >>> 01601|openflow-datapath|DBG:sending ofp_echo_reply >>> 01602|openflow-datapath|DBG:sent 8 remaining 0 0 >>> 01603|connection|WARN:rx error (Connection reset by peer) >>> ... >>> >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> <mailto:openflow-discuss@lists.stanford.edu> >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> >> >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> > > > -- > Daisuke Kotani / kot...@net.ist.i.kyoto-u.ac.jp > Ph.D Student > Network Media Group, > Department of Intelligence Science and Technology, > Graduate School of Informatics, Kyoto University > http://www.ecchu.jp/~daisuke/ > _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
