This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001656] FreeBSD: add AF_PACKET socket familiy
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Tue, 31 Dec 2013 00:13:34 +0000
- Subject: [Bug 1001656] FreeBSD: add AF_PACKET socket familiy
- Authentication-results: sourceware.org; auth=none
- Auto-submitted: auto-generated
- References: <bug-1001656-777 at http dot bugs dot ecos dot sourceware dot org/>
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 <bernd.edlinger@hotmail.de> ---
(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 the assignee for the bug.