* getaddrinfo - should accept IPPROTO_SCTP no? @ 2006-10-13 21:30 Rick Jones 2006-10-13 22:09 ` David Miller 2006-10-13 22:59 ` Ian McDonald 0 siblings, 2 replies; 5+ messages in thread From: Rick Jones @ 2006-10-13 21:30 UTC (permalink / raw) To: Linux Network Development list I made some recent changes to netperf to workaround what is IMO a bug in the Solaris getaddrinfo() where it will clear the ai_protocol field even when one gives it a protocol in the hints. [If you happen to be trying to use the test-specific -D to set TCP_NODELAY in netperf on Solaris, you might want to grab netperf TOT to get this workaround as it relates to issues with setting TCP_NODELAY - modulo what it will do to being able to run the netperf SCTP tests on Linux...] In the process though I have stumbled across what appears to be a bug (?) in "Linux" getaddrinfo() - returning a -7 EAI_SOCKTYPE if given as hints SOCK_STREAM and IPPROTO_SCTP - this on a system that ostensibly supports SCTP. I've seen this on RHAS4U4 as well as another less well known distro. I'm about to see about concocting an additional workaround in netperf for this, but thought I'd ask if my assumption - that getaddrinfo() returning -7 when given IPPROTO_SCTP - is indeed a bug in getaddrinfo(). Or am I just woefully behind in patches or completely offbase on what is correct behaviour for getaddrinfo and hints? FWIW, which may not be much, Solaris 10 06/06 seems content to accept IPPROTO_SCTP in the hints. thanks, rick jones http://www.netperf.org/svn/netperf2/trunk/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: getaddrinfo - should accept IPPROTO_SCTP no? 2006-10-13 21:30 getaddrinfo - should accept IPPROTO_SCTP no? Rick Jones @ 2006-10-13 22:09 ` David Miller 2006-10-14 0:00 ` Sridhar Samudrala 2006-10-13 22:59 ` Ian McDonald 1 sibling, 1 reply; 5+ messages in thread From: David Miller @ 2006-10-13 22:09 UTC (permalink / raw) To: rick.jones2; +Cc: netdev From: Rick Jones <rick.jones2@hp.com> Date: Fri, 13 Oct 2006 14:30:12 -0700 > I'm about to see about concocting an additional workaround in > netperf for this, but thought I'd ask if my assumption - that > getaddrinfo() returning -7 when given IPPROTO_SCTP - is indeed a bug > in getaddrinfo(). Or am I just woefully behind in patches or > completely offbase on what is correct behaviour for getaddrinfo and > hints? Since getaddrinfo() is implemented in GLIBC, this is not very much a kernel question unless you can point the failure at some kernel calls that the GLIBC getaddrinfo() implementation makes. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: getaddrinfo - should accept IPPROTO_SCTP no? 2006-10-13 22:09 ` David Miller @ 2006-10-14 0:00 ` Sridhar Samudrala 0 siblings, 0 replies; 5+ messages in thread From: Sridhar Samudrala @ 2006-10-14 0:00 UTC (permalink / raw) To: David Miller; +Cc: rick.jones2, netdev On Fri, 2006-10-13 at 15:09 -0700, David Miller wrote: > From: Rick Jones <rick.jones2@hp.com> > Date: Fri, 13 Oct 2006 14:30:12 -0700 > > > I'm about to see about concocting an additional workaround in > > netperf for this, but thought I'd ask if my assumption - that > > getaddrinfo() returning -7 when given IPPROTO_SCTP - is indeed a bug > > in getaddrinfo(). Or am I just woefully behind in patches or > > completely offbase on what is correct behaviour for getaddrinfo and > > hints? > > Since getaddrinfo() is implemented in GLIBC, this is not very > much a kernel question unless you can point the failure at > some kernel calls that the GLIBC getaddrinfo() implementation > makes. Yes. This needs to be supported in glibc. I think adding an entry for IPPROTO_SCTP in the following structure in glibc:getaddrinfo.c should fix it. static const struct gaih_typeproto gaih_inet_typeproto[] = { { 0, 0, "", 0 }, { SOCK_STREAM, IPPROTO_TCP, "tcp", 0 }, { SOCK_DGRAM, IPPROTO_UDP, "udp", 0 }, { SOCK_RAW, 0, "raw", GAI_PROTO_PROTOANY|GAI_PROTO_NOSERVICE }, { 0, 0, "", 0 } }; I will try it out and and submit a patch to glibc. Thanks Sridhar ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: getaddrinfo - should accept IPPROTO_SCTP no? 2006-10-13 21:30 getaddrinfo - should accept IPPROTO_SCTP no? Rick Jones 2006-10-13 22:09 ` David Miller @ 2006-10-13 22:59 ` Ian McDonald 2006-10-13 23:48 ` Rick Jones 1 sibling, 1 reply; 5+ messages in thread From: Ian McDonald @ 2006-10-13 22:59 UTC (permalink / raw) To: Rick Jones; +Cc: Linux Network Development list, DCCP Mailing List On 10/14/06, Rick Jones <rick.jones2@hp.com> wrote: > I made some recent changes to netperf to workaround what is IMO a bug in the > Solaris getaddrinfo() where it will clear the ai_protocol field even when one > gives it a protocol in the hints. > > [If you happen to be trying to use the test-specific -D to set TCP_NODELAY in > netperf on Solaris, you might want to grab netperf TOT to get this workaround as > it relates to issues with setting TCP_NODELAY - modulo what it will do to being > able to run the netperf SCTP tests on Linux...] > > In the process though I have stumbled across what appears to be a bug (?) in > "Linux" getaddrinfo() - returning a -7 EAI_SOCKTYPE if given as hints > SOCK_STREAM and IPPROTO_SCTP - this on a system that ostensibly supports SCTP. > I've seen this on RHAS4U4 as well as another less well known distro. > > I'm about to see about concocting an additional workaround in netperf for this, > but thought I'd ask if my assumption - that getaddrinfo() returning -7 when > given IPPROTO_SCTP - is indeed a bug in getaddrinfo(). Or am I just woefully > behind in patches or completely offbase on what is correct behaviour for > getaddrinfo and hints? > > FWIW, which may not be much, Solaris 10 06/06 seems content to accept > IPPROTO_SCTP in the hints. > > thanks, > > rick jones > http://www.netperf.org/svn/netperf2/trunk/ In all the DCCP code which has similar issues I just do the protocol selection on the socket call e.g. case TCP: new_sock = socket(AF_INET,SOCK_STREAM,0); break; case DCCP: new_sock = socket(AF_INET,SOCK_DCCP,IPPROTO_DCCP); break; case UDP: new_sock = socket(AF_INET,SOCK_DGRAM,0); break; I'm sure you know all this anyway so apologies in advance for telling you something you probably already know! We need to come up with a way to select service codes etc for DCCP which is another parameter needed for a DCCP socket when getaddrinfo is tidied up. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: getaddrinfo - should accept IPPROTO_SCTP no? 2006-10-13 22:59 ` Ian McDonald @ 2006-10-13 23:48 ` Rick Jones 0 siblings, 0 replies; 5+ messages in thread From: Rick Jones @ 2006-10-13 23:48 UTC (permalink / raw) To: Ian McDonald; +Cc: Linux Network Development list, DCCP Mailing List > In all the DCCP code which has similar issues I just do the protocol > selection on the socket call e.g. > case TCP: > new_sock = socket(AF_INET,SOCK_STREAM,0); > break; > case DCCP: > new_sock = socket(AF_INET,SOCK_DCCP,IPPROTO_DCCP); > break; > case UDP: > new_sock = socket(AF_INET,SOCK_DGRAM,0); > break; > > I'm sure you know all this anyway so apologies in advance for telling > you something you probably already know! No worries. David mentioned that I need to talk to the glibc folks. I'm still trying to web search my way to finding them. Meanwhile I may do in netperf for this what I do for Solaris' arbitrary clearing of the ai_protocol field - kludge around it and have netperf emit a warning. rick jones ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-10-14 0:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-10-13 21:30 getaddrinfo - should accept IPPROTO_SCTP no? Rick Jones 2006-10-13 22:09 ` David Miller 2006-10-14 0:00 ` Sridhar Samudrala 2006-10-13 22:59 ` Ian McDonald 2006-10-13 23:48 ` Rick Jones
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 NNTP newsgroup(s).