From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31793 invoked by alias); 31 Dec 2013 00:13:52 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 31771 invoked by uid 89); 31 Dec 2013 00:13:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail.ecoscentric.com Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 31 Dec 2013 00:13:48 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 078C1468000F for ; Tue, 31 Dec 2013 00:13:44 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmQdaX9jGHQV; Tue, 31 Dec 2013 00:13:36 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001656] FreeBSD: add AF_PACKET socket familiy Date: Tue, 31 Dec 2013 00:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: bernd.edlinger@hotmail.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: high X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-12/txt/msg00003.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001656 --- Comment #14 from Bernd Edlinger --- (In reply to comment #13) > After the first quick test: Yes, it looks like the IPv6 UDP packet is now > sent. Good. > However, I am wondering if it's really the right thing to stuff > padding bytes into sockaddr_in6. I am not familiar with the whole networking > code stuff, but I saw that in the Windows world and partly in various unix > flavors 28 Bytes for sockaddr_in6 or even little less seem common. > Is there > any RFC, ISO or POSIX standard where it's said that these structures should > have the same size? probably not. The goal is to be compatible to other O/S where possible. However for eCos an exact binary compatiblity is not required. Even the defines for AF_INET and AF_INET6 may be different from what they are on linux. For whatever reason eCos chose to enlarge struct sockaddr from 16 bytes (as it is on linux) to 32 bytes. I always assumed that was a smart move, which was done to make struct sockaddr large enough to hold a sockaddr_in6, but I never checked that, and I did not much testing with IPv6 either... Well, struct sockaddr is the base-class of all socket types, and therefore all other socket types should be at least as large as 32 bytes. As a consequence sockaddr_in has a padding enlarged from 8 (as it is on linux) enlarged to 24. But sockaddr_in6 should have done the same. > sidenote: Why was there even a 'len'-parameter in bsd_bind() when it was not > used up until your patch? Definitely a BUG. Fact is: The code in bsd_bind does _only_ work under the assumption that len == sizeof(sockaddr) otherwise you access beyond the end of *sa or you only copy a part of the underlying structure. I did not want to add more complexity here, like using dynamic allocations, because with AF_INET/AF_INET6/AF_PACKET I can make sure that all socket structures are exactly the same size. On the other hand, on linux nobody sets "sa_len" but uses the len parameter instead to tell bind() how long the structure is. So I figured it would be better to use the len parameter to set that member, because inside the network stack, there is no "len", but always sa_len. So, my intention was just to improve compatibilty to linux here, and still have the right data in sa_len for the network stack. Regards Bernd. -- You are receiving this mail because: You are on the CC list for the bug.