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],
&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.
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
