Re: Torrent clients bring pf-based firewall to its knees...?
On Fri, Jul 24, 2009 at 04:56:11PM -0400, Mike Edenfield wrote: > I've recently begun running a torrent client after hours on a PC sitting > behind our firewall (7.2-STABLE using pf). I have added a 'rdr' rule to > redirect incoming traffic to the client PC from the firewall, and as far > as the client is concerned everything is fine. FWIW, I don't do torrents a lot, but I've had no problems running the Vuze/Azureus torrent client behind a pfSense firewall (7.2-based with pf) -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Torrent clients bring pf-based firewall to its knees...?
Is there a main() function in your program? Are you building this for LE operation, or with the Systems/C runtime? If it's Systems/C, are you using the RENT library (and the -frent option on the compilation?) If you want to build a non-RENT program for USS, you can, but you have to set the appropriate environment varible under USS to execute it; as a USS program is executed with the code sections marked READ-ONLY. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
status of flash9/flash10 support in RELENG_7 ?
Does anyone know what is the status of flash9 or flash10 in RELENG_7 ? Following the thread of a couple of months ago, i tried to: - remove all linux-* ports - set the following in /etc/make.conf OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_NONBASE_PORTS=f8 - set the following in /etc/sysctl.conf compat.linux.osrelease=2.6.16 - set the following in /etc/fstab linproc /usr/compat/linux/proc linprocfs rw 0 0 - reinstall linux_base-f8-8_11 - reinstall linux-flashplugin-10.0r22 (which in turn brings in the relevant linux-f8-* ports) - also install nspluginwrapper and create a firefox plugin - upgrade firefox to firefox-3.5,1 (native), just in case - run firefox with "limit stacksize 4megabytes" (or variants) as recommended to avoid npviewer growing/not dying This was done on 3 different machines (one laptop with a centrino, 2 desktops with AMD X2 dual core running in i386 mode) with mixed [in]success. On one machine thing started working well, but on the other two they did not (the various packages were of course slightly disaligned) and while trying to replicate the configuration i also broke the good one without figuring out why. Symptoms are that on certain sites or actions (e.g. switch to full screen on youtube videos) i get firefox freezing like this 22381 luigi 13 960 82580K 57484K ucond 1 0:00 0.20% firefox-bin 22413 luigi 1 970 72920K 33448K futex 1 0:00 0.20% npviewer.bin 22414 luigi 1 970 72920K 33448K futex 1 0:00 0.20% npviewer.bin and recovering control (but no video) after 10+seconds I also get a lot of the following weak_unref warnings with various addresses (firefox-bin:22381): GLib-GObject-WARNING **: IA__g_object_weak_unref: couldn't find weak ref 0x297ba9f0(0x2a10d110) (but not sure how related is this, because it happens even without a flash plugin). I have also tried flash9 instead of flash10, o fc10 instead of fc8, all with similar results. Is there a recipe for a working flas9 or flash10 operation ? cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on amd64/amd64
TB --- 2009-07-24 21:39:39 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-07-24 21:39:39 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-07-24 21:39:39 - cleaning the object tree TB --- 2009-07-24 21:40:06 - cvsupping the source tree TB --- 2009-07-24 21:40:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-07-24 21:40:15 - building world TB --- 2009-07-24 21:40:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-24 21:40:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-24 21:40:15 - TARGET=amd64 TB --- 2009-07-24 21:40:15 - TARGET_ARCH=amd64 TB --- 2009-07-24 21:40:15 - TZ=UTC TB --- 2009-07-24 21:40:15 - __MAKE_CONF=/dev/null TB --- 2009-07-24 21:40:15 - cd /src TB --- 2009-07-24 21:40:15 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 24 21:40:16 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Jul 24 23:10:05 UTC 2009 TB --- 2009-07-24 23:10:05 - generating LINT kernel config TB --- 2009-07-24 23:10:05 - cd /src/sys/amd64/conf TB --- 2009-07-24 23:10:05 - /usr/bin/make -B LINT TB --- 2009-07-24 23:10:05 - building LINT kernel TB --- 2009-07-24 23:10:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-24 23:10:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-24 23:10:05 - TARGET=amd64 TB --- 2009-07-24 23:10:05 - TARGET_ARCH=amd64 TB --- 2009-07-24 23:10:05 - TZ=UTC TB --- 2009-07-24 23:10:05 - __MAKE_CONF=/dev/null TB --- 2009-07-24 23:10:05 - cd /src TB --- 2009-07-24 23:10:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jul 24 23:10:05 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/inflate.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/init_main.c cc1: warnings being treated as errors In file included from /src/sys/kern/init_main.c:71: /src/sys/sys/sysproto.h:1705: warning: redundant redeclaration of 'lkmnosys' /src/sys/sys/sysent.h:164: warning: previous declaration of 'lkmnosys' was here /src/sys/sys/sysproto.h:1802: warning: redundant redeclaration of 'lkmressys' /src/sys/sys/sysent.h:165: warning: previous declaration of 'lkmressys' was here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-24 23:20:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-24 23:20:14 - ERROR: failed to build lint kernel TB --- 2009-07-24 23:20:14 - 5024.71 user 564.53 system 6035.52 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Torrent clients bring pf-based firewall to its knees...?
If only a reboot solves the problem sounds like a kernel problem? mbuf leakage? On 2009-07-24 04:56:11PM -0400, Mike Edenfield wrote: > I've recently begun running a torrent client after hours on a PC sitting > behind our firewall (7.2-STABLE using pf). I have added a 'rdr' rule to > redirect incoming traffic to the client PC from the firewall, and as far as > the client is concerned everything is fine. > > However, after a short period of torrent activity, the machine running the > firewall becomes extremely slow and lagged for all network traffic, but > appears to be operating fine locally. Remote connections via ssh become > extremely unresponsive, and eventually connections start timing out, but > when logged in at the console, there doesn't appear to be any problem. > Running tcpdump does not show nusually high volume of traffic, no more than > I see during normal activity during the day. The volume and length of > connections doesn't seem to matter much -- trying to copy a BSD or Linux > DVD with hundreds of connections breaks just as quickly as much smaller > torrents with a handful of peers. > > I know there are some cheap NAT-ing routers that get in trouble with > torrents because of the heavy volume of state rules required, but I've > never heard of anything like that being present in pf. And I've used > torrent clients at home behind a pf firewall with no issues, but not on > this specific version of the FreeBSD. > > I've tried shutting down the torrent client, clearing out the state and nat > rules with pfctl, adding drop rules to reject the torrent traffic, and even > bringing the network adapter down completely, but only a physical reboot > (combined with not running the client ever again) seems to solve anything. > > Has anyone experienced this kind of problem before? Or alternatively, is > there some way besides tcpdump and top (neither of which show anything > unusual) that I can tell what exactly the machine is doing that's causing > the network lag? > > --Mike > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Torrent clients bring pf-based firewall to its knees...?
I've recently begun running a torrent client after hours on a PC sitting behind our firewall (7.2-STABLE using pf). I have added a 'rdr' rule to redirect incoming traffic to the client PC from the firewall, and as far as the client is concerned everything is fine. However, after a short period of torrent activity, the machine running the firewall becomes extremely slow and lagged for all network traffic, but appears to be operating fine locally. Remote connections via ssh become extremely unresponsive, and eventually connections start timing out, but when logged in at the console, there doesn't appear to be any problem. Running tcpdump does not show nusually high volume of traffic, no more than I see during normal activity during the day. The volume and length of connections doesn't seem to matter much -- trying to copy a BSD or Linux DVD with hundreds of connections breaks just as quickly as much smaller torrents with a handful of peers. I know there are some cheap NAT-ing routers that get in trouble with torrents because of the heavy volume of state rules required, but I've never heard of anything like that being present in pf. And I've used torrent clients at home behind a pf firewall with no issues, but not on this specific version of the FreeBSD. I've tried shutting down the torrent client, clearing out the state and nat rules with pfctl, adding drop rules to reject the torrent traffic, and even bringing the network adapter down completely, but only a physical reboot (combined with not running the client ever again) seems to solve anything. Has anyone experienced this kind of problem before? Or alternatively, is there some way besides tcpdump and top (neither of which show anything unusual) that I can tell what exactly the machine is doing that's causing the network lag? --Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [geom] page fault in g_mbr_config()
2009/7/24 pluknet : > Hi. > > I got a panic while performing a repetitive 'fdisk -BI aacd0', > where aacd0 is a disk on aac0: . > This means that the command was issued after filesystems > were already created on aacd (after the first fdisk -BI aacd0 > iteration), and are in umount'ed state. > > This is on 7.2-R, amd64. Config is a GENERIC plus ddb, carp, ipfw, quota. > > Fatal trap 12: page fault while in kernel mode > cpuid = 5; apic id = 05 > fault virtual address = 0x20 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0x804cc554 > stack pointer = 0x10:0xfffe80079b80 > frame pointer = 0x10:0xfffe80079bd0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2 (g_event) > [thread pid 2 tid 100013 ] > Stopped at g_mbr_config+0x64: movq 0x20(%rax),%r15 > db> bt > Tracing pid 2 tid 100013 td 0xff000144da50 > g_mbr_config() at g_mbr_config+0x64 > g_run_events() at g_run_events+0x1b8 > g_event_procbody() at g_event_procbody+0x57 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xfffe80079d30, rbp = 0 --- And, of course... db> show proc 818 Process 818 (fdisk) at 0xff0004ed1000: state: NORMAL uid: 0 gids: 0, 0, 5 parent: pid 814 at 0xff00045c0478 ABI: FreeBSD ELF64 arguments: fdisk threads: 1 100169 D g_waitfo 0xff0004ec9100 fdisk db> bt 818 Tracing pid 818 tid 100169 td 0xff0004fbf6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x354 g_waitfor_event() at g_waitfor_event+0x9a g_ctl_ioctl() at g_ctl_ioctl+0x2df giant_ioctl() at giant_ioctl+0x7d devfs_ioctl_f() at devfs_ioctl_f+0x77 kern_ioctl() at kern_ioctl+0xa2 ioctl() at ioctl+0xf9 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8008200ec, rsp = 0x7fffe1d8, rbp = 0x4 --- -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[geom] page fault in g_mbr_config()
Hi. I got a panic while performing a repetitive 'fdisk -BI aacd0', where aacd0 is a disk on aac0: . This means that the command was issued after filesystems were already created on aacd (after the first fdisk -BI aacd0 iteration), and are in umount'ed state. This is on 7.2-R, amd64. Config is a GENERIC plus ddb, carp, ipfw, quota. Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x8:0x804cc554 stack pointer = 0x10:0xfffe80079b80 frame pointer = 0x10:0xfffe80079bd0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) [thread pid 2 tid 100013 ] Stopped at g_mbr_config+0x64: movq0x20(%rax),%r15 db> bt Tracing pid 2 tid 100013 td 0xff000144da50 g_mbr_config() at g_mbr_config+0x64 g_run_events() at g_run_events+0x1b8 g_event_procbody() at g_event_procbody+0x57 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffe80079d30, rbp = 0 --- -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ataraid's revenge! (Was: Re: A nasty ataraid experience.)
On Thu, 2009-07-23 at 19:57 +0100, Bruce Simpson wrote: > 6 months on, ataraid(4) did it again. Which ataraid(4) controller is this? Seeing a verbose dmesg would help. There are several patches in the PR database for ataraid problems, it would be worth having a look. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS-UP: Shared Library Versions bumped...
On Thursday 23 July 2009 22:55:07 Daniel O'Connor wrote:
> On Wed, 22 Jul 2009, John Baldwin wrote:
> > > How many of those 800 ports are actually necessary and used?
> > > It would be better to get generate a complete list of your
> > > installed ports, use pkg_deinstall or pkg_delete to remove
> > > all ports, and then selectively re-install ports that are
> > > actually used.
> >
> > Xorg takes up ~200 ports alone (not including dependencies like perl,
> > etc.) since the Xorg decided release engineering was too hard. Throw
> > in things like KDE, OOo, Firefox, etc. for a desktop and you can get
> > a fairly high package count. :-/
>
> Ooh I only have 1315 on mine, but a 1.4GHz Pentium-M is pretty slow
> these days :(
>
> Perhaps there needs to be a psuedo port for 'base' (or a few) so that
> you can easily determine if you have already upgraded something against
> the new base you installed.
>
> Certainly I find it difficult to leave my laptop on for long enough to
> recompile everything when I upgrade -current (since I actually use it
> for work), and portupgrade -fa has no way to tell if it's already done
> something. If there were pseudo base ports you could tell it to force
> upgrade everything that depends on the old base port and it would DTRT.
I wrapped portmaster, since -af has the same problem when something screws the
build (mostly plist problems and $me wanting backup packages, but also
classics like using sudo as PM_SU_CMD and trying to reinstall it).
Basically, I made a list of all the installed ports and sorted dep order, then
called portmaster -u for every port and if successful put an empty file
+PM_DONE in /var/db/pkg//. On a restart the ports containing a
+PM_DONE file are skipped.
If the entire process finishes successfully, all +PM_DONE files are removed. I
briefly looked into building it into portmaster, but that looked to take
longer then I had time for. The main loop is at the bottom, perhaps Doug likes
the idea and has the time to integrate it.
> I, of course, have no patches for such a thing :)
>
> I've deleted /usr/local & /var/db/pkg in the past, it can be very
> therapeutic :) However it is not so good when your mp3 collection is
> mounted on /usr/local/mp3 and you forgot to unmount it first.. :(
Or your websites in /usr/local/www, your database in /usr/local/pgsql or your
squid conf and cache in /usr/local/squid. Especially when pkg_delete -af does
the right thing and leaves all this in tact, I don't see the value of rm -rf
/usr/local, other then a few minutes on a process that's likely going to be
several hours or days.
--
Mel
mark_done()
{
local _name
_name=$1
if test -d ${PKG_DBDIR}/${_name}; then
${SUDO} ${TOUCH} ${PKG_DBDIR}/${_name}/+PM_DONE
else
return 1;
fi
return 0;
}
for origin in ${LIST}; do
pkgname=$(make -C ${PORTSDIR}/${origin} -V PKGNAME)
if test -f ${PKG_DBDIR}/${pkgname}/+PM_DONE; then
echo "Already done: ${pkgname} (${LOOP}/${TOTAL})"
else
echo "===> Building ${pkgname}"
portmaster -u ${PORTSDIR}/${origin}
if test $? -eq 0; then
mark_done ${pkgname} || safe_abort
else
FAILED=$((${FAILED} + 1))
echo "Failed, continue? [n]"
read CONT
case "${CONT}" in
[yY]|[yY][eE]|[yY][eE][sS])
echo "===> Marking state as done"
mark_done ${pkgname} || safe_abort
;;
*) break;;
esac
fi
fi
done
if test ${FAILED} -eq 0; then
echo "===> Removing state files"
for FILE in ${PKG_DBDIR}/*/+PM_DONE; do
${SUDO} /bin/rm ${FILE}
done
echo "===> Removing origin list"
/bin/rm ${LISTFILE}
fi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS-UP: Shared Library Versions bumped...
On Wed, 22 Jul 2009, John Baldwin wrote: > > How many of those 800 ports are actually necessary and used? > > It would be better to get generate a complete list of your > > installed ports, use pkg_deinstall or pkg_delete to remove > > all ports, and then selectively re-install ports that are > > actually used. > > Xorg takes up ~200 ports alone (not including dependencies like perl, > etc.) since the Xorg decided release engineering was too hard. Throw > in things like KDE, OOo, Firefox, etc. for a desktop and you can get > a fairly high package count. :-/ Ooh I only have 1315 on mine, but a 1.4GHz Pentium-M is pretty slow these days :( Perhaps there needs to be a psuedo port for 'base' (or a few) so that you can easily determine if you have already upgraded something against the new base you installed. Certainly I find it difficult to leave my laptop on for long enough to recompile everything when I upgrade -current (since I actually use it for work), and portupgrade -fa has no way to tell if it's already done something. If there were pseudo base ports you could tell it to force upgrade everything that depends on the old base port and it would DTRT. I, of course, have no patches for such a thing :) I've deleted /usr/local & /var/db/pkg in the past, it can be very therapeutic :) However it is not so good when your mp3 collection is mounted on /usr/local/mp3 and you forgot to unmount it first.. :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
