Bug#295690: leafnode: fetchnews is not IPv6-aware

2005-02-17 Thread Andreas Krennmair
Hi,
* Mark Brown <[EMAIL PROTECTED]> [05-02-17 16:58]:
newszilla6.xs4all.nl: connecting to port nntp...
warning: newszilla6.xs4all.nl: cannot resolve host name: Name exists in
DNS, but has no associated address ("A"-type DNS resource record).
newszilla6.xs4all.nl: connection failed.
Can you please send strace output?  fetchnews is supposed to support
IPv6 - that error message is slightly misleading, it actually indicates
that the resolver didn't return any data.
Here's the relevant strace log:
#v+
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.23.3")}, 28) = 0
send(4, "\201e\1\0\0\1\0\0\0\0\0\0\nnewszilla6\6xs4all\2n"..., 38, 0) = 38
gettimeofday({1108667060, 67489}, NULL) = 0
poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(4, FIONREAD, [38])= 0
recvfrom(4, "\201e\201\200\0\1\0\0\0\0\0\0\nnewszilla6\6xs4all\2n"..., 1024, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.23.3")}, [16]) = 38
close(4)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.23.3")}, 28) = 0
send(4, "\201f\1\0\0\1\0\0\0\0\0\0\nnewszilla6\6xs4all\2n"..., 43, 0) = 43
gettimeofday({1108667060, 72589}, NULL) = 0
poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(4, FIONREAD, [43])= 0
recvfrom(4, "\201f\205\203\0\1\0\0\0\0\0\0\nnewszilla6\6xs4all\2n"..., 1024, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.23.3")}, [16]) = 43
close(4)= 0
time([1108667060])  = 1108667060
getpid()= 11824
rt_sigaction(SIGPIPE, {0xb7f6c7e0, [], 0}, {0x804a290, [ALRM], SA_NOCLDSTOP}, 
8) = 0
send(3, "<60>Feb 17 20:04:20 fetchnews[11"..., 176, 0) = 176
rt_sigaction(SIGPIPE, {0x804a290, [ALRM], SA_NOCLDSTOP}, NULL, 8) = 0
write(2, "warning: newszilla6.xs4all.nl: c"..., 138) = 138
#v-
And here's the relevant output of tcpdump when filtering for udp port
53:
#v+
20:04:20.067023 192.168.23.6.1561 > 192.168.23.3.domain:  33125+ A? 
newszilla6.xs4all.nl. (38) (DF)
20:04:20.068386 192.168.23.3.domain > 192.168.23.6.1561:  33125 0/0/0 (38) (DF)
20:04:20.072198 192.168.23.6.1561 > 192.168.23.3.domain:  33126+ A? 
newszilla6.xs4all.nl.home. (43) (DF)
20:04:20.073317 192.168.23.3.domain > 192.168.23.6.1561:  33126 NXDomain* 0/0/0 
(43) (DF)
#v-
(192.168.23.3 is the DNS server, 192.168.23.6 is the server leafnode is
running one, and .home is my home network's domain)
Regards,
Andreas Krennmair
--
Die so genannte Ohnmacht des einzelnen ist vielleicht die gefährlichste
Illusion, die ein Mensch überhaupt haben kann.
 -- Joseph Weizenbaum
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


Bug#295690: leafnode: fetchnews is not IPv6-aware

2005-02-18 Thread Andreas Krennmair
* Mark Brown <[EMAIL PROTECTED]> [05-02-18 11:50]:
On Thu, Feb 17, 2005 at 08:14:26PM +0100, Andreas Krennmair wrote:
20:04:20.072198 192.168.23.6.1561 > 192.168.23.3.domain:  33126+ A? 
newszilla6.xs4all.nl.home. (43) (DF)
20:04:20.073317 192.168.23.3.domain > 192.168.23.6.1561:  33126 NXDomain* 
0/0/0 (43) (DF)
Are you sure that your system is correctly configured to resolve IPv6
hostnames?  Leafnode is using gethostbyname() to resolve the server
address which ought to be returning IPv6 addresses just as happily as
IPv4.
You are right, my system wasn't configured correctly (resolv.conf was
missing the options inet6 ...), and now it does  requests before it
does A requests, but there are still problems:
#v+
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.23.3")}, 
28) = 0 send(6, "\36\234\1\0\0\1\0\0\0\0\0\0\nnewszilla6\6xs4all\2n"..., 38, 0) = 38
gettimeofday({1108727975, 573504}, NULL) = 0
poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(6, FIONREAD, [66])= 0
recvfrom(6, "\36\234\201\200\0\1\0\1\0\0\0\0\nnewszilla6\6xs4all\2n"..., 1024, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.23.3")}, [16]) = 66
close(6)= 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGALRM, {0x80590a0, [], SA_ONESHOT|SA_NOCLDSTOP}, NULL, 8) = 0
alarm(30)   = 0
connect(6, {sa_family=AF_INET6, sin6_port=htons(119), inet_pton(AF_INET6, 
"::6040:eab7:400:0", &sin6_addr), sin6_flowinfo=2282225952, 
sin6_scope_id=17707}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol)
#v-
Here's what the resolver does:
#v+
13:04:10.949476 192.168.23.6.1637 > 192.168.23.3.domain:  61129+ ? 
newszilla6.xs4all.nl. (38) (DF)
13:04:10.950693 192.168.23.3.domain > 192.168.23.6.1637:  61129 1/0/0  
newszilla6.xs4all.nl (66) (DF)
13:04:10.961646 192.168.23.6.1637 > 192.168.23.3.domain:  61130+ PTR? 
9.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.0.0.0.8.8.8.0.1.0.0.2.ip6.arpa. (90) (DF)
13:04:10.964385 192.168.23.3.domain > 192.168.23.6.1637:  61130 1/0/0 PTR 
newszilla6.xs4all.nl. (124) (DF)
#v-
What looks strange to me is the address in the inet_pton call
(newszilla6.xs4all.nl resolves to 2001:888:0:4::119, and programs like
telnet -6 get it right), and the sin6_flowinfo and sin6_scope_id
parameters. What is also strange is the output that fetchnews brings:
#v+
$ fetchnews -vvv
leafnode 1.10.8.rel: verbosity level is 3, debugmode is 0
try_lock(timeout=5), fqdn="andi.hat.mehrpower.at"
news.individual.de: connecting to port nntp...
warning: news.individual.de: connection to 0.0.0.0 failed: Address family not supported by protocol
news.individual.de: address list exhausted without establishing connection.
news.individual.de: connection failed.
news.tahina.priv.at: connecting to port nntp...
warning: news.tahina.priv.at: cannot resolve host name: Unexpected permanent server failure.
news.tahina.priv.at: connection failed.
news.gmane.org: connecting to port nntp...
warning: news.gmane.org: cannot resolve host name: Unexpected permanent server failure.
news.gmane.org: connection failed.
news.tugraz.at: connecting to port nntp...
warning: news.tugraz.at: connection to 0.0.0.0 failed: Address family not supported by protocol
news.tugraz.at: address list exhausted without establishing connection.
news.tugraz.at: connection failed.
newszilla6.xs4all.nl: connecting to port nntp...
warning: newszilla6.xs4all.nl: connection to 32.1.8.136 failed: Address family not supported by protocol
newszilla6.xs4all.nl: address list exhausted without establishing connection.
newszilla6.xs4all.nl: connection failed.
WARNING: some servers have not been queried!
wrote active file with 31160 lines
Started process to update overview data in the background.
Network activity has finished.
$ 
#v-

Regards,
Andreas Krennmair
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


Bug#425483: [EMAIL PROTECTED]: Bug#425483: newsbeuter: doesn't load a specific feed any more (https)]

2007-05-30 Thread Andreas Krennmair

* Nico Golde <[EMAIL PROTECTED]> [07-05-22 01:32]:

- Forwarded message from gregor herrmann <[EMAIL PROTECTED]> -

Subject: Bug#425483: newsbeuter: doesn't load a specific feed any more (https)
Resent-Date: Mon, 21 May 2007 23:09:02 +
From: gregor herrmann <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
X-Mailer: reportbug 3.38
Resent-Date: Mon, 21 May 2007 23:09:05 +

Package: newsbeuter
Version: 0.4-2+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Beware, this is not the best bugreport ever written but I'm not
really sure what's going on here and thought I might pass on what
I've found so far.

Alright. The problem started on the weekend where newsbeuter was
binNMUed and curl was updated. After that the feed
'https://info.colgarra.priv.at/planet/rss20.xml' doesn't load any
more. The error message in the status line is either "Success" (hu?)
or "Argument list to long". The problem occurs also if I have only
this one feed in ~/.newsbeuter/urls.

First I thought it might be an ssl problem or a curl problem
but curl on the command line works without problems (I had already
tweaked the certificates before).

In newsbeuter's source package I found a hint about the debugging
option. When I run 'newsbeuter -d debug.log -l 5' I get the following
two error lines (each after trying to load this feed and these are
the only lines with ERROR:):

At the first try (automatic at startup):
[2007-05-22 00:44:43] ERROR: rss_parser::parse: mrss_parse_url_with_options 
failed: err = Success (1)

At the second try (a manual reload later):
[2007-05-22 00:44:49] ERROR: rss_parser::parse: mrss_parse_url_with_options 
failed: err = Argument list too long (1)


This looks like a bug in libmrss, and I can reproduce it. According to
the log, it is libmrss that returns this error, and I can't do anything
about it from newsbeuter. So I propose to hand over this issue to the
libmrss people and let them research what's going on here.

Regards,
Andreas



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]