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 0615FA046B for ; Fri, 28 Jun 2019 17:38:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DEDF23798; Fri, 28 Jun 2019 17:38:28 +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 9A041F04 for ; Fri, 28 Jun 2019 17:38:27 +0200 (CEST) Received: by mail-pl1-f196.google.com with SMTP id cl9so3436598plb.10 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=nFxN8gbHn1ypZgBYQw/2iPS9C1ySSH/2sSeHiwepeczO/4YQSD7mk9XQeZ5P126NzT ak3byKU89LMlkwgIWAhQr167v1pIQ5H0X48PU3I3PzNqYo03xAeLV12XE8gVsXOf3uqK jiKhPSamBk5dZnwe0DnKXcnO+9/e8wj8mTGr08q+SlDEDQJu8cYZbL81wyoLipDEcK8h qMDQkS5u7v4dpPaR4yKNQl22xGStx3v+145uHoefBFCVvtZCUrUu630e5pFy0OhQhUHr thuTQDH8ZiW791W2smjgv30SknyxTzkABm+HDg4LBF/CA1Huwg6QwN0kG9suwt2ZM42D Zz8A== X-Gm-Message-State: APjAAAVDYvxma6aXS0EVjt/Ehp2TFen5B+llv0tVeg8DJJJST8RjWLHE Ix/eyeBWKsbUbmEkRuHax+vPVXd40UM= 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-users] Unable to Forward the Packet after UDP Payload Modification X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" 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.