Mailing List Archive: NTop: Misc

GTP bug in PF_RING

Index | Next | Previous | View Threaded

xutao881001 at gmail

Jul 25, 2012, 7:57 PM

Post #1 of 6 (485 views)
Permalink

GTP bug in PF_RING

OS: RHEL6.3

[root [at] mirro ~]# uname -a
Linux mirror 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

[root [at] mirro ~]# cat /etc/issue
Red Hat Enterprise Linux Server release 6.3 (Santiago)
Kernel \r on an \m

This problem in PF_RING 5.4.4 & PF_RING 5.4.5

I had sent a letter to describe this problem last week.

Sometimes the cpu load is very high and si is always 100%, when I using PF_RING(5.4.4&5.4.5). I haven't found this situation in old PF_RING.

I found the code(pf_ring.c, parse_raw_pkt):

1965 do {
1966 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8 bit len field */)) return(1);
1967 gtpext = (struct gtp_v1_ext_hdr *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
1969 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len)) return(1);
1970 next_ext_hdr = (u_int8_t *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len - 1 /* 8 bit next_ext_hdr field*/]);
1971 } while (next_ext_hdr);

the next_ext_hdr is a pointer, so the (next_ext_hdr) is always true. Also when the gtpext->len is 0, this is a dead loop.

I think this make the si is always 100% and make the system down.

After I change "while(next_ext_hdr)" to "while(*next_ext_hdr)", I haven't seen this again until now.

--
XTao
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

cardigliano at ntop

Jul 25, 2012, 11:18 PM

Post #2 of 6 (447 views)
Permalink

Re: GTP bug in PF_RING [In reply to]

XTao
thank you, this will be fixed immediately in svn

Alfredo

On Jul 26, 2012, at 4:57 AM, XTao wrote:

> OS: RHEL6.3
>
> [root [at] mirro ~]# uname -a
> Linux mirror 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> [root [at] mirro ~]# cat /etc/issue
> Red Hat Enterprise Linux Server release 6.3 (Santiago)
> Kernel \r on an \m
>
> This problem in PF_RING 5.4.4 & PF_RING 5.4.5
>
> I had sent a letter to describe this problem last week.
>
> Sometimes the cpu load is very high and si is always 100%, when I using PF_RING(5.4.4&5.4.5). I haven't found this situation in old PF_RING.
>
> I found the code(pf_ring.c, parse_raw_pkt):
>
> 1965 do {
> 1966 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8 bit len field */)) return(1);
> 1967 gtpext = (struct gtp_v1_ext_hdr *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
> 1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
> 1969 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len)) return(1);
> 1970 next_ext_hdr = (u_int8_t *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len - 1 /* 8 bit next_ext_hdr field*/]);
> 1971 } while (next_ext_hdr);
>
> the next_ext_hdr is a pointer, so the (next_ext_hdr) is always true. Also when the gtpext->len is 0, this is a dead loop.
>
> I think this make the si is always 100% and make the system down.
>
> After I change "while(next_ext_hdr)" to "while(*next_ext_hdr)", I haven't seen this again until now.
>
> --
> XTao
> Sent with Sparrow
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

xutao881001 at gmail

Jul 25, 2012, 11:29 PM

Post #3 of 6 (450 views)
Permalink

Re: GTP bug in PF_RING [In reply to]

The system is totally down again.
So I think there may be still some problem.

--
XTao
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Thursday, July 26, 2012 at 2:18 PM, Alfredo Cardigliano wrote:

> XTao
> thank you, this will be fixed immediately in svn
>
> Alfredo
>
> On Jul 26, 2012, at 4:57 AM, XTao wrote:
> > OS: RHEL6.3
> >
> > [root [at] mirro ~]# uname -a
> > Linux mirror 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
> >
> >
> > [root [at] mirro ~]# cat /etc/issue
> > Red Hat Enterprise Linux Server release 6.3 (Santiago)
> > Kernel \r on an \m
> >
> >
> > This problem in PF_RING 5.4.4 & PF_RING 5.4.5
> >
> > I had sent a letter to describe this problem last week.
> >
> > Sometimes the cpu load is very high and si is always 100%, when I using PF_RING(5.4.4&5.4.5). I haven't found this situation in old PF_RING.
> >
> > I found the code(pf_ring.c, parse_raw_pkt):
> >
> > 1965 do {
> > 1966 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8 bit len field */)) return(1);
> > 1967 gtpext = (struct gtp_v1_ext_hdr *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
> > 1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
> > 1969 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len)) return(1);
> > 1970 next_ext_hdr = (u_int8_t *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len - 1 /* 8 bit next_ext_hdr field*/]);
> > 1971 } while (next_ext_hdr);
> >
> > the next_ext_hdr is a pointer, so the (next_ext_hdr) is always true. Also when the gtpext->len is 0, this is a dead loop.
> >
> > I think this make the si is always 100% and make the system down.
> >
> > After I change "while(next_ext_hdr)" to "while(*next_ext_hdr)", I haven't seen this again until now.
> >
> > --
> > XTao
> > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> >
> > _______________________________________________
> > Ntop-misc mailing list
> > Ntop-misc [at] listgateway (mailto:Ntop-misc [at] listgateway)
> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway (mailto:Ntop-misc [at] listgateway)
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>

