Re: Need help with dns_query patch
On Wed, 13 Jul 2005, Luigi Gangitano wrote: Hi, I packaged an update squid 2.4.STABLE6 for Debian woody with the backported squid-2.5.STABLE9-dns_query from RedHat RHSA-2005-489, which is quite straight. With this patch squid fails[1] with rfc1035.c:410: rfc1035RRUnpack: Assertion `(*off) = sz' failed which can be reproduced accessing http://62.26.121.2:80/dat/bgf/trpix.gif This seems to happen on SuSE squid-2.5.STABLE1[2] too. I cannot understand the RFC1035 code enough to debug it, can you please help? The interactions between lib/rfc1035.c and src/dns_internal.c has changed many times to address issues with decoding of malformed packets. The following list of patches is relevant: squid-2.5.STABLE2-dns_root_label.patch squid-2.5.STABLE5-rfc1035NameUnpack.patch squid-2.5.STABLE7-fqdn_truncated.patch squid-2.5.STABLE9-dns_query-5.patch Also as can be seen in the list the dns_query patch was updated many times after the initial release so you'd better make sure it is the current revision you are backporting. Regards Henrik
Re: Need help with dns_query patch
Il giorno gio, 14/07/2005 alle 09.52 -0600, Duane Wessels ha scritto: I can (mostly) understand the RFC1035 code, but I cannot reproduce this bug. Can you reproduce it? If you can get a core file and stack trace that would be helpful. Also if you know anything about the type of nameserver that Squid is using in this case (BIND, dnscache, etc)? Since the URL contains an IP address, Squid should not issue a name-to-address DNS query. Perhaps Squid is configured to make address-to-name (PTR) queries and this is why the rfc1035.c code gets called for this request. Hi Duane, one of the users that are affected by this bug managed to trace it, again using an URL with an ip address (http://193.99.144.85/). This is what backtrace printed: #0 0x400c9781 in kill () from /lib/libc.so.6 #1 0x4004ee5e in pthread_kill () from /lib/libpthread.so.0 #2 0x4004f339 in raise () from /lib/libpthread.so.0 #3 0x400cabe1 in abort () from /lib/libc.so.6 #4 0x400c3e42 in __assert_fail () from /lib/libc.so.6 #5 0x080b270d in rfc1035RRUnpack (buf=0x80f3740 \027N\201\200, sz=68, off=0xbfff6b78, RR=0x85bb038) at rfc1035.c:410 #6 0x080b2b0c in rfc1035MessageUnpack (buf=0x80f3740 \027N\201\200, sz=68, answer=0xbfff6ba8) at rfc1035.c:600 #7 0x08065598 in idnsGrokReply (buf=0x80f3740 \027N\201\200, sz=68) at dns_internal.c:337 #8 0x080659f2 in idnsRead (fd=8, data=0xbfff6c30) at dns_internal.c:452 #9 0x080612bb in comm_check_incoming_poll_handlers (nfds=1, fds=0xbfff6cd0) at comm_select.c:236 #10 0x08061e1b in comm_poll_dns_incoming () at comm_select.c:900 #11 0x08061c9e in comm_poll (msec=10) at comm_select.c:484 #12 0x0807fd54 in main (argc=2, argv=0xbfffefd4) at main.c:741 Regards, -- Luigi Gangitano -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 signature.asc Description: This is a digitally signed message part
Re: Need help with dns_query patch
Hi Duane, thanks for your answer. I'm in contact with users that can reproduce the bug and provided them an unstripped version for the stack trace. In the meanwhile they reported that the bug appears with both dnscache (from djbdns-1.05) and pdnsd, both in standalone and transparent mode. I'm quoting one of the user on his analisys: I have checked the squid and dnscache logs for the timeframe in question and may have found something. The squid crashes could be identified in the access.log file by larger than usual timestamp deltas between consecutive log lines. I noticed that http://http.proxy.icq.com/hello was the URL I last saw in the crash that followed the cache.log entries following Jul 12, 9:00:14. Grepping for http://http.proxy.icq.com/hello, I notice that it is the last URL to be placed into access.log before the crashes at 8:55 and 9:00. At 9:05, it doesn't seem to have an adverse effect: Tue Jul 12 08:55:55 2005226 downstream proxy TCP_MISS/200 2586 GET http://ebay.doubleclick.net/adi/ebay.de.homepage.inactive/inactive;tn=2;to=h;tr=1;tw=240;ta=center;szs=110x110,110x110;ord=1121151443109; - FIRST_UP_PARENT/localhost text/html Tue Jul 12 08:55:55 2005314 downstream proxy TCP_MISS/200 3227 GET http://ebay.doubleclick.net/adi/ebay.de.homepage.inactive/inactive;tile=1;dcopt=ist;sz=275x300;ord=1121151443109; - FIRST_UP_PARENT/localhost text/html Tue Jul 12 08:55:55 2005221 downstream proxy TCP_MISS/200 346 GET http://http.proxy.icq.com/hello - FIRST_UP_PARENT/localhost AIM/HTTP Tue Jul 12 09:00:14 2005121 downstream proxy TCP_MISS/302 527 GET http://www.www.gmx.net.edu/ - FIRST_UP_PARENT/localhost text/html Tue Jul 12 09:00:14 2005169 downstream proxy TCP_MISS/200 16422 GET http://www.portland.co.uk/404.esp - FIRST_UP_PARENT/localhost text/html -- Tue Jul 12 09:00:17 2005 74 downstream proxy TCP_MISS/200 936 GET http://www.portland.co.uk/portland/images/switch.gif - FIRST_UP_PARENT/localhostimage/gif Tue Jul 12 09:00:17 2005 64 downstream proxy TCP_MISS/200 1064 GET http://www.portland.co.uk/portland/images/solo.gif - FIRST_UP_PARENT/localhost image/gif Tue Jul 12 09:00:17 2005230 downstream proxy TCP_MISS/200 346 GET http://http.proxy.icq.com/hello - FIRST_UP_PARENT/localhost AIM/HTTP Tue Jul 12 09:05:32 2005420 downstream proxy TCP_MISS/200 346 GET http://http.proxy.icq.com/hello - FIRST_UP_PARENT/localhost AIM/HTTP Tue Jul 12 09:05:33 2005553 downstream proxy TCP_MISS/200 316 GET http://64.12.163.134/monitor? - FIRST_UP_PARENT/localhost AIM/HTTP Tue Jul 12 09:05:33 2005616 downstream proxy TCP_MISS/200 300 POST http://64.12.163.134/data? - FIRST_UP_PARENT/localhost AIM/HTTP Here's the queries made to dnscache for the debug snippet I'd provided (the one that ends in the bug): 2005-07-12 09:00:13.765430500 query 37711366 01020304:8daa:e6c7 1 netscape.com. 2005-07-12 09:00:14.560191500 query 37711367 01020304:8daa:e5c3 1 localhost. 2005-07-12 09:00:14.621235500 query 37711368 01020304:8dab:7bce 1 www.www.gmx.net.edu. 2005-07-12 09:00:14.697003500 query 37711369 0a010425:0035:32f9 1 www.portland.co.uk. 2005-07-12 09:00:14.779568500 query 37711370 01020304:8dab:fae4 1 www.portland.co.uk. 2005-07-12 09:00:14.978950500 query 37711371 01020304:8dab:7bcf 1 www.portland.co.uk. 2005-07-12 09:00:14.983423500 query 37711372 01020304:8dab:71ec 1 www.portland.co.uk. 2005-07-12 09:00:15.090424500 query 37711373 01020304:8dab:d829 1 www.portland.co.uk. 2005-07-12 09:00:15.193001500 query 37711374 01020304:8dab:7bd0 1 www.portland.co.uk. 2005-07-12 09:00:15.29500 query 37711375 01020304:8dab:d82a 1 www.portland.co.uk. 2005-07-12 09:00:15.323293500 query 37711376 01020304:8dab:7bd1 1 www.google.com. 2005-07-12 09:00:15.338657500 query 37711377 0a010425:0035:3300 1 3.adbrite.com. 2005-07-12 09:00:16.133801500 query 37711378 01020304:8dab:d82b 1 3.adbrite.com. 2005-07-12 09:00:16.363244500 query 37711379 0a010425:0035:330a 1 www.ftjcfx.com. 2005-07-12 09:00:16.365113500 query 37711380 01020304:8dab:7bd2 1 www.portland.co.uk. 2005-07-12 09:00:16.679675500 query 37711381 01020304:8dab:d82c 1 www.portland.co.uk. 2005-07-12 09:00:16.691790500 query 37711382 01020304:8dab:7bd3 1 www.ftjcfx.com. 2005-07-12 09:00:16.795526500 query 37711383 01020304:8dab:05f3 1 www.portland.co.uk. 2005-07-12 09:00:16.985792500 query 37711384 01020304:8dab:71ed 1 www.portland.co.uk. 2005-07-12 09:00:17.046664500 query 37711385 01020304:8dab:05f4 1 www.portland.co.uk. 2005-07-12 09:00:17.081015500 query 37711386 01020304:8dab:71ee 1 www.portland.co.uk. 2005-07-12 09:00:17.113329500 query 37711387 01020304:8dab:7bd4 1 www.portland.co.uk. 2005-07-12 09:00:17.142708500 query 37711388 01020304:8dab:05f5 1 www.portland.co.uk. 2005-07-12 09:00:17.179930500 query 37711389 01020304:8dab:71ef 1 www.portland.co.uk. 2005-07-12 09:00:17.212402500 query 37711390
Re: Need help with dns_query patch
On Wed, 13 Jul 2005, Luigi Gangitano wrote: Hi, I packaged an update squid 2.4.STABLE6 for Debian woody with the backported squid-2.5.STABLE9-dns_query from RedHat RHSA-2005-489, which is quite straight. With this patch squid fails[1] with rfc1035.c:410: rfc1035RRUnpack: Assertion `(*off) = sz' failed which can be reproduced accessing http://62.26.121.2:80/dat/bgf/trpix.gif This seems to happen on SuSE squid-2.5.STABLE1[2] too. I cannot understand the RFC1035 code enough to debug it, can you please help? Hi Luigi, I can (mostly) understand the RFC1035 code, but I cannot reproduce this bug. Can you reproduce it? If you can get a core file and stack trace that would be helpful. Also if you know anything about the type of nameserver that Squid is using in this case (BIND, dnscache, etc)? Since the URL contains an IP address, Squid should not issue a name-to-address DNS query. Perhaps Squid is configured to make address-to-name (PTR) queries and this is why the rfc1035.c code gets called for this request. Duane W.
Need help with dns_query patch
Hi, I packaged an update squid 2.4.STABLE6 for Debian woody with the backported squid-2.5.STABLE9-dns_query from RedHat RHSA-2005-489, which is quite straight. With this patch squid fails[1] with rfc1035.c:410: rfc1035RRUnpack: Assertion `(*off) = sz' failed which can be reproduced accessing http://62.26.121.2:80/dat/bgf/trpix.gif This seems to happen on SuSE squid-2.5.STABLE1[2] too. I cannot understand the RFC1035 code enough to debug it, can you please help? Regards, [1] http://lists.debian.org/debian-security/2005/07/msg00152.html [2] http://www.novell.com/linux/download/updates/82_i386.html -- Luigi Gangitano -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972 C24A F19B A618 924C 0C26 signature.asc Description: This is a digitally signed message part
