From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dominique Martinet Subject: Re: KCM - recvmsg() mangles packets? Date: Sat, 4 Aug 2018 01:20:57 +0200 Message-ID: <20180803232057.GB7583@nautica> References: <20180803182830.GB29193@nautica> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Linux Kernel Network Developers To: Tom Herbert Return-path: Received: from nautica.notk.org ([91.121.71.147]:43058 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731741AbeHDBTg (ORCPT ); Fri, 3 Aug 2018 21:19:36 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Tom Herbert wrote on Fri, Aug 03, 2018: > struct my_proto { > struct _hdr { > uint32_t len; > } hdr; > char data[32]; > } __attribute__((packed)); > > // use htons to use LE header size, since load_half does a first convertion > // from network byte order > const char *bpf_prog_string = " \ > ssize_t bpf_prog1(struct __sk_buff *skb) \ > { \ > return bpf_htons(load_half(skb, 0)) + 4; \ > }"; > > The length in hdr is uint32_t above, but this looks like it's being > read as a short. Err, I agree this is obviously wrong here (I can blame my lack of attention to this and the example I used), but this isn't the problem as the actual size is between 0 and 32 -- I could use any size I want here and the result would the same. A "real" problem with the conversion program would mean that my example would not work if I slow it down, but I can send as many packet as I want if I uncomment the usleep() on the client side or if I just throttle the network stack with a loud tcpdump writing to stdout -- that means the algorithm is working even if it's making some badly-sized conversions. (Just to make sure I did fix it to htonl(load_word()) and I can confirm there is no difference) Thanks, -- Dominique Martinet