Darren Reed | 27 Apr 15:15 2016
Picon

ethtool/tc for NetBSD?

Is there a NetBSD equivalent to ethtool(8) on Linux?

reference:
https://github.com/pavel-odintsov/fastnetmon/wiki/Traffic-filtration-using-NIC-capabilities-on-wire-speed-%2810GE,-14Mpps%29
http://linux.die.net/man/8/ethtool

As an example, to drop ICMP packets:

ethtool --config-ntuple eth4 flow-type ip4 proto 1 action -1

... and the NIC drops them all for you, not an interrupt in sight in 
response to ICMP (but there's also no logs...)

The other interesting and obscure Linux networking command is "tc".
http://lartc.org/manpages/tc.txt

Cheers,
Darren

Edgar Fuß | 22 Apr 12:58 2016
Picon

pfil related panic on 6.1_STABLE

We hit the following panic on a recent 6.1_STABLE/amd64 server (manual OCR):

fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff804ccd44 cd 8 rflags 10212 cr2  ffff800147440128 cpl 4 rsp fffffe80010055c8
kernel: page fault trap, code=0
stopped in pid 0.3 (system) at	netbsd:memcpy+0x14:	movq	fffffffffffffff8(%rsi,%rdx,1),r10
db{0}> bt
memcpy() at netbsd:memcpy+0x14
m_copyback0() at netbsd:m_copyback0+0x22c
fr_check_wrapper() at netbsd:fr_check_wrapper+0x2e
pfil_run_hooks() at netbsd:pfil_run_hooks+0x9d
ip_output() at netbsd:ip_output+0x3fb
tcp_output() at netbsd:tcp_output+0x1542
tcp_input() at netbsd:tcp_input+0x13b6
ip_input() at netbsd:ip_input+0x43b
ipintr() at netbsd:ipintr+0x107
softint_dispatch() at netbsd:softint_dispatch+0x7b
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfffe8001005d70
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt --
0:
db{0}> show registers
ds	55f5
es	5608
fs	55f8
gs	55b2
rdi	fffffe80eff25800
rsi	ffff800147440000
rbp	fffffe8001005600
rbx	fffffe8107d48800
(Continue reading)

Dustin Marquess | 22 Apr 06:46 2016
Picon

vioif(4) and jumbo frames

While trying to figure out how to do jumbo frames inside of vioif, I
stumbled upon:

https://groups.google.com/forum/m/#!topic/mailing.openbsd.tech/v7SgQT6_MO8

Would that work or is there something else that's missing?  I'm kind
of new at the network driver stack.

Thanks!
-Dustin

Roy Marples | 22 Apr 03:14 2016
Gravatar

bridge(4) - feedback local packets into ether_input()

Hi List!

So my goal is to run a DHCP server and client on two virtual interfaces
and get them talking to each other. After the initial idea of
vether/pair was shot down I looked into what bridge(4) could do after
much prompting by our beloved Taylor.

Here is what I am trying to achieve WITHOUT BPF* (it works with BPF):
DHCP Server --- > tap0 --- > bridge0 <---- tap1 <----- DHCP client

Because tap(4) will drop packets if there is nothing using it as a TAP
device (in this scenario we're just treating it as an endpoint) we have
to solve the problem in bridge(4).

Because DHCP is essentially a broadcast operation, I copied the logic
from bridge_broadcast() into bridge_output() (used for originating local
packets) where we send the packet to ether_input() if it's broadcast or
multicast. Because bridge_output has coding for if src_if == dst_if I
reversed the logic on sending it to ether_input (src_if != dst_if) so
that the receiving interface doesn't double up.

The attached patch allows this to work fine.
Comments are welcome, especially if you think it breaks something.

Roy

* OK the DHCP client still requires BPF but that can be fixed once PR
kern/48280 is.
(Continue reading)

Roy Marples | 20 Apr 22:59 2016
Gravatar

vether(4)

Hi List!

There was some discussion recently about introducing vether(4) in a
thread about bridging here:
http://mail-index.netbsd.org/tech-net/2016/02/10/msg005588.html

Attached is a patch which ports the OpenBSD vether(4) driver to NetBSD.
It seems to function well as an endpoint to a bridge(4) interface and is
a lot simpler than tap(4).

Commentary welcome.

Would also welcome some discussion on extending vether(4) to allow it to
be paired (like a crossover cable) to another vether or to just import
pair(4) (again from OpenBSD). The argument for extending vether is that
both code bases are very similar.

I'm hopeful that paired vether will allow me to run a DHCP server on one
vether and a DHCP client on another and they talk to each other, as they
don't over a bridge using either vether or tap(4).

Roy
Index: sys/conf/files
===================================================================
RCS file: /cvsroot/src/sys/conf/files,v
retrieving revision 1.1154
diff -u -r1.1154 files
--- sys/conf/files	12 Apr 2016 11:51:08 -0000	1.1154
(Continue reading)

Edgar Fuß | 20 Apr 14:52 2016
Picon

generating ECONNRESET with no syscall?

Is it, for a user process, legally possible to put one of its socket into a 
state where trying to connect to it returns ECONNRESET without the process 
issuing any syscalls during the connection attempt?

We have two production web servers, both running lighttpd, the first still 
running on NetBSD 4.0.1, the second on 6.1. Occasioally, on the second, you 
get Connection Reset by Peer (NOT Connection Refused) on the HTTP port. 
ktrace-ng the lighttpd process reveals close to no activity. Restarting 
lighttpd instantly resolves the problem. Is there any way the lighttpd process 
may have put its socket into this condition or must this be a kernel issue?

Darren Reed | 16 Apr 15:32 2016
Picon

Multi-host LACP (MC-LAG) for NetBSD?

Just out of curiosity, are there any working implementations of
multi-host (or multi-chassis) LACP for NetBSD where a LAG is
created using LACP across two links from a pair of NetBSD hosts?

Darren

Kengo NAKAHARA | 15 Apr 04:42 2016
Picon

mbuf initialization macros

Hi,

I found some functions(e.g. _pf_mtap2() <at> sys/net/bpf.c) use mbuf allocated
on stack instead of allocated by m_get(). Furthermore, the functions
initialize mbuf incompletely. It might cause problems when struct mbuf
fields is modified.

I think mbuf initialization macros is required to prevent these potential
problems. That is, the following patch is required.

====================
diff --git a/sys/kern/uipc_mbuf.c b/sys/kern/uipc_mbuf.c
index f2056da..a8426b7 100644
--- a/sys/kern/uipc_mbuf.c
+++ b/sys/kern/uipc_mbuf.c
 <at>  <at>  -583,14 +583,10  <at>  <at>  m_get(int nowait, int type)
                return NULL;

        mbstat_type_add(type, 1);
+
+       M_HDR_INIT(m);
        mowner_init(m, type);
-       m->m_ext_ref = m;
        m->m_type = type;
-       m->m_len = 0;
-       m->m_next = NULL;
-       m->m_nextpkt = NULL;
-       m->m_data = m->m_dat;
-       m->m_flags = 0;

(Continue reading)

Ryota Ozaki | 14 Apr 08:55 2016
Picon

bridge(4): BRIDGE_MPSAFE by default and applying psref(9)

Hi,

I prepared two patches for bridge(4):
  http://www.netbsd.org/~ozaki-r/remove-BRIDGE_MPSAFE.diff
  http://www.netbsd.org/~ozaki-r/psref-bridge.diff

The former removes BRIDGE_MPSAFE switch and enables the
MP-safe code by default. After introducing softint-based
if_input, bridge can run in parallel even without NET_MPSAFE,
so I think we need to always enable it.

The latter applies psref(9) to bridge. I confirmed the new
implementation survives load test, which includes repeating
bridge creations/deletions and member interface
additions/removals, over several hours.

Note that I notice that we need to tweak shmif of the
rump kernel because it seems that the interrupt handler
of shmif can migration between CPUs and so the behavior
violates a contract of psref. We can fix it by applying
if_percpuq to shmif, but I'm not sure that's the way
to go. (I'll ask pooka about the issue.)

Anyway any comments on the patches?

Thanks,
  ozaki-r

Ryota Ozaki | 12 Apr 08:54 2016
Picon

Remove meaningless RTF_UP check

Hi,

There is a questionable code in ip_hresolv_output:
  http://nxr.netbsd.org/xref/src/sys/netinet/ip_output.c#230

As the comment says, checking RTF_UP and doing re-rtalloc1
is questionable. IIUC, it's meaningless because:

- An obtained rtentry is ensured that it's always RTF_UP
  by rtcache, rtalloc1 and rtlookup. If the rtentry isn't changed
  (RTF_UP gets dropped) during processing, the check should be
  unnecessary
- Even if not, i.e., an obtained rtentry can be changed during
  processing, checking only at the point doesn't help; the
  rtentry can be changed after the check

So I think we can get rid of it. Of course, in the future
we should ensure that RTF_UP isn't dropped if someone
is using it somehow once we remove the global locks.

Here is a patch:
  http://www.netbsd.org/~ozaki-r/remove-RTF_UP-check.diff

Any comments?

  ozaki-r

Dave Tyson | 11 Apr 23:22 2016
Picon

RTM_LLINFO removal breaks net-snmp package build

Just tried to compile net-snmp under a recent current amd64 snapshot and its 
failing to compile arp_sysctl.c as RTM_LLINFO is undeclared.

Dave

--

-- 
=========================================
Phone: 07805784357
Open Source O/S: www.netbsd.org
Caving: http://www.wirralcavinggroup.org.uk
=========================================


Gmane