hi Adria, this is the edited command line I am having the most success with:
ofprotocol tcp:127.0.0.1:6634 "$ofctl" --fail=closed "-D" "--pidfile=$pidfile" --out-of-band --listen=ptcp: --log-file="/tmp/log/ofprotocol.log" --verbose=vconn:file:info --verbose=rconn:file:dbg --inactivity-probe=90 & hope this helps! Andrew On Apr 24, 2013, at 11:43 AM, adria sole wrote: > Andrew and Daiskuke, > > I replaced my /lib/openflow/ofprotocol.sh for > https://gist.github.com/kazuyas/2016918/raw/f96a1d729952be40a8603f46d4ceb501b8661eb6/ofprotocol.sh, > and after 15s my router stills sending reset, may I have to change another > thing? > > many thanks, > Adria > > > 2013/4/24 Andrew Ferguson <a...@cs.brown.edu> > 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
