Date: Thu, 24 Jul 2008 08:31:50 +0100 From: Alex Trull <alex@trull.org> To: Robert Jameson <rj@dawnshosting.com> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: network problems 7.0-p3: sendto: Operation not permitted Message-ID: <1216884710.6500.0.camel@porksoda> In-Reply-To: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com> References: <9072a4470807232259x603f46k49474f5eb309d0fa@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-sIetbD7Lx7ZgMCqrbuYN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Robert, The config files you attached were a series of 403 forbidden htmls. The icmp pings (1 per second) do not constitute an attack. It looks like you are genuinely running out of free states or file descript= ors. Had you applied any tuning that may have been lost in the upgrade ? How many packets and sessions is this host meant to be handling - and what = sort of traffic ? -- Alex On Thu, Jul 24, 2008 at 01:59:23AM -0400, Robert Jameson wrote: > Hello Everyone, >=20 > Recently I upgraded to freebsd 7.0-p3 from 7.0-p2, once i upgraded i bega= n > to have problems with my network, nothing has changed configuration wise, > let me show you guy's an example. >=20 > (12:46 AM):(root@cube)/$ ping google.com > PING google.com (72.14.207.99): 56 data bytes > 64 bytes from 72.14.207.99: icmp_seq=3D0 ttl=3D240 time=3D64.713 ms > ^C > --- google.com ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 64.713/64.713/64.713/0.000 ms >=20 > (12:46 AM):(root@cube)/$ ping google.com > PING google.com (72.14.207.99): 56 data bytes > 64 bytes from 72.14.207.99: icmp_seq=3D0 ttl=3D240 time=3D73.814 ms > 64 bytes from 72.14.207.99: icmp_seq=3D1 ttl=3D240 time=3D64.943 ms > ^C > --- google.com ping statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 64.943/69.379/73.814/4.435 ms >=20 > (12:46 AM):(root@cube)/$ ping google.com > PING google.com (72.14.207.99): 56 data bytes > ping: sendto: Operation not permitted > ^C > --- google.com ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > (12:46 AM):(root@cube)/$ >=20 >=20 > As you can see above, I issued the ping command (4) times waiting for out= put > and then doing CTRL+C to interrupt the commands quickly and send them aga= in > on the 4th try i did not intterupt it and received the operation not > permitted. hitting ctrl+c on this error I can type ping again and it will > work correctly. >=20 >=20 > I have the same problem with almost every network command, wget, curl, > fetch, lynx, ssh, nslookup, host etc. >=20 >=20 >=20 > This appears to be an issue with the network. >=20 > I have attached my rc.conf and sysctl.conf and pf.conf please let me know= if > any other information is required. >=20 >=20 > Errors from /var/log/console.log: >=20 > Jul 18 21:10:02 cube kernel: Jul 18 21:10:02 cube named[908]: socket: too > many open file descriptors > Jul 19 00:30:13 cube kernel: Jul 19 00:30:13 cube named[9748]: socket: to= o > many open file descriptors > Jul 19 00:30:54 cube kernel: Jul 19 00:30:14 cube last message repeated 2= 8 > times >=20 >=20 >=20 > Initially I figured this problem was bind related and since it has been a > planned project for the past few months to switch to djbdns, I took the t= ime > to switch to djbdns, so bind is no longer running. >=20 > I was also receiving this in /var/log/messages: >=20 > Jul 20 22:15:39 cube kernel: Limiting open port RST response from 318 to = 200 > packets/sec > Jul 20 22:15:40 cube kernel: Limiting open port RST response from 624 to = 200 > packets/sec > Jul 20 22:15:42 cube kernel: Limiting open port RST response from 213 to = 200 > packets/sec > Jul 20 22:15:50 cube kernel: Limiting open port RST response from 439 to = 200 > packets/sec > Jul 20 22:15:51 cube kernel: Limiting open port RST response from 673 to = 200 > packets/sec > Jul 20 22:15:52 cube kernel: Limiting open port RST response from 730 to = 200 > packets/sec > Jul 20 22:15:53 cube kernel: Limiting open port RST response from 307 to = 200 > packets/sec > Jul 20 22:16:02 cube kernel: Limiting open port RST response from 435 to = 200 > packets/sec > Jul 20 22:16:03 cube kernel: Limiting open port RST response from 730 to = 200 > packets/sec > Jul 20 22:16:04 cube kernel: Limiting open port RST response from 287 to = 200 > packets/sec > Jul 20 22:16:13 cube kernel: Limiting open port RST response from 519 to = 200 > packets/sec > Jul 20 22:16:14 cube kernel: Limiting open port RST response from 740 to = 200 > packets/sec > Jul 20 22:16:15 cube kernel: Limiting open port RST response from 258 to = 200 > packets/sec > Jul 20 22:16:24 cube kernel: Limiting open port RST response from 407 to = 200 > packets/sec > Jul 20 22:16:25 cube kernel: Limiting open port RST response from 660 to = 200 > packets/sec >=20 > After spending some time on Google i came up with: >=20 > /etc/sysctl.conf > net.inet.icmp.icmplim=3D2000 >=20 > I know it seems abit high, but i kept adjusting until the error went away= . > (not really fixing the problem?) >=20 > If your mail client or the mailing list prevents you from seeing the > attached > You can view them here: > http://rj.dawnshosting.com/fbsd_ml/ >=20 >=20 > PS: While running tcpdump I see this >=20 > tcpdump -i fxp0 >=20 > Neither one of these ip's exist on my system is my cable company doing > something wrong? >=20 >=20 > 01:47:12.135929 arp who-has 64.253.3.161.dyn-cm-pool73.pool.hargray.net t= ell > 64.253.3.1.dyn-cm-pool73.pool.hargray.net > 01:47:12.155931 arp who-has 216.16.218.141.dyn-cm-pool46.pool.hargray.net= tell > 216.16.218.1.dyn-cm-pool46.pool.hargray.net > 01:47:12.196000 arp who-has 181.131.216.67.181.static.hargray.net tell > 1.131.216.67.1.static.hargray.net >=20 >=20 > tcpdump -i fxp0 | grep ICMP: >=20 > Is this an attack? >=20 > 01:55:41.231722 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37084, length 64 > 01:55:42.232794 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37085, length 64 > 01:55:43.285913 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37086, length 64 > 01:55:44.286340 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37087, length 64 > 01:55:45.287380 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37088, length 64 > 01:55:46.345843 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37089, length 64 > 01:55:47.346685 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37090, length 64 > 01:55:48.347366 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37091, length 64 > 01:55:49.348370 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37092, length 64 > 01:55:50.360130 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37093, length 64 > 01:55:51.596916 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37094, length 64 > 01:55:52.597659 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37095, length 64 > 01:55:53.640120 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37096, length 64 > 01:55:54.735275 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37097, length 64 > 01:55:55.735568 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37098, length 64 > 01:55:56.745012 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37099, length 64 > 01:55:57.835442 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37100, length 64 > 01:55:58.920583 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37101, length 64 > 01:56:00.022747 IP cube.dawnshosting.com > purple.haze.bluntroll.in: ICMP > echo request, id 22055, seq 37102, length 64 --=-sIetbD7Lx7ZgMCqrbuYN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIiC/mey4m6/eWxTQRAvnQAJ9H2EeeOYcpNqxt1DLwG69stTDLBACgibvr FIMP7ahxUHjP19f2LjTNc7k= =UPoB -----END PGP SIGNATURE----- --=-sIetbD7Lx7ZgMCqrbuYN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1216884710.6500.0.camel>