Re: [nox-dev] TCP packets are not parsed correctly

[James "Murphy" McCauley]

Hopefully it's fixed in the repository now.

-- Murphy

On Oct 15, 2010, at 8:27 PM, Niky Riga wrote:

> Hi,
> 
> Given that this bug is blocking one of the Gec9 plenary demos, I would like 
> to start debugging it.
> Do you have an idea where should I start looking? In which file do you 
> believe the problem is?
> 
> Thanks,
> niky
> 
> Niky Riga wrote:
>> I am running nox zaku as released on the September 15th, should I update?
>> 
>> --niky
>> 
>> James McCauley wrote:
>>> 
>>> didn't look at the original problem, but the rolled back patch does look 
>>> wrong to me. I think it's almost right now, but the last part should be 
>>> arr[i + 2]
>>> 
>>> On Oct 15, 2010 12:58 AM, "Kyriakos Zarifis" >> > wrote:
>> 
>> 
>> ___
>> nox-dev mailing list
>> nox-dev@noxrepo.org
>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> 


___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[Rob Sherwood]

I've put the pcapfile on yuba:~capveg/nineveh-fv.tcpdump (for those who have
access... it's a 2MB file).

It's a trace of both to the FV on nineveh:6633 (from the FV on openflow5)
and to the controller on nineveh:1734.  If you just filter on port 1734 you
get just the controller traffic.

- Rob
.


On Fri, Oct 15, 2010 at 9:44 PM, kk yap  wrote:

> Can someone send the pcap file on the list, so that people can
> actually start doing real investigation here?  If it is too big, send
> to Nick Bastin? (Sorry, Nick...)
>
> I would still like to see the NOX's output.
>
> Regards
> KK
>
> On 15 October 2010 21:36, Rob Sherwood  wrote:
> > Sorry... the "..." meant more packet_in's.
> >
> > - Rob
> > .
> >
> >
> > On Fri, Oct 15, 2010 at 9:15 PM, kk yap  wrote:
> >>
> >> < ERROR (vendor unsupported)
> >> < PACKET_IN (lldp)
> >> 
> >> and then disconnect
> >>
> >> Can I know the model of the switch, and what ... means?  The front
> >> part looks correct at a glance.  I am wondering why there is a LLDP
> >> without any packet out though.
> >>
> >> Regards
> >> KK
> >>
> >> PS>> Way to solve this:
> >> email
> >> more email
> >> 
> >> solved
> >>
> >> :)
> >>
> >> On 15 October 2010 21:10, Rob Sherwood 
> wrote:
> >> > KK: I've looked through the tcpdumps and the sequence is:
> >> >> HELLO
> >> > < HELLO
> >> >> FEATURE_REQUEST
> >> > < FEATURE_REPLY
> >> >> VENDOR MSG
> >> > < ERROR (vendor unsupported)
> >> > < PACKET_IN (lldp)
> >> > 
> >> > and then disconnect
> >> > - Rob
> >> > .
> >> >
> >> >
> >> > On Fri, Oct 15, 2010 at 9:07 PM, kk yap  wrote:
> >> >>
> >> >> What about having a tcpdump of the control traffic between NOX
> to/from
> >> >> FV, and FV to/from switch?  Each disconnection will have a new
> >> >> connection following it, then you will see the hellos, feature
> >> >> requests and replies, etc.
> >> >>
> >> >> I would like to see the NOX's log too.  NOX typically does not kill a
> >> >> connection silently.
> >> >>
> >> >> Just my knee-jerk reaction on how to debug this.
> >> >>
> >> >> Regards
> >> >> KK
> >> >>
> >> >> On 15 October 2010 20:23, Niky Riga  wrote:
> >> >> > Hi,
> >> >> >
> >> >> > We have installed the latest FlowVisor 0.6 beta5, but we still see
> >> >> > the
> >> >> > dpids
> >> >> > flapping.
> >> >> > Rob believes that it's nox that initiates the disconnection so I
> >> >> > would
> >> >> > like
> >> >> > to try and debug this.
> >> >> > Is there a way to increase the debug level beyond debug?:-) Where
> >> >> > should
> >> >> > I
> >> >> > start looking
> >> >> > in the code to see why nox decides to tear down a connection?
> >> >> >
> >> >> > Thanks,
> >> >> > Niky
> >> >> >
> >> >> > ___
> >> >> > nox-dev mailing list
> >> >> > nox-dev@noxrepo.org
> >> >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> >> >> >
> >> >>
> >> >> ___
> >> >> nox-dev mailing list
> >> >> nox-dev@noxrepo.org
> >> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> >> >
> >> >
> >
> >
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[kk yap]

Can someone send the pcap file on the list, so that people can
actually start doing real investigation here?  If it is too big, send
to Nick Bastin? (Sorry, Nick...)

I would still like to see the NOX's output.

Regards
KK

