On Tuesday, April 12, 2011 03:23:08 AM Stephan Mueller wrote:
Am Dienstag, 12. April 2011, um 05:18:44 schrieb Linda Knippers:
Hi Linda,
> Steve Grubb wrote:
> > Hello,
> >
> > There was a bug reported to day that I think merits an email and/or
> > discussion.
> >
> >
https://bugzilla.redhat.com/show_bug.cgi?id=695419
> > =================================
> > audisp-remote does
> >
> >> memset (&address, 0, sizeof(address));
> >> address.sin_family = htons(AF_INET);
> >> address.sin_port = htons(config.local_port);
> >> address.sin_addr.s_addr = htonl(INADDR_ANY);
> >
> > which shows in strace as
> >
> >> bind(3, {sa_family=0x200 /* AF_??? */,
> >> sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =
Bind does not do anything with the family - it just calls the bind callback
function set for the protocol by the socket syscall. What is the socket
syscall saying here?
The socket call is correct.
socket (AF_INET, SOCK_STREAM, 0);
Note that the socket syscall (specifically __sock_create) has the
following
code for the family:
if (family < 0 || family >= NPROTO)
return -EAFNOSUPPORT;
And NPROTO is defined as decimal 39 (in 2.6.38). Hence, 0x200 as a family
does not work for socket - the socket syscall would have returned an
error.
If for some reason the socket syscall uses AF_INET and diverts into IPv4,
sin_family does not seem to be used unless you have a socket-specific bind
function (e.g. RAW sockets).
It seems that bind(2) is not using the family. I checked on a system that is fixed vs
one that is not fixed. They both can transfer packets to one another. So, it looks like
you are right and there is only cosmetic problem.
To make a final determination on the impact, I would check:
- strace for socket syscall
- tcpdump on the connection
These seem to be OK aside from strace not being able to decipher the family member to
bind. However, the calls to bind and connect are successful.
-Steve