Yonghyeon PYUN wrote:
> msk(4) supported flow-control from day 1 with a hack and it was
> re-implemented later with proper way such that it always announces
> flow-control. However for other drivers(i.e vr(4)) that didn't
> support the feature in the beginning, you have to explicitly enable
> the
OpenBSD keeps count of the packets that have undergone IPv4 header/
TCP/UDP checksumming in hardware. These statics are available with
netstat -s, e.g.:
ip:
...
492152 input datagrams checksum-processed by hardware
911338 output datagrams checksum-processed by hardware
...
Pyun YongHyeon <[EMAIL PROTECTED]> wrote:
> I don't think it indicates whether checksum offloading actually
> works as OpenBSD blindly set a flag, which was derived from
> hardware, to indicate hardware performed the checksum computation.
Yes. It counts the instances where the network stack assu
Pyun YongHyeon <[EMAIL PROTECTED]> wrote:
> > OpenBSD's re(4) driver is ported from FreeBSD. Recently, Brad Smith
> > has been merging the tx/rx checksum offload support for the newer
> > chips (RTL8111C etc.) into the OpenBSD driver and I have done some
> > testing for him. Looking at the c
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> OpenBSD's re(4) driver is ported from FreeBSD. [...]
> * If VLAN tagging is enabled, no rx checksumming is registered at
> all.
For the record, this is in fact due to a difference in the OpenBSD
driver, i.e., it does
wang_jiabo <[EMAIL PROTECTED]> wrote:
> following is my setkey configration. I can get SAD and SPD. but when I
> run " ping6 -I rl0 3ffe:501::103:20a:ebff:fe85:9e56 " on FreeBSD
> FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must
> be multiple of 16
>
Something seems to be wrong with IPv6 neighbor discovery.
FreeBSD lorvorc.mips.inka.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 20
17:46:35 CET 2008 na...@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64
This box is on a network that has IPv6. No exciting configuration,
just ipv6_ena
Li, Qing:
> Please sync ./src/sys/netinet6/in6.c to
>
> SVN rev 186392 on 2008-12-22 07:11:15Z by qingli
= rev 1.92 in the CVS export
> Let me know how it works out for you.
Yes, that fixes the problem. Thanks!
--
Christian "naddy" Weisgerber na...@mips.inka.de
___
David Malone wrote:
> (Also, we probably really want people to run in orphan mode rather
> than local clock mode, but we can wait a little longer until orphan
> mode is more commonly deployed, IMHO...)
I didn't know about orphan mode, so I had to try it right away.
$ cat /etc/ntp.conf
server 12
Louis Mamakos wrote:
> > Shouldn't ntpd have figured out by now that the clock is gone (I
> > unplugged it yesterday) and have switched into orphan mode?
>
> It seems like orphan mode is something that you'd run on an ensemble
> of local machines to ensure that they continue to be synchronized w
Anybody here who uses a udav(4) device and can check that the multicast
filter works properly?
On NetBSD, were the driver was ported from, the multicast hash
filter is programmed with a little-endian ethernet CRC. On FreeBSD,
with a big-endian one. Which is it?
(Cc'ed to the original submitter
Shingo WATANABE:
> I know the udav(4) was ported to FreeBSD, but I don't know why
> programming with big-endian CRC on FreeBSD.
Most likely it's just an error that was introduced when the driver
was ported.
> When I wrote this driver on NetBSD, it worked well with little-endian
> CRC.
Well, man
OpenBSD has ported the em(4) driver from FreeBSD. At least on
OpenBSD, em(4) is partially broken: it fails to receive multicast
ethernet frames. This effectively breaks both IPv4 and IPv6
multicast, including IPv6 neighbor discovery.
I have one report that says FreeBSD 4.9's em(4) has the same b
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> OpenBSD has ported the em(4) driver from FreeBSD. At least on
> OpenBSD, em(4) is partially broken: it fails to receive multicast
> ethernet frames.
This turns out to be a bug in the OpenBSD driver that happened in
the
I just did some quick and dirty checks with netperf and noticed a
somewhat surprising result.
Machine A: Alpha PC164, FreeBSD 5.2-CURRENT, re(4), 1000Base-T
Machine B: Alpha PC164SX, OpenBSD 3.5, de(4), 100Base-TX
Switch:StarChip SGS-1008 (10/100/1000Base-T)
Running netperf -t UDP_STREAM on m
Ruslan Ermilov:
> > How does the machine get the idea it is pushing 200 Mbit/s down a
> > 100 Mbit/s link?
>
> Does ``netstat -I re0 -w 1'' show the same numbers while you're
> running the UDP_STREAM test?
Yes, it does (~2600 bytes).
I have two further GigE-equipped OpenBSD boxes on the LAN
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> Running netperf -t UDP_STREAM on machine A with target B reports a
> throughput of ~200(!) Mbit/s.
By popular request:
[EMAIL PROTECTED] /usr/local/netperf/netperf -H bardioc -t UDP_STREAM
UDP UNIDIRECTIONAL SEND TEST to bardioc
17 matches
Mail list logo
