You could just as easily use a CRC function, which has the nice
property of having a collision rate of 2^l, where l is the length
of the CRC. CRCs are also pretty low-cost to compute relative to
other methods.
-scooter
At 09:47 PM 8/25/00 -0400, you wrote:
>[I see my post made it]
>
>To expand
> Can anyone recommend a good reference on this? I've been reading RFC-1075
> and don't really understand it.--Glen Gross
>
> On Tue, 30 Nov 1999, B. Scott Michel wrote:
>
> > On Wed, 22 Dec 1999, Jonathan Lemon wrote:
> >
> > > On Dec 12, 1999
Scott Michel wrote:
> - tcpdump-ing the pn0 interface shows that the host thinks that it's
> sending data. tcpdump-ing elsewhere in the network shows that pn0
> isn't actually transmitting anything into the wire.
The host appears to be doing retransmissions but nothing g
As I'd recently posted on -current, I've been noticing TCP oddities in
3.3 and 3.4. I've got a pn card (NetGear FA310tx) and a few new things
to report:
- Invariably, a TCP connection will freeze with something in the send
queue. Connections don't freeze even if there's something in the
recei
On Wed, 22 Dec 1999, Jonathan Lemon wrote:
> On Dec 12, 1999 at 11:37:42AM -0800, Matthew Dillon wrote:
> I had a Netgear FS509 switch here that would eat packets transmitted
> through the GigE port under certain conditions. Netgear shipped me
> a new one, and I've been happy with it, until the
I've got a slightly hosed -current at the moment that complains
with this error message:
# make
oops: 894
followed by a very healthy looking notice about a segfault and
because I'm root in single user mode, core dumps are abounding.
Since I'm DITW at the moment, anyone got a clue? This Windows
A kernel cvsup'd at or about 1800 PDT this evening bought the farm
as so:
pmap_remove_pages(c3d07924, 0, bfbfe000, c3749034, 1)
exec_new_vmspace(c3dafe80, 1, 1, c3dafe80, c025dd5c)
exec_elf_imgact(c3d0fe80, c3d02fa0, c025e61c, 0, 1)
syscall(...)
Xint0x80_syscall(...)
I don't have enough disk spa
At line 71 in i386/isa/clock.c, there is the following:
#include
#include
XXX
#ifdef APIC_IO
#include
#endif
I'd say, and this is only a SWAG mind you, that the 'XXX' is
extraneous. Right?
-scooter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the
If you haven't /.'d today, there's a news article purporting that
FreeBSD can be exploited via kernel modules:
http://thc.pimmel.com/
-scooter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-current kernel as of 1700 PST (or thereabouts):
spec_strategy+0x31: movl0x28(%eax), eax
Note: %eax = 0
Traceback:
--
spec_strategy(c3d27dd0,c3d27dac,c01cbe1,c3d27dd0,c3d27ddc) at spec_strategy+0x31
spec_vnoperate(c
> This wouldn't help the poor sod whose connection gets shot down every
> eight days while he's not there and doesn't know what hit him.
One thing that no one points out is that this "idle" connection
is potentially a security threat. Even if the physical connection
is iced and is reconnected late
I don't recall that the FreeBSD version of egcs is built with Haifa
turned on, which is supposed to improve optimizations as the level
is increased (more aggressive instruction scheduling.)
> With egcs, the '-O' flag doesn't specify the optimization level like it
> does in GCC. It specifies
> % gdb foobar foobar.core
> Register %s not found in core file.
^^
Should read:
"Register eax not found in core file."
Silly me... :-)
-scooter
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Current's gdb cannot read core files today (cvsup'd on Monday
and installed Monday). It reports:
% gdb foobar foobar.core
Register %s not found in core file.
%
The error emanates in gdb/gdb/core-aout.c. I was going to try
to diagnose the problem this weekend but unfortunately I have
USNR duty.
A
"Open" (according to Lenny Kleinrock) meant "available"; thus OSPF
was supposed to mean "Available, shortest path first." But, then again,
these meanings get changed with time. "Open" is now a codeword for
GNU/GPL/intellectual rights unencumbtered software. For OSPF, it was
simply a description of
> Umm- it's never supposed to have been with a '*' in it for this YP
> implementation, I believe. Fixing the security check would be a good
> thing. Going to pam/nsswitch.conf would be even better.
Been that way for years, ever since I started supporting a SCO box
oh these many years ago with a U
I didn't see anything along these lines the the archive, so
here goes... (something different to the other threads running
these days.)
In 3.3.1 and 4.0-current, if one puts the following in /etc/passwd
to enable NIS logins:
+:*:
then logins (console or ssh) of ordinary users don't w
> Not true IMO. You still need to know what hardware you have before you
> can build your own kernels etc etc.
>
> > Also the eth[0..x] thing means you can replace your ethernet card
> > with a new one of a different type without having to look through
> > your config code for references to ed0 o
> I think Solaris (?) requires you to do this, it's called "plumbing
> your interfaces" or something (according to Julian).
Solaris requires "interface plumbing" as the result of STREAMS; you
have to push IP on top of the interface driver. For all intents and
purposes, the device name identifies a
19 matches
Mail list logo
