Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Justin Iurman]

Florin,

> For discarding options you’ll probably need to write your own function that
> first recomputes them and then moves the payload closer to the header.

Yep, that's what I had in mind.

> tcp_buffer_discard_bytes just chops off payload bytes, as in moves the 
> buffer’s
> current_data pointer. I don’t think it’s enough for what you need.

Indeed, it's not enough.

> Quick note, for completeness: If you’re planning on discarding all headers up 
> to
> tcp, the other option would be to move the tcp header forward, since it’s
> typically smaller than the payload.

I don't. Actually, the goal is only to strip off some tcp options that match 
against some rules.

Thanks,

Justin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Florin Coras]

Quick note, for completeness: If you’re planning on discarding all headers up 
to tcp, the other option would be to move the tcp header forward, since it’s 
typically smaller than the payload. 

Florin

> On Nov 20, 2017, at 2:07 PM, Florin Coras  wrote:
> 
> Hi Justin, 
> 
> For discarding options you’ll probably need to write your own function that 
> first recomputes them and then moves the payload closer to the header. 
> tcp_buffer_discard_bytes just chops off payload bytes, as in moves the 
> buffer’s current_data pointer. I don’t think it’s enough for what you need. 
> 
> Cheers,
> Florin
> 
>> On Nov 20, 2017, at 9:21 AM, Justin Iurman  wrote:
>> 
>> Hi Florin,
>> 
>> Sorry for the late response. In fact, you just confirmed what I expected, 
>> thank you. I'll go with my own parser to include all options (even the 
>> reserved ones), inspired by tcp_options_parse. I'll go with my own rewriter 
>> too, inspired by tcp_options_write. 
>> 
>> But, what about discarded options (the ones I just want to remove) ? How 
>> would you free/allocate/resize the buffer containing data (..., ip header, 
>> tcp header, payload...) ? I just found a function called 
>> tcp_buffer_discard_bytes but I'm not sure it's what I really need. I'm 
>> looking for the cleanest vpp-way to do this.
>> 
>> Thanks for your help !
>> 
>> Justin
>> 
>>> Hi Justin,
>>> 
>>> The expectation until now has been that options are not parsed until 
>>> hitting the
>>> tcp related nodes. If tcp_options_parse is enough, then make it public and 
>>> use
>>> it.  That function just expects a tcp_options_t struct for outputting the
>>> results so no need for a tcp_connection_t. Now, if you need your special
>>> function to both read, match and update in place the options, then I 
>>> recommend
>>> you write your own options parser.
>>> 
>>> Hope this helps,
>>> Florin
>>> 
 On Nov 14, 2017, at 5:13 AM, Justin Iurman  wrote:
 
 Hi Dave,
 
 Thanks (again) for your reply.
 
> Brief commercial: hopefully you added your node to the ip4 unicast 
> feature arc,
> configured to grab pkts, pre-ip4/6-lookup.
 
 Indeed, I added my node to the ip4-unicast feature arc.
 
> In feature-arc land, the following one-liner sets next0 so pkts will 
> visit the
> next enabled feature. The last node in the ip4-unicast feature arc is
> ip4-lookup...
> 
>   /* Next node in unicast feature arc */
> vnet_get_config_data (em->config_main[table_index],
>   >current_config_index, ,
>   /* # bytes of config data */ 0);
> 
> Check the ip protocol and ignore any non-TCP pkts:
> 
>   ip40 = vlib_buffer_get_current (b0);
>   if (ip40->protocol != IP_PROTOCOL_TCP)
> goto trace0;
> 
> Then use ip4_next_header() to find the tcp layer, etc. etc.
 
 Actually, I'm already able to access L3 and L4 structures. But, when I 
 have the
 following, for instance:
 
 ip40 = vlib_buffer_get_current (b0);
 if (ip40->protocol == IP_PROTOCOL_TCP)
 {
 tcp_header_t *tcp = ip4_next_header(ip40);
 // where are options (tcp_options_t) ?
 }
 
 How am I able to access TCP options for each packet ? I mean, I could 
 directly
 parse them by moving the data pointer but I've also seen a function called
 tcp_options_parse (see my previous email) that already does this job. How 
 would
 you proceed to do this ? The expected behavior is to match some options and
 strip them.
 
 Thanks,
 
 Justin
 ___
 vpp-dev mailing list
 vpp-dev@lists.fd.io
 https://lists.fd.io/mailman/listinfo/vpp-dev
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Florin Coras]

