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 <fcoras.li...@gmail.com> 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 <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