On 15 October 2010 21:36, Rob Sherwood  wrote:
> Sorry... the "..." meant more packet_in's.
>
> - Rob
> .
>
>
> On Fri, Oct 15, 2010 at 9:15 PM, kk yap  wrote:
>>
>> < ERROR (vendor unsupported)
>> < PACKET_IN (lldp)
>> 
>> and then disconnect
>>
>> Can I know the model of the switch, and what ... means?  The front
>> part looks correct at a glance.  I am wondering why there is a LLDP
>> without any packet out though.
>>
>> Regards
>> KK
>>
>> PS>> Way to solve this:
>> email
>> more email
>> 
>> solved
>>
>> :)
>>
>> On 15 October 2010 21:10, Rob Sherwood  wrote:
>> > KK: I've looked through the tcpdumps and the sequence is:
>> >> HELLO
>> > < HELLO
>> >> FEATURE_REQUEST
>> > < FEATURE_REPLY
>> >> VENDOR MSG
>> > < ERROR (vendor unsupported)
>> > < PACKET_IN (lldp)
>> > 
>> > and then disconnect
>> > - Rob
>> > .
>> >
>> >
>> > On Fri, Oct 15, 2010 at 9:07 PM, kk yap  wrote:
>> >>
>> >> What about having a tcpdump of the control traffic between NOX to/from
>> >> FV, and FV to/from switch?  Each disconnection will have a new
>> >> connection following it, then you will see the hellos, feature
>> >> requests and replies, etc.
>> >>
>> >> I would like to see the NOX's log too.  NOX typically does not kill a
>> >> connection silently.
>> >>
>> >> Just my knee-jerk reaction on how to debug this.
>> >>
>> >> Regards
>> >> KK
>> >>
>> >> On 15 October 2010 20:23, Niky Riga  wrote:
>> >> > Hi,
>> >> >
>> >> > We have installed the latest FlowVisor 0.6 beta5, but we still see
>> >> > the
>> >> > dpids
>> >> > flapping.
>> >> > Rob believes that it's nox that initiates the disconnection so I
>> >> > would
>> >> > like
>> >> > to try and debug this.
>> >> > Is there a way to increase the debug level beyond debug?:-) Where
>> >> > should
>> >> > I
>> >> > start looking
>> >> > in the code to see why nox decides to tear down a connection?
>> >> >
>> >> > Thanks,
>> >> > Niky
>> >> >
>> >> > ___
>> >> > nox-dev mailing list
>> >> > nox-dev@noxrepo.org
>> >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>> >> >
>> >>
>> >> ___
>> >> nox-dev mailing list
>> >> nox-dev@noxrepo.org
>> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>> >
>> >
>
>

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[Rob Sherwood]

Sorry... the "..." meant more packet_in's.

- Rob
.


On Fri, Oct 15, 2010 at 9:15 PM, kk yap  wrote:

> < ERROR (vendor unsupported)
> < PACKET_IN (lldp)
> 
> and then disconnect
>
> Can I know the model of the switch, and what ... means?  The front
> part looks correct at a glance.  I am wondering why there is a LLDP
> without any packet out though.
>
> Regards
> KK
>
> PS>> Way to solve this:
> email
> more email
> 
> solved
>
> :)
>
> On 15 October 2010 21:10, Rob Sherwood  wrote:
> > KK: I've looked through the tcpdumps and the sequence is:
> >> HELLO
> > < HELLO
> >> FEATURE_REQUEST
> > < FEATURE_REPLY
> >> VENDOR MSG
> > < ERROR (vendor unsupported)
> > < PACKET_IN (lldp)
> > 
> > and then disconnect
> > - Rob
> > .
> >
> >
> > On Fri, Oct 15, 2010 at 9:07 PM, kk yap  wrote:
> >>
> >> What about having a tcpdump of the control traffic between NOX to/from
> >> FV, and FV to/from switch?  Each disconnection will have a new
> >> connection following it, then you will see the hellos, feature
> >> requests and replies, etc.
> >>
> >> I would like to see the NOX's log too.  NOX typically does not kill a
> >> connection silently.
> >>
> >> Just my knee-jerk reaction on how to debug this.
> >>
> >> Regards
> >> KK
> >>
> >> On 15 October 2010 20:23, Niky Riga  wrote:
> >> > Hi,
> >> >
> >> > We have installed the latest FlowVisor 0.6 beta5, but we still see the
> >> > dpids
> >> > flapping.
> >> > Rob believes that it's nox that initiates the disconnection so I would
> >> > like
> >> > to try and debug this.
> >> > Is there a way to increase the debug level beyond debug?:-) Where
> should
> >> > I
> >> > start looking
> >> > in the code to see why nox decides to tear down a connection?
> >> >
> >> > Thanks,
> >> > Niky
> >> >
> >> > ___
> >> > nox-dev mailing list
> >> > nox-dev@noxrepo.org
> >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> >> >
> >>
> >> ___
> >> nox-dev mailing list
> >> nox-dev@noxrepo.org
> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> >
> >
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[Rob Sherwood]

Two of the switches are local to stanford and NECs:

necsw2  (00:00:00:12:e2:78:31:f5)
necsw(00:00:00:12:e2:78:67:65)

necsw is the main connection point to the other flowvisors, so it would
receive packet_in's from the other flowvisor.

- Rob
.


On Fri, Oct 15, 2010 at 9:15 PM, kk yap  wrote:

> < ERROR (vendor unsupported)
> < PACKET_IN (lldp)
> 
> and then disconnect
>
> Can I know the model of the switch, and what ... means?  The front
> part looks correct at a glance.  I am wondering why there is a LLDP
> without any packet out though.
>
> Regards
> KK
>
> PS>> Way to solve this:
> email
> more email
> 
> solved
>
> :)
>
> On 15 October 2010 21:10, Rob Sherwood  wrote:
> > KK: I've looked through the tcpdumps and the sequence is:
> >> HELLO
> > < HELLO
> >> FEATURE_REQUEST
> > < FEATURE_REPLY
> >> VENDOR MSG
> > < ERROR (vendor unsupported)
> > < PACKET_IN (lldp)
> > 
> > and then disconnect
> > - Rob
> > .
> >
> >
> > On Fri, Oct 15, 2010 at 9:07 PM, kk yap  wrote:
> >>
> >> What about having a tcpdump of the control traffic between NOX to/from
> >> FV, and FV to/from switch?  Each disconnection will have a new
> >> connection following it, then you will see the hellos, feature
> >> requests and replies, etc.
> >>
> >> I would like to see the NOX's log too.  NOX typically does not kill a
> >> connection silently.
> >>
> >> Just my knee-jerk reaction on how to debug this.
> >>
> >> Regards
> >> KK
> >>
> >> On 15 October 2010 20:23, Niky Riga  wrote:
> >> > Hi,
> >> >
> >> > We have installed the latest FlowVisor 0.6 beta5, but we still see the
> >> > dpids
> >> > flapping.
> >> > Rob believes that it's nox that initiates the disconnection so I would
> >> > like
> >> > to try and debug this.
> >> > Is there a way to increase the debug level beyond debug?:-) Where
> should
> >> > I
> >> > start looking
> >> > in the code to see why nox decides to tear down a connection?
> >> >
> >> > Thanks,
> >> > Niky
> >> >
> >> > ___
> >> > nox-dev mailing list
> >> > nox-dev@noxrepo.org
> >> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> >> >
> >>
> >> ___
> >> nox-dev mailing list
> >> nox-dev@noxrepo.org
> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> >
> >
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[kk yap]

< ERROR (vendor unsupported)
< PACKET_IN (lldp)

and then disconnect

Can I know the model of the switch, and what ... means?  The front
part looks correct at a glance.  I am wondering why there is a LLDP
without any packet out though.

Regards
KK

PS>> Way to solve this:
email
more email

solved

:)

On 15 October 2010 21:10, Rob Sherwood  wrote:
> KK: I've looked through the tcpdumps and the sequence is:
>> HELLO
> < HELLO
>> FEATURE_REQUEST
> < FEATURE_REPLY
>> VENDOR MSG
> < ERROR (vendor unsupported)
> < PACKET_IN (lldp)
> 
> and then disconnect
> - Rob
> .
>
>
> On Fri, Oct 15, 2010 at 9:07 PM, kk yap  wrote:
>>
>> What about having a tcpdump of the control traffic between NOX to/from
>> FV, and FV to/from switch?  Each disconnection will have a new
>> connection following it, then you will see the hellos, feature
>> requests and replies, etc.
>>
>> I would like to see the NOX's log too.  NOX typically does not kill a
>> connection silently.
>>
>> Just my knee-jerk reaction on how to debug this.
>>
>> Regards
>> KK
>>
>> On 15 October 2010 20:23, Niky Riga  wrote:
>> > Hi,
>> >
>> > We have installed the latest FlowVisor 0.6 beta5, but we still see the
>> > dpids
>> > flapping.
>> > Rob believes that it's nox that initiates the disconnection so I would
>> > like
>> > to try and debug this.
>> > Is there a way to increase the debug level beyond debug?:-) Where should
>> > I
>> > start looking
>> > in the code to see why nox decides to tear down a connection?
>> >
>> > Thanks,
>> > Niky
>> >
>> > ___
>> > nox-dev mailing list
>> > nox-dev@noxrepo.org
>> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>> >
>>
>> ___
>> nox-dev mailing list
>> nox-dev@noxrepo.org
>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
>

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[Rob Sherwood]

KK: I've looked through the tcpdumps and the sequence is:

> HELLO
< HELLO
> FEATURE_REQUEST
< FEATURE_REPLY
> VENDOR MSG
< ERROR (vendor unsupported)
< PACKET_IN (lldp)

and then disconnect

- Rob
.


On Fri, Oct 15, 2010 at 9:07 PM, kk yap  wrote:

> What about having a tcpdump of the control traffic between NOX to/from
> FV, and FV to/from switch?  Each disconnection will have a new
> connection following it, then you will see the hellos, feature
> requests and replies, etc.
>
> I would like to see the NOX's log too.  NOX typically does not kill a
> connection silently.
>
> Just my knee-jerk reaction on how to debug this.
>
> Regards
> KK
>
> On 15 October 2010 20:23, Niky Riga  wrote:
> > Hi,
> >
> > We have installed the latest FlowVisor 0.6 beta5, but we still see the
> dpids
> > flapping.
> > Rob believes that it's nox that initiates the disconnection so I would
> like
> > to try and debug this.
> > Is there a way to increase the debug level beyond debug?:-) Where should
> I
> > start looking
> > in the code to see why nox decides to tear down a connection?
> >
> > Thanks,
> > Niky
> >
> > ___
> > nox-dev mailing list
> > nox-dev@noxrepo.org
> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
> >
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[Rob Sherwood]

FYI, from the logs, nox is triggering the datapath_join() and then the
datapath_leave().

- Rob
.


On Fri, Oct 15, 2010 at 8:23 PM, Niky Riga  wrote:

> Hi,
>
> We have installed the latest FlowVisor 0.6 beta5, but we still see the
> dpids flapping.
> Rob believes that it's nox that initiates the disconnection so I would like
> to try and debug this.
> Is there a way to increase the debug level beyond debug?:-) Where should I
> start looking
> in the code to see why nox decides to tear down a connection?
>
> Thanks,
> Niky
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Dpids disconnecting

[kk yap]

What about having a tcpdump of the control traffic between NOX to/from
FV, and FV to/from switch?  Each disconnection will have a new
connection following it, then you will see the hellos, feature
requests and replies, etc.

I would like to see the NOX's log too.  NOX typically does not kill a
connection silently.

Just my knee-jerk reaction on how to debug this.

Regards
KK

On 15 October 2010 20:23, Niky Riga  wrote:
> Hi,
>
> We have installed the latest FlowVisor 0.6 beta5, but we still see the dpids
> flapping.
> Rob believes that it's nox that initiates the disconnection so I would like
> to try and debug this.
> Is there a way to increase the debug level beyond debug?:-) Where should I
> start looking
> in the code to see why nox decides to tear down a connection?
>
> Thanks,
> Niky
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] TCP packets are not parsed correctly

[Kyriakos Zarifis]

Hey Niky,

for a fast fix, and in order to avoid pulling/rebuilding, you can manually
apply this change in lib/packet/tcp.py
(somewhere around line 158 if I recall)

 self.options.append(tcp_opt(tcp_opt.MSS,val))
 elif arr[i] == tcp_opt.WSOPT:
 if arr[i+1] != 3:
raise Exception()
-val = struct.unpack('!H',arr[i+2:i+3])[0]
-self.options.append(tcp_opt(tcp_opt.WSOPT, val))
+self.options.append(tcp_opt(tcp_opt.WSOPT, arr[i+2]))

This should at least get you going immediately (and we'll push a full fix
asap).

On Fri, Oct 15, 2010 at 8:27 PM, Niky Riga  wrote:

> Hi,
>
> Given that this bug is blocking one of the Gec9 plenary demos, I would like
> to start debugging it.
> Do you have an idea where should I start looking? In which file do you
> believe the problem is?
>
> Thanks,
> niky
>
> Niky Riga wrote:
>
>> I am running nox zaku as released on the September 15th, should I update?
>>
>> --niky
>>
>> James McCauley wrote:
>>
>>>
>>> didn't look at the original problem, but the rolled back patch does look
>>> wrong to me. I think it's almost right now, but the last part should be
>>> arr[i + 2]
>>>
>>> On Oct 15, 2010 12:58 AM, "Kyriakos Zarifis" >> kyr.zari...@gmail.com>> wrote:
>>>
>>
>>
>> ___
>> nox-dev mailing list
>> nox-dev@noxrepo.org
>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>>
>
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] TCP packets are not parsed correctly

[Niky Riga]

Hi,

Given that this bug is blocking one of the Gec9 plenary demos, I would 
like to start debugging it.
Do you have an idea where should I start looking? In which file do you 
believe the problem is?


Thanks,
niky

Niky Riga wrote:

I am running nox zaku as released on the September 15th, should I update?

--niky

James McCauley wrote:


didn't look at the original problem, but the rolled back patch does 
look wrong to me. I think it's almost right now, but the last part 
should be arr[i + 2]


On Oct 15, 2010 12:58 AM, "Kyriakos Zarifis" > wrote:



___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org



___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

[nox-dev] Dpids disconnecting

[Niky Riga]

Hi,

We have installed the latest FlowVisor 0.6 beta5, but we still see the 
dpids flapping.
Rob believes that it's nox that initiates the disconnection so I would 
like to try and debug this.
Is there a way to increase the debug level beyond debug?:-) Where should 
I start looking

in the code to see why nox decides to tear down a connection?

Thanks,
Niky

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Problems about installing NOX 0.6.0

[kk yap]

Actually in this case, Chui-Hui will not be able to anything if we
have went the tarball way.  We are essentially not very customized to
CentOS.  Tarballs are also particularly hard to update.


Regards
KK

On 15 October 2010 18:04, Josh Smift  wrote:
> JM> Are you sure this is NOX 0.6.0? Where/how did you get the code? What
> JM> does "grep ^VERSION Makefile" (in your build directory) say?
>
> Sorry to keep banging this drum, but: This sort of thing would be a lot
> easier to keep track of if people who wanted a particular version could
> download a tarball or an OS-specific package, rather than just pulling
> directly from an array of git branches. :^(
>
>                                      -Josh (j...@bbn.com)
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Problems about installing NOX 0.6.0

[Josh Smift]

JM> Are you sure this is NOX 0.6.0? Where/how did you get the code? What
JM> does "grep ^VERSION Makefile" (in your build directory) say?

Sorry to keep banging this drum, but: This sort of thing would be a lot
easier to keep track of if people who wanted a particular version could
download a tarball or an OS-specific package, rather than just pulling
directly from an array of git branches. :^(

  -Josh (j...@bbn.com)

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Problems about installing NOX 0.6.0

[James "Murphy" McCauley]

Are you sure this is NOX 0.6.0?  Where/how did you get the code?  What does 
"grep ^VERSION Makefile" (in your build directory) say?

.. I just want to be sure we know what we're dealing with here.

-- Murphy

On Oct 15, 2010, at 3:01 PM, Chui-Hui Chiu wrote:

> Hi, all,
> 
> I have encountered a weird problem while installing NOX 0.6.0.
> 
> The following are the system settings on my host.
> 
> CentOS 5.5 Final - 2.6.18-194.17.1.el5PAE
> autoconf-2.63
> automake-1.10.3
> boost_1_44_0
> icu-4.4.2C
> libtool-2.4
> pcre-8.10
> Python-2.7
> swig-1.3.40
> Twisted-10.1.0
> xerces-c-3.1.1
> zope.interface-3.6.1
> 
> The configurations settings are
> 
> ./boot.sh --disable-ext --app-core
> ../configure --with-boost=/usr/local --with-python=/usr/local/bin/python
> 
> Here's the error message prompted when I compiled the NOX 0.6.0.
> 
> ../../../src/builtin/deployer.cc:142: error: expected initializer before '<' 
> token
> 
> make[5]: *** [deployer.lo] Error 1
> make[5]: Leaving directory 
> `/home/openflow/OpenFlowSwitch/nox/build/src/builtin'
> make[4]: *** [all] Error 2
> make[4]: Leaving directory 
> `/home/openflow/OpenFlowSwitch/nox/build/src/builtin'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/openflow/OpenFlowSwitch/nox/build/src'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/openflow/OpenFlowSwitch/nox/build/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/openflow/OpenFlowSwitch/nox/build'
> make: *** [all] Error 2
> 
> Hasn't the NOX 0.6.0 been released for a long time?  Having this syntax error 
> is unusual.  Is this a compatibility problem?  Does anyone have a solution?
> 
> 
> Sincerely,
> 
> CCH
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org


___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

[nox-dev] Problems about installing NOX 0.6.0

[Chui-Hui Chiu]

Hi, all,

I have encountered a weird problem while installing NOX 0.6.0.

The following are the system settings on my host.

CentOS 5.5 Final - 2.6.18-194.17.1.el5PAE
autoconf-2.63
automake-1.10.3
boost_1_44_0
icu-4.4.2C
libtool-2.4
pcre-8.10
Python-2.7
swig-1.3.40
Twisted-10.1.0
xerces-c-3.1.1
zope.interface-3.6.1

The configurations settings are

./boot.sh --disable-ext --app-core
../configure --with-boost=/usr/local --with-python=/usr/local/bin/python

Here's the error message prompted when I compiled the NOX 0.6.0.

../../../src/builtin/deployer.cc:142: error: expected initializer before '<'
token

make[5]: *** [deployer.lo] Error 1
make[5]: Leaving directory
`/home/openflow/OpenFlowSwitch/nox/build/src/builtin'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/home/openflow/OpenFlowSwitch/nox/build/src/builtin'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/openflow/OpenFlowSwitch/nox/build/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/openflow/OpenFlowSwitch/nox/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/openflow/OpenFlowSwitch/nox/build'
make: *** [all] Error 2

Hasn't the NOX 0.6.0 been released for a long time?  Having this syntax
error is unusual.  Is this a compatibility problem?  Does anyone have a
solution?


Sincerely,

CCH
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] TCP packets are not parsed correctly

[Niky Riga]

I am running nox zaku as released on the September 15th, should I update?

--niky

James McCauley wrote:


didn't look at the original problem, but the rolled back patch does 
look wrong to me. I think it's almost right now, but the last part 
should be arr[i + 2]


On Oct 15, 2010 12:58 AM, "Kyriakos Zarifis" > wrote:



___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Monitoring timers are not canceled when a dpid disconnects [was : Re: Problem with stat requests and reply]

[Niky Riga]

This is sort of my solution as well, with the only exception. Because 
the switch might connect, disconnects and connect again before
the timer fires, in which case the if connected[dpid] will return true 
although there was a disconnection in the middle, I also keep
track of which dpids currently have a periodic timer firing and check 
befor starting a new one when the connection come in.


In your code :

handle_dp_join():
 connected[dpid]=True
 if dpid not in set_timers  :
 post(period, request_stats)
 set_timers += [dpid]

request_stats():
 send_stats_request
 if connected[dpid]:
   post(request_stats_event, seconds)
 else :
set_timers.remove(dpid)

Niky



Kyriakos Zarifis wrote:
right. I guess timer1 should be refreshed only if the switch is still 
connected, which means you'd need to keep track of connection status 
per switch. When the switch disconnects, is that detected, and is a 
relevant event raised?

If so, maybe you could do something like

handle_dp_join():
  connected[dpid]=True
  post(period, request_stats)

handle_dp_leave():
  connected[dpid]=False

request_stats():
  send_stats_request
  if connected[dpid]:
post(request_stats_event, seconds)

and so if one session has timed out the corresponding timer will not 
reset, and just send one last request which will either time out or be 
caught in the next session?




On Fri, Oct 15, 2010 at 12:27 AM, Nicholas Bastin 
mailto:nbas...@stanford.edu>> wrote:


On Thu, Oct 14, 2010 at 23:58, kk yap mailto:yap...@stanford.edu>> wrote:

Guess no one wants to read the lengthy email.  Here's the question
with an re-enactment:
1. Switch connected to NOX
2. NOX send stat request
3. Switch disconnect from NOX
4. Switch reconnects to NOX
Now, should or can the switch send the stat reply for step 2?

I believe this what the FlowVisor is presenting to NOX.  I
might be
wrong, but that's how I have read this thread.


I don't read it that way.  I read it this way:

1. Switch connects to NOX
2. NOX starts timer1 that will periodically send stat requests
(the callback resets the timer)
3. Switch disconnects from NOX
4. Switch reconnects to NOX *before*  timer1 fires (and would error)
5. NOX starts timer2 that will periodically send stat requests
(because a "new" switch attached)
6. timer1 fires and then sets itself again
7. timer2 fires and then sets itself again

Rinse, lather, repeat.

Once you flap the switch a few times, instead of sending a stat
request every 10 seconds, you're sending a lot every second
because you now have a bunch of timers per switch.  Ultimately
this is a logic problem in the app, but it's exacerbated by NOX
not giving a handle to the timer, so you can't cancel it or even
know you still have it going on unless you keep track of that
yourself.

--
Nick

___
nox-dev mailing list
nox-dev@noxrepo.org 
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org




___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
  



___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] TCP packets are not parsed correctly

[James McCauley]

didn't look at the original problem, but the rolled back patch does look
wrong to me. I think it's almost right now, but the last part should be
arr[i + 2]
On Oct 15, 2010 12:58 AM, "Kyriakos Zarifis"  wrote:
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] TCP packets are not parsed correctly

[Kyriakos Zarifis]

Hi Niky,

something tells me this was introduced with a patch that I was asked to push
a while back (df58e02b9dec24564878e0d77274f551d349e070). I reverted it for
now, which I think temporarily corrects this (can you verify?) and i'll try
to push a real fix soon.

On Thu, Oct 14, 2010 at 9:47 PM, Niky Riga  wrote:

> Hi,
> I am running the zaku release for nox, and I am using a python module.
>
> I believe that there is a bug when parsing tcp packets in the pythong
> modules.
> I have a simple module that registers for the packet_in event.
>
> When a packet is received, and after the packet is parsed, I print the
> packet and the outcome is weird.
> For udp traffic the output is more normal.
>
> CODE:
> def packet_in_callback(dpid, inport, reason, len, bufid, packet):
>   if not packet.parsed:
>   log.msg('Ignoring incomplete packet',system='smartre')
>
>   # don't forward lldp packets  if packet.type == ethernet.LLDP_TYPE:
>   return CONTINUE
>   print packet
>   print type(packet)
>   print type(packet.next.next).mro()
>
> OUPUT  (TCP) :
> 00122|openflow-event|DBG:received packet-in event from e2b8dc3b1753
> (len:74)
> [(VMware, Inc.):f7:5b:1a>(Intel
> Corporate):e7:b8:9a:IP]([v:4hl:5l:60t:64]TCP
> cs:6a0d[10.17.53.201>10.17.53.101])?o#x??K??r??
> $?
> 
> [, , ]
>
> OUPUT (UDP) :
> [(Intel Corporate):5a:e7:4d>(Intel
> Corporate):5f:8a:c5:IP]([v:4hl:5l:30t:64]UDP
> cs:1d39[10.17.53.201>10.17.53.101]){33254>5000} l:10 c: 34577
> 
> [, ]
>
> Any ideas what might be wrong in parsing the packet?
>
> Thanks,
> Niky
>
>
>
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] TCP packets are not parsed correctly

[Kyriakos Zarifis]

Hi Niky,

something tells me this was introduced with a patch that I was asked to push
a while back (df58e02b9dec24564878e0d77274f551d349e070). I reverted it for
now, which I think corrects this temporarily (can you verify?) and i'll try
to correct the fix soon.

On Thu, Oct 14, 2010 at 9:47 PM, Niky Riga  wrote:

> Hi,
> I am running the zaku release for nox, and I am using a python module.
>
> I believe that there is a bug when parsing tcp packets in the pythong
> modules.
> I have a simple module that registers for the packet_in event.
>
> When a packet is received, and after the packet is parsed, I print the
> packet and the outcome is weird.
> For udp traffic the output is more normal.
>
> CODE:
> def packet_in_callback(dpid, inport, reason, len, bufid, packet):
>   if not packet.parsed:
>   log.msg('Ignoring incomplete packet',system='smartre')
>
>   # don't forward lldp packets  if packet.type == ethernet.LLDP_TYPE:
>   return CONTINUE
>   print packet
>   print type(packet)
>   print type(packet.next.next).mro()
>
> OUPUT  (TCP) :
> 00122|openflow-event|DBG:received packet-in event from e2b8dc3b1753
> (len:74)
> [(VMware, Inc.):f7:5b:1a>(Intel
> Corporate):e7:b8:9a:IP]([v:4hl:5l:60t:64]TCP
> cs:6a0d[10.17.53.201>10.17.53.101])?o#x??K??r??
> $?
> 
> [, , ]
>
> OUPUT (UDP) :
> [(Intel Corporate):5a:e7:4d>(Intel
> Corporate):5f:8a:c5:IP]([v:4hl:5l:30t:64]UDP
> cs:1d39[10.17.53.201>10.17.53.101]){33254>5000} l:10 c: 34577
> 
> [, ]
>
> Any ideas what might be wrong in parsing the packet?
>
> Thanks,
> Niky
>
>
>
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Monitoring timers are not canceled when a dpid disconnects [was : Re: Problem with stat requests and reply]

[Kyriakos Zarifis]

right. I guess timer1 should be refreshed only if the switch is still
connected, which means you'd need to keep track of connection status per
switch. When the switch disconnects, is that detected, and is a relevant
event raised?
If so, maybe you could do something like

handle_dp_join():
  connected[dpid]=True
  post(period, request_stats)

handle_dp_leave():
  connected[dpid]=False

request_stats():
  send_stats_request
  if connected[dpid]:
post(request_stats_event, seconds)

and so if one session has timed out the corresponding timer will not reset,
and just send one last request which will either time out or be caught in
the next session?



On Fri, Oct 15, 2010 at 12:27 AM, Nicholas Bastin wrote:

> On Thu, Oct 14, 2010 at 23:58, kk yap  wrote:
>
>> Guess no one wants to read the lengthy email.  Here's the question
>> with an re-enactment:
>> 1. Switch connected to NOX
>> 2. NOX send stat request
>> 3. Switch disconnect from NOX
>> 4. Switch reconnects to NOX
>> Now, should or can the switch send the stat reply for step 2?
>>
>> I believe this what the FlowVisor is presenting to NOX.  I might be
>> wrong, but that's how I have read this thread.
>>
>
> I don't read it that way.  I read it this way:
>
> 1. Switch connects to NOX
> 2. NOX starts timer1 that will periodically send stat requests (the
> callback resets the timer)
> 3. Switch disconnects from NOX
> 4. Switch reconnects to NOX *before*  timer1 fires (and would error)
> 5. NOX starts timer2 that will periodically send stat requests (because a
> "new" switch attached)
> 6. timer1 fires and then sets itself again
> 7. timer2 fires and then sets itself again
>
> Rinse, lather, repeat.
>
> Once you flap the switch a few times, instead of sending a stat request
> every 10 seconds, you're sending a lot every second because you now have a
> bunch of timers per switch.  Ultimately this is a logic problem in the app,
> but it's exacerbated by NOX not giving a handle to the timer, so you can't
> cancel it or even know you still have it going on unless you keep track of
> that yourself.
>
> --
> Nick
>
> ___
> nox-dev mailing list
> nox-dev@noxrepo.org
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Monitoring timers are not canceled when a dpid disconnects [was : Re: Problem with stat requests and reply]

[kk yap]

Just to clarify, I am just asking if the spec allows the switch to
send a reply after a disconnection.  Just want to make the spec more
rigorous.

Regards
KK

On 15 October 2010 00:27, Nicholas Bastin  wrote:
> On Thu, Oct 14, 2010 at 23:58, kk yap  wrote:
>>
>> Guess no one wants to read the lengthy email.  Here's the question
>> with an re-enactment:
>> 1. Switch connected to NOX
>> 2. NOX send stat request
>> 3. Switch disconnect from NOX
>> 4. Switch reconnects to NOX
>> Now, should or can the switch send the stat reply for step 2?
>>
>> I believe this what the FlowVisor is presenting to NOX.  I might be
>> wrong, but that's how I have read this thread.
>
> I don't read it that way.  I read it this way:
>
> 1. Switch connects to NOX
> 2. NOX starts timer1 that will periodically send stat requests (the callback
> resets the timer)
> 3. Switch disconnects from NOX
> 4. Switch reconnects to NOX *before*  timer1 fires (and would error)
> 5. NOX starts timer2 that will periodically send stat requests (because a
> "new" switch attached)
> 6. timer1 fires and then sets itself again
> 7. timer2 fires and then sets itself again
>
> Rinse, lather, repeat.
>
> Once you flap the switch a few times, instead of sending a stat request
> every 10 seconds, you're sending a lot every second because you now have a
> bunch of timers per switch.  Ultimately this is a logic problem in the app,
> but it's exacerbated by NOX not giving a handle to the timer, so you can't
> cancel it or even know you still have it going on unless you keep track of
> that yourself.
>
> --
> Nick
>

___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Monitoring timers are not canceled when a dpid disconnects [was : Re: Problem with stat requests and reply]

[Nicholas Bastin]

On Thu, Oct 14, 2010 at 23:58, kk yap  wrote:

> Guess no one wants to read the lengthy email.  Here's the question
> with an re-enactment:
> 1. Switch connected to NOX
> 2. NOX send stat request
> 3. Switch disconnect from NOX
> 4. Switch reconnects to NOX
> Now, should or can the switch send the stat reply for step 2?
>
> I believe this what the FlowVisor is presenting to NOX.  I might be
> wrong, but that's how I have read this thread.
>

I don't read it that way.  I read it this way:

1. Switch connects to NOX
2. NOX starts timer1 that will periodically send stat requests (the callback
resets the timer)
3. Switch disconnects from NOX
4. Switch reconnects to NOX *before*  timer1 fires (and would error)
5. NOX starts timer2 that will periodically send stat requests (because a
"new" switch attached)
6. timer1 fires and then sets itself again
7. timer2 fires and then sets itself again

Rinse, lather, repeat.

Once you flap the switch a few times, instead of sending a stat request
every 10 seconds, you're sending a lot every second because you now have a
bunch of timers per switch.  Ultimately this is a logic problem in the app,
but it's exacerbated by NOX not giving a handle to the timer, so you can't
cancel it or even know you still have it going on unless you keep track of
that yourself.

--
Nick
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org

Re: [nox-dev] Monitoring timers are not canceled when a dpid disconnects [was : Re: Problem with stat requests and reply]

[kk yap]

Guess no one wants to read the lengthy email.  Here's the question
with an re-enactment:
1. Switch connected to NOX
2. NOX send stat request
3. Switch disconnect from NOX
4. Switch reconnects to NOX
Now, should or can the switch send the stat reply for step 2?

I believe this what the FlowVisor is presenting to NOX.  I might be
wrong, but that's how I have read this thread.

Regards
KK

On 14 October 2010 23:46, Brandon Heller  wrote:
> I don't know what you mean by "responding to old stat requests".
> -b
>
> On Thu, Oct 14, 2010 at 9:30 PM, kk yap  wrote:
>>
>> Okay,
>>
>> I see what is the problem with NOX, but it seems like there is also a
>> problem with the FlowVisor.
>>
>> If a switch disconnects from NOX and reconnects, it would not (or
>> rather should not) reply to old stat requests?  This is the behavior
>> FlowVisor is presenting to NOX.  I am not sure here.  I believe the
>> spec is unclear.  So, I have cc-ed Glen and Brandon here for
>> clarification.
>>
>> Regards
>> KK
>>
>> On 14 October 2010 21:18, Niky Riga  wrote:
>> > Actually the problem arose because a switch was flapping,
>> > i.e. it was connecting and disconnecting periodically, causing multiple
>> > timers
>> > to be set and ending in stat timers firing multiple times per second
>> > requesting
>> > for stats even when the switch was in the middle of establishing the
>> > connection.
>> >
>> > This is how this works:
>> >
>> > - Everytime a switch is  connected a new timer is set  for requesting
>> > stats.
>> > This timer periodically fires.
>> >
>> > - When the switch is disconnected the timer is not canceled, but keeps
>> > periodically expiring.
>> >
>> > - When the switch is connected again a new series of timers is being
>> > started, so now the number of
>> > requests are doubled.
>> >
>> > - if the switch keeps flapping, we end up with n times more that
>> > expected
>> > stat requests, and can easily get up
>> > to 100s of requests per second.
>> >
>> > Nick Bastin, helped  debugging this and he thinks that there is no
>> > cancel
>> > timer functionality to call when
>> > a switch is disconnected. I have worked around this by keeping track of
>> > which dpid has already a timer set
>> > and not resetting one when it reconnects.
>> >
>> > Regarding wireshark, yes I used the tarball, I will get the one from
>> > git.
>> >
>> > Thanks,
>> > Niky
>> >
>> >
>> > James "Murphy" McCauley wrote:
>> >>
>> >> In the "Monitor module crashes" thead, I mentioned that I thought the
>> >> "controller" looked like it was doing weird stuff, but to be clear, I
>> >> meant
>> >> FlowVisor and not NOX.  It looks to me like FlowVisor is sending some
>> >> things
>> >> at weird times (for example, sending something weird during handshaking
>> >> is
>> >> where your crash was coming from... and that bug had been in NOX for
>> >> quite
>> >> some time without it ever coming up, apparently).
>> >>
>> >> Did you build the wireshark module from the OpenFlow tarball?  I think
>> >> that table stats reply dissecting is broken in the tarball, so my guess
>> >> is
>> >> that's why you're getting those errors in wireshark.  You should build
>> >> it
>> >> from the git repository.
>> >> -- Murphy
>> >>
>> >> On Oct 14, 2010, at 1:39 AM, Niky Riga wrote:
>> >>
>> >>
>> >>>
>> >>> Hi,
>> >>>
>> >>> I am using nox zaku and FV 0.4 beta4. I have been having problems with
>> >>> a module that pokes periodically the switches for statistics.
>> >>>
>> >>> In an effort to debug this, I made a clean installation of nox (zaku
>> >>> release)
>> >>> and run the default monitoring module of nox. And the problems
>> >>> persisted.
>> >>>
>> >>> Basically I was seeing errors in the controller of the type :
>> >>>
>> >>> 8163|nox|DBG:Success receiving in 'receiving features reply'
>> >>> 08164|nox|WARN:Received unsupported message type during handshake (17)
>> >>>
>> >>> I tried to run it with wireshark to be able to debug a little bit
>> >>> further
>> >>> but by the
>> >>> time I have set up my environment, the switches that were causing that
>> >>> had
>> >>> dropped of my FV.
>> >>>
>> >>> I was still seeing some errors from the remaining switches :
>> >>>
>> >>> 00112|openflow-event|ERR:received Openflow error packet from
>> >>> dpid=6c60026f13fe480: type=3, code=2, 72 bytes of data
>> >>> 00146|openflow-event|ERR:received Openflow error packet from
>> >>> dpid=6b20026f13f3b00: type=3, code=2, 72 bytes of data
>> >>> 00151|openflow-event|ERR:received Openflow error packet from
>> >>> dpid=e2b8dc3b1750: type=3, code=2, 72 bytes of data
>> >>>
>> >>> Running wireshark, the only thing I noticed was periodic messages of :
>> >>> 04:14:14          Warn Dissector bug, protocol OFP, in packet 20286:
>> >>> proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len"
>> >>> 04:14:14          Warn Dissector bug, protocol OFP, in packet 20345:
>> >>> proto.c:1389: failed assertion "(guint)hfindex < gpa_hfinfo.len"
>> >>> 04:14:15          Warn Dissector bug, protocol OF