Hi Justin, 

For discarding options you’ll probably need to write your own function that 
first recomputes them and then moves the payload closer to the header. 
tcp_buffer_discard_bytes just chops off payload bytes, as in moves the buffer’s 
current_data pointer. I don’t think it’s enough for what you need. 

Cheers,
Florin

> On Nov 20, 2017, at 9:21 AM, Justin Iurman  wrote:
> 
> Hi Florin,
> 
> Sorry for the late response. In fact, you just confirmed what I expected, 
> thank you. I'll go with my own parser to include all options (even the 
> reserved ones), inspired by tcp_options_parse. I'll go with my own rewriter 
> too, inspired by tcp_options_write. 
> 
> But, what about discarded options (the ones I just want to remove) ? How 
> would you free/allocate/resize the buffer containing data (..., ip header, 
> tcp header, payload...) ? I just found a function called 
> tcp_buffer_discard_bytes but I'm not sure it's what I really need. I'm 
> looking for the cleanest vpp-way to do this.
> 
> Thanks for your help !
> 
> Justin
> 
>> Hi Justin,
>> 
>> The expectation until now has been that options are not parsed until hitting 
>> the
>> tcp related nodes. If tcp_options_parse is enough, then make it public and 
>> use
>> it.  That function just expects a tcp_options_t struct for outputting the
>> results so no need for a tcp_connection_t. Now, if you need your special
>> function to both read, match and update in place the options, then I 
>> recommend
>> you write your own options parser.
>> 
>> Hope this helps,
>> Florin
>> 
>>> On Nov 14, 2017, at 5:13 AM, Justin Iurman  wrote:
>>> 
>>> Hi Dave,
>>> 
>>> Thanks (again) for your reply.
>>> 
 Brief commercial: hopefully you added your node to the ip4 unicast feature 
 arc,
 configured to grab pkts, pre-ip4/6-lookup.
>>> 
>>> Indeed, I added my node to the ip4-unicast feature arc.
>>> 
 In feature-arc land, the following one-liner sets next0 so pkts will visit 
 the
 next enabled feature. The last node in the ip4-unicast feature arc is
 ip4-lookup...
 
/* Next node in unicast feature arc */
  vnet_get_config_data (em->config_main[table_index],
>current_config_index, ,
/* # bytes of config data */ 0);
 
 Check the ip protocol and ignore any non-TCP pkts:
 
ip40 = vlib_buffer_get_current (b0);
if (ip40->protocol != IP_PROTOCOL_TCP)
  goto trace0;
 
 Then use ip4_next_header() to find the tcp layer, etc. etc.
>>> 
>>> Actually, I'm already able to access L3 and L4 structures. But, when I have 
>>> the
>>> following, for instance:
>>> 
>>> ip40 = vlib_buffer_get_current (b0);
>>> if (ip40->protocol == IP_PROTOCOL_TCP)
>>> {
>>> tcp_header_t *tcp = ip4_next_header(ip40);
>>> // where are options (tcp_options_t) ?
>>> }
>>> 
>>> How am I able to access TCP options for each packet ? I mean, I could 
>>> directly
>>> parse them by moving the data pointer but I've also seen a function called
>>> tcp_options_parse (see my previous email) that already does this job. How 
>>> would
>>> you proceed to do this ? The expected behavior is to match some options and
>>> strip them.
>>> 
>>> Thanks,
>>> 
>>> Justin
>>> ___
>>> vpp-dev mailing list
>>> vpp-dev@lists.fd.io
>>> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Justin Iurman]

Hi Florin,

Sorry for the late response. In fact, you just confirmed what I expected, thank 
you. I'll go with my own parser to include all options (even the reserved 
ones), inspired by tcp_options_parse. I'll go with my own rewriter too, 
inspired by tcp_options_write. 

But, what about discarded options (the ones I just want to remove) ? How would 
you free/allocate/resize the buffer containing data (..., ip header, tcp 
header, payload...) ? I just found a function called tcp_buffer_discard_bytes 
but I'm not sure it's what I really need. I'm looking for the cleanest vpp-way 
to do this.

Thanks for your help !

Justin

> Hi Justin,
> 
> The expectation until now has been that options are not parsed until hitting 
> the
> tcp related nodes. If tcp_options_parse is enough, then make it public and use
> it.  That function just expects a tcp_options_t struct for outputting the
> results so no need for a tcp_connection_t. Now, if you need your special
> function to both read, match and update in place the options, then I recommend
> you write your own options parser.
> 
> Hope this helps,
> Florin
> 
>> On Nov 14, 2017, at 5:13 AM, Justin Iurman  wrote:
>> 
>> Hi Dave,
>> 
>> Thanks (again) for your reply.
>> 
>>> Brief commercial: hopefully you added your node to the ip4 unicast feature 
>>> arc,
>>> configured to grab pkts, pre-ip4/6-lookup.
>> 
>> Indeed, I added my node to the ip4-unicast feature arc.
>> 
>>> In feature-arc land, the following one-liner sets next0 so pkts will visit 
>>> the
>>> next enabled feature. The last node in the ip4-unicast feature arc is
>>> ip4-lookup...
>>> 
>>> /* Next node in unicast feature arc */
>>>   vnet_get_config_data (em->config_main[table_index],
>>> >current_config_index, ,
>>> /* # bytes of config data */ 0);
>>> 
>>> Check the ip protocol and ignore any non-TCP pkts:
>>> 
>>> ip40 = vlib_buffer_get_current (b0);
>>> if (ip40->protocol != IP_PROTOCOL_TCP)
>>>   goto trace0;
>>> 
>>> Then use ip4_next_header() to find the tcp layer, etc. etc.
>> 
>> Actually, I'm already able to access L3 and L4 structures. But, when I have 
>> the
>> following, for instance:
>> 
>> ip40 = vlib_buffer_get_current (b0);
>> if (ip40->protocol == IP_PROTOCOL_TCP)
>> {
>>  tcp_header_t *tcp = ip4_next_header(ip40);
>>  // where are options (tcp_options_t) ?
>> }
>> 
>> How am I able to access TCP options for each packet ? I mean, I could 
>> directly
>> parse them by moving the data pointer but I've also seen a function called
>> tcp_options_parse (see my previous email) that already does this job. How 
>> would
>> you proceed to do this ? The expected behavior is to match some options and
>> strip them.
>> 
>> Thanks,
>> 
>> Justin
>> ___
>> vpp-dev mailing list
>> vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Florin Coras]

Hi Justin, 

The expectation until now has been that options are not parsed until hitting 
the tcp related nodes. If tcp_options_parse is enough, then make it public and 
use it.  That function just expects a tcp_options_t struct for outputting the 
results so no need for a tcp_connection_t. Now, if you need your special 
function to both read, match and update in place the options, then I recommend 
you write your own options parser. 

Hope this helps,
Florin

> On Nov 14, 2017, at 5:13 AM, Justin Iurman  wrote:
> 
> Hi Dave,
> 
> Thanks (again) for your reply.
> 
>> Brief commercial: hopefully you added your node to the ip4 unicast feature 
>> arc,
>> configured to grab pkts, pre-ip4/6-lookup.
> 
> Indeed, I added my node to the ip4-unicast feature arc.
> 
>> In feature-arc land, the following one-liner sets next0 so pkts will visit 
>> the
>> next enabled feature. The last node in the ip4-unicast feature arc is
>> ip4-lookup...
>> 
>> /* Next node in unicast feature arc */
>>vnet_get_config_data (em->config_main[table_index],
>>  >current_config_index, ,
>>  /* # bytes of config data */ 0);
>> 
>> Check the ip protocol and ignore any non-TCP pkts:
>> 
>> ip40 = vlib_buffer_get_current (b0);
>> if (ip40->protocol != IP_PROTOCOL_TCP)
>>   goto trace0;
>> 
>> Then use ip4_next_header() to find the tcp layer, etc. etc.
> 
> Actually, I'm already able to access L3 and L4 structures. But, when I have 
> the following, for instance:
> 
> ip40 = vlib_buffer_get_current (b0);
> if (ip40->protocol == IP_PROTOCOL_TCP)
> {
>  tcp_header_t *tcp = ip4_next_header(ip40);
>  // where are options (tcp_options_t) ?
> }
> 
> How am I able to access TCP options for each packet ? I mean, I could 
> directly parse them by moving the data pointer but I've also seen a function 
> called tcp_options_parse (see my previous email) that already does this job. 
> How would you proceed to do this ? The expected behavior is to match some 
> options and strip them.
> 
> Thanks,
> 
> Justin
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Justin Iurman]

Hi Dave,

Thanks (again) for your reply.

> Brief commercial: hopefully you added your node to the ip4 unicast feature 
> arc,
> configured to grab pkts, pre-ip4/6-lookup.

Indeed, I added my node to the ip4-unicast feature arc.

> In feature-arc land, the following one-liner sets next0 so pkts will visit the
> next enabled feature. The last node in the ip4-unicast feature arc is
> ip4-lookup...
> 
>  /* Next node in unicast feature arc */
> vnet_get_config_data (em->config_main[table_index],
>   >current_config_index, ,
>   /* # bytes of config data */ 0);
> 
> Check the ip protocol and ignore any non-TCP pkts:
> 
>  ip40 = vlib_buffer_get_current (b0);
>  if (ip40->protocol != IP_PROTOCOL_TCP)
>goto trace0;
> 
> Then use ip4_next_header() to find the tcp layer, etc. etc.

Actually, I'm already able to access L3 and L4 structures. But, when I have the 
following, for instance:

ip40 = vlib_buffer_get_current (b0);
if (ip40->protocol == IP_PROTOCOL_TCP)
{
  tcp_header_t *tcp = ip4_next_header(ip40);
  // where are options (tcp_options_t) ?
}

How am I able to access TCP options for each packet ? I mean, I could directly 
parse them by moving the data pointer but I've also seen a function called 
tcp_options_parse (see my previous email) that already does this job. How would 
you proceed to do this ? The expected behavior is to match some options and 
strip them.

Thanks,

Justin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Dave Barach (dbarach)]

Dear Justin,

Brief commercial: hopefully you added your node to the ip4 unicast feature arc, 
configured to grab pkts, pre-ip4/6-lookup. 

In feature-arc land, the following one-liner sets next0 so pkts will visit the 
next enabled feature. The last node in the ip4-unicast feature arc is 
ip4-lookup...

  /* Next node in unicast feature arc */
  vnet_get_config_data (em->config_main[table_index],
>current_config_index, ,
/* # bytes of config data */ 0);

Check the ip protocol and ignore any non-TCP pkts:

  ip40 = vlib_buffer_get_current (b0);
  if (ip40->protocol != IP_PROTOCOL_TCP)
goto trace0;

Then use ip4_next_header() to find the tcp layer, etc. etc.

HTH... Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Justin Iurman
Sent: Monday, November 13, 2017 5:30 PM
To: vpp-dev <vpp-dev@lists.fd.io>
Subject: [vpp-dev] TCP Options: tcp_header_t and tcp_options_t

Guys,

My node is located right before ip4_lookup. What's the fastest/cleanest way to 
get options related to a TCP packet, having access to a tcp_header_t structure 
(which is not directly linked to its options) ? Actually, I'd like to modify or 
remove some options on the fly. 

Do I have to call tcp_options_parse function from src/vnet/tcp/tcp_input.c ? 
But I guess it would duplicate the job, since it is already called at one 
moment. 

Or should I get the TCP connection, which connects both tcp_header_t and 
tcp_options_t ? Or should I directly modify options "in" the packet, by moving 
the data pointer (a sort-of copy of what tcp_options_parse already does) ?

Thanks for your help !

Justin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] TCP Options: tcp_header_t and tcp_options_t

[Justin Iurman]

Guys,

My node is located right before ip4_lookup. What's the fastest/cleanest way to 
get options related to a TCP packet, having access to a tcp_header_t structure 
(which is not directly linked to its options) ? Actually, I'd like to modify or 
remove some options on the fly. 

Do I have to call tcp_options_parse function from src/vnet/tcp/tcp_input.c ? 
But I guess it would duplicate the job, since it is already called at one 
moment. 

Or should I get the TCP connection, which connects both tcp_header_t and 
tcp_options_t ? Or should I directly modify options "in" the packet, by moving 
the data pointer (a sort-of copy of what tcp_options_parse already does) ?

Thanks for your help !

Justin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev