|
Posted by Dom Wilkinson on February 15, 2006, 10:47 am
If you were Registered and logged in, you could reply and use other advanced thread options
CSCsc61300 CPU increases with high volume of DNS requests using same
four-tuple.Here is list of all bugs recognised since the release of 6.3(5)
and there associated 'patch' versions:Note there is no 102 6.3.5.100/
30-Aug-2005 05:59 - CSCsb53549 VAC+ may cause interface to stop
passing all trafficCSCsb53760 Port redirection for DNS traffic does not work
correctly. 6.3.5.101/ 07-Sep-2005 02:23 - CSCsb71315 URL
Filtering with long URLs could cause memory corruptionCSCsb75773 Malformed
HTTP GET request causes URL filtering module to cause a crash. 6.3.5.103/
11-Oct-2005 22:59 - CSCei63244 Traceback with lu_rx thread name in
failover mode.CSCsb48916 Manual ipsec fail when esp-aes-256 specified with
authCSCsb68431 names can turn off on startup, possible configuration
lossCSCsb79761 Backspace sent in cut-through proxy authenticationCSCsb91253
SIP: PIX does not parse the expire value in Register 6.3.5.104/
09-Nov-2005 03:19 - CSCef19560 PIX - show uauth doesnt display users
with space in usernameCSCsb79609 SIP: PIX does not update BYE embryonic's
timestamp.CSCsb87382 SIP: Stanby PIX show the wrong value of xlate timeout
for sip media.CSCsb91279 SIP: Standby PIX set unusual value of conn idle
time.CSCsc23638 duplicate xlates on stateful standby due to static
misconfigurationCSCsc25386 Higher metric OSPF external route is
selectedCSCsc39368 PDM with Command Authorization requires the write command
for Read-Only 6.3.5.105/ 01-Dec-2005 00:08 - CSCsc36311
OpenSSL lib can be forced to negotiate the SSL 2.0 protocolCSCsc44193 ftp
fixup drops ftp server response packetsCSCsc49665 SIP : Large number of
static PAT cause delaying of RTP packetsCSCsc53472 PIX not following SNMP
packet size standard in RFC3417CSCsc53491 Pix does not support SNMP variable
ipForwardingCSCsc60930 PIX 6.3 Hitless Upgrade supportCSCsc61300 CPU
increases with high volume of DNS requests using same four-tuple. 6.3.5.106/
14-Jan-2006 00:09 - ? CSCdv54885 downloadable ACLs not deleted after
cl uauth when telnet to PIXCSCsc14915 PIX 6.3 Spoofed TCP SYN packets can
block legitimate TCP connectionsCSCsc66215 PIX reload with Thread Name:
https_proxyCSCsc68744 PIX - Syslog PIX-6-110001: No route to IP generated
incorrectlyCSCsc91098 SIP: PIX does not create media conns if first m= has
port 0 in sdp. 6.3.5.107/ 23-Jan-2006 20:28 - CSCsc82346
tftp fixup does not allow error message from clientCSCsc92911 PIX 6.3
crashing at mgcp_show_sessionsCSCsc95334 PIX does not recognize RADIUS
access-accept and access-reject packets.CSCsd08448 downloaded acl is not
removed after a virtual telnet login 6.3.5.108/ 07-Feb-2006
23:59 - CSCsb34758 connection to DMZ fails after PIX authentication
sessionCSCsc60975 PIX crashes after removing Packet capture
configuration...ver 6.3.5CSCsd14589 PIX reload with Thread Name:
tcp_slowCSCsd26109 High CPU, delayed traffic, block depletion for 2 sec when
> try messing with this command
>
> fixup protocol dns maximum-length <bytes>
> 512 is the default
>
> jlm33990 wrote:
> > Brand new to PIX. Here's the story...
> > pix 515e running 6.3(5)
> > Box will freeze from time to time and won't pass/handle new dns
> > requests. IP traffic is still ok if you use ip# only. Host names will
> > not resolve. Clear local will fix the problem. I don't have any rules
> > or statics for dns.
> > Inside clients point to an internal solaris named box for resolution
> > who will pass request to isp if he doesn't have answer. Another fix to
> > the problem is if I change my pc's resolver from the solaris box to the
> > isp's dns.
> > I've been running a solaris based firewall for years in the same
> > environment and never had such a problem.(if I put the solaris firewall
> > back in place the problem goes away)
> > One minute I think there is something wrong with the pix because a
> > reboot or clear local will fix the problem and the next minute I wonder
> > if there could be something wrong with my named server because, as I
> > said, if I point to the isp's dns servers the problem goes away. No
> > changes have been made to the internal named server.
> > I can see from syslog that the dns udp teardowns that normally take 1
> > second all of a sudden take 2 minutes when the problem happens. I've
> > looked throught the log around the time that happens and see nothing
> > suspicious.
> > Any ideas - I'm going insane
> > thanks...jim
> >
| 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map