Red Hat Bugzilla – Bug 507042
IPv6 entries in /etc/hosts breaks many applications
Last modified: 2010-06-28 09:10:31 EDT
There are two entries for "localhost" in /etc/hosts. One is for IPv4 and the other is for IPv6. Unfortunately, many services don't support IPv6 and get extremely confused. I spent an hour or two tracking down why I had a problem when I did "tftp localhost" and got a "connection refused" error.
When tracking this down, I had the same problem when I tried with nc. This clearly shows the problem. I had one copy of nc listening: "nc -u -l 50000". Another tried to connect but got an error:
amcnabb@guru:~% nc -u localhost 50000
nc: Write error: Connection refused
When I went in with "lsof -i", I eventually noticed that the first nc was listening on port 50000 with IPv4, but the second nc was trying to connect to localhost on port 50000 with *IPv6*. This took about an hour to track down and is completely unintuitive.
Thanks for report... and sorry for troubles. Without those entries machine with IPv6 only support will not work out-of-the-box - see https://bugzilla.redhat.com/show_bug.cgi?id=483244 . Therefore it would be better to actually fix the issue inside those broken applications instead of reverting those entries in setup to workaround that issue. However - this is duplicate report, see #496300 and feel free to add comments there. Closing DUPLICATE.
*** This bug has been marked as a duplicate of bug 496300 ***
Hi, I just tried exactly the same steps to reproduce the issue, but I was unsuccessful. I achieved the write error, but it was unrelated to this bug. That leads me to belief the issue described here is rather issue of individual applications (including nc - feel free to open bug for it). IMHO it is absolutely correct to have localhost entry for both IPv4 and IPv6 in /etc/hosts.
Another thought here: could you please try to trace if the second nc isn't trying to connect to localhost on IPv4 and _after_ it is unsuccessful it tries IPv6?
Ondrej, should this be cloned for nc and tftp, then?
Jan, could you clarify what you mean by "I achieved the write error, but it was unrelated to this bug"?
Jan, is there an easy way to do the trace you recommended? I'm not at all familiar with nc's source code.
Yep, it would be good to clone this for those/similar reports for nc/tftp/whateverisbroken.
I guess he meant strace ... so if you have 100% sure reproducer, just run `strace nc -u localhost 50000 2>tracebad.log` for unsuccessful and then successful connection and attach it to cloned bugzilla against nc.
Strace is one option, or you could try to catch network traffic with tcpdump / wireshark.
By unrelated write error I meant this:
I tried to run two nc instances:
server: nc -u -l 50000
client: nc -u localhost 50000
The first attempt to connect to server was successful. But once I killed the client instance (^C), server kept running, but next attempts to connect were unsuccessful and "nc: Write error: Connection refused" was displayed. That was not the case when I was trying to connect via TCP - once I closed the client, server correctly exited as well. So I suppose it has nothing to do with this issue and it is another bug, maybe even feature of nc when using UDP.
Jan, that's interesting. In my case, though, the server is definitely closed.
I attached the log from strace, so hopefully that's helpful.
Andrew, you probably forgot to attach the patch. Or am I missing it?
Jan, I didn't know there was a patch. What patch are you referring to?
(In reply to comment #6)
> I attached the log from strace, so hopefully that's helpful.
He probably meant the log from strace, which is still not attached to that bugzilla...
Created attachment 349309 [details]
output from an strace on nc
Oops. I filled out the attachment form earlier, but the submission must have failed. Hopefully it works this time.
(In reply to comment #9)
> (In reply to comment #6)
> > I attached the log from strace, so hopefully that's helpful.
> He probably meant the log from strace, which is still not attached to that
Indeed, sorry. Long day at work ...
Since bug #496300 was closed without resolution, I'm reopening this bug. Sorry if this isn't the right thing to do.
By the way, this bug means that nc and tftp, at least, need to be fixed as described in bug #496300.
Ok, adding tftp maintainer to CC (nc maintainer is already there) ... We could keep it opened - at least as a tracker bug for those apps which can't handle this IPv4/6 combined localhost.
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.