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

Reply via email to