Hi Syed,
type=3 corresponds to OFPET_FLOW_MOD_FAILED, and code=0 to
OFPFMFC_ALL_TABLES_FULL
Any reason why the flow table would be indeed full?
On Wed, Jan 12, 2011 at 3:45 PM, Syed Akbar Mehdi
akbar.me...@seecs.nust.edu.pk wrote:
Hi,
While running some captured network data through an
I think type 3 code 0 is failure to add a flow because you already have too
many, but you can look it up in the OpenFlow specification.
The data that goes with an error depends on the error. In the case of failure
to add a flow, I think it just returns the flow mod message to you (or at least
Thanks Murphy, Kyriakos. That is exactly the problem. Actually the data I am
using has about 1400 TCP connection initiations. Whenever a SYNACK is
received, I set the flow specifically for that connection with an idle
timeout of 1 sec. The data is for almost a whole day and most of these flows
are
Thanks! I'm glad my patches are decent.
I've attached another one for destiny:
In a Flow_removed_event, the fields are taken from an ofp_flow_removed
message,
but a couple of fields were missing (reason and priority). I added these
to the event
struct and changed python's flow removed
Thanks. I pushed this.
Regards
KK
On 12 January 2011 21:40, Derek Cormier derek.corm...@lab.ntt.co.jp wrote:
Thanks! I'm glad my patches are decent.
I've attached another one for destiny:
In a Flow_removed_event, the fields are taken from an ofp_flow_removed
message,
but a couple of
Woops, I introduced a bug. I was converting 'reason' to host byte order,
but it's only 8 bits. This causes it to always be 0 since it turns into
a short before ntohs(). I attached the fix, sorry about that.
-Derek
On 01/13/2011 02:55 PM, kk yap wrote:
Thanks. I pushed this.
Regards
KK
On
