4.9 doesn't answer.
Hello, I have one FreeBSD 4.9-STABLE server, that recently started to behave strangely. It is respones all ping request and I can change between consoles and the ftp and mysql server response (but I can't login). In the last week, it happened three-times. So, the apache, sshd, etc. doesn't answer. I can't login to the sshd server. And The CTRL+ALT+DEL also doesn't work. There is not kernel panic and I couldn't see anything in the log files, only the reset button helps. Anyone met this problem? Thanks, Zsolt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9 doesn't answer.
Hi Zsold, Zsolt Bognar wrote: Hello, I have one FreeBSD 4.9-STABLE server, that recently started to behave strangely. It is respones all ping request and I can change between consoles and the ftp and mysql server response (but I can't login). In the last week, it happened three-times. So, the apache, sshd, etc. doesn't answer. I can't login to the sshd server. And The CTRL+ALT+DEL also doesn't work. There is not kernel panic and I couldn't see anything in the log files, only the reset button helps. Anyone met this problem? I don't had this problem before, but for debugging purpose you should try to get serial access to this server. Then you can check why sshd and apache aren't responding. Or you may connect Keyboard Video and Mouse and take a look onto your root console ... There must be some messages ... This behaviour sometimes happend to me, but it was always a DNS Problem ... best regards, Marian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS problem
>Date: Sun, 1 Feb 2004 12:36:27 -0800 (PST) >From: Don Lewis <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: Re: DNS problem > >On 1 Feb, Kovács Péter wrote: >> Hello, >> >>> Which server in your organization is acting as a DNS >>> server? >> The Windows... >> >>> If you only have one network card in your FreeBSD box... >> Yes, I only have one. >> >>> This could be why you only see this kind of traffic with one IP address. >> Is there a way to fix this? > >Something on your FreeBSD box is sending DNS queries to your Windows box >and is timing out its query and closing the socket it used to send the >query before the Windows box returns its response. Because you have >net.inet.udp.log_in_vain enabled, your FreeBSD box logs the arrival of >the DNS response packet because there is not a UDP socket listening on >the port that the response is being returned to. > >About all you can do to turn off these messages is to turn off >udp.log_in_vain. As a substitute you could log unexpected packets using >one of the firewall packages on FreeBSD, which would allow you to ignore >packets coming from port 53 on your DNS server. I get similar messages, viz: Feb 2 09:16:59 localhost /kernel: Connection attempt to UDP 192.168.0.1:3826 from 192.168.0.1:53 Feb 2 09:17:39 localhost /kernel: Connection attempt to UDP 192.168.0.1:3827 from 192.168.0.1:53 Feb 2 09:20:28 localhost /kernel: Connection attempt to UDP 192.168.0.1:3853 from 192.168.0.1:53 Feb 2 09:20:33 localhost /kernel: Connection attempt to UDP 192.168.0.1:3854 from 192.168.0.1:53 Feb 2 09:20:43 localhost /kernel: Connection attempt to UDP 192.168.0.1:3855 from 192.168.0.1:53 Feb 2 09:21:01 localhost /kernel: Connection attempt to UDP 192.168.0.1:3856 from 192.168.0.1:53 Sysctl log_in_vain is is set for both tcp & udp. It has been like this for ages and so far I can find neither an explanation as to why, no a way to fix it (assuming it is some kind of breakage/misconfiguration). OS is 4.9-stable as of 15 January, 2004. There is indeed a Windows box at 192.168.0.2, but DNS is on the FreeBSD machine, configured as cache-only (supposedly; could be something not quite correct in that config...) There are 2 network interfaces and the syslog indicates (I think correctly) named listening on both of them when it starts. 192.168.0/24 is on an internal interface/network; the external interface gets its ip-address from the ISP via DHCP. What I'd like to do is 1. fix any errors/misconfigurations that might be causing those messages and 2. keep the cache-only nameserver, and have it run/query efficiently. Any ideas/suggestions/suggested reading? Thanks, -kc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9 doesn't answer.
Hello, Well, I took a look in the log files, I found only one strange message: "got bad cookie vp 0xe06ca980 bp 0xcfa24bdc" However, I met this message many times in the past and It hadn't been problem. The serial console is impossible, because the server is co-located. As I saw, the sshd sent me the header info (SSH-2.0-OpenSSH_3.7.1p2), but at this point stopped and didn't request the user name. Ps: sorry for my English. Zsolt "Marian Hettwer" <[EMAIL PROTECTED]> wrote news:[EMAIL PROTECTED] > I don't had this problem before, but for debugging purpose you should > try to get serial access to this server. Then you can check why sshd and > apache aren't responding. > Or you may connect Keyboard Video and Mouse and take a look onto your > root console ... > There must be some messages ... > > This behaviour sometimes happend to me, but it was always a DNS Problem ... > > best regards, > Marian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS problem
> >Date: Sun, 1 Feb 2004 12:36:27 -0800 (PST) > >From: Don Lewis <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Cc: [EMAIL PROTECTED] > >Subject: Re: DNS problem > > > >On 1 Feb, Kovács Péter wrote: > >> Hello, > >> > >>> Which server in your organization is acting as a DNS > >>> server? > >> The Windows... > >> > >>> If you only have one network card in your FreeBSD box... > >> Yes, I only have one. > >> > >>> This could be why you only see this kind of traffic with one IP address. > >> Is there a way to fix this? > > > >Something on your FreeBSD box is sending DNS queries to your Windows box > >and is timing out its query and closing the socket it used to send the > >query before the Windows box returns its response. Because you have > >net.inet.udp.log_in_vain enabled, your FreeBSD box logs the arrival of > >the DNS response packet because there is not a UDP socket listening on > >the port that the response is being returned to. > > > >About all you can do to turn off these messages is to turn off > >udp.log_in_vain. As a substitute you could log unexpected packets using > >one of the firewall packages on FreeBSD, which would allow you to ignore > >packets coming from port 53 on your DNS server. > > I get similar messages, viz: > > Feb 2 09:16:59 localhost /kernel: Connection attempt to UDP 192. > 168.0.1:3826 from 192.168.0.1:53 > Feb 2 09:17:39 localhost /kernel: Connection attempt to UDP 192. > 168.0.1:3827 from 192.168.0.1:53 > Feb 2 09:20:28 localhost /kernel: Connection attempt to UDP 192. > 168.0.1:3853 from 192.168.0.1:53 > Feb 2 09:20:33 localhost /kernel: Connection attempt to UDP 192. > 168.0.1:3854 from 192.168.0.1:53 > Feb 2 09:20:43 localhost /kernel: Connection attempt to UDP 192. > 168.0.1:3855 from 192.168.0.1:53 > Feb 2 09:21:01 localhost /kernel: Connection attempt to UDP 192. > 168.0.1:3856 from 192.168.0.1:53 > > Sysctl log_in_vain is is set for both tcp & udp. > > It has been like this for ages and so far I can find > neither an explanation as to why, no a way to fix it > (assuming it is some kind of breakage/misconfiguration). > OS is 4.9-stable as of 15 January, 2004. Your resolver asks the same question multiple times to multiple servers. It closes the socket after it gets the first answers. It is *normal* to receive answers from the other server after the first answer. It is also *normal* to receive answers late if the nameserver cannot resolve the answer. In this case it sends SERVFAIL to say that it is giving up. Usually the client has timed-out and closed the socket before that has happened. > There is indeed a Windows box at 192.168.0.2, but DNS is on > the FreeBSD machine, configured as cache-only (supposedly; > could be something not quite correct in that config...) > > There are 2 network interfaces and the syslog indicates > (I think correctly) named listening on both of them when it > starts. 192.168.0/24 is on an internal interface/network; > the external interface gets its ip-address from the ISP > via DHCP. > > What I'd like to do is 1. fix any errors/misconfigurations > that might be causing those messages and 2. keep the > cache-only nameserver, and have it run/query efficiently. > > Any ideas/suggestions/suggested reading? > > Thanks, > > -kc > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS problem
On 2 Feb, Kenneth W Cochran wrote: >>Date: Sun, 1 Feb 2004 12:36:27 -0800 (PST) >>From: Don Lewis <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Cc: [EMAIL PROTECTED] >>Subject: Re: DNS problem >> >>On 1 Feb, Kovács Péter wrote: >>> Hello, >>> Which server in your organization is acting as a DNS server? >>> The Windows... >>> If you only have one network card in your FreeBSD box... >>> Yes, I only have one. >>> This could be why you only see this kind of traffic with one IP address. >>> Is there a way to fix this? >> >>Something on your FreeBSD box is sending DNS queries to your Windows box >>and is timing out its query and closing the socket it used to send the >>query before the Windows box returns its response. Because you have >>net.inet.udp.log_in_vain enabled, your FreeBSD box logs the arrival of >>the DNS response packet because there is not a UDP socket listening on >>the port that the response is being returned to. >> >>About all you can do to turn off these messages is to turn off >>udp.log_in_vain. As a substitute you could log unexpected packets using >>one of the firewall packages on FreeBSD, which would allow you to ignore >>packets coming from port 53 on your DNS server. > > I get similar messages, viz: > > Feb 2 09:16:59 localhost /kernel: Connection attempt to UDP > 192.168.0.1:3826 from 192.168.0.1:53 > Feb 2 09:17:39 localhost /kernel: Connection attempt to UDP > 192.168.0.1:3827 from 192.168.0.1:53 > Feb 2 09:20:28 localhost /kernel: Connection attempt to UDP > 192.168.0.1:3853 from 192.168.0.1:53 > Feb 2 09:20:33 localhost /kernel: Connection attempt to UDP > 192.168.0.1:3854 from 192.168.0.1:53 > Feb 2 09:20:43 localhost /kernel: Connection attempt to UDP > 192.168.0.1:3855 from 192.168.0.1:53 > Feb 2 09:21:01 localhost /kernel: Connection attempt to UDP > 192.168.0.1:3856 from 192.168.0.1:53 > > Sysctl log_in_vain is is set for both tcp & udp. > > It has been like this for ages and so far I can find > neither an explanation as to why, no a way to fix it > (assuming it is some kind of breakage/misconfiguration). > OS is 4.9-stable as of 15 January, 2004. > > There is indeed a Windows box at 192.168.0.2, but DNS is on > the FreeBSD machine, configured as cache-only (supposedly; > could be something not quite correct in that config...) > > There are 2 network interfaces and the syslog indicates > (I think correctly) named listening on both of them when it > starts. 192.168.0/24 is on an internal interface/network; > the external interface gets its ip-address from the ISP > via DHCP. > > What I'd like to do is 1. fix any errors/misconfigurations > that might be causing those messages and 2. keep the > cache-only nameserver, and have it run/query efficiently. You've got the same problem as in the previous message. In this case the DNS client on your machine is closing the socket that was listening for the DNS response before your caching-only DNS server on the same machine is sending its response. Note the IP addresses in the log messages: Connection attempt to UDP 192.168.0.1:3826 from 192.168.0.1:53 Log_in_vain thinks your machine is "attacking" itself. I'd recommend turning off net.inet.udp.log_in_vain, and if you want to log unexpected UDP packets, do it using ipf or ipfw where you can tune what is logged and what is ignored. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD constantly crashing
On Wed, 28 Jan 2004, Stanislav Grozev wrote: > On Tue, Jan 27, 2004 at 12:10:51PM -0600, Stephen Bader wrote: > > I saw problems like this when PAE was crashing my box in the early version > > of 4.9. I would assume the patches were put into RELENG_4_9, but maybe you > > want to try RELENG_4 to get -STABLE? > > > > I know this doesn't explain why it is crashing in 4.7 or 4.8 though. Just > > a thought. > > yes, I had the same suspicions, that's why I downgraded to RELENG_4_8 and later > to RELENG_4_7. but to no avail - the same keeps happening. I am really out of > ideas as to why it persists. Have you checked the system temperature under load? Perhaps your heatsink is gone, or the building A/C is failing. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_4: Problems with mpt driver
On Tue, 27 Jan 2004, Matti Saarinen wrote: > > I have IBM x345 which has integrated LSI 1030 raid controller. I don't > know if the problem is in the driver or do I have malfunctioning > hardware. Many times but not all, when the system boots the console > output contains almost denumerable number of the following lines: > > mpt0: EvtLogData: Event Data:mpt0: 05020012mpt0: > mpt0: EvtLogData: IOCLogInfo: 0x110a > mpt0: EvtLogData: Event Data:mpt0: 05020012mpt0: > mpt0: EvtLogData: IOCLogInfo: 0x110a > > > At the same time the activity leds of the disks da9 and da10 are > contantly lit. Not sure the events are related, but it does appear that you have the mpt driver's debugging enabled. Have you been booting with -v, or have the mpt_debug kernel environment variable set in loader.conf, or setting something in sysctl.conf? The lights-on thing would seem to be some sort of bus freeze, like a BDR from a device. Since you're using a disk enclosure, is it reporting any problems accessing any of its disks? perhaps there's a bad cable or device going down in the enclosure? I have an x335 here, which is the ATA version of the x345, yet the MPT is still on the board. I plugged it into a couple of disks for testing and it worked, except if I enabled the Integrated Mirroring (IM) which requires OS support. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't First Install FreeBSD 5.2 Release
On Wed, 28 Jan 2004, Imam Akhadi wrote: > I was install FreeBSD 5.2 on Hewlett Packard : Intel Xeon Dual Proc PIII 550 > Mem 256, the drives are Seagate Cheetah 9,1 GB ... no RAID involved, its > just straight drives using the motherboard's onboard SCSI controller > AIC7880, I have found error on SCSI SCBs by default boot only, but I can > install successfully on safe mode, non ACPI, etc. So I am rebooting my > server, but I till found a error on defult boot only. I've tried to > recompile kernel, but no defferent... so still error... Is this a NetServer or a Compaq? I've run FreeBSD on several NetServers without problems. > Here is the problem, I'm having : > [...] > <<< Dump Card State Ends This is some sort of SCSI fault. Check cables and termination, and any messages output before the dump of the card state. > Can someone tell me whether or not this is indicative of a hardware, or > software, problem? Probably hardware. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS problem
>To: Kenneth W Cochran <[EMAIL PROTECTED]> >Cc: Don Lewis <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >From: [EMAIL PROTECTED] >Subject: Re: DNS problem >Date: Tue, 03 Feb 2004 07:28:29 +1100 > >> >Date: Sun, 1 Feb 2004 12:36:27 -0800 (PST) >> >From: Don Lewis <[EMAIL PROTECTED]> >> >To: [EMAIL PROTECTED] >> >Cc: [EMAIL PROTECTED] >> >Subject: Re: DNS problem >> > >> >On 1 Feb, Kovács Péter wrote: >> >> Hello, >> >> >> >>> Which server in your organization is acting as a DNS >> >>> server? >> >> The Windows... >> >> >> >>> If you only have one network card in your FreeBSD box... >> >> Yes, I only have one. >> >> >> >>> This could be why you only see this kind of traffic with one IP address. >> >> Is there a way to fix this? >> > >> >Something on your FreeBSD box is sending DNS queries to your Windows box >> >and is timing out its query and closing the socket it used to send the >> >query before the Windows box returns its response. Because you have >> >net.inet.udp.log_in_vain enabled, your FreeBSD box logs the arrival of >> >the DNS response packet because there is not a UDP socket listening on >> >the port that the response is being returned to. >> > >> >About all you can do to turn off these messages is to turn off >> >udp.log_in_vain. As a substitute you could log unexpected packets using >> >one of the firewall packages on FreeBSD, which would allow you to ignore >> >packets coming from port 53 on your DNS server. >> >> I get similar messages, viz: >> >> Feb 2 09:16:59 localhost /kernel: Connection attempt to UDP 192. >> 168.0.1:3826 from 192.168.0.1:53 >> Feb 2 09:17:39 localhost /kernel: Connection attempt to UDP 192. >> 168.0.1:3827 from 192.168.0.1:53 >> Feb 2 09:20:28 localhost /kernel: Connection attempt to UDP 192. >> 168.0.1:3853 from 192.168.0.1:53 >> Feb 2 09:20:33 localhost /kernel: Connection attempt to UDP 192. >> 168.0.1:3854 from 192.168.0.1:53 >> Feb 2 09:20:43 localhost /kernel: Connection attempt to UDP 192. >> 168.0.1:3855 from 192.168.0.1:53 >> Feb 2 09:21:01 localhost /kernel: Connection attempt to UDP 192. >> 168.0.1:3856 from 192.168.0.1:53 >> >> Sysctl log_in_vain is is set for both tcp & udp. >> >> It has been like this for ages and so far I can find >> neither an explanation as to why, no a way to fix it >> (assuming it is some kind of breakage/misconfiguration). >> OS is 4.9-stable as of 15 January, 2004. So let me try to restate/rephrase what is going on... > Your resolver asks the same question multiple times to multiple > servers. It closes the socket after it gets the first answers. > It is *normal* to receive answers from the other server after > the first answer. "My" resolver makes some queries from some high port to port 53 of whatever nameserver(s) it is configured (explicitly or by default) to query. The answers come back from port 53 of that/those servers to that originating (high) port. As soon as it gets an answer, it closes that high port from which it was asking. This all happens via UDP? > It is also *normal* to receive answers late if the nameserver > cannot resolve the answer. In this case it sends SERVFAIL to > say that it is giving up. Usually the client has timed-out > and closed the socket before that has happened. So the logged messages I'm seeing are resulting from ports that were closed (well, actually no longer listening) following an answer to the original query. (?) In other words - originating query-port (high) got closed b/c the resolver got some answer, therefore there's no longer a listener on it, therefore the logged message(s). Correct? Is this configurable somehow? Sounds like it might not be, as it appears to be a *resolver* behavior rather than that of the nameserver. Where might I find this documented? Many thanks, -kc >> There is indeed a Windows box at 192.168.0.2, but DNS is on >> the FreeBSD machine, configured as cache-only (supposedly; >> could be something not quite correct in that config...) >> >> There are 2 network interfaces and the syslog indicates >> (I think correctly) named listening on both of them when it >> starts. 192.168.0/24 is on an internal interface/network; >> the external interface gets its ip-address from the ISP >> via DHCP. >> >> What I'd like to do is 1. fix any errors/misconfigurations >> that might be causing those messages and 2. keep the >> cache-only nameserver, and have it run/query efficiently. >> >> Any ideas/suggestions/suggested reading? >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9-R on IBM xSeries 305 or Dell PowerEdge 650?
On Wed, 28 Jan 2004, Sergey A. Osokin wrote: > On Wed, Jan 28, 2004 at 05:27:58PM +0100, Marko Zec wrote: > > > > I'm shopping for a cheap uniprocessor rackmount server which will be > > running exclusively 4.9-RELEASE. It must have a fast processor / memory > > bus, and possibly an integrated dual gigabit copper NIC attached to > > PCI-X bus (plain PCI is not an option). SCSI / RAID stuff is not > > necessary - IDE will do fine. > > > > It seems that both IBM xSeries 305 and Dell PowerEdge 650 might fit... > > Does anyone have experiences with running FreeBSD on those machines? > > Any other alternatives worth considering? > > I use IBM xSeries 330, powered by 5.1-R and works very well. I have an x335 here, which apart from the keyboard not working due to ACPI wierdness, functions properly otherwise. Works as expected with ACPI disabled. The mouse doesn't work with SuSE 9, so its not a problem limited to FreeBSD. :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9 doesn't answer.
First thing to check is rDNS - make sure the box can resolve the IP addresses used to connect to it. That's often why ssh/telnet/ftp/etc hang up - waiting for rDNS results to write log records. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9-R on IBM xSeries 305 or Dell PowerEdge 650?
On Feb 2, 2004, at 6:02 PM, Doug White wrote: I have an x335 here, which apart from the keyboard not working due to ACPI wierdness, functions properly otherwise. Works as expected with ACPI disabled. On my x335's I've found: a. I needed to disable ACPI too. b. On 5.1 I needed to step down the number of open tags (camcontrol tags) to 32 or less to prevent the whole thing from locking up. c. On 4.9 I needed to not enable the HTT "processors" or I got sluggish performance. The real SMP processors work fine. Same for you? --Jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DNS problem
> >To: Kenneth W Cochran <[EMAIL PROTECTED]> > >Cc: Don Lewis <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > >From: [EMAIL PROTECTED] > >Subject: Re: DNS problem > >Date: Tue, 03 Feb 2004 07:28:29 +1100 > > > >> >Date: Sun, 1 Feb 2004 12:36:27 -0800 (PST) > >> >From: Don Lewis <[EMAIL PROTECTED]> > >> >To: [EMAIL PROTECTED] > >> >Cc: [EMAIL PROTECTED] > >> >Subject: Re: DNS problem > >> > > >> >On 1 Feb, Kovács Péter wrote: > >> >> Hello, > >> >> > >> >>> Which server in your organization is acting as a DNS > >> >>> server? > >> >> The Windows... > >> >> > >> >>> If you only have one network card in your FreeBSD box... > >> >> Yes, I only have one. > >> >> > >> >>> This could be why you only see this kind of traffic with one IP addres > s. > >> >> Is there a way to fix this? > >> > > >> >Something on your FreeBSD box is sending DNS queries to your Windows box > >> >and is timing out its query and closing the socket it used to send the > >> >query before the Windows box returns its response. Because you have > >> >net.inet.udp.log_in_vain enabled, your FreeBSD box logs the arrival of > >> >the DNS response packet because there is not a UDP socket listening on > >> >the port that the response is being returned to. > >> > > >> >About all you can do to turn off these messages is to turn off > >> >udp.log_in_vain. As a substitute you could log unexpected packets using > >> >one of the firewall packages on FreeBSD, which would allow you to ignore > >> >packets coming from port 53 on your DNS server. > >> > >> I get similar messages, viz: > >> > >> Feb 2 09:16:59 localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3826 from 192.168.0.1:53 > >> Feb 2 09:17:39 localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3827 from 192.168.0.1:53 > >> Feb 2 09:20:28 localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3853 from 192.168.0.1:53 > >> Feb 2 09:20:33 localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3854 from 192.168.0.1:53 > >> Feb 2 09:20:43 localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3855 from 192.168.0.1:53 > >> Feb 2 09:21:01 localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3856 from 192.168.0.1:53 > >> > >> Sysctl log_in_vain is is set for both tcp & udp. > >> > >> It has been like this for ages and so far I can find > >> neither an explanation as to why, no a way to fix it > >> (assuming it is some kind of breakage/misconfiguration). > >> OS is 4.9-stable as of 15 January, 2004. > > So let me try to restate/rephrase what is going on... > > > Your resolver asks the same question multiple times to multiple > > servers. It closes the socket after it gets the first answers. > > It is *normal* to receive answers from the other server after > > the first answer. > > "My" resolver makes some queries from some high port > to port 53 of whatever nameserver(s) it is configured > (explicitly or by default) to query. The answers come back > from port 53 of that/those servers to that originating > (high) port. As soon as it gets an answer, it closes > that high port from which it was asking. This all happens > via UDP? Yes. This is all built into the C library. Note if the answer is too small for UDP the client will be told by setting TC in the UDP answer then the resolver will re-query using TCP. > > It is also *normal* to receive answers late if the nameserver > > cannot resolve the answer. In this case it sends SERVFAIL to > > say that it is giving up. Usually the client has timed-out > > and closed the socket before that has happened. > > So the logged messages I'm seeing are resulting from ports > that were closed (well, actually no longer listening) > following an answer to the original query. (?) > > In other words - originating query-port (high) got closed > b/c the resolver got some answer, therefore there's no > longer a listener on it, therefore the logged message(s). > > Correct? > > Is this configurable somehow? Sounds like it might not be, > as it appears to be a *resolver* behavior rather than that > of the nameserver. No. It is not configurable. It is a consequence of using UDP. UDP does not have connections. It just has datagrams. UDP is choosen for the initial query because 1. the messages are small 2. the number of clients using a server at one time is large (each of the root servers handle ~13000 clients/sec). The only thing wrong here is that log-in-vain UDP doesn't have the equivalent of the TCP TIME_WAIT state which handles late anwers. > Where might I find this documented? > > Many thanks, > > -kc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://
