Kazaa/p2p on a LAN and ping problems
Network topology: LAN <==> FreeBSD Gateway <==> Internet Gateway specifications: FreeBSD overlord 4.8-STABLE FreeBSD 4.8-STABLE #0: Mon Sep 22 07:05:09 CDT 2003 k6-233, 128MB ram ipf packet filtering in place Internet (cable): 256kb up 2.0mbish down == It seems an impossible task to limit Kazaa and other p2p (Kazaa especially) from accessing the Internet from a LAN, especially when you're sharing the LAN with other college age people. So, I've instead told them to limit their upstream to 5kB, which leaves a good amount of of the upstream pipe for web browsing. However, whenever any p2p in the house is active pings on any external network degrade horribly, even if it's only a single host, and 20kb of my upstream bandwith remains. Wolfenstein servers that I pinged 30 on with no p2p activity on the LAN, for instance, begin to ping at 400-500 ; the situation is equally bad with MUDs and other ping reliant games such as Quake. Is this normal? Is there anything I can do to fix the problem so that ping dependant games can be played while p2p apps are active on the LAN? Kicking the network cable out works late at night, and at times during the day, but it isn't a permanent solution. Limiting p2p from the LAN completely is not possible from my position. A user on IRC mentioned he had no such problem with IPFW - if my problem isn't specific does that mean that my use of ipf is responsible for this behavior? Thanks, Eric ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Porting a linuxthreads app to FreeBSD problems
4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #0: Mon Sep 22 05:40:14 CDT 2003
gcc 3.2
I'm trying to port an app (C++) over to FreeBSD utilizing devel/linuxthreads,
and have it to the point it will compile. I've made the appropriate changes
to the compilation options, so everything seems kosher. Starting up the app,
however, it just stalls at a particular point every time. I was wondering if
anyone had encountered this before, and if so, how they solved the problem.
I'm including output from strace and ltrace at the end of my email.
The problem seems to revolve around mutexes, judging by the point at which
the app locks up - for reference, the app utilizes one mutex, of type
PTHREAD_MUTEX_RECURSIVE_NP.
Reading the README.FreeBSD from the devel/linuxthreads port there is a blurb:
c) The mutex wrapper functions only provide standard linuxthreads mutexes
(i.e. non-recursive mutexes). This might lead to deadlocks if libc
depends on recursive mutexes.
However, I've gotten previous versions of the application (which also used
PTHREAD_MUTEX_RECURSIVE_NP) working without stalling.
I'm grateful for any insight people can offer..I'm not really sure how to
approach debugging this problem, since it seems like it stalls before it ever
really begins running the application's code.
===
ltrace.out
_spinlock(0x081a90a4, 0x080dcb81, 0xbfbffa64, 0x080dcb81, 1) = 0
_spinlock(0x081a90a4, 0x080dcb81, 0xbfbffa64, 0x080dcb81, 1) = 0
_spinlock(0x081a90a4, 0x080dcb81, 0xbfbffa54, 0x080dcb81, 1) = 0
pthread_mutex_lock(0x081a9098, 0x081f20bc, 322832, 0x080db296, 32768) = 0
pthread_mutex_unlock(0x081a9098, 0x081f20bc, 322832, 0x080db296, 32768) = 0
_spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff9d0, 0x080e7a1d, 16) = 0
__error(16, 16, 0xbfbffaa4, 0x081bdd00, 0x081bdd00) = 0x081cbd5c
__error(2, 0x080e6dac, 0x08122774, 0xbfbff960, 63) = 0x081cbd5c
__error(0x08122774, 0xbfbff960, 63, 0x080e6d97, 16) = 0x081cbd5c
_spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff9a0, 0x080e7a1d, 24) = 0
pthread_mutexattr_init(0xbfbff9cc, 65535, 1, 0x08291030, 65535) = 0
pthread_mutexattr_settype(0xbfbff9cc, 1, 1, 0x08291030, 65535) = 0
pthread_mutex_init(0x08290040, 0xbfbff9cc, 1, 0x08291030, 65535) = 0
pthread_mutexattr_destroy(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 65535) = 0
_spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff980, 0x080e7a1d, 16) = 0
_spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff980, 0x080e7a1d, 16) = 0
_spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff980, 0x080e7a1d, 4) = 0
_spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff9a0, 0x080e7a1d, 24) = 0
pthread_mutexattr_init(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x08290040) = 0
pthread_mutexattr_settype(0xbfbff9cc, 1, 1, 0x08291030, 0x08290040) = 0
pthread_mutex_init(0x08290060, 0xbfbff9cc, 1, 0x08291030, 0x08290040) = 0
pthread_mutexattr_destroy(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x08290040)
= 0 _spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff9a0, 0x080e7a1d, 24) = 0
pthread_mutexattr_init(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x08290060) = 0
pthread_mutexattr_settype(0xbfbff9cc, 1, 1, 0x08291030, 0x08290060) = 0
pthread_mutex_init(0x08290080, 0xbfbff9cc, 1, 0x08291030, 0x08290060) = 0
pthread_mutexattr_destroy(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x08290060)
= 0 _spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff9a0, 0x080e7a1d, 24) = 0
pthread_mutexattr_init(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x08290080) = 0
pthread_mutexattr_settype(0xbfbff9cc, 1, 1, 0x08291030, 0x08290080) = 0
pthread_mutex_init(0x082900a0, 0xbfbff9cc, 1, 0x08291030, 0x08290080) = 0
pthread_mutexattr_destroy(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x08290080)
= 0 _spinlock(0x081a92a4, 0x080e7a1d, 0xbfbff9a0, 0x080e7a1d, 24) = 0
pthread_mutexattr_init(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x082900a0) = 0
pthread_mutexattr_settype(0xbfbff9cc, 1, 1, 0x08291030, 0x082900a0) = 0
pthread_mutex_init(0x082900c0, 0xbfbff9cc, 1, 0x08291030, 0x082900a0) = 0
pthread_mutexattr_destroy(0xbfbff9cc, 0xbfbff9cc, 1, 0x08291030, 0x082900a0)
= 0 pthread_mutex_lock(0x081a88b4, 1, 0xbfbff9d0, 0x0807d6ba, 0xbfbff9cc
--- SIGINT (Interrupt) ---
--- SIGINT (Interrupt) ---
+++ killed by SIGINT +++
===
strace.out
execve("./world", ["./world"], [/* 31 vars */]) = 0
mmap(0, 1976, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2813b000
munmap(0x2813b000, 1976)= 0
__sysctl([hw.pagesize], 2, "\0\20\0\0", [4], NULL, 0) = 0
mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0x2813b000 geteuid(0xbfbffa90) = 1001
getuid()= 1001 (euid 1001)
getegid(0xbfbffa90) = 1001
getgid()= 1001 (egid 1001)
open("/var/run/ld-elf.so.hints", O_RDONLY) = 3
read(3, "Ehnt\1\0\0\0\200\0\0\0z\0\0\0\0\0\0\0y\0\0\0\0\0\0\0\0"..., 128) =
128 lseek(3, 128, SEEK_SET) = 128
read(3, "/usr/lib:/usr/lib/compat:/usr/X1"..., 122
out of inodes (4.7-stable shortly post-install)
Just performed a from scratch installation of FreeBSD from a snapshot off snapshots.jp.freebsd.org (dated January 2 or 3, 2003), and when building stuff from ports have suddenly gotten the out of inodes message =( The install was done onto a 1.6gb harddrive, and was a reinstall of an already functional 4.7-stable machine, with the same partitioning settings, which is what makes this so strange. I didn't change anything in the partitioning/slice editors, so whatever settings I used were the default. The results of df -ih are as follows: FilesystemSize Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s1a89M44M37M54%1535 9983 13% / /dev/ad0s1e79M 4.0K72M 0% 2 102360% /tmp /dev/ad0s1f 886M 620M 195M76% 107214 6448 94% /usr /dev/ad0s1g93M92K86M 0% 44 121140% /usr/home /dev/ad0s1h99M 6.1M85M 7% 463 124634% /usr/local /dev/ad0s1d99M 406K90M 0% 120 126781% /var procfs4.0K 4.0K 0B 100% 41 9554% /proc /dev/ad1s1490M 2.0K 451M 0% 1 629730% /usr/obj As you can see I'm using up 94% of my /usr partition's inodes just standing still, and only have around 6500 free, compared with almost 11 used! The /usr partition does house both a source and ports tree, and as you can see I utilize a second hard-drive to build my world. Unfortunately I don't have a copy of an inode comparison with the old install, but I do know that I had never gotten that message merely building portupgrade, or even when building two things at once. The space taken up by files is about the same, however, when compared to the older setup. Those things said, I guess my question is, for a low use gateway is 6500 free inodes enough; am I causing myself grief over nothing? (By low use I mean it does nothing but serves webpages and performs firewalling/NAT duties for the household; no mail or news handling, or anything like that). I'd considered for a moment doing a reinstall, but I'm not sure if it's the small size of the partition/hard drive that is limiting their number, or if perhaps they were created with an overly large size for a partition that houses such a large number of small files. Additionally, now that the installation is finished, the only partitions that should be experiencing any growth should be /var and /usr/local, so the inode limit should only be tested during a port's build, shouldn't it? Anyhow, could someone more familiar with such matters weigh in? Thanks, Troubled in Texas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
testing ability to send mail to list, apologize for the spam
nt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
general questions about patches ports [nethack]
(no answers off ports, so thought I'd give it a try on questions) In an effort to get some experience with ports I've been working in my spare time on making a local entry in the tree that lets you apply a variety of nethack enhancing, generally accepted patches (namely the hell patch, dump patch, new toys, and toughvlad patches) using -D appendations to the initial make command. It builds fine with various patches enabled; however, I had to modify the original diffs to get everything to apply it an order independent fashion. Part of this was necessary because I was specifying the files to use via PATCHFILES and some .if defined() ... .endif branches in the Makefile, and their application order did matter. Anyhow, I got that sorted out, and have been storing my patchfiles on a remote server and fetching using a PATCH_SITES define, which fetches and applies seamlessly. That brings me to my questions.. First, for future reference, is there a way, besides naming patchfiles aa ab ac etc, to get PATCHFILES, or any similar defines, to apply patches in a user specifid particular order? Second, is there a way to store/bundle optional patches with a port and be able to include them in the build or not, at your discretion, so that you don't have to fetch them from third party sites? Third, is there even any interest in something like this, or does conservative BSD philosophy frown on game patches such as these being included in the ports tree, leaving it to the end user to compile from scratch and apply patches by hand if they wish enhancement? --Eric To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-ports" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
[no subject]
subscribe freebsd-questions To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
