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 yap <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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_at<tcp_header>(0)) {
>>>> int tcp_len = TCP_OFFSET(tcp->tcp_ctl) * 4;
>>>> if (tcp_len >= sizeof *tcp) {
>>>> return reinterpret_cast<const
>>>> tcp_header*>(b.try_pull(tcp_len));
>>>> }
>>>> }
>>>> return 0;
>>>> }
>>>>
>>>> _______________________________________________
>>>> nox-dev mailing list
>>>> [email protected]
>>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>>>>
>>>>
>>>
>>
>
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