cardigliano at ntop

Jul 25, 2012, 11:35 PM

Post #4 of 6 (447 views)
Permalink

Re: GTP bug in PF_RING [In reply to]

XTao
please try to capture a .pcap able to reproduce the issue

Thank you
Alfredo

On Jul 26, 2012, at 8:29 AM, XTao wrote:

> The system is totally down again.
> So I think there may be still some problem.
>
> --
> XTao
> Sent with Sparrow
>
> On Thursday, July 26, 2012 at 2:18 PM, Alfredo Cardigliano wrote:
>
>> XTao
>> thank you, this will be fixed immediately in svn
>>
>> Alfredo
>>
>> On Jul 26, 2012, at 4:57 AM, XTao wrote:
>>
>>> OS: RHEL6.3
>>>
>>> [root [at] mirro ~]# uname -a
>>> Linux mirror 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> [root [at] mirro ~]# cat /etc/issue
>>> Red Hat Enterprise Linux Server release 6.3 (Santiago)
>>> Kernel \r on an \m
>>>
>>> This problem in PF_RING 5.4.4 & PF_RING 5.4.5
>>>
>>> I had sent a letter to describe this problem last week.
>>>
>>> Sometimes the cpu load is very high and si is always 100%, when I using PF_RING(5.4.4&5.4.5). I haven't found this situation in old PF_RING.
>>>
>>> I found the code(pf_ring.c, parse_raw_pkt):
>>>
>>> 1965 do {
>>> 1966 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8 bit len field */)) return(1);
>>> 1967 gtpext = (struct gtp_v1_ext_hdr *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
>>> 1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
>>> 1969 if(data_len < (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len)) return(1);
>>> 1970 next_ext_hdr = (u_int8_t *) (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len - 1 /* 8 bit next_ext_hdr field*/]);
>>> 1971 } while (next_ext_hdr);
>>>
>>> the next_ext_hdr is a pointer, so the (next_ext_hdr) is always true. Also when the gtpext->len is 0, this is a dead loop.
>>>
>>> I think this make the si is always 100% and make the system down.
>>>
>>> After I change "while(next_ext_hdr)" to "while(*next_ext_hdr)", I haven't seen this again until now.
>>>
>>> --
>>> XTao
>>> Sent with Sparrow
>>>
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc [at] listgateway
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

xutao881001 at gmail

Jul 29, 2012, 6:19 PM

Post #5 of 6 (442 views)
Permalink

Re: GTP bug in PF_RING [In reply to]

Finally, I found this problem:
pf_ring.c, parse_raw_pkt()

1965 do {
1966 if(data_len <
(hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8
bit len field */)) return(1);
1967 gtpext = (struct gtp_v1_ext_hdr *)
(&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
1969 if(data_len <
(hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len))
return(1);
1970 next_ext_hdr = (u_int8_t *)
(&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len -
1 /* 8 bit next_ext_hdr field*/]);
1971 } while (*next_ext_hdr);

When gtpext->len == 0, this will be a dead loop.
So I add modified the code:

1967 gtpext = (struct gtp_v1_ext_hdr *)
(&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
if (gtpext->len == 0) return(1);
1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
1969 if(data_len <
(hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len))
return(1);
1970 next_ext_hdr = (u_int8_t *)
(&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len -
1 /* 8 bit next_ext_hdr field*/]);
1971 } while (*next_ext_hdr);

