From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C3EADA046B for ; Fri, 28 Jun 2019 17:38:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1697F4C93; Fri, 28 Jun 2019 17:38:30 +0200 (CEST) Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by dpdk.org (Postfix) with ESMTP id 9AF333798 for ; Fri, 28 Jun 2019 17:38:27 +0200 (CEST) Received: by mail-pl1-f196.google.com with SMTP id k8so3451976plt.3 for ; Fri, 28 Jun 2019 08:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=lnLCosXN/CMhdBP58fNz/UVh5+Bw9oISOGsKRL6XZWk=; b=ErCcvBYAos730YqfEp6Eq8qh6QNB3FwrZcqyQNAy4Fn2rrau3M7NkWXyGl5azg/9V9 HsNKcjV+rKb15BQq1qYblqeT9wy3/I7h8eZduIICblT6ERwhUX3+4hF+Or2QPjPqtbKc 3PiZlmGpBuA3xpO9VJO3AwlYeX1bvC+2lNfPbbkyNHdgexAgyAJWkCXe/MXPWc8y/WjT Unjg4TO35JTRoNIbdfvQkeDpfJAsPMLjbKmRdtjoRtC1/kcS7cTJB9/k6M7Do/yGYFKi ubgwn5xeSqal6w0i5e/2nIScSQEw3UMZBGIuQoEBPkqtGvKIzg8Ynw7jIsHx3Le20yub Hh+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lnLCosXN/CMhdBP58fNz/UVh5+Bw9oISOGsKRL6XZWk=; b=F2kZsNzxv25UgXLBVr6FZFbFH6qxwHo+RF3Mwypz+cum/d5qQLqws6Y4ABSaz2H8CA FZN+4bQAhK4kz665NU0IsY4oJFgeeC5MCECf76wVQbNcCXD+raeb9U3yU0Pz0IRUQQ7g e2Yy4n+sbpKJUVDcXIsa0RQGShuTozN9mk+GT4T5Db70LN4SG58yK5G5xhdWMvwwZDUH f8jM2a4/tCwE5vGB8sK0ycckEwx8DOFt/0eH3zszY/amqksqYXj/SNht/YOWtwkhXk8b EWiuJxDvw0HjyiKTNX5YhTJFX8yRVN0fxNYV8P2h847v51ZbhZ6AzCDl1ou0jfbPchHN v8Uw== X-Gm-Message-State: APjAAAVdAc8ib+kE0f/opQxiiLEQAFcAhQrjjT3qh6JSucm78L9+Eb8U E6Zh5jpNYzAGcm/ylGsRq6FQdA== X-Google-Smtp-Source: APXvYqw+lAKiA+Wl7BLNhPCQlxjz60hGPj98uC7YcwF2CFy//oMyauQsSt3OlFrRzwm3VwKewA8Tnw== X-Received: by 2002:a17:902:549:: with SMTP id 67mr12333163plf.86.1561736306714; Fri, 28 Jun 2019 08:38:26 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u10sm2783924pfh.54.2019.06.28.08.38.26 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 28 Jun 2019 08:38:26 -0700 (PDT) Date: Fri, 28 Jun 2019 08:38:20 -0700 From: Stephen Hemminger To: satyavalli rama Cc: dev@dpdk.org, users@dpdk.org Message-ID: <20190628083820.66680042@hermes.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [dpdk-users] Unable to Forward the Packet after UDP Payload Modification X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 27 Jun 2019 23:00:35 +0530 satyavalli rama wrote: > Hi >=20 >=20 > With Scapy we are sending UDP Packets to =E2=80=98P0=E2=80=99 of DPDK - V= M -1 as below >=20 > >>>sendp(Ether(src=3D"52:00:00:00:00:4a",dst=3D"50:00:00:00:00:8F")/IP(ds= t=3D"20.20.20.20",proto=3D17)/UDP(sport=3D4009,dport=3D4019)/Raw(load=3D('H= elllo Basha')), iface=3D"ens9", loop=3D1, count=3D10, inter=3D1.0002) =20 >=20 >=20 > I'm modifying MAC address in l2fwd_simple_forward (52:00:00:00:AB:CD) > and calling the below API after mac updation, in the =E2=80=98l2fwd=E2=80= =99 DPDK > Sample application. >=20 > But I'm unable to receive the =E2=80=98Appended Data=E2=80=99 on the Dest= ination Port. > P0 itself is dropping our packets... >=20 > Without Appending the Payload/Data we are able to see our packets on > the Destination Port. >=20 > Please let me know whether this issue is with respect to appending or > buffering or checksum related... >=20 > static void >=20 > pkt_modify(struct rte_mbuf *m, unsigned dest_portid) >=20 > { >=20 > struct ether_hdr *eth; >=20 > struct ipv4_hdr *ipv4; >=20 > struct udp_hdr *udp; >=20 > char *udpData; >=20 > int len =3D 0; >=20 > const char *mess =3D "Eureka"; >=20 > char *newData =3D NULL; >=20 > eth =3D rte_pktmbuf_mtod(m, struct ether_hdr *); >=20 > ipv4 =3D rte_pktmbuf_mtod_offset(m, struct ipv4_hdr *,sizeof(struct ether= _hdr)); >=20 > udp =3D rte_pktmbuf_mtod_offset(m, struct udp_hdr *, sizeof(struct > ether_hdr)+sizeof(struct ipv4_hdr)); >=20 > len =3D m->data_len; >=20 > udpData =3D rte_pktmbuf_mtod_offset(m, char *, len); >=20 > newData =3D rte_pktmbuf_append(m, 6); >=20 > if (newData !=3D NULL) >=20 > rte_memcpy(newData, mess, 6); >=20 >=20 > len =3D m->data_len; >=20 > udpData =3D rte_pktmbuf_mtod_offset(m, char *, sizeof(struct > ether_hdr)+sizeof(struct ipv4_hdr)+ >=20 > sizeof(struct udp_hdr)); >=20 > return ; >=20 > } >=20 >=20 > Please help me on figuring out this.... >=20 > Thanks, >=20 > Satya Valli. You aren't changing the ip header length or checksum. So your message at the end just looks like additional L2 trailer.