"M. Warner Losh" wrote:
> : Actually, it appears I'm wrong, and you just haven't read the
> : message yet. Apparently there have been some commits which
> : fix your problem for you (though they may be limited to -current).
>
> Nope. They have been MFC'd as of April 30th or so. The entire wi
>
On Tue, May 07, 2002 at 02:20:49AM +, Baldur Gislason wrote:
> Also, there's a kernel option:
> # RANDOM_IP_ID causes the ID field in IP packets to be randomized
> # instead of incremented by 1 with each packet generated. This
> # option closes a minor information leak which allows remote
> #
On Mon, 6 May 2002, Garrett Wollman wrote:
> < said:
>
> > Is doing this wise? I have this nagging feeling that randomizing (or
> > zeroing on each new connection) the timestamp would degrade its usefulness
> > for PAWS checks and the like. (Don't ask me how, I haven't thought it
> > through
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: Martin Minkus wrote:
: > Perhaps when I have some spare time I can go look into the wi driver.
: > And perhaps your right, firmware changes on the orinoco cards are the
: > cause of this; I have flashed mine to
Also, there's a kernel option:
# RANDOM_IP_ID causes the ID field in IP packets to be randomized
# instead of incremented by 1 with each packet generated. This
# option closes a minor information leak which allows remote
# observers to determine the rate of packet generation on the
# machine by w
Martin Minkus wrote:
> Perhaps when I have some spare time I can go look into the wi driver.
> And perhaps your right, firmware changes on the orinoco cards are the
> cause of this; I have flashed mine to 8.1 (or whatever the latest
> firmware is, 8.something). My white wavelan cards were original
In message: <005b01c1f4db$e3563f20$020a@bender>
"Martin Minkus" <[EMAIL PROTECTED]> writes:
: But it's a standard WaveLAN/Orinico card, which is what the wi driver is
: intended for?
:
: I never had to worry about any of this when I had the old white/bronze
: 2mbit wavelan cards,
> > Martin Minkus wrote:
> > > But it's a standard WaveLAN/Orinico card, which is what the wi
> > > driver is intended for?
> > >
> > > I never had to worry about any of this when I had the old
> > > white/bronze 2mbit wavelan cards, but with silver and gold cards,
> > > its been nothing but f
> > But it's a standard WaveLAN/Orinico card, which is what the
> wi driver
> > is intended for?
> >
> > I never had to worry about any of this when I had the old
> white/bronze
> > 2mbit wavelan cards, but with silver and gold cards, its
> been nothing
> > but fun and games
>
> I supp
< said:
> Is doing this wise? I have this nagging feeling that randomizing (or
> zeroing on each new connection) the timestamp would degrade its usefulness
> for PAWS checks and the like. (Don't ask me how, I haven't thought it
> through fully.)
I don't think so, because the timestamps, as cur
On Mon, 6 May 2002, Garrett Wollman wrote:
> 1) Change the RFC 1323 implementation to use ticks relative to the
> time the socket was created. This is fairly easy to do and requires
> changes to only a handful of lines of code. (Keep in mind that only
> timestamps we send over the network ough
Currently, FreeBSD's implementation of RFC 1323 uses the contents of
the `ticks' variable verbatim in the TCP timestamp options that it
generates. This is perhaps undesirable, in that it allows the system
at the other end to determine how long the system has been up.
(Current versions of `nmap' d
Simon 'corecode' Schubert writes:
> the pptp server is wrong configured. it's address may be `vpngw1'. it
> also tells `vpngw1' as peer address for the ppp session. this means that
> a routing loop is produced: packets that are destined for vpngw1 (peer)
> are tunneled to vpngw1 (tunnel endpoint).
hey,
okay, please ignore my previous post...
i sniffed around and found out that the ppp process was kill(TERM)'ed by
pptp itself. wondering why this happened led to this conclusion:
the pptp server is wrong configured. it's address may be `vpngw1'. it
also tells `vpngw1' as peer address for the
> Martin Minkus wrote:
> > But it's a standard WaveLAN/Orinico card, which is what the wi driver is
> > intended for?
> >
> > I never had to worry about any of this when I had the old white/bronze
> > 2mbit wavelan cards, but with silver and gold cards, its been nothing
> > but fun and games
> There seem to be two problematic cases. In the first, _both_ of these
> conditions fire in tcp_input.c:
>
> else if (++tp->t_dupacks == tcprexmtthresh) {
>
> and
>
> if (tcp_do_newreno && SEQ_LT(th->th_ack,
> tp->snd_recover)) {
yes, this is a problem because FreeBSD 4.[34 and before
Martin Minkus wrote:
> But it's a standard WaveLAN/Orinico card, which is what the wi driver is
> intended for?
>
> I never had to worry about any of this when I had the old white/bronze
> 2mbit wavelan cards, but with silver and gold cards, its been nothing
> but fun and games
I suppose I c
Bill Fumerola wrote:
> [ this is probably more appropriate for -net, -hackers bcc:'d ]
>
> On Fri, May 03, 2002 at 08:35:01AM +0100, andrew mejia wrote:
>
>
>>[andrew]$ exactly what i would suggest. a single
>>NIC can handle multiple assigments pretty easily,
>>unless you're expecting mega-
But it's a standard WaveLAN/Orinico card, which is what the wi driver is
intended for?
I never had to worry about any of this when I had the old white/bronze
2mbit wavelan cards, but with silver and gold cards, its been nothing
but fun and games
-Original Message-
From: Terry Lamber
Title: Message
Okay, i am getting
some wierd stuff with this :)
I got a WinXP client
running the Orinico Client manager, and am watching what speed the FreeBSD
machine is sending me packets at.
silence:~# wicontrol
-t 5
With that option
set, lets play with ifconfig.
silence:~# ifco
20 matches
Mail list logo
