search for: ai_addrconfig

AI_CANONNAME is only relevant when the resulting official name is used, which is not the case in tftpd for the address to bind to. Also AI_ADDRCONFIG isn't helpful. This flag is good for sockets used to connect(2) somewhere. But for listening sockets it makes tftpd fail to start when -a 0.0.0.0:69 is passed and no network device is up yet. This addresses Debian bug https://bugs.debian.org/771441 --- common/tftpsubs.c | 4 ++-- common/tftps...

On Sun, Jan 29, 2017 at 12:09:43PM +0100, Uwe Kleine-K?nig wrote: > AI_CANONNAME is only relevant when the resulting official name is used, > which is not the case in tftpd for the address to bind to. Also > AI_ADDRCONFIG isn't helpful. This flag is good for sockets used to > connect(2) somewhere. But for listening sockets it makes tftpd fail to > start when -a 0.0.0.0:69 is passed and no network device is up yet. > > This addresses Debian bug https://bugs.debian.org/771441 > --- > common/tft...

https://bugzilla.mindrot.org/show_bug.cgi?id=2483 Bug ID: 2483 Summary: use AI_ADDRCONFIG flag for getaddrinfo() hints on Solaris Product: Portable OpenSSH Version: 6.8p1 Hardware: All OS: Solaris Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous A...

Okay, let me chime in here. AI_ADDRCONFIG seems to be the Wrong Thing[TM]. AI_PASSIVE seems to be the Right Thing[TM]. Part of the problem is that the fallback code for the case of getaddrinfo() not being there is braindead, and of course the original code used to use gethostbyname() directly. I already have a much better fallback versio...

...Thu, Feb 02, 2017 at 04:08:49PM +1030, Ron via Syslinux wrote: > On Sun, Jan 29, 2017 at 12:09:43PM +0100, Uwe Kleine-K?nig wrote: > > AI_CANONNAME is only relevant when the resulting official name is used, > > which is not the case in tftpd for the address to bind to. Also > > AI_ADDRCONFIG isn't helpful. This flag is good for sockets used to > > connect(2) somewhere. But for listening sockets it makes tftpd fail to > > start when -a 0.0.0.0:69 is passed and no network device is up yet. > > > > This addresses Debian bug https://bugs.debian.org/771441 >...

...advancing this toward a workable solution in any way. Note I repeated less than before. I hope this will simplify the discussion and stop both of us arguing about stuff that doesn't matter much. > My previous replies to you were already focussed on the part of your > patch that removed AI_ADDRCONFIG, and why it was not needed at best, > and harmful at worst. Yes, you told me in the situations you care about the modification doesn't help you. I seem to care about different situations where the patch is beneficial. So if the patch doesn't make things worse for you (and all others out...

...ting the same things, while ignoring the options I've shown you that do properly fix the problem(s) you're claiming to care about, isn't actually advancing this toward a workable solution in any way. My previous replies to you were already focussed on the part of your patch that removed AI_ADDRCONFIG, and why it was not needed at best, and harmful at worst. I can read the actual code, and understand how gai works, and I'm pretty sure Mike understood all of that too when he first reported this bug. I'd already long ago checked that there wasn't a real bug being triggered somewhere h...

...tpd when requested to bind to an address X does in pseudo code and simplified: if X looks like an ipv6 address: family = AF_INET6 elif X looks like an ipv4 address: family = AF_INET else: family = AF_UNSPEC addrinfo = getaddrinfo(X, NULL, { .ai_family = family, .ai_flags = AI_CANONNAME | AI_ADDRCONFIG }) bind(fd, addrinfo) (where bind() works on both AF_INET and AF_INET6 if getaddrinfo returns both). This does the right thing most of the time. There are cases however where the behaviour is wrong or at least undesirable: a) if X = 0.0.0.0 and no interface (but lo) has an ipv4 address, ge...

...K address. I had in mind that at some point in the future (say with ipv8 or 802.11t-2042) the flag might mean more. I'd say the intension is to use AI_PASSIVE if you plan to listen on this address, so it seemed right to use it. But I'm willing to restrict the discussion to the removing of AI_ADDRCONFIG. > > > Using AI_CANONNAME here should be harmless at worst. So the only actual > > > change is to drop AI_ADDRCONFIG - the flag which limits getaddrinfo to > > > returning only the address families that are actually supported by the > > > configured interfaces...

On Fri, Feb 03, 2017 at 10:19:06AM +0100, Uwe Kleine-K?nig wrote: > On Fri, Feb 03, 2017 at 03:40:32PM +1030, Ron wrote: > > On Thu, Feb 02, 2017 at 02:22:47PM +0100, Uwe Kleine-K?nig wrote: > > > On Thu, Feb 02, 2017 at 04:08:49PM +1030, Ron via Syslinux wrote: > > > > > > > The use of AI_PASSIVE here is a placebo. That flag has no effect unless > >

