Robert Elz | 27 Jun 03:32 2016
Picon

srt(4), and IPv6

I'd appreciate it if those of you who understand the IPv6
stack (and particularly the embedded scope-id in link locals
hack) could take a look at the patch to net/if_srt.c in
PR kern/51280 and see if it looks reasonable.

kre

Rhialto | 23 Jun 21:15 2016
Picon

Named in NetBSD 7.0.1

I have named (from 7.0.1) spewing the following errors every few
seconds:

Jun 23 21:09:56 murthe named[22809]: client 0x7f7ff0677800 (220.29.86.203.in-addr.arpa):
query_find: unexpected error after resuming: failure
Jun 23 21:09:59 murthe named[22809]: client 0x7f7feee13800 (220.29.86.203.in-addr.arpa):
query_find: unexpected error after resuming: failure
Jun 23 21:10:01 murthe named[22809]: client 0x7f7ff4330000 (220.29.86.203.in-addr.arpa):
query_find: unexpected error after resuming: failure
Jun 23 21:10:04 murthe named[22809]: client 0x7f7ff0069000 (220.29.86.203.in-addr.arpa):
query_find: unexpected error after resuming: failure
Jun 23 21:10:06 murthe named[22809]: client 0x7f7feeb55800 (220.29.86.203.in-addr.arpa):
query_find: unexpected error after resuming: failure
Jun 23 21:10:09 murthe named[22809]: client 0x7f7ff7336800 (220.29.86.203.in-addr.arpa):
query_find: unexpected error after resuming: failure
Jun 23 21:10:12 murthe named[22809]: client 0x7f7ff2503000 (220.29.86.203.in-addr.arpa):
query_find: unexpected error after resuming: failure

This is rather annoying. It also does it for other queries but for this
one it has been going on for a very long time now.

Where does it come from and what can I do about it?
Could it come from blackholing sources of sshd attacks? Although it
would be unexpected if those hosts were dns servers.

-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl    -- are condemned to reinvent it. Poorly.
(Continue reading)

Support | 19 Jun 19:38 2016

Re: [Ticket C-55262-288992128] your account


Attention!

Check your money balance on http://kirasinclair.com/wp-cron/user/1.htm

Money System Support

John Klos | 19 Jun 01:13 2016

Can't set lower MTU on gif?

Hi,

I'd like to use gif to route IPv4 over IPv6. I set up gif0 on a NetBSD 7 
machine like so via /etc/ifconfig.gif0:

create
tunnel 2001:470:a068:5:250:baff:fecb:32e 2605:bc00:0:114:230:48ff:fe98:d1a8
inet 192.80.49.75 192.80.49.74 netmask 255.255.255.254

The other end is a NetBSD-7 machine, and this works - both sides can ping 
one another, I can add 192.80.49.74 as a default route and talk over IPv4 
to the Internet.

However, any packets larger than 1200 bytes or so don't get passed. In 
FreeBSD's man page for gif(4), this is mentioned:

"If the outer protocol is IPv6, path MTU discovery for encapsulated 
packets may affect communication over the interface. The first 
bigger-than-pmtu packet may be lost.  To avoid the problem, you may want 
to set the interface MTU for gif to 1240 or smaller, when the outer header 
is IPv6 and the inner header is IPv4."

https://www.freebsd.org/cgi/man.cgi?gif(4)

However, NetBSD doesn't let the MTU for gif to be set to less than 1280 
bytes:

#define GIF_MTU_MIN     (1280)  /* Minimum MTU */

Is there a good reason for this? If there is, then what's a better way to 
(Continue reading)

Kengo NAKAHARA | 17 Jun 10:57 2016
Picon

RFC: eliminate gif(4) Tx softint(9)

Hi,

I have reconsidered and researched gif(4) implementation, as a result
I think gif(4) Tx softint(9) should be eliminated. That is, the
following patch is required.
    http://www.netbsd.org/~knakahara/gif-direct-output/gif-direct-output.patch
I tested this patch by ATF and some gif(4) workload.

gif(4) Tx softint(9) is introduced by if_gif.c:r1.33 which is contributed
by KAME project. I ask my co-worker who was a member of the project, he
says "there must be no reason that gif(4) Tx must use softint. They
just wanted to use softint as it had been just implemented." Hmm, it
seems gif(4) Tx softint(9) can be eliminated.

Another point of view, each gif(4) establishes one Tx softint(9) handler,
that is, if 100 gif(4)s are created and set tunnel address, 100 softint(9)
handlers are established. That would cause harmful effect to softint(9)
processing. So, I think gif(4) Tx softint(9) should be eliminated.

Thoughts?
Or, does anyone know why gif(4) Tx processing uses softint(9)?

Thanks,

--

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
(Continue reading)

Emmanuel Dreyfus | 11 Jun 04:57 2016
Picon

ipnat kernel options

Hello

I hit the case where ipnat ceases to function. In such case, ipnat -s
show non-zero "no memory" numbers, I therefore assume that I hit an
ipnat limit.

The kernel already has LARGE_NAT, but I just discovered this in
src/sys/external/bsd/ipf/netinet/ip_nat.h
#undef  LARGE_NAT       

Hence it is not taken into account. and I need to directly set the other
values that LARGE_NAT was supposed to bump:
NAT_SIZE
RDR_SIZE
HOSTMAP_SIZE
NAT_TABLE_MAX
NAT_TABLE_SZ

That raises a question: how can I know what above limit is reached by
reading ipnat -s output?

