> My bandwidth is very very limited. Not more than 140 Kbps on both
> sides at any time. I use G729 as a codec in order to reduce
> consumption. Use the pf.conf below, when VoIP is the only traffic,
> the quality of the calls is excelent with no voice cutting at all.
> Now if I start a download I i
You said you live rurally - in that case, perhaps you should build/buy a small
quality (read as: won't get wet) shed, have your systems there and run some
outdoor-rated CAT5e from it to your house. That should allow you to use KVM
extenders, serial, etc. Remember the inverse-square law for RF. R
To: Stuart Henderson <[EMAIL PROTECTED]>
Subject: Re: brute force voip QoS
> > pass out queue (std_out,lowdelay)
>
> here, you place ACKs from downloads at a higher priority than
> your voip calls. this is unlikely to be what you want with priq
> over a 140Kb/s link..
According to pf.conf, that
Currently I'm blackholing and rejecting some traffic with route add
-reject/-blackhole 127.0.0.1; this works fine, but bounces all the
rejected/blackholed traffic to the loopback interface.
This behaviour is.. annoying, and possibly ineffecient. I'm probably searching
for a null/blackhole/fak
On Fri, Aug 08, 2008 at 06:54:05PM -0500, patric conant wrote:
> You strongly overestimate the value of your comments (3 cents), it seems
> like there are many places more appropriate than this one for you to suggest
> middle-of-the-road hardware running a proprietary OS that has among the
> worst
> So you expect additional reliability from stacking ebayed cisco equipment
> with OpenBSD bridges behind them, as the original poster mentioned, and cost
> effectiveness by buying used cisco equipment and paying for relicensing so
> that you can get updates, compared to setting up OpenBSD boxes as
> Question: How can I make sure that "em2" doesn't become "em0"
> if my dual-port NIC dies? This would be fatal for my firewall
> setup. At least the antispoof rules _must_ be bound to the
> network devices.
Yep, this is an ugly problem.
You could have a shellscript at boot scan ifconfig output a
My understanding of this issue is that it is only likely to be caused by an
exploited domain, or running OpenBSD. Both should be a rare event (OpenBSD
isn't really production-ready on this hardware). It's acceptable in the
majority of cases to just let the domain be unused.
It's a bug, it's irr
I'm running OpenBSD 4.2 on SPARC64. I have managed to get a simple BGP setup
working on IPv4, however the IPv6 version of the same setup fails. A BGP
session is established in both cases and peer B claims to be announcing what it
should be announcing, yet in the IPv6 version peer A does not add
> Option -f filename, Filename of the key file, seems to be the right
> option and '-' is the usual way of indicating stdin.
So? Just use /dev/stdin.
> But if ISP's must have blackbox on their interfaces (hello FBI),than you can't
> trust your local hosting company even if they are very friendly ;-)
Cisco prefers a blueish-black color. Juniper boxes tend to be white and blue.
In most Western countries there are many ISPs; if many of them were
11 matches
Mail list logo
