On Mon, Mar 15, 2004 at 10:54:36PM -0500, Dr. David Johnson wrote:
> I think the only other data that may help is that my
> friend says his DSL link is supposed to be 144 up, and
> 288 down, but in using some Internet sites that are
> supposed to measure speed, these show downloads of
> only about a tenth of the nominal value!
288/144 what? kilobit per second? again, i'm not
a marketing engineer, but those seem very v.42-era
numbers, not adsl-era... 256Kb/s down/128 Kb/s up
i could believe... but what does he *really* get?
maybe his ISP has a "broadband reports" style
speedtest their repair department will actually take
slow speed tickets against -- maybe find that on their
www or try calling the tech support and just ask:
" do you guys have your own speedtest site ? "
worst case, ISP probably runs an ftp server with some
"webspace" for the customers, could just use that to
test.
which leads me into the second question:
> <START PF.CONF>
>
> ext_if="rl0"
> int_if="rl1"
>
> altq on $int_if priq bandwidth 2Mb queue { vonage_in, others_in }
> queue others_in priq (default)
> queue vonage_in priority 15
> altq on $ext_if priq bandwidth 2Mb queue { vonage_out, others_out }
> queue others_out priq(default)
> queue vonage_out priority 15
why are you queueing on $ext_if at 2Mb ?
if he truly does have a "144 Kb/s" upstream, you should
perhaps try setting external interface upstream bandwidth
to something around "128 Kb" or lower.
internally, if you do not anticipate running any
"on the obsd machine" services where you would want to
be able to xfer off of it at 10Mb/s or 100Mb/s, you
could certainly get away with setting the $int_if
bandwidth to be around a bit less than _what you find_
his dsl circuit actually realizes for "IP layer downstream"
( i say it that way to guard against the idea of the overhead
of ATM cells or what-have-you, in despite of "IP layer
downstream" being an admittedly contrived term ).
that way if you did queue internal-only traffic, you
wouldn't be cutting yourself *too* short because of the low
$int_if bandwidth setting.
if you were doing something like samba, or dropping files
on the obsd box and then pulling them off onto the lan,
you probably wouldn't want to queue those packets, and
therefore they wouldn't be cut to fit into the bandwidth
set low to anticipate compliance with the downstream of
his dsl.... tho i don't see $int_if as being the topic
at the moment.
> von = "192.168.0.2"
>
> pass in all
> pass quick on lo0 all
>
> pass out on $int_if from any to $von queue vonage_in
> pass out on $ext_if from $von to any queue vonage_out
>
> <END PF.CONF>
if von = 192.168.0.2, that's probably the IP it got from
the netgear router a while ago, and like some stubborn win98
junk.. you could perhaps reset the vonage, tell
obsd's /etc/dhcpd.conf to not have a dynamic range of
IPs to hand out; watch /var/log/daemon for the MAC
addr of the vonage when it DHCPDISCOVERs ( assuming you
don't have the MAC yet, if you do, just reset it
and put in the stuff in dhcpd.conf like normal )...
a quick call to vonage techsup might tell you if
resetting it is likely to "factory" the box, and clear
out the old IP or not...
then again, calling tech support is going to be like
roulette.... there _are_ sharp people behind the
phones at most places; however, the chances of
reaching them are much less than reaching one of their
( likely several ) duller comrades who are in the same
queue ( or higher, even... ... ), so if you talk to
someone who you feel is not nearly a peer to you
knowledge wise, hang up and roll the dice again. <g>
> I took out comments for ease in viewing.
> Please, do you have any ideas on how to make this work?
if it is just a queueing problem, first thing i would
think to do is fix the $ext_if bandwidth setting...
i don't know VoIP, but perhaps it doesn't need to use
alot of bandwidth, but wants a low delay. consider HFSC?
i just posted some links a day or so ago, the second one
( iirc ) was the one which has provided to me the most illumination
on HFSC.
i know, some must see that i've turned into an HFSC _whore_ and
would likely use it to make nutritous and delicious milkshakes in
the morning if i could.... , but it is enjoyable.
something like:
ext_bw = "110Kb"
altq on $ext_if bandwidth $ext_bw queue { vonage others }
queue vonage bandwidth 10% priority 7 \
hfsc( realtime( 50% 250 10% ) linkshare( 50% 50 10% )
queue others bandwidth 10% priority 1 \
hfsc( realtime( 0% 1000 50% ) linkshare( 0 100 25% ) \
upperlimit $e_bw default )
might work, as a starting point; or perhaps might be slightly
better?.
plus those are _going_ to be suboptimal numbers, but it parses
ok, which sometimes is 1/2 the battle when you're making up numbers
for HFSC....
please note no space in "110Kb"
you mention openbsd being a bridge. i've never setup a bridge
so i cannot attest to whether or not a configuration mishap
with that level of the equation can create a situation like
you have...
> Is there a reason I must use a static IP address for
> the ATA186??
i'm guessing it might just be DHCP stupid.
vonage -> DHCPREQUEST for 192.168.0.2
openbsd -> DHCPNAK
vonage -> DHCP_REQUEST!!! for 192.168.0.2
openbsd -> DHCP_NAK, jerkface
... silence
rather than
vonage -> DHCPREQUEST for 192.168.0.2
openbsd -> DHCPNAK
vonage -> ok, sorry, DHCPDISCOVER
openbsd -> oh, hi, DHCPOFFER for whatever
vonage -> oh, pleased to meet you, DHCPREQUEST for whatever
openbsd -> DHCPACK
sorry if i am slighly offbase with my DHCP dialogue and
it offends ppl.
i know this might be pot calling kettle black, but fwiw,
i bet most ppl have steered clear of your situation due
to the length of your emails :P.
jared
--
[ openbsd 3.4 GENERIC ( mar 1 ) // i386 ]