On Thu, Jul 26, 2012 at 2:35 PM, Alfredo Cardigliano
<cardigliano [at] ntop> wrote:
> XTao
> please try to capture a .pcap able to reproduce the issue
>
> Thank you
> Alfredo
>
> On Jul 26, 2012, at 8:29 AM, XTao wrote:
>
> The system is totally down again.
> So I think there may be still some problem.
>
> --
> XTao
> Sent with Sparrow
>
> On Thursday, July 26, 2012 at 2:18 PM, Alfredo Cardigliano wrote:
>
> XTao
> thank you, this will be fixed immediately in svn
>
> Alfredo
>
> On Jul 26, 2012, at 4:57 AM, XTao wrote:
>
> OS: RHEL6.3
>
> [root [at] mirro ~]# uname -a
> Linux mirror 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012
> x86_64 x86_64 x86_64 GNU/Linux
>
> [root [at] mirro ~]# cat /etc/issue
> Red Hat Enterprise Linux Server release 6.3 (Santiago)
> Kernel \r on an \m
>
> This problem in PF_RING 5.4.4 & PF_RING 5.4.5
>
> I had sent a letter to describe this problem last week.
>
> Sometimes the cpu load is very high and si is always 100%, when I using
> PF_RING(5.4.4&5.4.5). I haven't found this situation in old PF_RING.
>
> I found the code(pf_ring.c, parse_raw_pkt):
>
> 1965 do {
> 1966 if(data_len <
> (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8 bit len
> field */)) return(1);
> 1967 gtpext = (struct gtp_v1_ext_hdr *)
> (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
> 1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
> 1969 if(data_len <
> (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len)) return(1);
> 1970 next_ext_hdr = (u_int8_t *)
> (&data[.hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len - 1 /* 8
> bit next_ext_hdr field*/]);
> 1971 } while (next_ext_hdr);
>
> the next_ext_hdr is a pointer, so the (next_ext_hdr) is always true. Also
> when the gtpext->len is 0, this is a dead loop.
>
> I think this make the si is always 100% and make the system down.
>
> After I change "while(next_ext_hdr)" to "while(*next_ext_hdr)", I haven't
> seen this again until now.
>
> --
> XTao
> Sent with Sparrow
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

deri at ntop

Jul 30, 2012, 1:50 AM

Post #6 of 6 (436 views)
Permalink

Re: GTP bug in PF_RING [In reply to]

XTao,
fixed thanks

Luca

On 07/30/2012 03:19 AM, xTao wrote:
> Finally, I found this problem:
> pf_ring.c, parse_raw_pkt()
>
> 1965 do {
> 1966 if(data_len <
> (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8
> bit len field */)) return(1);
> 1967 gtpext = (struct gtp_v1_ext_hdr *)
> (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
> 1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
> 1969 if(data_len <
> (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len))
> return(1);
> 1970 next_ext_hdr = (u_int8_t *)
> (&data[.hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len -
> 1 /* 8 bit next_ext_hdr field*/]);
> 1971 } while (*next_ext_hdr);
>
> When gtpext->len == 0, this will be a dead loop.
> So I add modified the code:
>
> 1967 gtpext = (struct gtp_v1_ext_hdr *)
> (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
> if (gtpext->len == 0) return(1);
> 1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
> 1969 if(data_len <
> (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len))
> return(1);
> 1970 next_ext_hdr = (u_int8_t *)
> (&data[.hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len -
> 1 /* 8 bit next_ext_hdr field*/]);
> 1971 } while (*next_ext_hdr);
>
>
> On Thu, Jul 26, 2012 at 2:35 PM, Alfredo Cardigliano
> <cardigliano [at] ntop> wrote:
>> XTao
>> please try to capture a .pcap able to reproduce the issue
>>
>> Thank you
>> Alfredo
>>
>> On Jul 26, 2012, at 8:29 AM, XTao wrote:
>>
>> The system is totally down again.
>> So I think there may be still some problem.
>>
>> --
>> XTao
>> Sent with Sparrow
>>
>> On Thursday, July 26, 2012 at 2:18 PM, Alfredo Cardigliano wrote:
>>
>> XTao
>> thank you, this will be fixed immediately in svn
>>
>> Alfredo
>>
>> On Jul 26, 2012, at 4:57 AM, XTao wrote:
>>
>> OS: RHEL6.3
>>
>> [root [at] mirro ~]# uname -a
>> Linux mirror 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012
>> x86_64 x86_64 x86_64 GNU/Linux
>>
>> [root [at] mirro ~]# cat /etc/issue
>> Red Hat Enterprise Linux Server release 6.3 (Santiago)
>> Kernel \r on an \m
>>
>> This problem in PF_RING 5.4.4 & PF_RING 5.4.5
>>
>> I had sent a letter to describe this problem last week.
>>
>> Sometimes the cpu load is very high and si is always 100%, when I using
>> PF_RING(5.4.4&5.4.5). I haven't found this situation in old PF_RING.
>>
>> I found the code(pf_ring.c, parse_raw_pkt):
>>
>> 1965 do {
>> 1966 if(data_len <
>> (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len +1 /* 8 bit len
>> field */)) return(1);
>> 1967 gtpext = (struct gtp_v1_ext_hdr *)
>> (&data[hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len]);
>> 1968 gtp_len += (gtpext->len * GTP_EXT_HDR_LEN_UNIT_BYTES);
>> 1969 if(data_len <
>> (hdr->extended_hdr.parsed_pkt.offset.payload_offset+gtp_len)) return(1);
>> 1970 next_ext_hdr = (u_int8_t *)
>> (&data[.hdr->extended_hdr.parsed_pkt.offset.payload_offset + gtp_len - 1 /* 8
>> bit next_ext_hdr field*/]);
>> 1971 } while (next_ext_hdr);
>>
>> the next_ext_hdr is a pointer, so the (next_ext_hdr) is always true. Also
>> when the gtpext->len is 0, this is a dead loop.
>>
>> I think this make the si is always 100% and make the system down.
>>
>> After I change "while(next_ext_hdr)" to "while(*next_ext_hdr)", I haven't
>> seen this again until now.
>>
>> --
>> XTao
>> Sent with Sparrow
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads