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 <justin.iur...@uliege.be> 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 <justin.iur...@uliege.be> 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],
>>>> &b0->current_config_index, &next0,
>>>> /* # 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
