public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <bug-1001656-104-mwB7rP5box@http.bugs.ecos.sourceware.org/> (raw)
In-Reply-To: <bug-1001656-104@http.bugs.ecos.sourceware.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 on the CC list for the bug.

  parent reply	other threads:[~2013-12-31  0:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17 13:50 [Bug 1001656] New: " bugzilla-daemon
2012-08-17 13:54 ` [Bug 1001656] " bugzilla-daemon
2012-08-17 15:12 ` bugzilla-daemon
2012-09-14 14:08 ` bugzilla-daemon
2013-06-25 17:11 ` bugzilla-daemon
2013-07-15 12:01 ` bugzilla-daemon
2013-07-15 12:58 ` bugzilla-daemon
2013-07-15 15:39 ` bugzilla-daemon
2013-07-23 18:48 ` bugzilla-daemon
2013-11-26  9:49 ` bugzilla-daemon
2013-11-26 10:21 ` bugzilla-daemon
2013-12-06 10:03 ` bugzilla-daemon
2013-12-06 15:37 ` bugzilla-daemon
2013-12-09 14:25 ` bugzilla-daemon
2013-12-31  0:13 ` bugzilla-daemon [this message]
2014-01-21 16:46 ` bugzilla-daemon
2014-01-22  7:46 ` bugzilla-daemon
2014-01-31 10:39 ` bugzilla-daemon
2014-01-31 10:41 ` bugzilla-daemon
2014-01-31 10:43 ` bugzilla-daemon
2014-01-31 10:44 ` bugzilla-daemon
2014-01-31 10:51 ` bugzilla-daemon
2015-06-10  8:48 ` bugzilla-daemon
2015-06-10  8:53 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-1001656-104-mwB7rP5box@http.bugs.ecos.sourceware.org/ \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=ecos-patches@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).