>I think committing this would be beneficial. Would someone w/ commit
>privs care to review and then commit this bit?
I wrote it in rev 1.41 and gave it to the squid folks; it turned out
to cause X to fail in unexplained ways so we reverted it. Then I added
PRUS_MORETOCOME in rev 1.50,
>Can anyone explain how or where the "199.15.32&0xc70f22" entry could
>have come from? I've been unable to remove it ...
Have you tried
route -delete 199.15.32.0 -netmask 199.15.34.0? (I'm guessing at the .0
part; it got truncated. "netstat -nrA" might help figure out what it
really is)
(I ca
PRUS_MORETOCOME is indeed too complex to solve the microcosmic problem
of writes between 100 and 208 bytes; however, it solves the more general
problem of the Nagle/MTU interaction even when the MTU is larger than a
cluster (e.g. loopback, ATM, FDDI, etc). Try the atomic patch (and
remove PRUS_MO
>The TCP checksum protects more than just the contents of the packet
>on the wire; it's also a (somewhat) weak check on the contents
>of your packet sitting in memory, and as it's going over the bus
>in your computer between memory and peripherals and for other end-to-end
>sorts of issues.
In f
>On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not
>forwarded.
"smurf" attacks love using broadcast forwarders.
RFC 2644 says:
> A router MAY have an option to enable receiving network-prefix-
> directed broadcasts on an interface and MAY have an option to
>
This is a bug in delayed checksum. The checksum in the encapsulated
packet is the pseudo-header checksum:
mango% ipcksum
0011 0018 c009 c87f e002 0304
correct checksum of the 12 bytes is 9446 1's complement is 6bb9
(6bb9 is the udp checksum in the encapsulated packet). ip_output()
has to do t
Please try this patch. It gives multicast packets on a multicast
router similar treatment to those that IPSEC packets get, by calculating
the delayed checksum early and not permitting it to be offloaded to
the interface.
Thanks,
Bill
Index: ip_output.c
=
>However, there does exist one case that have good checksum, no matter I
>apply the patch or not.
Is the local system a member of one or the other of these groups?
i.e. does it work when the local system is a member, or not, or
is that not a predictor of the behavior?
Bill
To Unsubscribe: s
I looked at the larger context and realized that ip_mloopback()
was wrong too. Try this updated patch; it is a superset of the
previous one.
Bill
Index: ip_output.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrie
>Is this PR-worthy?
Not really; the C99 conformance project is already working on this
(in particular, I am working on scanf).
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
>I think committing this would be beneficial. Would someone w/ commit
>privs care to review and then commit this bit?
I wrote it in rev 1.41 and gave it to the squid folks; it turned out
to cause X to fail in unexplained ways so we reverted it. Then I added
PRUS_MORETOCOME in rev 1.50,
>Can anyone explain how or where the "199.15.32&0xc70f22" entry could
>have come from? I've been unable to remove it ...
Have you tried
route -delete 199.15.32.0 -netmask 199.15.34.0? (I'm guessing at the .0
part; it got truncated. "netstat -nrA" might help figure out what it
really is)
(I c
PRUS_MORETOCOME is indeed too complex to solve the microcosmic problem
of writes between 100 and 208 bytes; however, it solves the more general
problem of the Nagle/MTU interaction even when the MTU is larger than a
cluster (e.g. loopback, ATM, FDDI, etc). Try the atomic patch (and
remove PRUS_M
I've got this program in my head that takes a CVS tree and turns it
into a branch ofanother CVS tree (e.g. FreeBSD rev 1.7 turns into
rev 1.1.1.7) but it's never managed to make it out of my head, so
it must be harder than I keep thinking it is =)
Bill
To Unsubscribe: send mail to [EMAIL PRO
>I know the WaveLAN stuff is crap
Actually, I've had terrific luck with WaveLAN IEEE stuff on laptops
for the last year or so. I'm not sure what's so bad about it?...
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
The FreeBSD driver doesn't currently support encryption, correct.
The Linux driver does, so perhaps it would be fairly easy to port the
functionality, and the Linux driver is dual-licensed under GPL and BSD
licenses so there's no worry of GPL contamination.
ftp://sourceforge.org/pcmcia/contrib/wa
Er, I meant the 3.x driver =) How embarassing.
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I have an Airport configuration utility almost usable, if you're interested
in trying it. (It doesn't support configuring keys yet, although I think
I know where they're stored so if you want to experiment...)
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hac
>What should I do when I see ALLMULTI?
You should go promiscuous to multicast. If the card doesn't support
that, you should go fully promiscuous and drop unicasts that aren't
to you. (Make sure you don't block packets that bpf is going to
want to see).
Bill
To Unsubscribe: send mail to [E
19 matches
Mail list logo
