Using the wireless access point is the same scenario as a wired learning switch. In this case, you can think of your wireless access point as a two port switch (bridging the interfaces). Your controller will just learn multiple clients on the same in_port. Nox's pyswitch shouldn't need to be modified in order to do L2 switching now that you're using wireless.
Aaron On Wed, Jun 13, 2012 at 1:23 PM, shreya pandita <shreya.pand...@gmail.com>wrote: > 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 > >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
