Possible Innfeed bug - Destination has unspecified address.
D. Stussy
publishing "0.0.0.0" (the unspecified address) as its address. It appears
that innfeed is not spooling for that feed but instead connecting back to
me. Inn_status is reporting that one of my incoming connections is myself
(and yes, I do have myself in "~news/etc/incoming.conf" for some mailing
list gateways) with approximately the same article counts as the bad feed.
Should innfeed continue feeding a site with the unspecified address? I
don't believe so. I haven't looked back at the source code but I don't
remember this being checked for anywhere the last time I did look. Can
anyone confirm this behavior?
For those sharing the peer:
usenet.zapto.org. 60 IN A 0.0.0.0
Julien ÉLIE
> One of my peers has had a change in its DNS address record and is now
> publishing "0.0.0.0" (the unspecified address) as its address. It appears
> that innfeed is not spooling for that feed but instead connecting back to
> me.
I am unsure if it is really a bug.
22:24 news@trigofacile ~% telnet 0.0.0.0 119
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
200 news.trigofacile.com InterNetNews server INN 2.5.0 (20080507 prerelease) ready
0.0.0.0 is localhost even for telnet.
> usenet.zapto.org. 60 IN A 0.0.0.0
He could also advertise a private address (which could exist in your own
private network if you have one...).
--
Julien ÉLIE
« Il buvait toutes mes paroles, et comme je parlais beaucoup,
à un moment, je le vois qui titubait... » (Raymond Devos)
D. Stussy
news:fvt49o$d71$1...@news.trigofacile.com...
> Hi D. Stussy,
> > One of my peers has had a change in its DNS address record and is now
> > publishing "0.0.0.0" (the unspecified address) as its address. It
appears
> > that innfeed is not spooling for that feed but instead connecting back
to
> > me.
>
> I am unsure if it is really a bug.
>
> 22:24 news@trigofacile ~% telnet 0.0.0.0 119
> Trying 0.0.0.0...
> Connected to 0.0.0.0.
> Escape character is '^]'.
> 200 news.trigofacile.com InterNetNews server INN 2.5.0 (20080507
prerelease) ready
>
> 0.0.0.0 is localhost even for telnet.
>
> > usenet.zapto.org. 60 IN A 0.0.0.0
>
> He could also advertise a private address (which could exist in your own
> private network if you have one...).
OK, but isn't the unspecified address invalid as a destination address? It
can be used as a source only when a host doesn't know its own address
(autoconfiguration - DHCP, BOOTP, etc.). Regardless, here, it's feeding
data over the link, and as it does loop back to me, all messages are being
rejected as I've already received them (of course). What should happen (in
my opinion) is that the feed be spooled and then fed out when the remote
host places a regular, reachable anycast address back into the DNS. An
RFC1918 address is valid here(*). Until yesterday, a regular
run-of-the-mill address was there.
The fact that the unspecified address is an invalid destination is why I
called it a bug.
(*)- However, he shouldn't be advertising an RFC 1918 address in the public
view of his DNS data. I'm assuming that this is temporary as the news admin
hasn't responded to my e-mail query yet.
Ray Banana
> The fact that the unspecified address is an invalid destination is why I
> called it a bug.
If it's a bug, it's a bug of the underlying operating system and its
network stack. INN does not do any address resolution by itself.
traceroute 0.0.0.0
traceroute to 0.0.0.0 (0.0.0.0), 30 hops max, 40 byte packets
1 localhost.localdomain (127.0.0.1) 0.036 ms 0.008 ms 0.007 ms
This is on Linux. On *BSD systems this will just time out without a
result and on Windows you will get a "invalid destination" error.
> (*)- However, he shouldn't be advertising an RFC 1918 address in the public
> view of his DNS data. I'm assuming that this is temporary as the news admin
> hasn't responded to my e-mail query yet.
Well, that's Henry, and Henry is somewhat ... *peculiar*. I used to peer
with him and he had a habit of doing strange things to his servers and
DNS entries every two or three months.
--
Too many ingredients in the soup, no room for a spoon.
http://news.motzarella.org
D. Stussy
news:80y76lh...@banana.shacknet.nu...
> Thus spake "D. Stussy" <sp...@bde-arc.ampr.org>
> > The fact that the unspecified address is an invalid destination is why I
> > called it a bug.
>
> If it's a bug, it's a bug of the underlying operating system and its
> network stack. INN does not do any address resolution by itself.
Regardless of whether the underlying OS will connect it to somewhere or not,
it's still not a valid destination and needs to be checked for and ignored
(passed over in favor of the "next" address or spool if no other address is
available). Don't forget the same with IPv6's "::".
Ray Banana
>> > The fact that the unspecified address is an invalid destination is why I
>> > called it a bug.
>> If it's a bug, it's a bug of the underlying operating system and its
>> network stack. INN does not do any address resolution by itself.
> Regardless of whether the underlying OS will connect it to somewhere or not,
> it's still not a valid destination and needs to be checked for and ignored
> (passed over in favor of the "next" address or spool if no other address is
> available). Don't forget the same with IPv6's "::".
From an architecture point of view INN is an application using network
services. Thus it should not and should not have to implement the
lower levels of the OSI model. IOW, I prefer a consistent behaviour of
all applications using the same services and http://0.0.0.0 should get
me to the same destination as telnet 0.0.0.0 119.
D. Stussy
And "telnet 0.0.0.0 119" and "http://0.0.0.0/" are also technically invalid.
Specifying 0.0.0.0 (or for IPv6, "::") as the destination address is
universally invalid. INN (or any other program) should not be making
invalid connection requests. 0.0.0.0 is valid only as a SOURCE address -
during host/IP autoconfiguration. The remaining 2^32-1 IPv4 and 2^128-1
IPv6 addresses are all valid destinations (for this purpose). Regardless of
whether the underlying OS accepts or rejects the connection, it is
semantically wrong to attempt such.
Linux accepts it only for a single reason: Inn's inbound socket has been
bound to 0.0.0.0 as the unspecified address - and that's a literal match. I
bet if I were to specifically bind the socket to ONLY my main IPv4 address
(via the "bindaddress" configuration command), then no connection would be
made. I may be testing this later. Whether this is ALSO a Linux-only bug I
shall deterime later.
I don't know why this peer decided to change its address to 0.0.0.0 instead
of deleting the A record completely, but I'm momentarily glad it did - as it
exposed the problem.
Russ Allbery
> Linux accepts it only for a single reason: Inn's inbound socket has been
> bound to 0.0.0.0 as the unspecified address - and that's a literal match.
Actually, Linux treats 0.0.0.0 as an outbound address synonymously with
127.0.0.1, as near as I can tell.
I await your bug reports against OpenSSH, lynx, and ncftp, all of whom
also accept and use a 0.0.0.0 IP address. :) That's just the first three
other programs I checked.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Please post questions rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Ray Banana
> Linux accepts it only for a single reason: Inn's inbound socket has been
> bound to 0.0.0.0 as the unspecified address - and that's a literal
> match.
1. Linux directs connection requests to 0.0.0.0 to 127.0.0.1 regardless
of the applications that requests them. Ping, telnet, web browsers
and netcat will be directed to the local loopback interface when
requesting a connection to 0.0.0.0, which is actually the *network*
address of the local network.
2. Innfeed is a completely independent process, the interfaces that innd
binds to are irrelevant for how innfeed's connection requests are
handled by the network stack
> I bet if I were to specifically bind the socket to ONLY my main IPv4 address
> (via the "bindaddress" configuration command), then no connection would be
> made.
3. I see the same behaviour on my Linux servers although innd *does*
explicitly bind to one particluar interface.
D. Stussy
news:fvt1bf$qug$1...@snarked.org...
> One of my peers has had a change in its DNS address record and is now
In looking at this further and while debugging a local patch to avoid the
above problem, I noticed something else strange. First, a simple patch:
diff -ur inn-STABLE-20080229/innfeed/host.c inn-Modified/innfeed/host.c
--- inn-STABLE-20080229/innfeed/host.c 2008-02-29 10:08:19.000000000 +0000
+++ inn-Modified/innfeed/host.c 2008-05-12 20:24:25.000000000 +0000
@@ -3298,6 +3322,20 @@
fputc ('\n',fp) ;
+ if (host->ipAddrs) {
+ int i;
+ char *family;
+
+ for(i=0; host->ipAddrs[i] != NULL; ++i) {
+ switch(host->ipAddrs[i]->sa_family) {
+ case AF_INET: family="IPv4"; break;
+ case AF_INET6: family="IPv6"; break;
+ default: family="????"; break;
+ }
+ fprintf(fp,"IP Addr %-2u: %-4.4s %s\n", i+1, family,
sprint_sockaddr(host->ipAddrs[i]));
+ }
+ }
+
fprintf (fp, " seconds: %-7ld art. timeout: %-5d ip name:
%s\n",
host->firstConnectTime > 0 ? (long)(now - host->firstConnectTime)
: 0,
host->params->articleTimeout, host->params->ipName) ;
--- End of patch
As one might guess, this patch causes innfeed to print the IP addresses
(IPv4 and IPv6) that it has internally stored for a peer. It prints one
line as expected for the stable version released 02/29/2008 (the version I
had on hand), but when I apply it to today's version (Stable 05/12/2008), I
was rather surprised: Each address seems to be duplicated in the "ipAddrs"
array 3 times. That is just strange. This is the only patch applied to
today's version - a fresh copy.
Why is each IP address stored 3 times in the array? Where multiple
addresses exist, all copies of the same address were consecutive.
Example:
------------------------------------------------------------------
feeder.erje.net
Addr 1 : IPv6 2001:470:992a::1
Addr 2 : IPv6 2001:470:992a::1
Addr 3 : IPv6 2001:470:992a::1
Addr 4 : IPv4 88.198.5.53
Addr 5 : IPv4 88.198.5.53
Addr 6 : IPv4 88.198.5.53
seconds: 746 art. timeout: 600 ip name:
snarked-in.feeder.erje.net
...
------------------------------------------------------------------
With the "i" index incrementing, it's not some stupid error inside the loop.
PS: What's with all the "%d"'s for values which are obviously UNSIGNED or
non-negative only. Why not "%u" for those values?
Julien ÉLIE
> As one might guess, this patch causes innfeed to print the IP addresses
> (IPv4 and IPv6) that it has internally stored for a peer. It prints one
> line as expected for the stable version released 02/29/2008 (the version I
> had on hand), but when I apply it to today's version (Stable 05/12/2008), I
> was rather surprised: Each address seems to be duplicated in the "ipAddrs"
> array 3 times. That is just strange. This is the only patch applied to
> today's version - a fresh copy.
>
> Why is each IP address stored 3 times in the array? Where multiple
> addresses exist, all copies of the same address were consecutive.
I do not know exactly where the problem comes from (I assume it is triggered
off by some changes for bindaddress/bindaddress6 -- revision 7778).
Note that CURRENT works fine (only one IP is printed).
STABLE has the problem but innfeed still does its job correctly.
I forward the bug to inn-workers.
--
Julien ÉLIE
« Qui habet aures audiendi, audiat. » (Évangiles)
D. Stussy
Thank you for confirming that it wasn't me. I also note that it won't
hamper overall operation - just waste some resources (memory, bandwidth,
etc).
As for the whole "unspecified address" as destination thing, I still don't
like it, but it appears as if it may be a Linux kernel bug, not INN.
However, I'm still a bit shocked at the attitude of going ahead and letting
innfeed try an invalid situation - poor programming practice, but I do
understand that it makes the code cleaner. My view is that no properly
designed program should be allowed to do invalid things.
Julien ÉLIE
>> I forward the bug to inn-workers.
>
> Thank you for confirming that it wasn't me. I also note that it won't
> hamper overall operation - just waste some resources (memory, bandwidth,
> etc).
Miquel van Smoorenburg found the problem:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
It's standard getaddrinfo() behaviour. It returns the same address
three times .. a small test program that prints the return
values of getaddrinfo shows:
$ ./getaddrinfo feeder.erje.net
family: 2, socktype: 1, protocol: 6
family: 2, socktype: 2, protocol: 17
family: 2, socktype: 3, protocol: 0
(that's protocol TCP, UDP, and IP)
If we add
hints.ai_socktype = SOCK_STREAM;
to the code where the hints struct is filled, then the result is:
$ ./getaddrinfo feeder.erje.net
family: 2, socktype: 1, protocol: 6
This isn't really a big problem, things won't break. It just means
that rotating the peer IP addressses is a bit slower than it could be.
For 2.4.4 this should fix it I think:
#---------------- innfeed-host-thrice-fix.diff ---------------
diff -ruN inn-2.4.4.orig/innfeed/host.c inn-2.4.4/innfeed/host.c
--- inn-2.4.4.orig/innfeed/host.c 2008-05-05 12:18:36.000000000 +0200
+++ inn-2.4.4/innfeed/host.c 2008-05-14 14:06:18.000000000 +0200
@@ -1158,6 +1158,7 @@
memset(&hints, 0, sizeof(hints));
hints.ai_family = family ? family : AF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;
#ifdef AI_ADDRCONFIG
hints.ai_flags = AI_ADDRCONFIG;
#endif
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I will commit it as soon as possible. Therefore, the problem will not
be happening again in STABLE snapshots.
Thanks for having seen it.
--
Julien ÉLIE
« -- Il est temps d'aller déguster une bonne cervoise de derrière les fagots !
-- Accompagnées de sangliers dodus rôtis sur ces mêmes fagots, bien sûr ! » (Astérix)
D. Stussy
> Miquel van Smoorenburg found the problem:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> It's standard getaddrinfo() behaviour. It returns the same address
> three times .. a small test program that prints the return
> values of getaddrinfo shows:
>
> $ ./getaddrinfo feeder.erje.net
> family: 2, socktype: 1, protocol: 6
> family: 2, socktype: 2, protocol: 17
> family: 2, socktype: 3, protocol: 0
>
> (that's protocol TCP, UDP, and IP)
From the man page: "... or if the same service is available from multiple
socket protocols (one SOCK_STREAM address and another SOCK_DGRAM address,
for example)."
I missed that too. Grrrr!
> ...
> #---------------- innfeed-host-thrice-fix.diff ---------------
> diff -ruN inn-2.4.4.orig/innfeed/host.c inn-2.4.4/innfeed/host.c
> --- inn-2.4.4.orig/innfeed/host.c 2008-05-05 12:18:36.000000000 +0200
> +++ inn-2.4.4/innfeed/host.c 2008-05-14 14:06:18.000000000 +0200
> @@ -1158,6 +1158,7 @@
>
> memset(&hints, 0, sizeof(hints));
> hints.ai_family = family ? family : AF_UNSPEC;
> + hints.ai_socktype = SOCK_STREAM;
> #ifdef AI_ADDRCONFIG
> hints.ai_flags = AI_ADDRCONFIG;
> #endif
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> I will commit it as soon as possible. Therefore, the problem will not
> be happening again in STABLE snapshots.
> Thanks for having seen it.
Too bad this didn't make it into the official inn-2.4.4 release yesterday.
Although not absolutely needed, I wonder if "hints.ai_protocol" should
specify TCP (6) also - just for completeness? If the function were expanded
to return data from other AFs (e.g. "AX.25" which has both a datagram and
connected/stream modes) in the future, ....
Julien ÉLIE
> Too bad this didn't make it into the official inn-2.4.4 release yesterday.
Note that the release was generated on May, 5th and ready on May, 9th
on ftp.isc.org; Russ was waiting for ISC to update their web site
before sending the announcement yesterday (the 14th).
File: inn-2.4.4.tar.gz 1853 KB 05/05/2008 10:19:00
File: inn-2.4.4.tar.gz.asc 1 KB 09/05/2008 17:01:00
File: inn-2.4.4.tar.gz.md5 1 KB 05/05/2008 10:19:00
That is especially why your bug report had not been taken into account
for the release. I just wanted to tell you that, in case you thought
it was released despite your bug report.
> Although not absolutely needed, I wonder if "hints.ai_protocol" should
> specify TCP (6) also - just for completeness? If the function were expanded
> to return data from other AFs (e.g. "AX.25" which has both a datagram and
> connected/stream modes) in the future, ....
Well, we shall see when other AFs are implemented :-)
And it should also be added to other places into the code.
Not for the 2.4 branch anyway!
--
Julien ÉLIE
« Il vaut mieux avoir de l'avenir que du passé. »
D. Stussy
> > Too bad this didn't make it into the official inn-2.4.4 release
yesterday.
>
> Note that the release was generated on May, 5th and ready on May, 9th
> on ftp.isc.org; Russ was waiting for ISC to update their web site
> before sending the announcement yesterday (the 14th).
>
> ftp://ftp.isc.org/isc/inn/
>
> File: inn-2.4.4.tar.gz 1853 KB 05/05/2008 10:19:00
> File: inn-2.4.4.tar.gz.asc 1 KB 09/05/2008 17:01:00
> File: inn-2.4.4.tar.gz.md5 1 KB 05/05/2008 10:19:00
>
> That is especially why your bug report had not been taken into account
> for the release. I just wanted to tell you that, in case you thought
> it was released despite your bug report.
No. I know that these things take time to filter through their support
systems.