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 Seetharaman <seeth...@stanford.edu> wrote:
> 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 <yap...@stanford.edu> 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 <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_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
>>>>> nox-dev@noxrepo.org
>>>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>>>>>
>>>>>
>>>>
>>>
>>
>
invalid-packets-check.tgz
Description: GNU Zip compressed data
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