...vice on 'this machine' is illustrative. There's no deeper distinction or fundamental difference related to what functions you might later pass the address(es) you obtain to. > > Using AI_CANONNAME here should be harmless at worst. So the only actual > > change is to drop AI_ADDRCONFIG - the flag which limits getaddrinfo to > > returning only the address families that are actually supported by the > > configured interfaces on the system. And ordinarily that would seem to > > be a fairly uncontroversially Good Thing to do, for both connecting and > > liste...

...server/upsd.c > trunk/server/upsd.h > trunk/server/upstype.h > Log: > * clients/upsclient.ch: > - hostname can now be specified as a fully.qualified.domain.name or an [address literal] > - cleaned up IPv6 code > * m4/nut_check_ipv6.m4: > - removed check for AI_ADDRCONFIG, since it is no longer used (for portability reasons, wasn't really needed anyway) > * server/upsd.ch, server/conf.c, server/stype.h: > - listen on multiple TCP sockets (to be configured in upsd.conf) > - removed -i and -p options which are obsoleted by the above > - liste...

With the Ipv6 patch (r708), I get: upsclient.c: In function `upscli_connect': upsclient.c:469: `AI_ADDRCONFIG' undeclared (first use in this function) upsclient.c:469: (Each undeclared identifier is reported only once upsclient.c:469: for each function it appears in.) Even if it doesn't break IPv4 support, it may break portability, as IPv6 seems to require specific functions that are not as standa...

...h>, but Winsock isn't actually used. What's the reason? diff --git a/config.h b/config.h index bd1dac1..76c7514 100644 --- a/config.h +++ b/config.h @@ -325,6 +325,11 @@ const char *gai_strerror(int); #define AI_CANONNAME 0x0002 /* Request for canonical name. */ #endif +#ifndef AI_ADDRCONFIG +#define AI_ADDRCONFIG 0x0020 /* Use configuration of this host to choose + returned address type.. */ +#endif + #ifndef EAI_NONAME #define EAI_NONAME -2 /* NAME or SERVICE is unknown. */ #endif @@ -335,15 +340,16 @@ const char *gai_strerror(int);...

...tests indicate a problem. A notable change to the networking code between 1.2 and 1.4 was that we switched to using getaddrinfo() to resolve names. But that ought to be able to handle a string with an IP address, as it does on Linux, etc. For the server we use: hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG | AI_NUMERICSERV; And for the client: hints.ai_flags = AI_ADDRCONFIG | AI_NUMERICSERV; The switch to getaddrinfo() was a first step towards IPv6 support, but also replaces use of an obsolete, non-thread-safe API with a thread-safe alternative API which we can reasonably expect all platforms...

Dear Olly Betts, same 32 bit compiler version hardware OS OS version as here (where remotetcp_chert passed and skipped 3) xapian-core-1.2.21.tar.xz http://nurmi-labs.blogspot.com/2015/10/xapian.html ./apitest backend remoteprog_brass: All 225 tests passed, 3 skipped. ./apitest backend remotetcp_brass: All 225 tests passed, 3 skipped. ./apitest backend remoteprog_chert: All 225 tests passed,

...} else - buff = NULL; -#else + freehostent(host); + } + } else { + /* According to FreeBSD's man page, getipnodebyname and such + * aren't threadsafe either */ + _lock_resolver(); + /* Try IPv6 if available and configured; else try IPv4 */ + host = getipnodebyname(what, AF_INET6, AI_ADDRCONFIG, &err); + _unlock_resolver(); + if (host == NULL) { + _lock_resolver(); + host = getipnodebyname(what, AF_INET, AI_ADDRCONFIG, + &err); + _unlock_resolver(); + } + if (host) { + inet_ntop(host->h_addrtype, host->h_addr_list[0], + buff, len); + freehostent(hos...

Hi! I am using OpenBSD 4.4 with the build-in TFTP-Daemon for PXE. Distributing OpenBSD works fine. Now I want to distribute OpenBSD and WinPE. I've installed PXELinux 3.72 and configured it. Works also fine for PXELinux and distributing OpenBSD. To distribute WinPE I need a remap rule (\ -> /) for the TFTP-Daemon. I've created a file /etc/tftpd.remap with the following rule: rgG \\ /

OK, I have removed the autoconf test for s6_addr32 (which is no longer used), and wrote a new test for IN6_IS_ADDR_V4MAPPED. The latter is probably portable, but since we're already in the business of testing, it does not hurt to do so. Arjen, I wonder about server/access.c, line 60-61: return (IN6_IS_ADDR_V4MAPPED(ip6) && ((((const u_int32_t *)ip6)[3] &

https://bugzilla.mindrot.org/show_bug.cgi?id=1950 Bug #: 1950 Summary: sshd tries to bind over and over to ::1 for several seconds Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2