76 lines
1.9 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2013 6WIND S.A.
app/testpmd: add engine that replies to ARP and ICMP echo requests Add a new specific packet processing engine in the "testpmd" application that only replies to ARP requests and to ICMP echo requests. For this purpose, a new "icmpecho" forwarding mode is provided that can be dynamically selected with the following testpmd command: set fwd icmpecho before starting the receipt of packets on the selected ports. Then, the "icmpecho" engine performs the following actions on all received packets: - replies to a received ARP request by sending back on the RX port a ARP reply with a "sender hardware address" field containing the MAC address of the RX port, - replies to a ICMP echo request by sending back on the RX port a ICMP echo reply, swapping the IP source and the IP destination address in the IP header, - otherwise, simply drops the received packet. When replying to a received packet that was encapsulated into a VLAN tunnel, the reply is sent back with the same VLAN identifier. By default, the testpmd configures VLAN header stripping RX option on each port. This option is not managed by the icmpecho engine which won't detect packets that were encapsulated into a VLAN. To address this issue, the VLAN header stripping option must be previously switched off with the following testpmd command: vlan set strip off When the "verbose" mode has been set with the testpmd command "set verbose 1", the "icmpecho" engine displays informations about each received packet. The "icmpecho" forwarding engine can also be used to simply check port connectivity at the hardware level (check that cables are well-plugged) and at the software level (receipt of VLAN packets, for instance). Signed-off-by: Ivan Boule <ivan.boule@6wind.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-04-30 15:30:11 +02:00
*/
#ifndef _RTE_ARP_H_
#define _RTE_ARP_H_
/**
* @file
*
* ARP-related defines
*/
#include <stdint.h>
#include <rte_ether.h>
app/testpmd: add engine that replies to ARP and ICMP echo requests Add a new specific packet processing engine in the "testpmd" application that only replies to ARP requests and to ICMP echo requests. For this purpose, a new "icmpecho" forwarding mode is provided that can be dynamically selected with the following testpmd command: set fwd icmpecho before starting the receipt of packets on the selected ports. Then, the "icmpecho" engine performs the following actions on all received packets: - replies to a received ARP request by sending back on the RX port a ARP reply with a "sender hardware address" field containing the MAC address of the RX port, - replies to a ICMP echo request by sending back on the RX port a ICMP echo reply, swapping the IP source and the IP destination address in the IP header, - otherwise, simply drops the received packet. When replying to a received packet that was encapsulated into a VLAN tunnel, the reply is sent back with the same VLAN identifier. By default, the testpmd configures VLAN header stripping RX option on each port. This option is not managed by the icmpecho engine which won't detect packets that were encapsulated into a VLAN. To address this issue, the VLAN header stripping option must be previously switched off with the following testpmd command: vlan set strip off When the "verbose" mode has been set with the testpmd command "set verbose 1", the "icmpecho" engine displays informations about each received packet. The "icmpecho" forwarding engine can also be used to simply check port connectivity at the hardware level (check that cables are well-plugged) and at the software level (receipt of VLAN packets, for instance). Signed-off-by: Ivan Boule <ivan.boule@6wind.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-04-30 15:30:11 +02:00
#ifdef __cplusplus
extern "C" {
#endif
/**
* ARP header IPv4 payload.
*/
struct rte_arp_ipv4 {
struct rte_ether_addr arp_sha; /**< sender hardware address */
uint32_t arp_sip; /**< sender IP address */
struct rte_ether_addr arp_tha; /**< target hardware address */
uint32_t arp_tip; /**< target IP address */
} __rte_packed __rte_aligned(2);
app/testpmd: add engine that replies to ARP and ICMP echo requests Add a new specific packet processing engine in the "testpmd" application that only replies to ARP requests and to ICMP echo requests. For this purpose, a new "icmpecho" forwarding mode is provided that can be dynamically selected with the following testpmd command: set fwd icmpecho before starting the receipt of packets on the selected ports. Then, the "icmpecho" engine performs the following actions on all received packets: - replies to a received ARP request by sending back on the RX port a ARP reply with a "sender hardware address" field containing the MAC address of the RX port, - replies to a ICMP echo request by sending back on the RX port a ICMP echo reply, swapping the IP source and the IP destination address in the IP header, - otherwise, simply drops the received packet. When replying to a received packet that was encapsulated into a VLAN tunnel, the reply is sent back with the same VLAN identifier. By default, the testpmd configures VLAN header stripping RX option on each port. This option is not managed by the icmpecho engine which won't detect packets that were encapsulated into a VLAN. To address this issue, the VLAN header stripping option must be previously switched off with the following testpmd command: vlan set strip off When the "verbose" mode has been set with the testpmd command "set verbose 1", the "icmpecho" engine displays informations about each received packet. The "icmpecho" forwarding engine can also be used to simply check port connectivity at the hardware level (check that cables are well-plugged) and at the software level (receipt of VLAN packets, for instance). Signed-off-by: Ivan Boule <ivan.boule@6wind.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-04-30 15:30:11 +02:00
/**
* ARP header.
*/
struct rte_arp_hdr {
uint16_t arp_hardware; /* format of hardware address */
#define RTE_ARP_HRD_ETHER 1 /* ARP Ethernet address format */
app/testpmd: add engine that replies to ARP and ICMP echo requests Add a new specific packet processing engine in the "testpmd" application that only replies to ARP requests and to ICMP echo requests. For this purpose, a new "icmpecho" forwarding mode is provided that can be dynamically selected with the following testpmd command: set fwd icmpecho before starting the receipt of packets on the selected ports. Then, the "icmpecho" engine performs the following actions on all received packets: - replies to a received ARP request by sending back on the RX port a ARP reply with a "sender hardware address" field containing the MAC address of the RX port, - replies to a ICMP echo request by sending back on the RX port a ICMP echo reply, swapping the IP source and the IP destination address in the IP header, - otherwise, simply drops the received packet. When replying to a received packet that was encapsulated into a VLAN tunnel, the reply is sent back with the same VLAN identifier. By default, the testpmd configures VLAN header stripping RX option on each port. This option is not managed by the icmpecho engine which won't detect packets that were encapsulated into a VLAN. To address this issue, the VLAN header stripping option must be previously switched off with the following testpmd command: vlan set strip off When the "verbose" mode has been set with the testpmd command "set verbose 1", the "icmpecho" engine displays informations about each received packet. The "icmpecho" forwarding engine can also be used to simply check port connectivity at the hardware level (check that cables are well-plugged) and at the software level (receipt of VLAN packets, for instance). Signed-off-by: Ivan Boule <ivan.boule@6wind.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-04-30 15:30:11 +02:00
uint16_t arp_protocol; /* format of protocol address */
uint8_t arp_hlen; /* length of hardware address */
uint8_t arp_plen; /* length of protocol address */
uint16_t arp_opcode; /* ARP opcode (command) */
#define RTE_ARP_OP_REQUEST 1 /* request to resolve address */
#define RTE_ARP_OP_REPLY 2 /* response to previous request */
#define RTE_ARP_OP_REVREQUEST 3 /* request proto addr given hardware */
#define RTE_ARP_OP_REVREPLY 4 /* response giving protocol address */
#define RTE_ARP_OP_INVREQUEST 8 /* request to identify peer */
#define RTE_ARP_OP_INVREPLY 9 /* response identifying peer */
app/testpmd: add engine that replies to ARP and ICMP echo requests Add a new specific packet processing engine in the "testpmd" application that only replies to ARP requests and to ICMP echo requests. For this purpose, a new "icmpecho" forwarding mode is provided that can be dynamically selected with the following testpmd command: set fwd icmpecho before starting the receipt of packets on the selected ports. Then, the "icmpecho" engine performs the following actions on all received packets: - replies to a received ARP request by sending back on the RX port a ARP reply with a "sender hardware address" field containing the MAC address of the RX port, - replies to a ICMP echo request by sending back on the RX port a ICMP echo reply, swapping the IP source and the IP destination address in the IP header, - otherwise, simply drops the received packet. When replying to a received packet that was encapsulated into a VLAN tunnel, the reply is sent back with the same VLAN identifier. By default, the testpmd configures VLAN header stripping RX option on each port. This option is not managed by the icmpecho engine which won't detect packets that were encapsulated into a VLAN. To address this issue, the VLAN header stripping option must be previously switched off with the following testpmd command: vlan set strip off When the "verbose" mode has been set with the testpmd command "set verbose 1", the "icmpecho" engine displays informations about each received packet. The "icmpecho" forwarding engine can also be used to simply check port connectivity at the hardware level (check that cables are well-plugged) and at the software level (receipt of VLAN packets, for instance). Signed-off-by: Ivan Boule <ivan.boule@6wind.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-04-30 15:30:11 +02:00
struct rte_arp_ipv4 arp_data;
} __rte_packed __rte_aligned(2);
app/testpmd: add engine that replies to ARP and ICMP echo requests Add a new specific packet processing engine in the "testpmd" application that only replies to ARP requests and to ICMP echo requests. For this purpose, a new "icmpecho" forwarding mode is provided that can be dynamically selected with the following testpmd command: set fwd icmpecho before starting the receipt of packets on the selected ports. Then, the "icmpecho" engine performs the following actions on all received packets: - replies to a received ARP request by sending back on the RX port a ARP reply with a "sender hardware address" field containing the MAC address of the RX port, - replies to a ICMP echo request by sending back on the RX port a ICMP echo reply, swapping the IP source and the IP destination address in the IP header, - otherwise, simply drops the received packet. When replying to a received packet that was encapsulated into a VLAN tunnel, the reply is sent back with the same VLAN identifier. By default, the testpmd configures VLAN header stripping RX option on each port. This option is not managed by the icmpecho engine which won't detect packets that were encapsulated into a VLAN. To address this issue, the VLAN header stripping option must be previously switched off with the following testpmd command: vlan set strip off When the "verbose" mode has been set with the testpmd command "set verbose 1", the "icmpecho" engine displays informations about each received packet. The "icmpecho" forwarding engine can also be used to simply check port connectivity at the hardware level (check that cables are well-plugged) and at the software level (receipt of VLAN packets, for instance). Signed-off-by: Ivan Boule <ivan.boule@6wind.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-04-30 15:30:11 +02:00
/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice
*
* Make a RARP packet based on MAC addr.
*
* @param mpool
* Pointer to the rte_mempool
* @param mac
* Pointer to the MAC addr
*
* @return
* - RARP packet pointer on success, or NULL on error
*/
enforce experimental tag at beginning of declarations Putting a '__attribute__((deprecated))' in the middle of a function prototype does not result in the expected result with gcc (while clang is fine with this syntax). $ cat deprecated.c void * __attribute__((deprecated)) incorrect() { return 0; } __attribute__((deprecated)) void *correct(void) { return 0; } int main(int argc, char *argv[]) { incorrect(); correct(); return 0; } $ gcc -o deprecated.o -c deprecated.c deprecated.c: In function ‘main’: deprecated.c:3:1: warning: ‘correct’ is deprecated (declared at deprecated.c:2) [-Wdeprecated-declarations] int main(int argc, char *argv[]) { incorrect(); correct(); return 0; } ^ Move the tag on a separate line and make it the first thing of function prototypes. This is not perfect but we will trust reviewers to catch the other not so easy to detect patterns. sed -i \ -e '/^\([^#].*\)\?__rte_experimental */{' \ -e 's//\1/; s/ *$//; i\' \ -e __rte_experimental \ -e '/^$/d}' \ $(git grep -l __rte_experimental -- '*.h') Special mention for rte_mbuf_data_addr_default(): There is either a bug or a (not yet understood) issue with gcc. gcc won't drop this inline when unused and rte_mbuf_data_addr_default() calls rte_mbuf_buf_addr() which itself is experimental. This results in a build warning when not accepting experimental apis from sources just including rte_mbuf.h. For this specific case, we hide the call to rte_mbuf_buf_addr() under the ALLOW_EXPERIMENTAL_API flag. Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com> Signed-off-by: David Marchand <david.marchand@redhat.com>
2019-06-29 13:58:53 +02:00
__rte_experimental
struct rte_mbuf *
rte_net_make_rarp_packet(struct rte_mempool *mpool,
const struct rte_ether_addr *mac);
app/testpmd: add engine that replies to ARP and ICMP echo requests Add a new specific packet processing engine in the "testpmd" application that only replies to ARP requests and to ICMP echo requests. For this purpose, a new "icmpecho" forwarding mode is provided that can be dynamically selected with the following testpmd command: set fwd icmpecho before starting the receipt of packets on the selected ports. Then, the "icmpecho" engine performs the following actions on all received packets: - replies to a received ARP request by sending back on the RX port a ARP reply with a "sender hardware address" field containing the MAC address of the RX port, - replies to a ICMP echo request by sending back on the RX port a ICMP echo reply, swapping the IP source and the IP destination address in the IP header, - otherwise, simply drops the received packet. When replying to a received packet that was encapsulated into a VLAN tunnel, the reply is sent back with the same VLAN identifier. By default, the testpmd configures VLAN header stripping RX option on each port. This option is not managed by the icmpecho engine which won't detect packets that were encapsulated into a VLAN. To address this issue, the VLAN header stripping option must be previously switched off with the following testpmd command: vlan set strip off When the "verbose" mode has been set with the testpmd command "set verbose 1", the "icmpecho" engine displays informations about each received packet. The "icmpecho" forwarding engine can also be used to simply check port connectivity at the hardware level (check that cables are well-plugged) and at the software level (receipt of VLAN packets, for instance). Signed-off-by: Ivan Boule <ivan.boule@6wind.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
2014-04-30 15:30:11 +02:00
#ifdef __cplusplus
}
#endif
#endif /* _RTE_ARP_H_ */