Hey , I was just wondering , what should be my controller functionality be for openflow in wireless like -- for eg nox controller module "pyswitch" makes the switch behave like a learning switch . Mac addresses are associated with the port numbers entries . If the destination mac entry is already there in the flow table , it would output to the respective port number , else it would flood except for the input port.
Now that the switch is an wireless acess point . How should my controller behaviour be like .? I am confused . Any suggestions down this line ..so that I can write a small NOX controller API for wireless . Now that I have this tp link router with me and I would point it to a controller <may be a nox api ,which I would have to write > On Thu, Jun 7, 2012 at 5:09 PM, Andrew Ferguson <a...@cs.brown.edu> wrote: > > On Jun 7, 2012, at 1:47 PM, shreya pandita wrote: > > Jan 01 04:44:18|00009|rconn|INFO|tcp:10.0.0.5:6633: connected > Jan 01 04:44:48|00010|rconn|ERR|tcp:10.0.0.5:6633: no response to > inactivity probe after 15 seconds, disconnecting > Jan 01 04:44:48|00011|rconn|INFO|tcp:10.0.0.5:6633: connection dropped > Jan 01 04:44:49|00012|rconn|INFO|tcp:10.0.0.5:6633: connecting... > > > The controller and the openwrt switch are connected , for sometime and > then they lose connection . Is this a normal behaviour ??. Is there any > file or something where I can increase the inactivity period. > > > Hi Shreya, > > I have seen this behavior as well. It's not a serious problem for two > reasons 1) it immediately re-connects after dropping the connection due to > inactivity, and 2) if you have any OF messages being exchanged between the > switch and the controller, these heartbeat messages won't be responsible > for keeping the connection alive, and you won't see the > disconnect/reconnect cycle. > > I've looked into why this is happening and it seems to be some sort of > timing issue. The switch receives the OF ECHO_REPLY message from the > controller, but doesn't process it. However, if you add the option > "--verbose=vconn:file:dbg" to ofprotocol, then it *does* process the > ECHO_REPLY message. That seems to be enough to cause the packet to be > processed. > > I recently tried re-compiling the kernel for the TP-LINK to use 1000 Hz > timers instead of the default 100 Hz, but that causes the ethernet drivers > not to load, and you'll need to re-flash the firmware with a serial cable. > :-) I'm going to try 250 Hz timers when I get a chance, but I'm still > speculating on the root cause. > > Happy to share more details with you off list. > > cheers, > Andrew >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss