[nox-dev] Handling corrupted TCP header
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is because
this incoming tcp packet has nw_proto=6 and tcp port numbers of 0,
but outgoing flow_mod has nw_proto of 0 and tcp port numbers of 0.
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be 0 in the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a invalid
TCP packet. Does anyone see problems with removing the else clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp-tcp_src;
tp_dst = tcp-tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Buffer b)
{
if (const tcp_header *tcp = b.try_attcp_header(0)) {
int tcp_len = TCP_OFFSET(tcp-tcp_ctl) * 4;
if (tcp_len = sizeof *tcp) {
return reinterpret_castconst tcp_header*(b.try_pull(tcp_len));
}
}
return 0;
}
attachment: packet_with_bad_tcp_offset.PNG___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Handling corrupted TCP header
Hi Srini,
What is this packet? The length of TCP is zero?!?! I wish to
understand the circumstance for which we are getting the packet before
commenting on the right way to handle this.
Regards
KK
On 13 January 2011 10:38, Srini Seetharaman seeth...@stanford.edu wrote:
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is because
this incoming tcp packet has nw_proto=6 and tcp port numbers of 0,
but outgoing flow_mod has nw_proto of 0 and tcp port numbers of 0.
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be 0 in the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a invalid
TCP packet. Does anyone see problems with removing the else clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp-tcp_src;
tp_dst = tcp-tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Buffer b)
{
if (const tcp_header *tcp = b.try_attcp_header(0)) {
int tcp_len = TCP_OFFSET(tcp-tcp_ctl) * 4;
if (tcp_len = sizeof *tcp) {
return reinterpret_castconst
tcp_header*(b.try_pull(tcp_len));
}
}
return 0;
}
___
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] Handling corrupted TCP header
We don't know who sent it, but it came from outside our network. If it
is easy to take down a network by just sending 1 invalid packet, I'd
be worried!
On Thu, Jan 13, 2011 at 10:59 AM, kk yap yap...@stanford.edu wrote:
Hi Srini,
What is this packet? The length of TCP is zero?!?! I wish to
understand the circumstance for which we are getting the packet before
commenting on the right way to handle this.
Regards
KK
On 13 January 2011 10:38, Srini Seetharaman seeth...@stanford.edu wrote:
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is because
this incoming tcp packet has nw_proto=6 and tcp port numbers of 0,
but outgoing flow_mod has nw_proto of 0 and tcp port numbers of 0.
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be 0 in the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a invalid
TCP packet. Does anyone see problems with removing the else clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp-tcp_src;
tp_dst = tcp-tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Buffer b)
{
if (const tcp_header *tcp = b.try_attcp_header(0)) {
int tcp_len = TCP_OFFSET(tcp-tcp_ctl) * 4;
if (tcp_len = sizeof *tcp) {
return reinterpret_castconst
tcp_header*(b.try_pull(tcp_len));
}
}
return 0;
}
___
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] Handling corrupted TCP header
Hi Srini,
I think you are fixing this in the wrong place. Putting nw_proto=0
does not cause an infinite loop. Where is the loop happening? Can
you provide more detailed NOX output so that we can even start looking
at this.
Regards
KK
On 13 January 2011 11:02, Srini Seetharaman seeth...@stanford.edu wrote:
We don't know who sent it, but it came from outside our network. If it
is easy to take down a network by just sending 1 invalid packet, I'd
be worried!
On Thu, Jan 13, 2011 at 10:59 AM, kk yap yap...@stanford.edu wrote:
Hi Srini,
What is this packet? The length of TCP is zero?!?! I wish to
understand the circumstance for which we are getting the packet before
commenting on the right way to handle this.
Regards
KK
On 13 January 2011 10:38, Srini Seetharaman seeth...@stanford.edu wrote:
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is because
this incoming tcp packet has nw_proto=6 and tcp port numbers of 0,
but outgoing flow_mod has nw_proto of 0 and tcp port numbers of 0.
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be 0 in the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a invalid
TCP packet. Does anyone see problems with removing the else clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp-tcp_src;
tp_dst = tcp-tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Buffer b)
{
if (const tcp_header *tcp = b.try_attcp_header(0)) {
int tcp_len = TCP_OFFSET(tcp-tcp_ctl) * 4;
if (tcp_len = sizeof *tcp) {
return reinterpret_castconst
tcp_header*(b.try_pull(tcp_len));
}
}
return 0;
}
___
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] C++ Posting Timer Error
Hi, I am writing a component in C++ that uses a timer.
In the .hh file I put:
*Timer post(const Timer_Callback, const timeval duration) const;
Disposition handle_datapath_join(const Event e);*
And in the .cc file there is a post that calls a timer method:
*#include timeval.hh
#include timer-dispatcher.hh*
* Disposition newcomp::handle_datapath_join(const Event e) {
timeval tv={1,0};
post(boost::bind(newcomp::timer,this), tv);
return CONTINUE;
}
*
And the timer method:*
void newcomp::timer() {
lg.dbg(One second has passed...\n);
}
*
It compiles normally but when I tried to execute it, I got the following
message:
*00043|nox|ERR:Cannot change the state of 'newcomp' to INSTALLED:
'newcomp' ran into an error:
Can't open a dynamic library: 'nox/netapps/newcomp/newcomp.so: cannot
open shared object file: No such file or directory' or
'nox/netapps/newcomp/.libs/newcomp.so: undefined symbol:
vigil::applications::newcomp::post(boost::functionvoid ()() const,
timeval const) const'
*Any suggestions to solve this problems?
Best Regards.*
*
--
Ricardo Bennesby da Silva
Ciência da Computação - UFAM
LabCIA - Laboratório de Computação Inteligente e Autônoma
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Handling corrupted TCP header
KK,
I think the implementer will read the spec the other way around.
Spec requires nothing special about OFPP_TABLE action (it does not say
don't generate pkt_in, if there is no match). So the switch
just follows the default behavior, i.e., pkt_in will be generated.
I would expect the reference design also does the same.
Masa
On 01/13/2011 06:38 PM, kk yap wrote:
Because the action of pkt_out is OFPP_TABLE.
(the packet in pkt_out does not match to the entry that is installed by
flow_mod, since the matching entry says nw_proto=0).
Is there anything in the spec that says that the switch should send
another packet-in if there is no matching entry for a OFPP_TABLE? I
am failing to find that. Can someone point to why this behavior is
specified by the spec?
Regards
KK
On 13 January 2011 18:28, Masayoshi Kobayashimkoba...@stanford.edu wrote:
KK,
I thought about it a little. Why is the switch doing step 7?
Because the action of pkt_out is OFPP_TABLE.
(the packet in pkt_out does not match to the entry that is installed by
flow_mod, since the matching entry says nw_proto=0).
Masa
On 01/13/2011 06:06 PM, kk yap wrote:
Hi Srini,
I thought about it a little. Why is the switch doing step 7?
Anyway, I do agree that NOX is not handling malformed packets right.
I have included an invalid field in the struct flow, and created a
component that ignore invalid packets. If anyone will double-check
and test the patches attached, I will push it.
Regards
KK
On 13 January 2011 16:13, Srini Seetharamanseeth...@stanford.eduwrote:
I explained this to KK in person. For others, here is the sequence of
events:
1. Packet arrives with (nw_proto=6, tp_src=0, tp_dst=0). Store in bufid
'X'
2. flow.cc identifies that the arrived TCP packet is corrupted, and
generates
pkt_in event with flow structure having (nw_proto=0, tp_src=0,
tp_dst=0)
3. Authenticator generates a flow_in with flow_in.flow being same as
above
3. routing.cc generates a flow_mod for the flow_in with the match pattern
defined using the fields of the flow_in.flow
4. Switch inserts a flow table entry for matching (nw_proto=0,
tp_src=0, tp_dst=0)
5. routing.cc generates a pkt_out for the bufid 'X' with action =
OFPP_TABLE
6. Switch notices that the packet in bufid 'X' has no matching flow table
entry,
because there is a mismatch on the nw_proto field
7. Switch generates a new pkt_in event
8. Go to step (2)
This is the infinite loop.
Srini.
On Thu, Jan 13, 2011 at 1:08 PM, kk yapyap...@stanford.eduwrote:
Hi Srini,
I think you are fixing this in the wrong place. Putting nw_proto=0
does not cause an infinite loop. Where is the loop happening? Can
you provide more detailed NOX output so that we can even start looking
at this.
Regards
KK
On 13 January 2011 11:02, Srini Seetharamanseeth...@stanford.edu
wrote:
We don't know who sent it, but it came from outside our network. If it
is easy to take down a network by just sending 1 invalid packet, I'd
be worried!
On Thu, Jan 13, 2011 at 10:59 AM, kk yapyap...@stanford.eduwrote:
Hi Srini,
What is this packet? The length of TCP is zero?!?! I wish to
understand the circumstance for which we are getting the packet before
commenting on the right way to handle this.
Regards
KK
On 13 January 2011 10:38, Srini Seetharamanseeth...@stanford.edu
wrote:
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is
because
this incoming tcp packet has nw_proto=6 and tcp port numbers of 0,
but outgoing flow_mod has nw_proto of 0 and tcp port numbers of
0.
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be 0 in
the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a
invalid
TCP packet. Does anyone see problems with removing the else clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp-tcp_src;
tp_dst = tcp-tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Bufferb)
{
if (const tcp_header *tcp = b.try_attcp_header(0)) {
int tcp_len = TCP_OFFSET(tcp-tcp_ctl) * 4;
if (tcp_len= sizeof *tcp) {
return reinterpret_castconst
tcp_header*(b.try_pull(tcp_len));
}
}
return 0;
}
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
___
nox-dev mailing list
[nox-dev] pytopology patch
Hi, I have added 2 new functions to pytopology that makes it more useful/usable: * get_datapaths() : returns a list of all datapathids in the network * get_neighbors(dpid) : returns a list of neighbors of a given datapathid. I've attached a patch for the destiny branch (commit no. 5917f412d6d2a23ce5373ec499872cb8b40833e8). Thanks, Nikhil pytopology_destiny.patch Description: Binary data ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] pytopology patch
Awesome, thanks Nikhil. Hi, I have added 2 new functions to pytopology that makes it more useful/usable: * get_datapaths() : returns a list of all datapathids in the network * get_neighbors(dpid) : returns a list of neighbors of a given datapathid. I've attached a patch for the destiny branch (commit no. 5917f412d6d2a23ce5373ec499872cb8b40833e8). Thanks, Nikhil ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org -- ~~~ Martin Casado Nicira Networks, Inc. www.nicira.com | www.openvswitch.org cell: 650-776-1457 ~~~ ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