--

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu <at> netbsd.org

Rhialto | 9 Jun 00:07 2016
Picon

dhcpcd and routing of ipv6 prefixes

(oops, should have sent this to tech-net <at>  ...)

Can it be that if I use dhcpcd to obtain an IPv6 prefix from my router
(a FritzBox in my case), and it assigns the prefix::1 address to the
desired interface, that still no routing in that direction occurs?

Here is my case:

dhcpcd.conf:

    interface re0
	noipv4

    interface re1
	# enable routing solicitation get the default IPv6 route
	ipv6rs
	# also the default IPv4 route will go here
	gateway
	# request an IPv6 address
	ia_na 1
	# get a /64 and assign it to re0
	ia_pd 2 re0/0

ifconfig re0:

re0: ...
        inet 10.0.0.16 netmask 0xffffff00 broadcast 10.0.0.255
        inet6 fe80::d63d:7eff:fe2d:6798%re0 prefixlen 64 scopeid 0x1
        inet6 2001:984:4b2a:fc::1 prefixlen 64

(Continue reading)

Edgar Fuß | 7 Jun 20:29 2016
Picon

ipf.conf vs. ipf6.conf

Next question on ipf (the one in NetBSD-6):

Is my impression correct that rules in ipf.conf (i.e. loaded with ipf 
without -6) only apply to IPv4 while rules in ipf6.conf (i.e. loaded 
via ipf -6) apply only to IPv6. Right?

Now, what if rules are added to a non-default group? Are these groups also 
IP version specific or will a packet having matched a "head 100" rule in 
ipf.conf be matched against a "group 100" rule in ipf6.conf?

Is it also correct that non-IP frames (ARP, PPPoE) are never matched by 
IPF rules?

Edgar Fuß | 7 Jun 20:17 2016
Picon

ipf group/head (and quick)

I'm once again confused about the exact semantics of ipf groups, especially 
in conjunction with "quick".

Generally, my impression is that rules in ipf.conf (or elsewhere) are, in 
turn, added to per-group lists depending on the "group" part of the rule (0 
as a default); then, after parsing, we have as many lists as we have groups 
and every packet starts to be matched against the rules on list 0, until it 
matches a "head n" rule, after which it starts to be matched against all the 
rules on list n, no matter where they appear in ipf.conf. Is that correct?
So, if, in ipf.conf, rule #3 is "head 100", #2 and #5 are "group 100" and 
#1, #4 #6 are default, and no rule is "quick", a packet matching the critera 
of #3 would be matched against #1, then #3, then #2 and #5, right? Would it 
also be matched against #4 or #6 afterwards?
What if a rule belonging to a non-default group has a "quick" attribute? 
Will this stop processing of the group or the whole ruleset?
Then, there's a sentence about "quick" on "head" rules I don't understand: 
"If quick is used with a head rule, rule processing isn't stopped until it 
has returned from processing the group". How could it stop otherwise? What 
exactly does "return" mean?

Can someone please enlighten me?

Kengo NAKAHARA | 19 May 11:01 2016
Picon

bridge(4) and wm(4) with NET_MPSAFE is MP-scalable for now

Hi,

bridge(4) and wm(4) of latest NetBSD-current, that is
    - if_bridge.c:r1.123 (or later)
    - if_wm.c:r1.406 (or later)
are MP-scalable now, if the kernel is built with NET_MPSAFE option on.

Here is the measurement result by ipgen.
# ipgen is packet generator implemented by ryo <at> n.o.
# see
#     https://github.com/iij/ipgen
#     http://www.netbsd.org/gallery/presentations/msaitoh/2016_AsiaBSDCon/ipgen.pdf

+ without NET_MPSAFE kernel

framesize|0M  100M 200M 300M 400M 500M 600M 700M 800M 900M 1Gbps
---------+----+----+----+----+----+----+----+----+----+----+
      64 |#######                                             125.00Mbps,  186011/1488095pps
     128 |##############                                      268.97Mbps,  227171/ 844594pps
     256 |############################################        875.64Mbps,  396575/ 452898pps
     512 |################################################## 1000.00Mbps,  234962/ 234962pps
    1024 |##################################################  999.99Mbps,  119731/ 119731pps
    1280 |##################################################  999.99Mbps,   96153/  96153pps
    1408 |################################################## 1000.00Mbps,   87535/  87535pps
    1518 |################################################## 1000.00Mbps,   81274/  81274pps

+ with NET_MPSAFE kernel 1 core

framesize|0M  100M 200M 300M 400M 500M 600M 700M 800M 900M 1Gbps
---------+----+----+----+----+----+----+----+----+----+----+
(Continue reading)

Tyler Retzlaff | 13 May 21:56 2016
Picon

patch make struct protosw pr_input non-variadic

Hi,

The attached patch for review (originally produced by riastradh <at> )
that provides the structural changes needed to make
protosw::pr_input protocol-specific and ditch its variadic
prototype pr_input(struct mbuf *, ...).

Similar work has already been done & discussed.

https://mail-index.netbsd.org/tech-net/2016/01/16/msg005484.html

Once the structural changes are in I'll generate a second patch
adapting the variadic implementations of pr_input to functions with
apropriate prototypes.

This patch:
* moves pr_input out of struct protosw and places it into <proto>sw
  specitic structure.
* converts domain::dom_protosw to an array of pointers

comments? objections? cleanups?

Thanks
Attachment (dom_protosw2.patch): text/x-diff, 44 KiB

Gmane