However, see the OVS FAQ: Q: I can't seem to use Open vSwitch in a wireless network.
A: Wireless base stations generally only allow packets with the source MAC address of NIC that completed the initial handshake. Therefore, without MAC rewriting, only a single device can communicate over a single wireless link. This isn't specific to Open vSwitch, it's enforced by the access point, so the same problems will show up with the Linux bridge or any other way to do bridging. On Wed, Jun 13, 2012 at 01:34:12PM -0700, Aaron Rosen wrote: > 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 _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
