Re: [vpp-dev] VPP: Answer UDP Packets
Hi Alessio, Don’t call adj_nbr_add_or_lock from a worker thread, it must only be called from the main thread – the adjacency DB is not thread safe. Stash the result of the call in your ‘key’ object. /neale From: Alessio Silvestro <ale.silver...@gmail.com> Date: Friday, 14 July 2017 at 14:15 To: "Neale Ranns (nranns)" <nra...@cisco.com> Cc: Dharmaray Kundargi <dharmaray.kunda...@mavenir.com>, "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" <ksek...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] VPP: Answer UDP Packets [SOLVED] the variable must be declared as ==> extern adj_index_t adj_index; In my case, I have 3 workers configured. Now it works. Cheers, Alessio On Thu, Jul 13, 2017 at 3:12 PM, Alessio Silvestro <ale.silver...@gmail.com<mailto:ale.silver...@gmail.com>> wrote: Hi Neale, thanks for the info. I was already doing that, but I get an unpredictable behavior from vpp. My node listens for UDP packets. For each packet, it creates a new packet and send it back to the source IP address. Below the piece of code that set the buffer's parameters. adj_index_t adj_index; adj_index = adj_nbr_add_or_lock(FIB_PROTOCOL_IP4,VNET_LINK_IP4, (const ip46_address_t*)_addr, key.sw_if_index); b->flags |= VNET_BUFFER_LOCALLY_ORIGINATED; vnet_buffer (b)->ip.adj_index[VLIB_RX] = adj_index; vnet_buffer (b)->ip.adj_index[VLIB_TX]= adj_index; vnet_buffer (b)->sw_if_index[VLIB_RX] = key.sw_if_index; vnet_buffer (b)->sw_if_index[VLIB_TX] = key.sw_if_index; where the key variable includes the IP addresses and sw_if_index taken from the source buffer. Sometimes I am able to receive and send back UDP traffic. In those cases, the adj_index has value 1. In the other cases, VPP crashes and I got the following error message: 1: /root/vpp/build-data/../src/vlib/node.c:102 (vlib_node_runtime_update) assertion `vlib_get_thread_index () == 0' fails Below the backtrace on GDB. (gdb) bt #0 0x75e3a428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x75e3c02a in __GI_abort () at abort.c:89 #2 0x00407cc2 in os_panic () at /root/vpp/build-data/../src/vpp/vnet/main.c:263 #3 0x7661f5f9 in debugger () at /root/vpp/build-data/../src/vppinfra/error.c:84 #4 0x7661fa01 in _clib_error (how_to_die=2, function_name=0x0, line_number=0, fmt=0x77982d98 "%s:%d (%s) assertion `%s' fails") at /root/vpp/build-data/../src/vppinfra/error.c:143 #5 0x779147e2 in vlib_node_runtime_update (vm=0x77b9d400 , node_index=257, next_index=1) at /root/vpp/build-data/../src/vlib/node.c:102 #6 0x77915468 in vlib_node_add_next_with_slot (vm=0x77b9d400 , node_index=257, next_node_index=336, slot=1) at /root/vpp/build-data/../src/vlib/node.c:187 #7 0x774b221c in vlib_node_add_next (vm=0x77b9d400 , node=257, next_node=336) at /root/vpp/build-data/../src/vlib/node_funcs.h:1080 #8 0x774b2df6 in vnet_rewrite_init (vnm=0x6f1100 , sw_if_index=1, this_node=257, next_node=336, rw=0x7fffb5f4fe40) at /root/vpp/build-data/../src/vnet/adj/rewrite.c:108 #9 0x77493391 in adj_nbr_add_or_lock (nh_proto=FIB_PROTOCOL_IP4, link_type=VNET_LINK_IP4, nh_addr=0x7fffb60b0ad6, sw_if_index=1) at /root/vpp/build-data/../src/vnet/adj/adj_nbr.c:233 #10 0x771686c3 in add_udp4_transport (vm=0x7fffb5f0df94, b=0x7fff5fea8080, query_id=55949, client_port=1112, key=...) at /root/vpp/build-data/../src/vnet/alessio/server.c:73 #11 0x77168ba3 in send_answer (vm=0x7fffb5f0df94, rt=0x7fffb6561554, query_id=55949, client_port=1112, key=...) at /root/vpp/build-data/../src/vnet/alessio/server.c:201 #12 0x77168e0c in server_inline (vm=0x7fffb5f0df94, node=0x7fffb6561554, from_frame=0x7fffb5fad900) at /root/vpp/build-data/../src/vnet/alessio/server.c:287 #13 0x77168e85 in server (vm=0x7fffb5f0df94, node=0x7fffb6561554, from_frame=0x7fffb5fad900) at /root/vpp/build-data/../src/vnet/alessio/server.c:316 #14 0x778f5007 in dispatch_node (vm=0x7fffb5f0df94, node=0x7fffb6561554, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb5fad900, last_time_stamp=277689848578863) at /root/vpp/build-data/../src/vlib/main.c:1016 #15 0x778f55c0 in dispatch_pending_node (vm=0x7fffb5f0df94, pending_frame_index=4, last_time_stamp=277689848578863) at /root/vpp/build-data/../src/vlib/main.c:1166 #16 0x778f763c in vlib_main_or_worker_loop (vm=0x7fffb5f0df94, is_main=0) at /root/vpp/build-data/../src/vlib/main.c:1625 #17 0x778f7730 in vlib_worker_loop (vm=0x7fffb5f0df94) at /root/vpp/build-data/../src/vlib/main.c:1650 #18 0x77940d94 in vlib_worker_thread_fn (arg=0x7fffb54
Re: [vpp-dev] VPP: Answer UDP Packets
Hi Alessio,
I can even give you the API ;)
/**
* @brief
* Add (and lock) a new or lock an existing neighbour adjacency
*
* @param nh_proto
* The protocol for the next-hop address (v4 or v6)
*
* @param link_type
* A description of the protocol of the packets that will forward
* through this adj. On an ethernet interface this is the MAC header's
* ether-type
*
* @param nh_addr
* The address of the next-hop/peer to send the packet to
*
* @param sw_if_index
* The interface on which the peer resides
*/
extern adj_index_t adj_nbr_add_or_lock(fib_protocol_t nh_proto,
vnet_link_t link_type,
const
ip46_address_t *nh_addr,
u32
sw_if_index);
/neale
From: Alessio Silvestro <ale.silver...@gmail.com>
Date: Wednesday, 12 July 2017 at 15:30
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: Dharmaray Kundargi <dharmaray.kunda...@mavenir.com>, "Klement Sekera -X
(ksekera - PANTHEON TECHNOLOGIES at Cisco)" <ksek...@cisco.com>,
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP: Answer UDP Packets
Hi Neale,
can you please point me a code example of how to access the adjacency-DB in
order to get the adjacency index to use for the ip4-rewrite node?
Thanks,
Alessio
On Wed, Jun 21, 2017 at 12:53 PM, Neale Ranns (nranns)
<nra...@cisco.com<mailto:nra...@cisco.com>> wrote:
Hi Dharmaray,
The short answer is that ip4-lookup performs the lookup in a FIB table of the
packet’s destination address, the result of which is an adjacency. The
ip4-rewrite node applies the ‘L2’ encap of an adjacency and transmits the
packet on the output port*. So typically packets will go first to ip4-lookup,
get the adjacency, then proceed to ip4-rewrite.
When choosing between which of the two nodes to send your packet to, you should
consider which of the pre-conditions for the required data you meet. In order
to perform the IP lookup, the node needs to know which FIB table to use. In
order to perform the rewrite, the node needs to know which adjacency to use.
So if you want to send your packet to the ip4-rewrite node, then you must have
already chosen which adjacency to use. For single-hop BFD this is a simple
matter of getting the adjacency from the adjacency-DB based on the peer and
interface – you can think of this as caching the result of the lookup. The
advantage of this is that we bypass the ip4-lookup node and so don’t pay its
performance cost.
If you know the next-hop to send to, but not the interface (and so can’t use
the adjacency-DB directly) then you can register with the FIB to track that
next-hop and be informed of the changing adjacency to use.
Hth,
neale
*typically. The exception being tunnels.
-Original Message-
From: <vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>> on
behalf of Dharmaray Kundargi
<dharmaray.kunda...@mavenir.com<mailto:dharmaray.kunda...@mavenir.com>>
Date: Wednesday, 21 June 2017 at 10:48
To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"
<ksek...@cisco.com<mailto:ksek...@cisco.com>>, Alessio Silvestro
<ale.silver...@gmail.com<mailto:ale.silver...@gmail.com>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VPP: Answer UDP Packets
BFD UDP code is interesting example.
I was looking at bfd_udp_input rather and one question in relation to this.
Though both ' bfd_udp_input ()' and ' bfd_send_periodic()' form the IP and
UDP headers using ' bfd_add_transport_layer', they pass the packet to different
next nodes.
bfd_udp_input uses "ip4-lookup" as the next node whereas '
bfd_send_periodic()' uses "ip4-rewrite".
So what's the difference between these two nodes? (ip4-rewrite vs ip4-
lookup) and when to use what ?
Regards
Dharmaray
-Original Message-
From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>
[mailto:vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>] On
Behalf Of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
Sent: Monday, June 19, 2017 12:09 PM
To: Alessio Silvestro
<ale.silver...@gmail.com<mailto:ale.silver...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP: Answer UDP Packets
Couple of potential issues which I see:
1.) if this buffer is generated by vpp, it should be flagged as such
(b->flags |= VNET_BUFFER_LOCALLY_ORIGINATED;)
2.) I don't see it passed to another node - you need to create a frame and
associate the buffer with it, then pass t
Re: [vpp-dev] VPP: Answer UDP Packets
Hi Neale, can you please point me a code example of how to access the adjacency-DB in order to get the adjacency index to use for the ip4-rewrite node? Thanks, Alessio On Wed, Jun 21, 2017 at 12:53 PM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > Hi Dharmaray, > > The short answer is that ip4-lookup performs the lookup in a FIB table of > the packet’s destination address, the result of which is an adjacency. The > ip4-rewrite node applies the ‘L2’ encap of an adjacency and transmits the > packet on the output port*. So typically packets will go first to > ip4-lookup, get the adjacency, then proceed to ip4-rewrite. > > When choosing between which of the two nodes to send your packet to, you > should consider which of the pre-conditions for the required data you meet. > In order to perform the IP lookup, the node needs to know which FIB table > to use. In order to perform the rewrite, the node needs to know which > adjacency to use. > So if you want to send your packet to the ip4-rewrite node, then you must > have already chosen which adjacency to use. For single-hop BFD this is a > simple matter of getting the adjacency from the adjacency-DB based on the > peer and interface – you can think of this as caching the result of the > lookup. The advantage of this is that we bypass the ip4-lookup node and so > don’t pay its performance cost. > > If you know the next-hop to send to, but not the interface (and so can’t > use the adjacency-DB directly) then you can register with the FIB to track > that next-hop and be informed of the changing adjacency to use. > > Hth, > neale > > *typically. The exception being tunnels. > > -Original Message- > From: <vpp-dev-boun...@lists.fd.io> on behalf of Dharmaray Kundargi < > dharmaray.kunda...@mavenir.com> > Date: Wednesday, 21 June 2017 at 10:48 > To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" < > ksek...@cisco.com>, Alessio Silvestro <ale.silver...@gmail.com> > Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] VPP: Answer UDP Packets > > BFD UDP code is interesting example. > > I was looking at bfd_udp_input rather and one question in relation to > this. > Though both ' bfd_udp_input ()' and ' bfd_send_periodic()' form the IP > and UDP headers using ' bfd_add_transport_layer', they pass the packet to > different next nodes. > bfd_udp_input uses "ip4-lookup" as the next node whereas ' > bfd_send_periodic()' uses "ip4-rewrite". > > So what's the difference between these two nodes? (ip4-rewrite vs ip4- > lookup) and when to use what ? > > Regards > Dharmaray > > > > > -Original Message- > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] > On Behalf Of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) > Sent: Monday, June 19, 2017 12:09 PM > To: Alessio Silvestro <ale.silver...@gmail.com> > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] VPP: Answer UDP Packets > > Couple of potential issues which I see: > > 1.) if this buffer is generated by vpp, it should be flagged as such > (b->flags |= VNET_BUFFER_LOCALLY_ORIGINATED;) > > 2.) I don't see it passed to another node - you need to create a frame > and associate the buffer with it, then pass the frame to the next node, > which would be either ip4-arp or ip4-rewrite for ipv4 case depending on > whether the arp resolution has taken place or not... > > take a look at functions > > bfd_udp_init() - where the next nodes are resolved > bfd_transport_udp4() - where the next node is decided and frame created > > You can take a look at show error and show trace to see what happens > to the packet.. > > HTH, > Klement > > > Quoting Alessio Silvestro (2017-06-16 17:20:30) > >Dear Klement, > > > >thanks for the hint. I had a look at the code bfd_main.c and in > particular > >at the function bfd_send_periodic(). > > > >I wrote the function send_udp_packet() -- see below -- in order > to send > >out UDP packets. > > > >The function is executed (I can see from the VPP terminal) and no > >exception is raised, however I do not see any packet out. > > > >1 -- is the function correct or I am missing something? > > > >2 -- if it is not correct, how I can see where the problem is? > > > >Thanks, > > > >Alessio > > > >static void send_udp_packet(vl
Re: [vpp-dev] VPP: Answer UDP Packets
BFD UDP code is interesting example.
I was looking at bfd_udp_input rather and one question in relation to this.
Though both ' bfd_udp_input ()' and ' bfd_send_periodic()' form the IP and UDP
headers using ' bfd_add_transport_layer', they pass the packet to different
next nodes.
bfd_udp_input uses "ip4-lookup" as the next node whereas ' bfd_send_periodic()'
uses "ip4-rewrite".
So what's the difference between these two nodes? (ip4-rewrite vs ip4- lookup)
and when to use what ?
Regards
Dharmaray
-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
Sent: Monday, June 19, 2017 12:09 PM
To: Alessio Silvestro <ale.silver...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP: Answer UDP Packets
Couple of potential issues which I see:
1.) if this buffer is generated by vpp, it should be flagged as such (b->flags
|= VNET_BUFFER_LOCALLY_ORIGINATED;)
2.) I don't see it passed to another node - you need to create a frame and
associate the buffer with it, then pass the frame to the next node, which would
be either ip4-arp or ip4-rewrite for ipv4 case depending on whether the arp
resolution has taken place or not...
take a look at functions
bfd_udp_init() - where the next nodes are resolved
bfd_transport_udp4() - where the next node is decided and frame created
You can take a look at show error and show trace to see what happens to the
packet..
HTH,
Klement
Quoting Alessio Silvestro (2017-06-16 17:20:30)
>Dear Klement,
>
>thanks for the hint. I had a look at the code bfd_main.c and in particular
>at the function bfd_send_periodic().
>
>I wrote the function send_udp_packet() -- see below -- in order to send
>out UDP packets.
>
>The function is executed (I can see from the VPP terminal) and no
>exception is raised, however I do not see any packet out.
>
>1 -- is the function correct or I am missing something?
>
>2 -- if it is not correct, how I can see where the problem is?
>
>Thanks,
>
>Alessio
>
>static void send_udp_packet(vlib_main_t * vm, vlib_node_runtime_t * rt){
>u32 bi;
>vlib_buffer_alloc (vm, , 1)
>vlib_buffer_t *b = vlib_get_buffer (vm, bi);
>ASSERT (b->current_data == 0);
>memset (vnet_buffer (b), 0, sizeof (*vnet_buffer (b)));
>VLIB_BUFFER_TRACE_TRAJECTORY_INIT (b);
>add_udp4_transport (vm,b);
>}
>
>int add_udp4_transport (vlib_main_t * vm, vlib_buffer_t * b)
>{
>vnet_buffer (b)->ip.adj_index[VLIB_RX] = ~0;
>vnet_buffer (b)->ip.adj_index[VLIB_TX]= ~0;
>vnet_buffer (b)->sw_if_index[VLIB_RX] = 0;
>vnet_buffer (b)->sw_if_index[VLIB_TX] = ~0;
>u8 *data;
>udp_header_t *udp;
>ip4_header_t *ip;
>data = vlib_buffer_get_current (b);
>udp = (udp_header_t *) (data - sizeof (udp_header_t));
>ip = (ip4_header_t *) ((u8 *) udp - sizeof (ip4_header_t));
>// Build packet header
>u32 src_address = 167772161; //[1]10.0.0.1 u32 version
>u32 dst_address = 167772162; // 10.0.0.2 u32 version
>ip->src_address.as_u32 = src_address;
>ip->dst_address.as_u32 = dst_address;
>ip->ip_version_and_header_length = 0x45;
>ip->ttl = 254;
>ip->protocol = IP_PROTOCOL_UDP; //0x45 == IP_PROTOCOL_UDP
>ip->length = clib_host_to_net_u16 (b->current_length + sizeof (*udp));
>ip->checksum = ip4_header_checksum (ip);
>udp->src_port = DNS_SERVER_PORT;
>udp->dst_port = DNS_DST_PORT;
>udp->length = clib_host_to_net_u16 (b->current_length);
>udp->checksum = 0;
>b->current_length = sizeof (*ip) + sizeof (*udp);
>return 1;
>}
>
>On Wed, Jun 14, 2017 at 6:56 PM, Klement Sekera -X (ksekera - PANTHEON
>TECHNOLOGIES at Cisco) <[2]ksek...@cisco.com> wrote:
>
> Hi Alessio,
>
> you can take a look at BFD code which
>
> a.) creates and sends its own UDP packets - bfd_main.c -
> bfd_send_periodic() creates, encapsulates (UDP) and sends a packet out
> b.) loops back packets received - bfd_udp.c -
> bfd_udp_echo_input()
>
> I'm not sure what's your use case, whether you are trying to reuse
> existing buffer, but one of these should fit it.
>
> Regards,
> Klement
>
> Quoting Alessio Silvestro (2017-06-14 17:22:14)
> >Dear all,
> >I implemented a new VPP node that receives UDP traffic using the
> following
> >function:
> >
>
Re: [vpp-dev] VPP: Answer UDP Packets
Couple of potential issues which I see:
1.) if this buffer is generated by vpp, it should be flagged as such
(b->flags |= VNET_BUFFER_LOCALLY_ORIGINATED;)
2.) I don't see it passed to another node - you need to create a frame
and associate the buffer with it, then pass the frame to the next node,
which would be either ip4-arp or ip4-rewrite for ipv4 case depending on
whether the arp resolution has taken place or not...
take a look at functions
bfd_udp_init() - where the next nodes are resolved
bfd_transport_udp4() - where the next node is decided and frame created
You can take a look at show error and show trace to see what happens to
the packet..
HTH,
Klement
Quoting Alessio Silvestro (2017-06-16 17:20:30)
>Dear Klement,
>
>thanks for the hint. I had a look at the code bfd_main.c and in particular
>at the function bfd_send_periodic().
>
>I wrote the function send_udp_packet() -- see below -- in order to send
>out UDP packets.
>
>The function is executed (I can see from the VPP terminal) and no
>exception is raised, however I do not see any packet out.
>
>1 -- is the function correct or I am missing something?
>
>2 -- if it is not correct, how I can see where the problem is?
>
>Thanks,
>
>Alessio
>
>static void send_udp_packet(vlib_main_t * vm, vlib_node_runtime_t * rt){
> u32 bi;
> vlib_buffer_alloc (vm, , 1)
> vlib_buffer_t *b = vlib_get_buffer (vm, bi);
> ASSERT (b->current_data == 0);
> memset (vnet_buffer (b), 0, sizeof (*vnet_buffer (b)));
> VLIB_BUFFER_TRACE_TRAJECTORY_INIT (b);
> add_udp4_transport (vm,b);
>}
>
>int add_udp4_transport (vlib_main_t * vm, vlib_buffer_t * b)
>{
> vnet_buffer (b)->ip.adj_index[VLIB_RX] = ~0;
> vnet_buffer (b)->ip.adj_index[VLIB_TX]= ~0;
> vnet_buffer (b)->sw_if_index[VLIB_RX] = 0;
> vnet_buffer (b)->sw_if_index[VLIB_TX] = ~0;
> u8 *data;
> udp_header_t *udp;
> ip4_header_t *ip;
> data = vlib_buffer_get_current (b);
> udp = (udp_header_t *) (data - sizeof (udp_header_t));
> ip = (ip4_header_t *) ((u8 *) udp - sizeof (ip4_header_t));
> // Build packet header
> u32 src_address = 167772161; //[1]10.0.0.1 u32 version
> u32 dst_address = 167772162; // 10.0.0.2 u32 version
> ip->src_address.as_u32 = src_address;
> ip->dst_address.as_u32 = dst_address;
> ip->ip_version_and_header_length = 0x45;
> ip->ttl = 254;
> ip->protocol = IP_PROTOCOL_UDP; //0x45 == IP_PROTOCOL_UDP
> ip->length = clib_host_to_net_u16 (b->current_length + sizeof (*udp));
> ip->checksum = ip4_header_checksum (ip);
> udp->src_port = DNS_SERVER_PORT;
> udp->dst_port = DNS_DST_PORT;
> udp->length = clib_host_to_net_u16 (b->current_length);
> udp->checksum = 0;
> b->current_length = sizeof (*ip) + sizeof (*udp);
> return 1;
>}
>
>On Wed, Jun 14, 2017 at 6:56 PM, Klement Sekera -X (ksekera - PANTHEON
>TECHNOLOGIES at Cisco) <[2]ksek...@cisco.com> wrote:
>
> Hi Alessio,
>
> you can take a look at BFD code which
>
> a.) creates and sends its own UDP packets - bfd_main.c -
> bfd_send_periodic() creates, encapsulates (UDP) and sends a packet out
> b.) loops back packets received - bfd_udp.c - bfd_udp_echo_input()
>
> I'm not sure what's your use case, whether you are trying to reuse
> existing buffer, but one of these should fit it.
>
> Regards,
> Klement
>
> Quoting Alessio Silvestro (2017-06-14 17:22:14)
> > Dear all,
> > I implemented a new VPP node that receives UDP traffic using the
> following
> > function:
> >
> > udp_register_dst_port (vm, PORT, my_node.index , 1 /* is_ip4 */);
> >
> > I am able to parse the packet and I would like to be able to send
> back an
> > UDP packet.
> >
> > Looking at the source code, the only function that seems fit my
> scope is
> > the following (in ~/vpp/src/vnet/udp/udp.h)
> >
> > ip_udp_encap_one (vlib_main_t * vm, vlib_buffer_t * b0, u8 * ec0,
> word
> > ec_len,
> >
> > u8 is_ip4)
> >
> > Is that correct or there is another function for this purpose?
> >
> > Thanks in advance for any help.
> >
> > Best regards,
> >
> > Alessio
>
> References
>
>Visible links
>1. http://10.0.0.1/
>2. mailto:ksek...@cisco.com
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VPP: Answer UDP Packets
Dear Klement,
thanks for the hint. I had a look at the code bfd_main.c and in particular
at the function bfd_send_periodic().
I wrote the function send_udp_packet() -- see below -- in order to send
out UDP packets.
The function is executed (I can see from the VPP terminal) and no exception
is raised, however I do not see any packet out.
1 -- is the function correct or I am missing something?
2 -- if it is not correct, how I can see where the problem is?
Thanks,
Alessio
static void send_udp_packet(vlib_main_t * vm, vlib_node_runtime_t * rt){
u32 bi;
vlib_buffer_alloc (vm, , 1)
vlib_buffer_t *b = vlib_get_buffer (vm, bi);
ASSERT (b->current_data == 0);
memset (vnet_buffer (b), 0, sizeof (*vnet_buffer (b)));
VLIB_BUFFER_TRACE_TRAJECTORY_INIT (b);
add_udp4_transport (vm,b);
}
int add_udp4_transport (vlib_main_t * vm, vlib_buffer_t * b)
{
vnet_buffer (b)->ip.adj_index[VLIB_RX] = ~0;
vnet_buffer (b)->ip.adj_index[VLIB_TX]= ~0;
vnet_buffer (b)->sw_if_index[VLIB_RX] = 0;
vnet_buffer (b)->sw_if_index[VLIB_TX] = ~0;
u8 *data;
udp_header_t *udp;
ip4_header_t *ip;
data = vlib_buffer_get_current (b);
udp = (udp_header_t *) (data - sizeof (udp_header_t));
ip = (ip4_header_t *) ((u8 *) udp - sizeof (ip4_header_t));
// Build packet header
u32 src_address = 167772161; //10.0.0.1 u32 version
u32 dst_address = 167772162; // 10.0.0.2 u32 version
ip->src_address.as_u32 = src_address;
ip->dst_address.as_u32 = dst_address;
ip->ip_version_and_header_length = 0x45;
ip->ttl = 254;
ip->protocol = IP_PROTOCOL_UDP; //0x45 == IP_PROTOCOL_UDP
ip->length = clib_host_to_net_u16 (b->current_length + sizeof (*udp));
ip->checksum = ip4_header_checksum (ip);
udp->src_port = DNS_SERVER_PORT;
udp->dst_port = DNS_DST_PORT;
udp->length = clib_host_to_net_u16 (b->current_length);
udp->checksum = 0;
b->current_length = sizeof (*ip) + sizeof (*udp);
return 1;
}
On Wed, Jun 14, 2017 at 6:56 PM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hi Alessio,
>
> you can take a look at BFD code which
>
> a.) creates and sends its own UDP packets - bfd_main.c -
> bfd_send_periodic() creates, encapsulates (UDP) and sends a packet out
> b.) loops back packets received - bfd_udp.c - bfd_udp_echo_input()
>
> I'm not sure what's your use case, whether you are trying to reuse
> existing buffer, but one of these should fit it.
>
> Regards,
> Klement
>
> Quoting Alessio Silvestro (2017-06-14 17:22:14)
> >Dear all,
> >I implemented a new VPP node that receives UDP traffic using the
> following
> >function:
> >
> >udp_register_dst_port (vm, PORT, my_node.index , 1 /* is_ip4 */);
> >
> >I am able to parse the packet and I would like to be able to send
> back an
> >UDP packet.
> >
> >Looking at the source code, the only function that seems fit my scope
> is
> >the following (in ~/vpp/src/vnet/udp/udp.h)
> >
> >ip_udp_encap_one (vlib_main_t * vm, vlib_buffer_t * b0, u8 * ec0, word
> >ec_len,
> >
> > u8 is_ip4)
> >
> >Is that correct or there is another function for this purpose?
> >
> >Thanks in advance for any help.
> >
> >Best regards,
> >
> >Alessio
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VPP: Answer UDP Packets
Hi Alessio, you can take a look at BFD code which a.) creates and sends its own UDP packets - bfd_main.c - bfd_send_periodic() creates, encapsulates (UDP) and sends a packet out b.) loops back packets received - bfd_udp.c - bfd_udp_echo_input() I'm not sure what's your use case, whether you are trying to reuse existing buffer, but one of these should fit it. Regards, Klement Quoting Alessio Silvestro (2017-06-14 17:22:14) >Dear all, >I implemented a new VPP node that receives UDP traffic using the following >function: > >udp_register_dst_port (vm, PORT, my_node.index , 1 /* is_ip4 */); > >I am able to parse the packet and I would like to be able to send back an >UDP packet. > >Looking at the source code, the only function that seems fit my scope is >the following (in ~/vpp/src/vnet/udp/udp.h) > >ip_udp_encap_one (vlib_main_t * vm, vlib_buffer_t * b0, u8 * ec0, word >ec_len, > > u8 is_ip4) > >Is that correct or there is another function for this purpose? > >Thanks in advance for any help. > >Best regards, > >Alessio ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
