tap not (re-)adding IPv6 link-local anymore?

[Bjoern A. Zeeb]

Hi,

using tap with bhyve when I reboot an instance but the tap8 does not get
destroyed but re-used it loses it's IPv6 link-local address and as bhyve
starts again (remote end comes up) it doesn't come back.

I have to manually toggle tap8 down, tap8 up to get the IPv6 link-locla
back.   Anyone else observing this?

/bz

--
Bjoern A. Zeeb r15:7

Re: ifp gone in ip6_output() -> panic

[Bjoern A. Zeeb]

On Wed, 22 May 2024, Zhenlei Huang wrote:





On May 22, 2024, at 12:17 PM, Bjoern A. Zeeb  
wrote:

Hi,

sorry, I cannot dump; this is a diskless and netdump does not do IPv6;
needless to say that would be funny in this case anyway; unfortunately
I have also already re-compiled the kernel so I can only look things up approx.

FreeBSD main from May 13 (f3eeeb959c9b00c89a2e1ff009c78162eb398656).

I assume we lost the ifp from a destroy of a cloned interface in ip6_output()
between lines 806 and 811?


Kernel page fault with the following non-sleepable locks held:
exclusive rw rawinp (rawinp) r = 0 (0xf80002a6e1a0) locked @ 
/usr/src/sys/netinet6/raw_ip6.c:393
stack backtrace:
#0 0x80bb679c at witness_debugger+0x6c
#1 0x80bb7979 at witness_warn+0x3e9
#2 0x81061d10 at trap_pfault+0x80
#3 0x81033878 at calltrap+0x8
#4 0x80d99228 at rip6_send+0x5a8
#5 0x80bf570e at sosend_generic+0x5ee
#6 0x80bf5c49 at sousrsend+0x79
#7 0x80bfbd5c at kern_sendit+0x1bc
#8 0x80bfc073 at sendit+0x1b3
#9 0x80bfc1ab at sys_sendmsg+0x5b
#10 0x81062638 at amd64_syscall+0x158
#11 0x8103418b at fast_syscall_common+0xf8
Created wlan(4) interfaces: wlan


Note the creation of wlan, and a following ICMP6 (ping6) packet.


Yes I think it was running netif restart wlan0 in loops.


[...]


I'm not quite sure, but it seems the `ifp` is not fully constructed. See 
https://cgit.freebsd.org/src/tree/sys/net/if.c#n950 
<https://cgit.freebsd.org/src/tree/sys/net/if.c#n950>

If I read the code correctly, the clone created interface is made visible via 
`if_link_ifnet(ifp);` , and at that time the
`ifp->if_afdata[AF_INET6]` is NULL and is not initialized yet by 
`if_attachdomain1()` which will call `in6_domifattach()`
to allocate the required data.

So I guess there is a race condition. I bet this can be repeated easily.

I have not tested this yet, and not sure if it is the right fix, but you can 
give it a try.


I'll do; I haven't seen the error happening since on other test
machines, so not sure about repeatability.

I am also not entirely sure this is not a ping6 ff02::1%wlan0 while
the ifp was destroyed by netif restart at the same time the packet was
still on the way out?

If it was during create, the wlan(4) interface would not be associated
and UP at that point of if_attach_internal() and
`ifconfig inet6 -ifdisabled` would not have been run to be able to send
that packet in first place?

Othwerwise the packet would have had to "survive" the clone destroy and
clone create cycle somewhere ...?



diff --git a/sys/net/if.c b/sys/net/if.c
index c3c27fbf678f..16ee5667e7bb 100644
--- a/sys/net/if.c
+++ b/sys/net/if.c
@@ -947,11 +947,11 @@ if_attach_internal(struct ifnet *ifp, bool vmove)
   }
#endif

-   if_link_ifnet(ifp);
-
   if (domain_init_status >= 2)
   if_attachdomain1(ifp);

+   if_link_ifnet(ifp);
+
   EVENTHANDLER_INVOKE(ifnet_arrival_event, ifp);
   if (IS_DEFAULT_VNET(curvnet))
   devctl_notify("IFNET", ifp->if_xname, "ATTACH", NULL);


--
Bjoern A. Zeeb r15:7

ifp gone in ip6_output() -> panic

[Bjoern A. Zeeb]

 RBP-352, decl = 
ip6_output.c:404
 Variable: id = {0x023ab638}, name = "ifpp", type = "ifnet **", valid ranges = 
, location = [0x80d8167b, 0x80d838c4) -> DW_OP_breg6 RBP-304, decl = 
ip6_output.c:405
 Variable: id = {0x023ab648}, name = "inp", type = "inpcb *", valid ranges = 
, location = DW_OP_fbreg +16, decl = ip6_output.c:405
 Variable: id = {0x023ab657}, name = "m", type = "mbuf *", valid ranges = 
, location = DW_OP_fbreg -48, decl = ip6_output.c:409
 Variable: id = {0x023ab666}, name = "sin6", type = "sockaddr_in6", valid ranges 
= , location = DW_OP_fbreg -380, decl = ip6_output.c:413
 Variable: id = {0x023ab676}, name = "src_sa", type = "sockaddr_in6", valid 
ranges = , location = DW_OP_fbreg -336, decl = ip6_output.c:413
 Variable: id = {0x023ab686}, name = "dst_sa", type = "sockaddr_in6", valid 
ranges = , location = DW_OP_fbreg -128, decl = ip6_output.c:413
 Variable: id = {0x023ab696}, name = "odst", type = "in6_addr", valid ranges = 
, location = DW_OP_fbreg -432, decl = ip6_output.c:414
 Variable: id = {0x023ab6a6}, name = "alwaysfrag", type = "int", valid ranges = 
, location = DW_OP_fbreg -192, decl = ip6_output.c:421
 Variable: id = {0x023ab6b6}, name = "exthdrs", type = "ip6_exthdrs", valid 
ranges = , location = DW_OP_fbreg -248, decl = ip6_output.c:423
 Variable: id = {0x023ab6c6}, name = "src0", type = "in6_addr", valid ranges = 
, location = DW_OP_fbreg -416, decl = ip6_output.c:424
 Variable: id = {0x023ab6d6}, name = "dst0", type = "in6_addr", valid ranges = 
, location = DW_OP_fbreg -400, decl = ip6_output.c:424
 Variable: id = {0x023ab6e6}, name = "zone", type = "u_int32_t", valid ranges = 
, location = DW_OP_fbreg -188, decl = ip6_output.c:425
 Variable: id = {0x023ab726}, name = "error", type = "int", valid ranges = 
, location = [0x80d8214f, 0x80d8251a) -> DW_OP_consts +0, DW_OP_stack_value, 
decl = ip6_output.c:417
 Variable: id = {0x023ab736}, name = "vlan_pcp", type = "int", valid ranges = 
, location = [0x80d819c2, 0x80d82a18) -> DW_OP_breg6 RBP-96, decl = 
ip6_output.c:418
 Variable: id = {0x023ab746}, name = "ia", type = "in6_ifaddr *", valid ranges = 
, location = [0x80d82187, 0x80d82a18) -> DW_OP_breg6 RBP-264, decl = 
ip6_output.c:419
 Variable: id = {0x023ab776}, name = "ip6", type = "ip6_hdr *", valid ranges = 
, location = [0x80d81e29, 0x80d82665) -> DW_OP_breg6 RBP-168, decl = 
ip6_output.c:407
 Variable: id = {0x023ab7c6}, name = "nexthdrp", type = "u_char *", valid ranges = 
, location = [0x80d81a4f, 0x80d82a18) -> DW_OP_breg6 RBP-136, decl = 
ip6_output.c:415
 Variable: id = {0x023ab7d6}, name = "ro_pmtu", type = "route_in6 *", valid ranges = 
, location = [0x80d81ab4, 0x80d824c0) -> DW_OP_reg3 RBX, decl = 
ip6_output.c:411
 Variable: id = {0x023ab7e6}, name = "dst", type = "sockaddr_in6 *", valid ranges = 
, location = [0x80d81b39, 0x80d82466) -> DW_OP_breg6 RBP-88, decl = 
ip6_output.c:413
 Variable: id = {0x023ab7f6}, name = "fibnum", type = "uint32_t", valid ranges = 
, location = [0x80d81b26, 0x80d827e3) -> DW_OP_breg6 RBP-72, decl = 
ip6_output.c:429
 Variable: id = {0x023ab806}, name = "origifp", type = "ifnet *", valid ranges = 
, location = [0x80d8218b, 0x80d824ae) -> DW_OP_reg12 R12, decl = 
ip6_output.c:408
 Variable: id = {0x023ab876}, name = "tlen", type = "int", valid ranges = 
, location = , decl = ip6_output.c:416
 Variable: id = {0x023ab882}, name = "dontfrag", type = "int", valid ranges = 
, location = , decl = ip6_output.c:421


806 KASSERT((ifp != NULL), ("output interface must not be NULL"));
807 KASSERT((origifp != NULL), ("output address interface must not be 
NULL"));
808
809 if ((flags & IPV6_FORWARDING) == 0) {
810 /* XXX: the FORWARDING flag can be set for mrouting. */
811 in6_ifstat_inc(ifp, ifs6_out_request);
812 }
813
814 /* Setup data structures for scope ID checks. */

--
Bjoern A. Zeeb r15:7

[Differential] D45109: Add support for Realtek RTL8211F-VD PHY

[bz (Bjoern A. Zeeb)]

bz accepted this revision.
bz added a comment.


  Should be fine; otherwise we'll deal with it as needed; do we know what 
mii_mpd_rev 7 is/was?

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D45109/new/

REVISION DETAIL
  https://reviews.freebsd.org/D45109

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: peterj, #network, manu, bz
Cc: bz, freebsd-net-list

TCP/IPv6 LOR in main

[Bjoern A. Zeeb]

Hi,

with ALPHA1 inside a bhyve development VM:

lock order reversal:
 1st 0xfe0001522a70 tcphash (tcphash, sleep mutex) @ 
/sys/netinet/tcp_usrreq.c:1513
 2nd 0x81aa7bb0 in6_ifaddr_lock (in6_ifaddr_lock, rm) @ 
/sys/netinet6/in6_src.c:305
lock order tcphash -> in6_ifaddr_lock attempted at:
#0 0x80bc063e at witness_checkorder+0xbbe
#1 0x80b463e9 at _rm_rlock_debug+0x139
#2 0x80d7b99a at in6_selectsrc+0x45a
#3 0x80d7b4f1 at in6_selectsrc_socket+0x41
#4 0x80d79437 at in6_pcbconnect+0x247
#5 0x80d5d554 at tcp6_connect+0xa4
#6 0x80d5aeab at tcp6_usr_connect+0x2eb
#7 0x80bfcb43 at soconnectat+0xb3
#8 0x80c03c90 at kern_connectat+0xe0
#9 0x80c03b9b at sys_connect+0x9b
#10 0x8104a398 at amd64_syscall+0x138
#11 0x8101cbeb at fast_syscall_common+0xf8


--
Bjoern A. Zeeb r15:7

IPv6 LORs etc

[Bjoern A. Zeeb]

Hi,

I am seeing a lot more LORs etc. again:


# rtsol vtnet0
Invoking IPv6 network device address event may sleep with the following 
non-sleepable locks held:
exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xf8000176c600) locked 
@ /usr/src/sys/dev/virtio/network/if_vtnet.c:2188
stack backtrace:
#0 0x80bc4925 at witness_debugger+0x65
#1 0x80bc5a79 at witness_warn+0x3f9
#2 0x80d7096a at in6_update_ifa+0xc1a
#3 0x80d9c5b9 at in6_ifadd+0x1d9
#4 0x80d98d3f at nd6_ra_input+0x103f
#5 0x80d6b3f8 at icmp6_input+0x898
#6 0x80d838a3 at ip6_input+0xcc3
#7 0x80ca72dd at netisr_dispatch_src+0xad
#8 0x80c88e6a at ether_demux+0x17a
#9 0x80c8a492 at ether_nh_input+0x392
#10 0x80ca72dd at netisr_dispatch_src+0xad
#11 0x80c892b9 at ether_input+0xd9
#12 0x8097ba03 at vtnet_rxq_eof+0x7c3
#13 0x8097b19a at vtnet_rx_vq_process+0x9a
#14 0x80b0c286 at ithread_loop+0x276
#15 0x80b08730 at fork_exit+0x80
#16 0x81020d8e at fork_trampoline+0xe


lock order reversal: (sleepable after non-sleepable)
 1st 0xf8000176c600 vtnet0-rx0 (vtnet0-rx0, sleep mutex) @ 
/usr/src/sys/dev/virtio/network/if_vtnet.c:2188
 2nd 0x81a4e960 in6_multi_sx (in6_multi_sx, sx) @ 
/usr/src/sys/netinet6/in6_mcast.c:1219
lock order vtnet0-rx0 -> in6_multi_sx attempted at:
#0 0x80bc44e3 at witness_checkorder+0xbb3
#1 0x80b5d392 at _sx_xlock+0x62
#2 0x80d79341 at in6_joingroup+0x31
#3 0x80d70d2b at in6_update_ifa+0xfdb
#4 0x80d9c5b9 at in6_ifadd+0x1d9
#5 0x80d98d3f at nd6_ra_input+0x103f
#6 0x80d6b3f8 at icmp6_input+0x898
#7 0x80d838a3 at ip6_input+0xcc3
#8 0x80ca72dd at netisr_dispatch_src+0xad
#9 0x80c88e6a at ether_demux+0x17a
#10 0x80c8a492 at ether_nh_input+0x392
#11 0x80ca72dd at netisr_dispatch_src+0xad
#12 0x80c892b9 at ether_input+0xd9
#13 0x8097ba03 at vtnet_rxq_eof+0x7c3
#14 0x8097b19a at vtnet_rx_vq_process+0x9a
#15 0x80b0c286 at ithread_loop+0x276
#16 0x80b08730 at fork_exit+0x80
#17 0x81020d8e at fork_trampoline+0xe


lock order reversal:
 1st 0xfe00014d3a10 tcphash (tcphash, sleep mutex) @ 
/usr/src/sys/netinet/tcp_usrreq.c:1512
 2nd 0x81a4e9c0 in6_ifaddr_lock (in6_ifaddr_lock, rm) @ 
/usr/src/sys/netinet6/in6_src.c:305
lock order tcphash -> in6_ifaddr_lock attempted at:
#0 0x80bc44e3 at witness_checkorder+0xbb3
#1 0x80b4b11f at _rm_rlock_debug+0x12f
#2 0x80d8011f at in6_selectsrc+0x44f
#3 0x80d7fc80 at in6_selectsrc_socket+0x40
#4 0x80d7dbc7 at in6_pcbconnect+0x247
#5 0x80d61b33 at tcp6_connect+0xa3
#6 0x80d5f4e4 at tcp6_usr_connect+0x304
#7 0x80c009af at soconnectat+0xaf
#8 0x80c07aa1 at kern_connectat+0xe1
#9 0x80c07995 at sys_connect+0x75
#10 0x8104d6c0 at amd64_syscall+0x140
#11 0x8102063b at fast_syscall_common+0xf8


--
Bjoern A. Zeeb r15:7

connection loss related to ndp?

[Bjoern A. Zeeb]

Hi,

I am on 14-CUREENT (6fa88a4ad35e from April) and I recently started to
experience something which looks like:

ping6 -n ff02::1%wlan0 works
ping6 -n host works

but ssh to host hangs.  Given this seemed to be periodic-ish and I only
always notice way after the facts I started to poke around and found:

ndp -P
ndp -R
rtsol wlan0

fixes things.


I've seen similar problems with NDP vs. routing table updates and
another rtsol call would not bring back the default route unless
ndp -R was run before and I wonder if these are connected.

Both have become a bit annoying problems on a day-to-day IPv6-only usage
for me that I had never experienced like this (in the last decade) before.

If anyone has ideas and saves me from spending too many hours digging
into this now I'd appreciate.

/bz

--
Bjoern A. Zeeb r15:7

LoR tcphash -> in6_ifaddr_lock

[Bjoern A. Zeeb]

where does this one come from these days?

lock order reversal:
 1st 0xfe0002305a10 tcphash (tcphash, sleep mutex) @ 
/usr/src/sys/netinet/tcp_usrreq.c:1477
 2nd 0x81a5b9d0 in6_ifaddr_lock (in6_ifaddr_lock, rm) @ 
/usr/src/sys/netinet6/in6_src.c:305
lock order tcphash -> in6_ifaddr_lock attempted at:
#0 0x80bc92c3 at witness_checkorder+0xbb3
#1 0x80b503df at _rm_rlock_debug+0x12f
#2 0x80d84c2f at in6_selectsrc+0x44f
#3 0x80d84790 at in6_selectsrc_socket+0x40
#4 0x80d826f7 at in6_pcbconnect+0x247
#5 0x80d66813 at tcp6_connect+0xa3
#6 0x80d641f4 at tcp6_usr_connect+0x304
#7 0x80c057ff at soconnectat+0xaf
#8 0x80c0c8f1 at kern_connectat+0xe1
#9 0x80c0c7e5 at sys_connect+0x75
#10 0x81051760 at amd64_syscall+0x140
#11 0x81023e1b at fast_syscall_common+0xf8


--
Bjoern A. Zeeb r15:7

Re: Bind fails in jail with assigned IP address

[Bjoern A. Zeeb]

On Fri, 13 Jan 2023, Matthew Seaman wrote:


On 08/01/2023 18:52, Steffen Christgau wrote:

ip4.addr
A list of IPv4 addresses assigned to the jail.  If this is set, the jail 
is restricted to using only these addresses. [...] Attempts to use


I think someone needs to add the word "unicast" to these sentences.

In classic plain old IP jails there is no MC support.  You need, as
Matthew points out below, a vnet enabled jail for that.


wildcard addresses silently use the jailed address instead. For IPv4 the 
first address given will be used as the source address when

source address selection on unbound sockets cannot find a better match.
The effect of the silently changed wildcard address in my case is that the 
changed address prevents the required binding of the second/sending socket. 
This is inconsistent with the behavior outside a jail. Is this actually 
intended? If so, what can be done to bind both sockets to their required 
ports?


I also tried to set ip4.saddrsel = 1 in the jail config, but it appeared 
that nothing changed. If the IP address configuration is omitted for the 
jail, the service does not encounter the error of an address that is 
already in use.


If there is a solution to have the daemon run in a jail, I would be happy 
to discuss this. If jails are not suitable for this use case, let me know 
as well. 




Did you try using vnet style jails? These have their own, separate, loopback 
interface and a separate network interface, typically using epair(4) so you 
should avoid the silent rewriting of wildcard addresses that is causing you 
such difficulty.


See: https://wiki.freebsd.org/Jails/VNET
/usr/src/share/examples/jails/jib

Cheers,

Matthew




--
Bjoern A. Zeeb r15:7

Re: Import dhcpcd(8) into FreeBSD base

[Bjoern A. Zeeb]

  this is a partial integration of dhcpcd, which prevents some useful
  feature available in the master mode, and some complexity remains in
  the rc.d scripts.  I think these are a trade-off.  I am interested in
  whether this integration has a big problem when people use the
  imported dhcpcd.

  And probably we have to revisit this integration when we want to
  support DHCP 4o6 or something that involves IPv4 and IPv6 at the same
  time.  The flexibility of the "toolbox" approach would be helpful in
  minimizing the impact on the existing configurations when more future
  integration change occurs.


Agreed. I noted my concerns above and would favour a full blown dhcpcd 
configuration for new installs and leave the current dhclient/rtsold for 
exising installs. No need to force people to move.


I think that is a very sensible approach to do it incrementally.

If people can agree on
(1) importing it and first closing the gap of the missing DHCPv6 client making
sure it does all people have accumultaed over the years,
(2) and then solving the "how do I disable dhclient and rtsold and per-IF 
configs
and just run the-one-thing as an alternative in rc" in the 2nd step

I would think that will (a) reduce resistance and (b) give more time to test
and try for people, especially in 14 but it would (c) also be backward cmpatible
with 13 and thus smoothen (and possibly accelerate) any possible transition
and could possibly be MFCed even to provide (integrated) DHCPv6 there as well.

And I am not saying that (2) couldn't follow within days or weeks of (1).  I am 
just
saying that I'd prefer it to be seen as a distinct problem.

Then the next questions would be if or when to flip the default and as indecated
before and above if/when to remove the current state of art but if we take a 
step
at a time we'll probably save ourselves a lot of discussion and can move 
forward?

My 0.001ct
/bz

--
Bjoern A. Zeeb r15:7

vtnet may sleep with the following non-sleepable locks held

[Bjoern A. Zeeb]

Hi,

not sure if the problem is from f0d8d352c06ff or older or newer in fact.
I see this when enabled IPv6 on vtnet on main with GENERIC and do a rtsol 
vtnet0:

Invoking IPv6 network device address event may sleep with the following 
non-sleepable locks held:
exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xf80001793480) locked 
@ /main_clean_for_test/sys/dev/virtio/network/if_vtnet.c:2198
stack backtrace:
#0 0x80c80405 at witness_debugger+0x65
#1 0x80c8155a at witness_warn+0x3ea
#2 0x80e2263d at in6_update_ifa+0xd7d
#3 0x80e4db5d at in6_ifadd+0x1fd
#4 0x80e4a0a8 at nd6_ra_input+0xfb8
#5 0x80e1d01b at icmp6_input+0x76b
#6 0x80e351bf at ip6_input+0xc2f
#7 0x80d5cd9f at netisr_dispatch_src+0xaf
#8 0x80d3f03e at ether_demux+0x16e
#9 0x80d406cc at ether_nh_input+0x3fc
#10 0x80d5cd9f at netisr_dispatch_src+0xaf
#11 0x80d3f509 at ether_input+0x99
#12 0x80a3d1c3 at vtnet_rxq_eof+0x763
#13 0x80a3c9b7 at vtnet_rx_vq_process+0x97
#14 0x80bc91a9 at ithread_loop+0x279
#15 0x80bc5840 at fork_exit+0x80
#16 0x810c3cae at fork_trampoline+0xe
lock order reversal: (sleepable after non-sleepable)
 1st 0xf80001793480 vtnet0-rx0 (vtnet0-rx0, sleep mutex) @ 
/main_clean_for_test/sys/dev/virtio/network/if_vtnet.c:2198
 2nd 0x81fb1ec8 in6_multi_sx (in6_multi_sx, sx) @ 
/main_clean_for_test/sys/netinet6/in6_mcast.c:1193
lock order vtnet0-rx0 -> in6_multi_sx attempted at:
#0 0x80c7ffcd at witness_checkorder+0xbdd
#1 0x80c19093 at _sx_xlock+0x63
#2 0x80e2b451 at in6_joingroup+0x31
#3 0x80e229d8 at in6_update_ifa+0x1118
#4 0x80e4db5d at in6_ifadd+0x1fd
#5 0x80e4a0a8 at nd6_ra_input+0xfb8
#6 0x80e1d01b at icmp6_input+0x76b
#7 0x80e351bf at ip6_input+0xc2f
#8 0x80d5cd9f at netisr_dispatch_src+0xaf
#9 0x80d3f03e at ether_demux+0x16e
#10 0x80d406cc at ether_nh_input+0x3fc
#11 0x80d5cd9f at netisr_dispatch_src+0xaf
#12 0x80d3f509 at ether_input+0x99
#13 0x80a3d1c3 at vtnet_rxq_eof+0x763
#14 0x80a3c9b7 at vtnet_rx_vq_process+0x97
#15 0x80bc91a9 at ithread_loop+0x279
#16 0x80bc5840 at fork_exit+0x80
#17 0x810c3cae at fork_trampoline+0xe


--
Bjoern A. Zeeb r15:7

Re: epoch callback panic

[Bjoern A. Zeeb]

On 1 Apr 2022, at 20:51, Peter Holm wrote:


On Fri, Apr 01, 2022 at 10:33:15PM +0200, Hans Petter Selasky wrote:

On 4/1/22 19:07, Peter Holm wrote:

markj@ asked me to post this one:

panic: rw lock 0xf801bccb1410 not unlocked
cpuid = 4
time = 1648770125
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe00e48a3d10

vpanic() at vpanic+0x17f/frame 0xfe00e48a3d60
panic() at panic+0x43/frame 0xfe00e48a3dc0
_rw_destroy() at _rw_destroy+0x35/frame 0xfe00e48a3dd0
in_lltable_destroy_lle_unlocked() at 
in_lltable_destroy_lle_unlocked+0x1a/frame 0xfe00e48a3df0

epoch_call_task() at epoch_call_task+0x13a/frame 0xfe00e48a3e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa7/frame 
0xfe00e48a3ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame 
0xfe00e48a3ef0

fork_exit() at fork_exit+0x80/frame 0xfe00e48a3f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e48a3f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---

Details @ https://people.freebsd.org/~pho/stress/log/log0275.txt



Hi,

Maybe you need to grab the lock before destroying it?



This was on a pristine main-n254137-31190aa02eef0.


If there was no other emory corruption and my memory serves me right, 
la_flags = 0x1 was LLE_DELETED which gives a good hint on the call path.


If I had to bet it’s coming out of the 2nd condition in 
in_scrubprefixlle ... I’d check lltable_delete_addr .. and so on ..


/bz

Re: epair and vnet jail loose connection.

[Bjoern A. Zeeb]

On 13 Mar 2022, at 17:45, Michael Gmelin wrote:

On 13. Mar 2022, at 18:16, Bjoern A. Zeeb 
 wrote:


On 13 Mar 2022, at 16:33, Michael Gmelin wrote:

It's important to point out that this only happens with kern.ncpu>1.
With kern.ncpu==1 nothing gets stuck.

This perfectly fits into the picture, since, as pointed out by 
Johan,

the first commit that is affected[0] is about multicore support.


Ignore my ignorance, what is the default of net.isr.maxthreads and 
net.isr.bindthreads (in stable/13) these days?




My tests were on CURRENT and I’m afk, but according to cgit[0][1], 
max is 1 and bind is 0.


Would it make sense to repeat the test with max=-1?


I’d say yes, I’d also bind, but that’s just me.

I would almost assume Kristof running with -1 by default (but he can 
chime in on that).



Best
Michael

[0] https://cgit.freebsd.org/src/tree/sys/net/netisr.c#n280
[1] 
https://cgit.freebsd.org/src/tree/sys/net/netisr.c?h=stable%2F13#n280

Re: epair and vnet jail loose connection.

[Bjoern A. Zeeb]

On 13 Mar 2022, at 16:33, Michael Gmelin wrote:

It's important to point out that this only happens with kern.ncpu>1.
With kern.ncpu==1 nothing gets stuck.

This perfectly fits into the picture, since, as pointed out by Johan,
the first commit that is affected[0] is about multicore support.


Ignore my ignorance, what is the default of net.isr.maxthreads and 
net.isr.bindthreads (in stable/13) these days?


/bz

Re: epair and vnet jail loose connection.

[Bjoern A. Zeeb]

On Thu, 10 Mar 2022, Wolfgang Zenker wrote:

Hi,


I did do a  hey -h2 -n 10 -c 10 -z 60s https://wp.test.nl to that machine and in 
the 60 seconds the jail became unresponsive. Then i did run the dtrace.sh script 
above like so /root/bin/dtrace.sh > /root/dtrace_output

I hope this helps, if you need anything please let me know. Also root access is 
possible if you want. That way you do not have to create a test environment.



Were there other epair interfaces running at this time, with active traffic?



The dtrace output appears to show that the appropriate callouts (to 
epair_tx_start_deferred()) are getting through, so I’d expect traffic to be 
flowing.


There is one second jail using epair on that system, using the same
bridge as well. This second jail is a low-traffic system, it is unlikely
but possible that there was some traffic during that time.


Were you bridging or routing?  I seem to remember if_bridge being
loaded from loader?  So you'll always have some broad-/multi-cast.



In all previous cases this second jail continued to be reachable all
the time.


I don't know the latest incarnations of epair code very well anymore.
I'd probably go and look at stats (netstat etc) for the interface and
possibly protocols as well before restarting the jail;  check if there
are packets queued, dropped exacessively or if the in/out packet
coutners are still increasing (on both sides)?

I'd probably also run a tcpdump then on both sides of the epair to see
if packets are still arriving on one side and not the other?

And if it is a bridging setup, I wonder if taking that out of the
picture (you could remove the epair end from the bridge, put an
address on it and send a ff02::1 mc ping6 or something) and see.

Also does setting the epairs down/up (on both ends) make any
differences?

I am basically trying to narrow things down, as restarting entire
jails and with that a network stack is a lot more changes than just
epair.

/bz

--
Bjoern A. Zeeb r15:7

Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

[Bjoern A. Zeeb]

On Sun, 5 Dec 2021, Lutz Donnerhacke wrote:


On Sun, Dec 05, 2021 at 08:20:08PM +0200, John Hay wrote:

Something I have observed is that if you use FreeBSD 13 as a router with 2
subnets on the same interface, it will generate redirects when hosts send
packets to the other subnet via the FreeBSD router. I think it is wrong.


No, it's correct.


The host does not have a more direct way to get to the other subnet.


The other host can arp for an address in a non-connected network on the
interface because it's the same L2 domain. Hence the ICMP redirect is send
out to provide the shortcut (skipping the router).


That has always be a very Linux-y approach;  FreeBSD should not ARP
for any subnet it is not connected to (at least it didn't use to).

I think you could add a host route in the past and then it would but
with the current IPv4 I couldn't even say from quickly looking what it
would do.



RFC792
on page 13 does not talk about interfaces, but networks, "If G2 and the
host identified by the internet source address of the datagram are on the
same network...".


"network" == "layer 2 domain".


No, no in this context;  it talks about about the "internet source
address of a datagram" and hence network == Layer 3 as that is where
internet addresses belong.   No one would phrase it anymore like this
these days but in those days ...

/bz

--
Bjoern A. Zeeb r15:7

Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

[Bjoern A. Zeeb]

On Sat, 4 Dec 2021, Bjoern A. Zeeb wrote:


On Sat, 4 Dec 2021, Kurt Jaeger wrote:

I can reproduce some of this problem in the lab:


Here's a fix https://reviews.freebsd.org/D33274 for HEAD.

/bz

--
Bjoern A. Zeeb r15:7

Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

[Bjoern A. Zeeb]

On Sat, 4 Dec 2021, Kurt Jaeger wrote:

I can reproduce some of this problem in the lab:

19:01:53.113623 02:16:b4:9a:e5:0a > 02:16:b4:9a:e5:0b, ethertype IPv4 (0x0800), 
length 126: (tos 0x0, ttl 64, id 56538, offset 0, flags [none], proto ICMP (1), 
length 112)
203.0.113.1 > 203.0.113.254: ICMP redirect 192.0.2.2 to host 0.0.0.0, 
length 92
 ^^^
(tos 0x0, ttl 1, id 48284, offset 0, flags [none], proto ICMP (1), 
length 84)

Now the above is one of the problems;  the other parts I'll get back to
you off-list first because it might not be a network stack problem in
first instance.

--
Bjoern A. Zeeb r15:7

Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

[Bjoern A. Zeeb]

On Sat, 4 Dec 2021, Kurt Jaeger wrote:


Hi!


10:20:16.889185 IP x.x.x..1 > y.y.y.1: ICMP redirect z.z.z.z to host 0.0.0.0, 
length 48


whoops.



This has been stopped by net.inet.ip.redirect=0 on rtr1, but my question is:

Why is rtr1 sending those multi-hop icmp redirects at all ?


Could you elaborate on:



(a) Do rtr1 or rtr2 have a default route or are they carrying a full DFZ
without default route?


rtr1 runs frr, has full route, either with or without default route.


If that makes no difference then something else is wrong.



rtr2 has only static routes, default points to rtr1.


Assumption: if both rtr2 and rtr1 are running 13 and not 12, rtr2
does have a default route and rtr1 has a full DFZ only and no
default route?


Seeo above.


(b) At the time this happens does rtr1 have a route to z.z.z.z ?
route -4 get z.z.z.z


Yes.


And that is not pointing back to the interface rtr2 is on but out
on an interface towards inet?

/bz

--
Bjoern A. Zeeb r15:7

Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?

[Bjoern A. Zeeb]

On Sat, 4 Dec 2021, Kurt Jaeger wrote:


Hi!

We (AS12502) recently upgraded one router from 12.2.x to 13.0.x. This
caused some surprising effect, with the router sending out
icmp redirects to 0.0.0.0 over multiple hops:

Example:

inet -- wan:rtr1:lan -- rtr2 -- wan:host
x.x.x.1y.y.y.1

host sends a packet to z.z.z.z and receives an icmp redirect from x.x.x.1
like this:

10:20:16.889185 IP x.x.x..1 > y.y.y.1: ICMP redirect z.z.z.z to host 0.0.0.0, 
length 48


whoops.


This has been stopped by net.inet.ip.redirect=0 on rtr1, but my question is:

Why is rtr1 sending those multi-hop icmp redirects at all ?


Could you elaborate on:

(a) Do rtr1 or rtr2 have a default route or are they carrying a full DFZ
without default route?

Assumption: if both rtr2 and rtr1 are running 13 and not 12, rtr2
does have a default route and rtr1 has a full DFZ only and no
default route?

(b) At the time this happens does rtr1 have a route to z.z.z.z ?
route -4 get z.z.z.z

/bz

--
Bjoern A. Zeeb r15:7

Re: LAN ure interface problem

[Bjoern A. Zeeb]

On 22 Oct 2021, at 14:00, Ludovit Koren wrote:


Hi,

I have installed FreeBSD 14.0-CURRENT #1 
main-n250134-225639e7db6-dirty

on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN
interface:

ure0 on uhub0
ure0:  
on usbus1

miibus0:  on ure0
rgephy0:  PHY 0 on miibus0
rgephy0: OUI 0x00e04c, model 0x, rev. 0
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
1000baseT-FDX, 1000baseT-FDX-master, auto

ue0:  on ure0
ue0: bpf attached
ue0: Ethernet address: 00:e0:4c:68:04:20


When there is bigger load on the interface, for example rsync of the 
big

directory, the carrier is lost. The only solution I found is to remove
and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did 
not

help. The output of the ifconfig:

ue0: flags=8843 metric 0 mtu 
1500


options=68009b
ether 00:e0:4c:68:04:20
inet 192.168.1.18 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX )
status: active
nd6 options=29

I do not know and did not find anything relevant, if the driver is 
buggy

or the hardware has some problems. Please, advice.


I found that issuing a usbconf reset usually helps to bring it back.

That said I have a machine with a port on a root hub directly and there 
it behaves a lot better compared to when I connect it to different port 
on the 2nd root hub with an intermediate uhub on the same machine.


/bz

Re: Iterating all VNETs from userspace application

[Bjoern A. Zeeb]

On 18 Oct 2021, at 4:46, Özkan KIRIK wrote:


Hi,

I'm trying to gather all even within jails/vnet interface stats which
interface type ifmd_data.ifi_type == IFT_ETHER (6) for bsnmpd. Related
function (not modified) is here:

https://github.com/freebsd/freebsd-src/blob/main/contrib/bsnmp/snmp_mibII/mibII.c#L926-L985

It's possible to add a filter interface type adding a line below line 
961:

if (mib.ifmd_data.ifi_type != IFT_ETHER) return;

I'm looking for a way to iterate VNET instances, but net/vnet.h is
only for kernel space.
VNET_LIST_RLOCK_NOSLEEP();
VNET_FOREACH(vnet_iter) {
CURVNET_SET(vnet_iter);
mib_refresh_iflist();
CURVNET_RESTORE();
}
VNET_LIST_RUNLOCK_NOSLEEP();
The code above not working in userspace.

Also I wonder that if it's possible to switch between jails. The
pseudo code I want to write:

JAIL_FOREACH(jail_iter) {
jail_attach(jail_iter);
mib_refresh_iflist();
jail_detach();
}

What is the right way to gather all interface stats ?


Have a look at libkvm;  I seem to remember adding vnet support.

/bz

Re: change to deprecate broadcast on host 0 of a subnet

[Bjoern A. Zeeb]

On 12 Sep 2021, at 15:25, Mike Karels wrote:

Long ago (4.2BSD), the IP broadcast address was the lowest address on 
a
network, the one with a host part of 0.  In RFC1122, the broadcast 
address

was standardized using a host part of all ones.  4.3BSD changed its
default, and made the broadcast address settable with ifconfig.  
However,
FreeBSD *still* broadcasts packets sent to the lowest address on a 
subnet.


I have a change in review to stop broadcasting the lowest address on a
subnet by default, but added a sysctl to revert to the current 
behavior.

I really doubt that anyone is still using a 0-based broadcast address.
This change allows host 0 on a subnet to be used as an assigned host
address, as long as the systems on that network support it (including
routers).  Linux already has this change.

The review is https://reviews.freebsd.org/D31861.  See also
https:/datatracker.ietf.org/draft-schoen-intarea-lowest-address/ and


I think it is:

https://datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/


some of the discussion in https://reviews.freebsd.org/D19316.

Comments are welcome on the review.  I will wait a couple of days
for comments before proceeding.  I am also interested in comments on
whether this should be MFC'ed to 13-stable after a suitable delay.


I would have even gone one further step back and put this under 
EXPERIMENTAL
in HEAD and wait until this draft has gone anywhere but with your sysctl 
I think

it is fine (from reading the email not the recent review).

I would prefer if the current behaviour stayed default (would also MFC 
better)

and then flip if this will indeed go anywhere.


My personal note on this is: it is riding a dead horse, driven by 
economics,
and it feels 30 year too late to still do this and change this historic 
behaviour.


/bz

Re: accept_rtadv

[Bjoern A. Zeeb]

On 27 Feb 2021, at 20:34, Doug Hardie wrote:




On Feb 27, 2021, at 11:06, Michael Gmelin  wrote:




On 27. Feb 2021, at 19:40, Doug Hardie  wrote:

On 27 February 2021, at 10:34, Michael Gmelin  
wrote:





On 27. Feb 2021, at 19:21, Doug Hardie  wrote:


On 27 February 2021, at 04:37, Michael Gmelin  
wrote:





On 27. Feb 2021, at 08:21, Doug Hardie  wrote:


From the Handbook:

32.9.2. Configuring IPv6
To configure a FreeBSD system as an IPv6 client, add these two 
lines to rc.conf:


ifconfig_rl0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"

This does not work.  I have in rc.conf:

ifconfig_bge0_ipv6="inet6 accept_rtadv"
ifconfig_ue0_ipv6="inet6 accept_rtadv"
ifconfig_ue1_ipv6="inet6 accept_rtadv"

On all three interfaces, ifconfig shows:
nd6 options=21

ACCEPT_RTADV is not listed and sure enough router advertisements 
are ignored.  I have to manually enter:

ifconfig bge0 ipv6 accept_rtadv
for each interface.  Then ifconfig shows:

nd6 options=23

and the interface now accepts router advertisements.  This is a 
bug, but I don't kn

ow if it's in the code or the handbook.


I just tried here on 12.2-p4 with em0 and it worked as expected. 
I do have ipv4 configured on that interface too though.


Do you have anything else in your rc.conf (especially any other 
ifconfig lines)?


If not, could you try adding

ifconfig_bge0="up"
etc.


### IPv6 Setup ###


Well, here you set "ifconfig_bge0_ipv6" to one value


ifconfig_bge0_ipv6="inet6 accept_rtadv"


And there you overwrite it with a new value


ifconfig_bge0_ipv6="inet6 fec2::210 prefixlen 64"


Therefore, the first line has no effect at all.

You can double check this by calling

 sysrc ifconfig_bge0_ipv6

Setting all things in one config setting might work (haven’t 
tried it myself), like in


 ifconfig_bge0_ipv6="inet6 fec2::210 prefixlen 64 accept_rtadv"

-m



ipv6_static_routes="lan1 lan2"
ipv6_route_lan1="fec1:: -prefixlen 64 fec2::205"
ipv6_route_lan2="fec2:: -prefixlen 64 fec2::205"

That is all associated with IPv6.  IPv4 is configured and used.

-- Doug


You are supposed to be able to sent multiple IP addresses on an 
interface and that generally works.  From the handbook, I get that 
the "ifconfig_rl0_ipv6="inet6 accept_rtadv" line causes the default 
link-local addresses to be configured and should set accept_rtadv.  
The other lines should just add additional IP addresses.  Logically, 
adding the accept_rtadv in each seems a bit much.  Although, that is 
the way it worked in FreeBSD 9.  That was documented in the handbook 
at that time.  Adding additional IP addresses should not clear any 
of the interface flags unless included in the command.




rc.conf is key value in general, the format is

  key=value1

If you write further done in the file

  key=differentvalue

the value of key will be "differentvalue", like the first line never 
existed. (This is unrelated to IPv6 or router advertisements, just 
the basic principle of rc.conf).


One way I used to configure things like that in the past was using 
one ifconfig__ipv6 line to set flags etc and then use 
ifconfig__aliases to set ip addresses.


Something like

  ifconfig_bge0_ipv6="inet6 accept_rtadv"
  ifconfig_bge0_aliases="inet6 fec2::210 prefixlen 64"

(I haven’t tried this, as I’m afk and typed it on the phone, 
which is a bit of a pita, and from the top of my head,so you would 
have to try/verify yourself).


-m


Ahh.  The handbook is needing a note about that.  There should be 
something similar to what was done for IPv4 where it shows adding 
additional addresses using:


Ifconfig_bge0_alias0 ...
Ifconfig_bge0_alias1 ...

That would be very helpful.  Thanks for the explinations.



aliases are address family independent;  you write =“inet 
192.0.2.17/24”  or =“inet6 2001:db8::2:17/64” as you wish.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FreeBSD does not reply to IPv6 Neighbor Solicitations

[Bjoern A. Zeeb]

On 4 Jan 2021, at 14:17, Lutz Donnerhacke wrote:


Victor Sudakov wrote:

Dear Colleagues,

Why could it be that a FreeBSD 12.2 host does not reply to ICMPv6
Neighbor Solicitations from the router?


Any ideas please?


Thank you for pointing this out.
I do have an similar effect, after upgrading, and you point me to a 
good

direction.
I'll investigate and report back.



I’d start by checking netstat -s -p icmp6 and netstat -s -p ip6  for 
any suspicious counter updates.


Another thing to do might be to turn on nd6 log/debugging by sysctl  
(sysctl net.inet6.icmp6.nd6_debug=0xff should do it) and keep an eye on 
the kernel messages.



/bz

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Panic in in6_joingroup_locked

[Bjoern A. Zeeb]

On 22 Oct 2020, at 22:10, Alexander V. Chernikov wrote:


21.10.2020, 23:05, "Ryan Stone" :

Today at $WORK we saw a panic due to a race between
in6_joingroup_locked and if_detach_internal. This happened on a
branch that's about 2 years behind head, but the relevant code in 
head

does not appear to have changed.

The backtrace of the panic was this:

panic: Fatal trap 9: general protection fault while in kernel mode
Stack: --
kernel:trap_fatal+0x96
kernel:trap+0x76
kernel:in6_joingroup_locked+0x2c7
kernel:in6_joingroup+0x46
kernel:in6_update_ifa+0x18e5
kernel:in6_ifattach+0x4d0
kernel:in6_if_up+0x99
kernel:if_up+0x7d
kernel:ifhwioctl+0xcea
kernel:ifioctl+0x2c9
kernel:kern_ioctl+0x29b
kernel:sys_ioctl+0x16d
kernel:amd64_syscall+0x327

We panic'ed here, because the memory pointed to by ifma has been 
freed

and filled with 0xdeadc0de:

https://svnweb.freebsd.org/base/head/sys/netinet6/in6_mcast.c?revision=365071=markup#l421

Another thread was in the process of trying to destroy the same
interface. It had the following backtrace at the time of the panic:

#0 sched_switch (td=0xfea654845aa0, newtd=0xfea266fa9aa0,
flags=) at /b/mnt/src/sys/kern/sched_ule.c:2423
#1 0x80643071 in mi_switch (flags=, newtd=0x0)
at /b/mnt/src/sys/kern/kern_synch.c:605
#2 0x80693234 in sleepq_switch (wchan=0x8139cc90
, pri=0) at /b/mnt/src/sys/kern/subr_sleepqueue.c:612
#3 0x806930c3 in sleepq_wait (wchan=0x8139cc90
, pri=0) at /b/mnt/src/sys/kern/subr_sleepqueue.c:691
#4 0x8063fcb3 in _sx_xlock_hard (sx=,
x=, opts=0, timo=0, file=,
line=) at
/b/mnt/src/sys/kern/kern_sx.c:936
#5 0x8063f313 in _sx_xlock (sx=0x8139cc90 ,
opts=0, timo=, file=0x80ba6d2a
"/b/mnt/src/sys/net/i
f_vlan.c", line=668) at /b/mnt/src/sys/kern/kern_sx.c:352
#6 0x807558b2 in vlan_ifdetach (arg=,
ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if_vlan.c:668
#7 0x80747676 in if_detach_internal (vmove=0, ifp=, ifcp=) at /b/mnt/src/sys/net/if.c:1203
#8 if_detach (ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if.c:1060
#9 0x80756521 in vlan_clone_destroy (ifc=0xf802f29dbe80,
ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if_vlan.c:1102
#10 0x8074dc57 in if_clone_destroyif (ifc=0xf802f29dbe80,
ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if_clone.c:330
#11 0x8074dafe in if_clone_destroy (name=) at
/b/mnt/src/sys/net/if_clone.c:288
#12 0x8074b2fd in ifioctl (so=0xfea6363806d0,
cmd=2149607801, data=, td=0xfea654845aa0) at
/b/mnt/src/sys/net/if.
c:3077
#13 0x806aab1c in fo_ioctl (fp=, 
com=
out>, active_cred=, td=, data=
) at /b/mnt/src/sys/sys/file.h:396
#14 kern_ioctl (td=0xfea654845aa0, fd=4, com=,
data=) at /b/mnt/src/sys/kern/sys_generic.c:938
#15 0x806aa7fe in sys_ioctl (td=0xfea654845aa0,
uap=0xfea653441b30) at /b/mnt/src/sys/kern/sys_generic.c:846
#16 0x809ceab8 in syscallenter (td=) at
/b/mnt/src/sys/amd64/amd64/../../kern/subr_syscall.c:187
#17 amd64_syscall (td=0xfea654845aa0, traced=0) at
/b/mnt/src/sys/amd64/amd64/trap.c:1196
#18 fast_syscall_common () at 
/b/mnt/src/sys/amd64/amd64/exception.S:505


Frame 7 was at this point in if_detach_internal

https://svnweb.freebsd.org/base/head/sys/net/if.c?revision=366230=markup#l1206

As you can see, a couple of lines up if_purgemaddrs() was called and
freed all multicast addresses assigned to the interface, which
destroyed the multicast address being added out from under
in6_joingroup_locked.

[sorry, re-posting in plain text]
I don't have a solution w.r.t. multicast locking spaghetti, but from 
looking into a code, it looks like that
extending network epoch to the whole in6_getmulti() would fix this 
panic?


would that introduce even more recursions?




I see two potential paths forward: either the wacky locking in
in6_getmulti() gets fixed so that we don't have to do the "drop the
lock to call a function that acquires that lock again" dance that
opens up this race condition, or we fix if_addmulti so that it adds 
an

additional reference to the address if retifma is non-NULL.

The second option would be a KPI change that would have a nasty side
effect of leaking the address if an existing caller wasn't fixed, but
on the other hand the current interface seems pretty useless if it
can't actually guarantee that the address you asked for will exist
when you get around to trying to manipulate it.

Does anybody have any thoughts on this?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to 
"freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPv6 behind NAT

[Bjoern A. Zeeb]

On 12 Sep 2020, at 15:42, Gordon Bergling wrote:


Hi,

does anyone know if it is possible to create an IPv6 tunnel via a 
tunnelbroker,
Hurricane Electric for example, if the system is behind a NAT 
connection?


See https://ipv6.he.net/certification/faq.php

Search for the section labeled “Tunnel Broker” and read the notes.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Ipv6 neighbor limit

[Bjoern A. Zeeb]

On 3 Sep 2020, at 12:48, Hans Petter Selasky wrote:

> On 2020-09-03 14:34, Cristian Cardoso wrote:
>> Hi
>> Would anyone know if there is any limit in the FreeBSD kernel for IPv6
>> neighbors? I checked the ndp documentation and found nothing, looking
>> at the return of the sysctl command I also did not find anything
>> explicit.
>>
>
> Hi,
>
> There is something called:
>
> sys/netinet/in.h:#define  IP_MAX_MEMBERSHIPS  4095
> sys/netinet6/in6.h:#defineIPV6_MAX_MEMBERSHIPS4095
>
> Is this what you are looking for?


Or more along the lines of  https://reviews.freebsd.org/D24035 ?

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Multicast issue, interface not leaving Mutlicast Group

[Bjoern A. Zeeb]

On 8 Aug 2020, at 12:31, Abelenda Diego wrote:


On Sat, 8 Aug 2020 12:54:37 +0200
Hans Petter Selasky  wrote:


On 2020-08-07 15:25, Abelenda Diego wrote:

Hello,

I have discovered that I had a multicast issue for years I did not 
know
about. I use a FreeBSD (opnsense) setup as router for my home 
network and
have igmpproxy for IPTV. Somehow everything seems to work, until I 
realized
that my ISP was making a DoS with multicast. It is pretty much what 
was

described years ago here:
https://forum.netgate.com/topic/62591/igmp-issues-causing-isp-to-perform-multicast-dos-on-my-pfsense/7.
But the solution of not using FreeBSD seem weird. So dug a lot 
learning
about Multicast IGMPv{2,3} etc in the process. Here is an abstract 
of what

I found:


Which version of FreeBSD is this (uname -a) ?

There has been some fixes in the multicast area from time to time, 
and
you should make sure you've got all the fixes incorporated in the 
kernel

you are using, typically by testing a kernel based on a -stable or
-current branch of FreeBSD.

--HPS



Hello,

This is opnsense, so it is not like I can change kernel as I want. 
Moreover the
kernel used by opnsense has some patches for stf 6rd support for 
example,

things like that.

Anyway, the kernel I use is:

FreeBSD $hostname 12.1-RELEASE-p7-HBSD FreeBSD 12.1-RELEASE-p7-HBSD #0 
 427d53bc125(stable/20.7)-dirty: Sun Jul 26 05:51:42 CEST 2020 
root@sensey64:/usr/obj/usr/src/amd64.amd64/sys/SMP  amd64


But from what you are asking, it seems you suggest my issue is kernel 
related
and in no way a userspace problem. So I cannot do anything to mitigate 
the

issue?

BTW I said reset the interface fixed the issue, but in fact, I need to 
reboot,

I found no way to clear the multicast group memberships.



Is this related to:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248512  and the there 
referenced other bugs?



/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Support for Intel AX200 WiFi 6 card

[Bjoern A. Zeeb]

On 26 Jul 2020, at 23:33, Kevin Oberman wrote:


Thanks! This is really great news!

One question though. The status report shows the iwl driver as 
supporting
"7k/8k/9k/22k" devices. In the insanity of product models vs. chip 
models

vs. marketing names, is the AX200 one of these?


Yes.  Basically all the cards which can do 11ac and are supported by 
iwlwifi on Linux.


I do have two AX200 I am testing with.

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Support for Intel AX200 WiFi 6 card

[Bjoern A. Zeeb]

On 26 Jul 2020, at 22:20, Kevin Oberman wrote:

Hi,

Can anyone comment on the state of support for this card? Just having 
it
work would be great even if the very nice WiFi 6 features are still 
down
the line a bit. It's just really hard to do anything with a laptop 
with no

WiFi connectivity.


https://www.freebsd.org/news/status/report-2020-04-2020-06.html#Intel-wireless-and-11ac-update

There’s no WiFi yet (also see 
https://lists.freebsd.org/pipermail/freebsd-wireless/2020-July/009233.html 
).


I wish I could give you a date sooner than later, I just cannot yet.  
Keep an eye on the wireless mailing list.



Best Regards,
Bjoern

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: somewhat reproducable vimage panic

[Bjoern A. Zeeb]

On 23 Jul 2020, at 9:02, Kristof Provost wrote:


On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote:

On 23 Jul 2020, at 8:09, Kristof Provost wrote:


On 23 Jul 2020, at 9:19, Kristof Provost wrote:

On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:

So, it's pretty easy to trigger, just attach a couple USB ethernet
adapters, in my case, they were ure, but likely any two spare 
ethernet

interfaces will work, and wire them back to back..


I’ve been able to trigger it using epair as well:

`sudo sh testinterfaces.txt epair0a epair0b`

I did have to comment out the waitcarrier() check.

I’ve done a little bit of digging, and I think I’m starting to 
see how this breaks.


This always affects the jailed vlan interfaces. They’re getting 
deleted, but the ifp doesn’t go away just yet because it’s still 
in use by the multicast code.

The multicast code does its cleanup in task queues,


Wow, did I miss that back then? Did I review a change and not notice? 
Sorry if that was the case.


Vnet teardown is blocking and forceful.
Doing deferred cleanup work isn’t a good idea at all.
I think that is the real problem here.

I’d rather have us fix this than putting more bandaids into the 
code.


Yeah, agreed. I think hselasky has a better fix: 
https://reviews.freebsd.org/D24914


I just saw his e-mail in a different thread.


That’ll probably work;  still, the deferred teardown work seems wrong 
to me;  I haven’t investigated;  the patch kind-of says exactly that 
as well: if “wait until deferred stuff is done” is all we are doing, 
why can we not do it on the spot then?


/bz

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: somewhat reproducable vimage panic

[Bjoern A. Zeeb]

On 23 Jul 2020, at 8:09, Kristof Provost wrote:


On 23 Jul 2020, at 9:19, Kristof Provost wrote:

On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:

So, it's pretty easy to trigger, just attach a couple USB ethernet
adapters, in my case, they were ure, but likely any two spare 
ethernet

interfaces will work, and wire them back to back..


I’ve been able to trigger it using epair as well:

`sudo sh testinterfaces.txt epair0a epair0b`

I did have to comment out the waitcarrier() check.

I’ve done a little bit of digging, and I think I’m starting to see 
how this breaks.


This always affects the jailed vlan interfaces. They’re getting 
deleted, but the ifp doesn’t go away just yet because it’s still 
in use by the multicast code.

The multicast code does its cleanup in task queues,


Wow, did I miss that back then? Did I review a change and not notice? 
Sorry if that was the case.


Vnet teardown is blocking and forceful.
Doing deferred cleanup work isn’t a good idea at all.
I think that is the real problem here.

I’d rather have us fix this than putting more bandaids into the code.

/bz

PS:  I love that you can repro this with epairs, means we can write a 
generic test code piece for this and commit it.



so by the time it gets around to doing that the ifp is already marked 
as dying and the vnet is gone.
There are still references to the ifp though, and when the multicast 
code tries to do its cleanup we get the panic.


This hack stops the panic for me, but I don’t know if this is the 
best solution:


diff --git a/sys/net/if.c b/sys/net/if.c
index 59dd38267cf..bd0c87eddf1 100644
--- a/sys/net/if.c
+++ b/sys/net/if.c
	@@ -3681,6 +3685,10 @@ if_delmulti_ifma_flags(struct ifmultiaddr 
*ifma, int flags)

ifp = NULL;
}
 #endif
+
+   if (ifp && ifp->if_flags & IFF_DYING)
+   return;
+
/*
	 	 * If and only if the ifnet instance exists: Acquire the address 
lock.

 */
diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c
index 39fc82c5372..6493e2a5bfb 100644
--- a/sys/netinet/in_mcast.c
+++ b/sys/netinet/in_mcast.c
@@ -623,7 +623,7 @@ inm_release(struct in_multi *inm)

/* XXX this access is not covered by IF_ADDR_LOCK */
CTR2(KTR_IGMPV3, "%s: purging ifma %p", __func__, ifma);
-   if (ifp != NULL) {
+   if (ifp != NULL && (ifp->if_flags & IFF_DYING) == 0) {
CURVNET_SET(ifp->if_vnet);
inm_purge(inm);
free(inm, M_IPMADDR);

Best regards,
Kristof

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: somewhat reproducable vimage panic

[Bjoern A. Zeeb]

On 22 Jul 2020, at 19:34, John-Mark Gurney wrote:

John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 
-0700:

Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200:

Is this related to

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 
 and 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 



Definitely not 234985..  I'm using ue interfaces, and so they don't
get destroyed while the jail is going away...

I don't think it's 238326 either.  This is 100% reliable and it's in
the IP multicast code..  It looks like in_multi isn't holding an
interface or address lock waiting for things to free up...


Did a little more poking, and it looks like the vnet is free'd before
the ifnet is free'd causing this problem:
(kgdb) print inm->inm_ifp[0].if_refcount
$5 = 1
(kgdb) print inm->inm_ifp[0].if_vnet[0]
$6 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = 
0xdeadc0dedeadc0de},

  vnet_magic_n = 3735929054, vnet_ifcnt = 3735929054,
  vnet_sockcnt = 3735929054, vnet_state = 3735929054,
  vnet_data_mem = 0xdeadc0dedeadc0de, vnet_data_base = 
16045693110842147038,

  vnet_shutdown = 222}

So the multicast code is fine, it holds and releases a reference to
ifnet..

The issue is that the reference to the ifnet doesn't involve a
reference to the vnet/prison.


Does it need to?  The ifnet cannot go away while something holds a 
reference to it, right?


Sounds more like the teardown order is wrong (again)?

There should be no more multicast when IP etc. is gone.  That means MC 
doesn’t properly cleanup itself.


I guess I should go back now and re-read your original problem statement 
on how you trigger this..


/bz


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: panic: starting DAD on non-tentative address 0xfffff800034a5800,

[Bjoern A. Zeeb]

On 3 Jun 2020, at 20:15, Alexander V. Chernikov wrote:


03.06.2020, 11:46, "Bjoern A. Zeeb" :

Hi,

got this with HEAD from a few days ago, just in case it rings a bell
with someone.
I'm curious what are the conditions. Was it the first "up" for the 
interface?
It looks like we're not locking anything in nd6_dad_timer, so 
potentially if one configures IPv6 address, waits for most of the dad 
timer, then do down/up, this can potentially happen.


I cannot really say.  I plugged an unsupported interface into USB;  
there were two other wifi dongles on the USB hub.  When I came back to 
the machine console later in the day, I found this.  Not sure if it was 
related.




Otherwise I’ll go investigate when it happens again; I’ll try to
setup netdump to get more information.

panic: starting DAD on non-tentative address 0xf800034a5800
cpuid = 1
time = 1500939739
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe003b65a690
vpanic() at vpanic+0x182/frame 0xfe003b65a6e0
panic() at panic+0x43/frame 0xfe003b65a740
nd6_dad_start() at nd6_dad_start+0x3bb/frame 0xfe003b65a7e0
in6_if_up() at in6_if_up+0x62/frame 0xfe003b65a820
if_up() at if_up+0x69/frame 0xfe003b65a850
ifhwioctl() at ifhwioctl+0xbf8/frame 0xfe003b65a8d0
ifioctl() at ifioctl+0x3ac/frame 0xfe003b65a9a0
kern_ioctl() at kern_ioctl+0x27b/frame 0xfe003b65aa00
sys_ioctl() at sys_ioctl+0x127/frame 0xfe003b65aad0
amd64_syscall() at amd64_syscall+0x140/frame 0xfe003b65abf0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe003b65abf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047cd8a, rsp =
0x7fffe258, rbp = 0x7fffe2b0 ---
KDB: enter: panic
[ thread pid 12247 tid 100088 ]
Stopped at kdb_enter+0x37: movq $0,0x10c9ad6(%rip)
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to 
"freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

panic: starting DAD on non-tentative address 0xfffff800034a5800,

[Bjoern A. Zeeb]

Hi,

got this with HEAD from a few days ago, just in case it rings a bell 
with someone.
Otherwise I’ll go investigate when it happens again;  I’ll try to 
setup netdump to get more information.



panic: starting DAD on non-tentative address 0xf800034a5800
cpuid = 1
time = 1500939739
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe003b65a690

vpanic() at vpanic+0x182/frame 0xfe003b65a6e0
panic() at panic+0x43/frame 0xfe003b65a740
nd6_dad_start() at nd6_dad_start+0x3bb/frame 0xfe003b65a7e0
in6_if_up() at in6_if_up+0x62/frame 0xfe003b65a820
if_up() at if_up+0x69/frame 0xfe003b65a850
ifhwioctl() at ifhwioctl+0xbf8/frame 0xfe003b65a8d0
ifioctl() at ifioctl+0x3ac/frame 0xfe003b65a9a0
kern_ioctl() at kern_ioctl+0x27b/frame 0xfe003b65aa00
sys_ioctl() at sys_ioctl+0x127/frame 0xfe003b65aad0
amd64_syscall() at amd64_syscall+0x140/frame 0xfe003b65abf0
fast_syscall_common() at fast_syscall_common+0x101/frame 
0xfe003b65abf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047cd8a, rsp = 
0x7fffe258, rbp = 0x7fffe2b0 ---

KDB: enter: panic
[ thread pid 12247 tid 100088 ]
Stopped at  kdb_enter+0x37: movq$0,0x10c9ad6(%rip)
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [PATCH] Implement the upcoming RFC4941bis (IPv6 SLAAC temporary addresses/privacy extensions)

[Bjoern A. Zeeb]

On 3 Apr 2020, at 1:55, Fernando Gont wrote:

Hi Fernando,

can you follow-up on 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245103 with your more 
complete patch so this is properly tracked?  I’ll be happy to deal 
with it the next days if no one else beats me to it.


/bz



Folks/Hiroki,

I've implemented the upcoming revision of RFC4941 
(https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-08) for 
FreeBSD.


The main changes are this:

* Reduce the Valid Lifetime from 1 week to 2 days. This effectively 
limits the number of concurrent temporary addresses per prefix to 2


* Use different interface-ids for each temporary address, to prevent 
correlation of network activity among temporary addresses 
corresponding to different prefixes.


P.S.: The patch is also available here: 




 cut here 
diff --git sys/netinet6/in6_ifattach.c sys/netinet6/in6_ifattach.c
index 91ef544d8b2..c093b53974a 100644
--- sys/netinet6/in6_ifattach.c
+++ sys/netinet6/in6_ifattach.c
@@ -87,7 +87,6 @@ VNET_DECLARE(struct inpcbinfo, ripcbinfo);
 #defineV_ripcbinfo VNET(ripcbinfo)

 static int get_rand_ifid(struct ifnet *, struct in6_addr *);
-static int generate_tmp_ifid(u_int8_t *, const u_int8_t *, u_int8_t 
*);
 static int get_ifid(struct ifnet *, struct ifnet *, struct in6_addr 
*);

 static int in6_ifattach_linklocal(struct ifnet *, struct ifnet *);
 static int in6_ifattach_loopback(struct ifnet *);
@@ -152,84 +151,6 @@ get_rand_ifid(struct ifnet *ifp, struct in6_addr 
*in6)

return 0;
 }

-static int
-generate_tmp_ifid(u_int8_t *seed0, const u_int8_t *seed1, u_int8_t 
*ret)

-{
-   MD5_CTX ctxt;
-   u_int8_t seed[16], digest[16], nullbuf[8];
-   u_int32_t val32;
-
-   /* If there's no history, start with a random seed. */
-   bzero(nullbuf, sizeof(nullbuf));
-   if (bcmp(nullbuf, seed0, sizeof(nullbuf)) == 0) {
-   int i;
-
-   for (i = 0; i < 2; i++) {
-   val32 = arc4random();
-   bcopy(, seed + sizeof(val32) * i, sizeof(val32));
-   }
-   } else
-   bcopy(seed0, seed, 8);
-
-   /* copy the right-most 64-bits of the given address */
-   /* XXX assumption on the size of IFID */
-   bcopy(seed1, [8], 8);
-
-   if (0) {/* for debugging purposes only */
-   int i;
-
-   printf("generate_tmp_ifid: new randomized ID from: ");
-   for (i = 0; i < 16; i++)
-   printf("%02x", seed[i]);
-   printf(" ");
-   }
-
-   /* generate 16 bytes of pseudo-random value. */
-   bzero(, sizeof(ctxt));
-   MD5Init();
-   MD5Update(, seed, sizeof(seed));
-   MD5Final(digest, );
-
-   /*
-* RFC 3041 3.2.1. (3)
-* Take the left-most 64-bits of the MD5 digest and set bit 6 (the
-* left-most bit is numbered 0) to zero.
-*/
-   bcopy(digest, ret, 8);
-   ret[0] &= ~EUI64_UBIT;
-
-   /*
-* XXX: we'd like to ensure that the generated value is not zero
-* for simplicity.  If the caclculated digest happens to be zero,
-* use a random non-zero value as the last resort.
-*/
-   if (bcmp(nullbuf, ret, sizeof(nullbuf)) == 0) {
-   nd6log((LOG_INFO,
-   "generate_tmp_ifid: computed MD5 value is zero.\n"));
-
-   val32 = arc4random();
-   val32 = 1 + (val32 % (0x - 1));
-   }
-
-   /*
-* RFC 3041 3.2.1. (4)
-* Take the rightmost 64-bits of the MD5 digest and save them in
-* stable storage as the history value to be used in the next
-* iteration of the algorithm.
-*/
-   bcopy([8], seed0, 8);
-
-   if (0) {/* for debugging purposes only */
-   int i;
-
-   printf("to: ");
-   for (i = 0; i < 16; i++)
-   printf("%02x", digest[i]);
-   printf("\n");
-   }
-
-   return 0;
-}

 /*
  * Get interface identifier for the specified interface.
@@ -798,58 +719,15 @@ in6_ifdetach_destroy(struct ifnet *ifp)
_in6_ifdetach(ifp, 0);
 }

-int
-in6_get_tmpifid(struct ifnet *ifp, u_int8_t *retbuf,
-const u_int8_t *baseid, int generate)
-{
-   u_int8_t nullbuf[8];
-   struct nd_ifinfo *ndi = ND_IFINFO(ifp);
-
-   bzero(nullbuf, sizeof(nullbuf));
-   if (bcmp(ndi->randomid, nullbuf, sizeof(nullbuf)) == 0) {
-   /* we've never created a random ID.  Create a new one. */
-   generate = 1;
-   }
-
-   if (generate) {
-   bcopy(baseid, ndi->randomseed1, sizeof(ndi->randomseed1));
-
-   /* generate_tmp_ifid will update seedn and buf */
-   (void)generate_tmp_ifid(ndi->randomseed0, ndi->randomseed1,
-   ndi->randomid);
-   }
-   

Re: IPv6 in jails

[Bjoern A. Zeeb]

On 19 Mar 2020, at 2:14, Victor Sudakov wrote:


If it does, can you add a

exec.start += "sleep  2 ";

to your config


OK, I've added it to the configs of 3 experimental jails.


and see if your problem goes away?


It goes away partially (only for sshd in 2 of the 3 available jails), 
and
not for syslogd in any of the 3 available jails. Restarting the 
daemons
from within the jail fixes the problem. An example from a problem 
jail:



..



If it does, the reason is
that you configure an IPv6 address to an interface and DUD has not 
yet
completed by the time sshd or other daemons start.  Giving it the 2 
seconds

avoids this problem and the address is usable at that time.


There is obviously a race somewhere, but the 2 second sleep does not
eliminate it entirely.


Well not so much of a race but than a “gap”.

The point is you are configuring an address on the base system and the 
jail knows nothing about it so it’ll simply start the daemons.  
Normally the startup scripts would do the right thing.


I don’t think “polluting” jail(8) with logic to check that the 
addresses become available or not is a good idea.  However I agree that 
it should automatically do the right thing somehow ..





Thank you for the hint in the right direction, what would you suggest
further?


If you make it 3 seconds, does it deterministically work then?



/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPv6 in jails

[Bjoern A. Zeeb]

On 18 Mar 2020, at 15:50, Victor Sudakov wrote:

If sshd in the host is configured to listen on all available 
interfaces and

addresses (the default) then it will catch your jails IP too.


Why is it not catching the 192.168.4.204 address then?

You must configure sshd in the host to listen only on hosts IP and 
then you

will connect to the jails sshd.


OK, I've stopped the sshd on the host entirely, and restarted the 
jails.

Why am I still not seeing the jailed sshd listening on tcp6?


Can you check the logfile inside the jail and see if it complains?

Can you then do a jexec test4 and run service sshd restart and see if it 
starts working?   If it does, can you add a


exec.start += "sleep  2 ";

to your config and see if your problem goes away?  If it does, the 
reason is that you configure an IPv6 address to an interface and DUD has 
not yet completed by the time sshd or other daemons start.  Giving it 
the 2 seconds avoids this problem and the address is usable at that 
time.




Your theory is probably incorrect.


The theory is incorrect.   The jail will always take precedence (at 
least since the multi-IP jail patches in 2008).



/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPv6 in jails

[Bjoern A. Zeeb]

On 18 Mar 2020, at 15:15, Victor Sudakov wrote:


Dear Colleagues,

Is IPv6 in jails supposed to work? Does not work for me, what am I 
doing

wrong?

Here is a test jail:

test4 {
path = /d02/jails/test4 ;
mount.devfs;
ip4 = new;
ip6 = new;
ip4.addr = 192.168.4.204/24;
ip6.addr = 2001:470:ecba:3::4/64;


I usually do something like this:

ip6.addr += "lo0|2001:db8:1234:5678::ef/128";

to add the single address out of a /64 to the loopback interface on the 
host and then pass it through to the jail.  The /64 however is actually 
routed to my host so might not work if you have the /64 on the physical 
interface.


Given it is a jail without vnet you cannot assign a /64 to the jail, you 
want to just specify the address usually (plainly or as /128).




host.hostname = test4.vas.sibptus.ru ;
interface = re1 ;
allow.raw_sockets = true ;
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
}

However when I look from inside the jail, I see the daemons listening
only on IPv4:

root@test4:/ # sockstat -l
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN 
ADDRESS

root sendmail   17178 3  tcp4   192.168.4.204:25  *:*
root sshd   17175 3  tcp4   192.168.4.204:22  *:*
root syslogd17110 5  udp4   192.168.4.204:514 *:*

If I "ssh 2001:470:ecba:3::4" from outside, I get into the host 
instead

of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not
available inside the jail).


One thing to check first is ifconfig inside the jail does see the 
address?



/bz

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPv6, SLAAC, routing in iocage jail

[Bjoern A. Zeeb]

On 8 Jan 2020, at 14:08, Patrick M. Hausen wrote:


Hi,

Am 08.01.2020 um 14:50 schrieb Bjoern A. Zeeb 
:

https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/


Try replacing the

# KEYWORD: nojail

with

# KEYWORD: nojailvnet

in /etc/rc.d/netoptions.


Found and understood - I will give it a try later today and report 
back.


May I remark that the semantics of "nojail" vs. "nojailvnet" are a 
*bit* confusing?


	Determine if booting in a jail, and add "nojail" (no jails allowed) 
or "nojailvnet"
	(only allow vnet-enabled jails) to the list of KEYWORDS to skip in 
rcorder(8).


Shouldn't the latter be named "onlyjailvnet" or some such? Naming 
things ... ;-)


I have to say I had to look things up myself as I was confused.  I’ve 
not been involved in these things before.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPv6, SLAAC, routing in iocage jail

[Bjoern A. Zeeb]

On 8 Jan 2020, at 11:57, Patrick M. Hausen wrote:


Hi all,

does anyone in this list have an idea if this behaviour is to be 
expected?


I assume it is not in any way FreeNAS specific, of course. Might be an
iocage artefact, though.

https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/


Try replacing the

# KEYWORD: nojail

with

# KEYWORD: nojailvnet

in /etc/rc.d/netoptions . I don’t know why its the one or other 
currently and if the other keyword is good for the entire file, but if 
this change helps you that can be sorted out.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FreeBSD as multicast router

[Bjoern A. Zeeb]

On 8 Nov 2019, at 22:55, Mike Karels wrote:

> They are already exported via sysctl, and fetched that way on a live
> system.  But netstat was stupidly insisting that _mrtstats have a value
> in the namelist first.

Oh DOH!

> That is not true if ip_mroute was loaded as a
> module, and also if VNET was defined.  The fix is not to complain or quit
> unless sysctl fails, or if operating on a core file and _mrtstat is
> not found.
>
> When I'm happy with the patch, I'll put it in review.

Great; sign me up for review.


> I haven't checked
> yet how other functions deal with VNET (if at all) in a core file.

libkvm knows about vnets to some extend.  The answer probably is “badly”.

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FreeBSD as multicast router

[Bjoern A. Zeeb]

On 8 Nov 2019, at 7:30, Mike Karels wrote:


P.S. I rebuild kernel with MROUTING option but
=
# netstat -gs -f inet
No IPv4 MROUTING kernel support
=



still here


Oh, I see; that's another manifestation of the bug that makes netstat
fail with the loadable module.  It doesn't work if VNET is defined,
because then there isn't a single stats structure with the expected
name.  My fixed netstat would work.  Let me know what FreeBSD version
you are running, and I can build a fixed version; or I can send a 
patch.


How did you fix netstat?

The proper way to fix this seems to be to stop using lkvm for querying 
the stats and properly exporting them in the kernel.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: DHCPv6 client in base

[Bjoern A. Zeeb]

On 14 Oct 2019, at 23:04, Ben Woods wrote:


Whilst I don’t have anything against wide-dhcp, I personally prefer
integrated IPv4/IPv6 tools. ping vs ping6 for example would be better
integrated in my opinion.


I have a totally different opinion on this.  I prefer to have a tool 
that does one job. K.I.S.S.


In addition I consider IPv4 dead.  Let it die.  Stop thinking IPv4.  
Don’t screw the users over on the way out of the protocol by making 
changes to how things worked for a decade or two or three in the last 
minute.  Never change a running system.


If you want to touch IPv4 along, I am out on the IPv6 change.

Further I really, very soon, want to get rid of more IPv4 code for a lot 
of systems I am building as less code less attack surface.  We started 
compiling INET out in 2011 in addition to INET6.  I have a way more 
eager hobby project at the moment which does remove IPv4 entirely from 
the tree.  I do that by splattering more #ifdef code around all IPv4 
code I can find and then remove it. (two step needed to be able to 
merge-track FreeBSD still).  I can tell you even just doing that for 
libc is a pain.  If it takes us another 6-8 years until the rest of the 
world gets there, I’ll be happy (very much like it took the world to 
get to the IPv6-only discussions we have everywhere actively these 
days).





The “feature” that I believe is missing from wide-dhcp is active
maintenance.


I am not sure but I’d assume that’s a lot also to the fact of its 
current state as to where it is living.  If it were in head with a bit 
of infrastructure and not as a “import from upstream” project I 
think some people might “commit to it” a lot more.




I do agree that we should minimise excess code in FreeBSD also, but I
believe that once dhcpcd has been proven to work, we could look at 
removing
dhclient and rtsold. Agree with your comment that before this occurs, 
we
should check what features / security improvements / tighter 
integration
have been added along the way, and ensure they make their way into 
dhcpcd.


If dhcpcd was imported, I believe this would come with a phased 
approach:

- import dhcpcd, but leave dhclient and rtsold as default


- Make sure all the security concerns are rooted out.
- Update documentation, handbook, samples, ..   and educate our users.


- add kernel support for tighter dhcpcd integration
- switch defaults to dhcpcd, but leave dhclient and rtsold as 
available

- remove dhclient and rtsold


If you really want a proper smooth transition you probably need at least 
one major release overlap and that’s half a decade of maintaining two 
software sets.


/bz



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: VLAN+bridge problem [was: no network between jails and host with VNET on same interface]

[Bjoern A. Zeeb]

On 27 Sep 2019, at 13:31, Alexander N. Lunev via freebsd-net wrote:


Hello everyone!

I have a strange connectivity problem on jails with VNET networking.

I've deployed a jail system with VNET networking on a server with 
FreeBSD 12.0-RELEASE-p10. Jails are working fine, can reach out outer 
network and each other, but there's no connectivity between host and 
jails.


Server is connected to switch trunk port by igb1 interface, which is 
bridged with epairXa interfaces in bridge0, while jails using epairXb 
interfaces (they are renamed to jail0 in each jail to simplify 
things).



===  host =
[igb1]---\
   | +-+
 [vlan4 (10.1.1.247)]| |
 | bridge0 |
 /--[epair1a]| |
/+-+
| /-[epair0a]/
| |
=  jail1_filter2 ==
| \-[jail0(ex-epair0b)]
| |
| [vlan4 (10.1.1.26)]
=  jail2_noc ==
\-[jail0(ex-epair1b)]
|
[vlan4 (10.1.1.201)]
===


On the host and in every jail i have a vlan4 interface, and here's 
addresses for those vlan4 interfaces:


host@vlan4:  10.1.1.247
jail1_filter2@vlan4: 10.1.1.26
jail2_noc@vlan4: 10.1.1.201

Host can't ping jails, but can ping outer world. Jails can ping each 
other and outer world, but not host - "ping: sendto: Host is down", 
there's no ARP entry for host' vlan4 address.


I've tried to add static arp entry for 10.1.1.247 in jails - with no 
success (arp is added, network still not working).


Host and both jails have firewall_type=OPEN configured.

What is wrong here?



I believe the problem here is not jail specific at all.  I’d assume, 
the same would happen in other scenarios where you bridge on the host to 
another interface.


I am assuming the VLAN interface output routine calls the igb1 output 
routine and the bridge never sees that packet but I haven’t looked at 
the vlan code in a long time.


My best guess would be to try to create the VLAN interface on the host 
upon the bridge and not upon the physical interface.  Can you try that 
and see if that works?



/bz





___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: rpc.statd already ipv6 clean?

[Bjoern A. Zeeb]

On 27 Sep 2019, at 21:52, Rick Macklem wrote:


Mihir Luthra wrote:

Hi Rick,
Rick wrote:
Although I'll admit it isn't something I am particularily fond of, 
FreeBSD likes

utilities to build/work with only one of ipv4/ipv6.
To do this, "#ifdef INET" and "#ifdef INET6" is applied to the code 
and the

Makefile is tweaked to define one or both of these.
(You can look at usr.sbin/nfsuserd for an example of this.)


Yes I see. Although I was thinking, wouldn't it be better if we can 
take a flag via >getopts for ipv6/ipv4 if the machine supports both 
with macro guards around >too?

bz@ is the guy to ask. I've cc'd him.


We are also exchanging private emails currently to sort out the 
confusion between “compiling out”, transport protocol, and 
addresses/protocol carried inside the (RPC) packets.


This is three different things and all should be sorted.  My work is 
mostly on the “compiling out” as I don’t want/need INET anymore 
mostly.  Ensuring that the transport protocol works dual-stack is a 
good, easier part.   For RPC and some others making sure to be able to 
not only transport IPv4 addresses in the payload protocol but also IPv6 
addresses can be the hard part.  I assume the latter is what you were 
referring to in the lines below?


Btw, these protocols are old Sun Microsystems ones without any 
published
RFC, so what is "correct" is difficult to determine. I suppose the 
Open
Solaris sources is the best protocol specification. (Interop. testing 
with Linux

would be nice, since Linux is the "defacto standard" now.)

Good luck with it, rick

Thanks for the tips,
Mihir

rick

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: rpc.statd already ipv6 clean?

[Bjoern A. Zeeb]

On 26 Sep 2019, at 15:25, Rick Macklem wrote:


Mihir Luthra wrote:

Hiroki Sato wrote:



 I think you should learn TI-RPC API first.  The nettype specifies a
 class of transport protocol, not address family.

Thanks, I did some more research on TI-RPC today.
In `statd.c` what I see is in 
`create_service()`/`complete_service()`,
transport info is being fetched through getnetconfig(), which makes 
it
listen on all transports. I guess its clean in `statd.c` but same can 
also
be done in `procs.c`/`file.c`. Maybe trying all transports until it 
finds
one which is connectionless? Apologies if I got something wrong, new 
to

this topic.

Also, while looking at the code, I think it always assumes ipv4 is 
always

present. Like `127.0.0.1` is added to host list always. On ipv6 only
machine this may fail.
Although I'll admit it isn't something I am particularily fond of, 
FreeBSD likes

utilities to build/work with only one of ipv4/ipv6.
To do this, "#ifdef INET" and "#ifdef INET6" is applied to the code 
and the

Makefile is tweaked to define one or both of these.
(You can look at usr.sbin/nfsuserd for an example of this.)


I am not sure if this is entirely on-topic but here’s a diff from a 
work-tree of mine from sometime earlier this year:


https://people.freebsd.org/~bz/20190926-01-golegacy.diff

This is a lot of resolver and rpc (libc) code.  I think this did compile 
but I am almost certain that a few changes are not doing the right thing 
and need review and testing.


I might have upstreamed 2 or 3 lines of this already in case the patch 
doesn’t apply cleanly anymore.


I’ll be more than happy to work with someone going through this as 
well and reviewing/updating it.  I can also put it into Phabricator; at 
the moment it only collects dust as I didn’t have time to work on this 
hobby project lately.


/bz





Btw, these protocols are old Sun Microsystems ones without any 
published
RFC, so what is "correct" is difficult to determine. I suppose the 
Open
Solaris sources is the best protocol specification. (Interop. testing 
with Linux

would be nice, since Linux is the "defacto standard" now.)

Good luck with it, rick

Kind Regards,
Mihir
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: addrs capability of rtadvd?

[Bjoern A. Zeeb]

On 17 Aug 2019, at 6:03, John-Mark Gurney wrote:


I am setting up ipv6, and going through the guide at:
https://www.freebsd.org/doc/handbook/network-ipv6.html#idp71931000

And noticed the addrs#1 property in the example.  I checked the
rtadvd.conf man page, and I do not see an entry for addrs.  Should
this be removed?  I also did a quick check of the rtadvd source code,
and I don't see a makeentry for addrs either.

If no one objects, I'll remove it.


Or replace it with a working example?  Would something like this work to 
even show multiple prefixes (beyond the handbook example)?


  :addr=“2001:db8:4242:::”:prefixlen#64:\
  :addr2="2001:db8:4242:1::”:prefixlen2#64:


And yes, removing the “:addrs#1” from the handbook should be fine.

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: In freshly installed 12i386 VM dhclient printed "No buffer space available"

[Bjoern A. Zeeb]

On 5 May 2019, at 19:06, Yuri wrote:

I just took the latest 12i386 ISO image, installed into a VM with 2GB 
memory, and got the "No buffer space available" from dhclient during 
the initial IPv4 network setup.


This should never happen, IMO.


Which NIC is this?  em0 or virtio?   I do see this on a Laptop with em0; 
 just wondering if this is an iflib problem?


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: use of #ifdef INET and #ifdef INET6 in the kernel sources

[Bjoern A. Zeeb]

On 28 Feb 2019, at 1:11, Rick Macklem wrote:


I thought (can't remember when/how I was told) that it was no longer
recommended to add
#ifdef INET
or
#ifdef INET6
to the kernel sources.


Not sure who said this.

I'll admit I think #ifdef'ng code when it isn't necessary to get it to 
build makes the

code less readable and, as such, I prefer not to do this.


We all agree on this.


So, is this still recommended for blocks of code that only execute for 
the version
of IP, but will build for kernels that do not have the particular 
"options INET{6}"

in the kernel config?


Yes.


If it is still recommended, I will do it, but I'll admit I don't 
understand why it should
be done? (All it does is reduce the size of the executable by a small 
amount and

that doesn't seem significant to me.)


That small amount is still relevant on some devices where people go to 
great lengths to fit our constantly growing base into a tiny small 
thingy.


And it allows you to lose code from your kernel that you don’t 
need/want, such as if you’d want to rip out all INET sources from a 
tree.


I know both of these groups still do exist.

Also every code not compiled in is not an attack surface, where you 
think it’s executed or not.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D5165: [patch] dev/bwn suppressing "bwn0: unsupported rate 0" console messages

[bz (Bjoern A. Zeeb)]

bz added a comment.


  Ok looks like bwi doesn't need.
  
  I don't know too much about bwn(4).
  Given we have hard coded mapping tables with a limited set of 'rates' 
according to bwn_hwrate2ieeerate() and bwn_ieeerate2hwrate() would it make 
sense to manually code a "one lower than this" table?  I cannot see where we 
set the custom (limited) list of rates.  bwn_addchannels() seems to add a lot 
more if I am not mistaken?

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D5165/new/

REVISION DETAIL
  https://reviews.freebsd.org/D5165

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: mugius.0x101.freebsd_gmail.com, #network, s3erios_gmail.com
Cc: bz, imp, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D5165: [patch] dev/bwn suppressing "bwn0: unsupported rate 0" console messages

[bz (Bjoern A. Zeeb)]

bz added a comment.


  Depending on the outcome here, it look like bwi will need similar treatment?

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D5165/new/

REVISION DETAIL
  https://reviews.freebsd.org/D5165

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: mugius.0x101.freebsd_gmail.com, #network, s3erios_gmail.com
Cc: bz, imp, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: epair(4) and net.route.netisr_maxqlen

[Bjoern A. Zeeb]

On 12 Nov 2018, at 3:44, Eugene Grosbein wrote:

My additions are mostly for Wolfgang,


12.11.2018 6:23, Wolfgang Zenker wrote:


on a jail with quite a lot of somewhat bursty network traffic I get
warnings from netdata recently about packets being dropped because of
net.route.netisr_maxqlen being to small. Before I start setting this
value to some random value I'ld like to find out what it actually 
means.

A search for documentation turned up nothing; a look at the sources
found that it is used for the size of a "software interrupt queue" in
epair(4). But what does it mean? And does this give me enough
information to find a good value to set for this sysctl?


netisr packet queues keep packets received by the interface and
not yet processed by destined subsystem or userland application
that may be short of CPU cycles or blocked for some reason.

First, the system won't allow you to raise net.route.netisr_maxqlen 
over the limit net.isr.maxqlimit.

The limit itself can be changed with /boot/loader.conf and reboot.
Default value of limit is 10240. I generally raise the limit upto 
102400
for hosts with heavy/bursty traffic. Note that actual increase of 
net.route.netisr_maxqlen
somewhat increases usage of kernel memory and that could be important 
for 32 bit kernel

and/or system with very low amount of RAM.

There may be several netisr packet queues in the system and raising 
net.route.netisr_maxqlen
allows all of them to grow. epair(4) has its own setting 
net.link.epair.netisr_maxqlen
that defaults to net.route.netisr_maxqlen if unset, so you may be 
start experimenting with
net.link.epair.netisr_maxqlen first, instead of system global 
net.route.netisr_maxqlen.


Don't set net.route.netisr_maxqlen to random value but double its 
current value
and see if that would be enough. If not, double it again. If 4096 
apears not enough,
you should check your applications why they can't keep with incoming 
traffic rate.


Also if you have multiple epair interface-combinations and a multi-core 
CPU you might also want to try (which never became default I think) to 
experiment with these settings in loader.conf:


net.isr.bindthreads=1
net.isr.maxthreads=256 # net.isr will always reduce it to 
mp_cpus


which should help balancing the load across the cores.  Note: these 
changes also affect all other possible traffic going through the netisr 
framework.


The netisr(9) man page has some documentation of these fields but not 
everything.  The source code does have a lot of comments and if someone 
would improve the man page that might be a good start:

https://svnweb.freebsd.org/base/head/sys/net/netisr.c?annotate=326272#l159


netstat -Q is also a good source for monitoring and diagnostics.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Long-lived connections over WiFi get stuck

[Bjoern A. Zeeb]

On 8 Nov 2018, at 19:14, Yuri wrote:

I have the problem that vnc-over-ssh connection from the laptop on 
WiFi gets stuck regularly, while the local browser on the laptop still 
works fine.


Eventually vnc-over-ssh either disconnects, or can be revived by 
pulling the WiFi card out and putting it back in.


The only difference between the browser and vnc-over-ssh is that 
browser connections are supposedly shorter, and can supposedly get 
reset by the browser when they aren't responsive, while ssh 
connections are long-lived and probably intense because vnc regularly 
needs to transfer large screen portions, and ssh doesn't reconnect 
when stuck.



What could be a problem with long connections getting stuck? How can 
this be troubleshooted?


My initial thought was MTU issues.


You might want to run tcpdump/wireshark and see what’s going on.  
Wireshark might help you with the analysis.


/bz

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: WiFi AC support?

[Bjoern A. Zeeb]

On 19 Oct 2018, at 3:32, Ronald F. Guilmette wrote:


Just curious Are any of the wireless adaptors listed here:

https://www.freebsd.org/releases/12.0R/hardware.html#support

capable of doing 802.11ac?


Adaptors are;  FreeBSD drivers not yet.  There is ongoing work to 
improve the situation but no timeline yet.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: epair failure in production on 11.1-STABLE (r328930) ? weird!

[Bjoern A. Zeeb]

On 2 Jul 2018, at 21:11, Dr Josef Karthauser wrote:

We’re experiencing a strange issue in production failure with epair 
(which we’re using to talk vimage to jails).


FreeBSD s5 11.1-STABLE FreeBSD 11.1-STABLE #2 r328930: Tue Feb  6 
16:05:59 GMT 2018 root@s5:/usr/obj/usr/src/sys/TRUESPEED  amd64


Looks like epair has suddenly stopped forwarding packets between the 
pair interfaces. Our server has been up for 82 days and it’s been 
working fine, but suddenly packets have stopped being forwarded 
between epairs across the entire system. (We’ve got around 30 epairs 
on the host).  So, we’ve got a sudden ARP resolution failure which 
is affecting all services. :(.


Ok, that’s a very interesting new observation I have not heard before 
or missed.   You are saying that for about 30 epair pairs NONE is 
working anymore?   All 30 are “dead”?


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [vnet] [epair] epair interface stops working after some time

[Bjoern A. Zeeb]

On 27 Mar 2018, at 14:40, Kristof Provost wrote:


(Re-cc freebsd-net, because this is useful information)

On 27 Mar 2018, at 13:07, Reshad Patuck wrote:
The epair crash occurred again today running the epair module code 
with the added dtrace sdt providers.

​
Running the same command as last time, 'dtrace -n ::epair\*:' returns 
the following:

```
CPU IDFUNCTION:NAME

…

  0  66499   epair_transmit_locked:enqueued
```


Looks like its filled up a queue somewhere and is dropping 
connections post that.

​
The value of the 'error' is 55 I can see both the ifp and m structs 
but don't know what to look for in them.


That’s useful. Error 55 is ENOBUFS, which in IFQ_ENQUEUE() means 
we’re hitting _IF_QFULL().
There don’t seem to be counters for that drop though, so that makes 
it hard to diagnose without these extra probe points.
It also explains why you don’t really see any drop counters 
incrementing.


The fact that this queue is full presumably means that the other side 
is not reading packets off it any more.
That’s supposed to happen in epair_start_locked() (Look for the 
IFQ_DEQUEUE() calls).


It’s not at all clear to my how, but it looks like the receive side 
is not doing its work.


It looks like the IFQ code is already a fallback for when the netisr 
queue is full.
That code might be broken, or there might be a different issue that 
will just mean you’ll always end up in the same situation, 
regardless of queue size.


It’s probably worth trying to play with 
‘net.route.netisr_maxqlen’. I’d recommend *lowering* it, to see 
if the problem happens more frequently that way. If it does it’ll be 
helpful in reproducing and trying to fix this. If it doesn’t the 
full queues is probably a consequence rather than a cause/trigger.
(Of course, once you’ve confirmed that lowering the netisr_maxqlen 
makes the problem more frequent go ahead and increase it.)


netstat -Q  will be useful
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Allowing a local subnet route to change to a different ifnet

[Bjoern A. Zeeb]

On 18 Jan 2018, at 0:09, Rodney W. Grimes wrote:

>> I have a customer that has configured two different IPs on the same
>> subnet on two different interfaces.  The behaviour that they want is
>> that if the link on one of the two interfaces goes down, the route to
>> that subnet will migrate to the other IP on the other interface as a
>> quasi-failover behaviour.  Under FreeBSD 7, we had a daemon that
>> accomplished this by detecting the link loss and then using "route
>> change" to move the route to the up interface.  If the subnet in
>> question was 192.168.1.0/24, for example, we could run "route change
>> 192.1.68.1.0/24 -ifp em1" to migrate the route.
>
> "route change 192.1.68.1.0/24 -ifp em1" does not appear to be
> valid syntax to me, -ifp is not a route option?
> Did you mean -interface?

The proper syntax should be route change -ifp  
but that’s not the issue (the other syntax works or used to work but
not according to specification).


>> Running on -head I run into two issues.  The first comes out of
>> r264986, which changes the behaviour of RTM_CHANGE.  The code path
>> changed significantly, but the part that impacts me is that now any
>> RTM_CHANGE command with the gateway set NULL gets EINVAL immediately
>> where previously it was allowed.  I've hacked around this problem
>> locally for testing purposes but I really don't understand the code
>> well enough at this point to see what a real fix would look like.

Running route -n monitor & while doing the change I get very weird
results (without your patch).

[ignore the patch for the moment]

>> My first, and most important question, is whether a patch that would
>> allow a subnet route to be migrated to a different interface be
>> something that would be acceptable in FreeBSD?

Yes.

>> If so, I need guidance
>> on what a proper fix for both issues would look like so that I can
>> implement fixes that I can upstream.
>
> From a fundemental standpoint this should work,
> that it is now broken is a regression that needs fixed.

+1

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [SOLVED] performance issue within VNET jail

[Bjoern A. Zeeb]

On 23 Dec 2017, at 14:06, Michael Grimm wrote:

I will skip these questions for the time being, because I did solve my 
issue 15 minutes before your mail ;-) And I feel sorry for all your 
now "wasted" efforts in trying to help me.


That’s OK.  You solved the issue; that’s what’s important!


Because I am leaving in some hours for Xmas vacations, I won't be able 
to come back to this issue for some days now.


I'd like to thank all of you for your patience and help, and:

Merry Christmas and with kind regards,


And to you!

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: performance issue within VNET jail

[Bjoern A. Zeeb]

On 22 Dec 2017, at 20:30, Michael Grimm wrote:


Hi —

[  I am including freebsd...@freebsd.org now and removing 
freebsd-j...@freebsd.org ]
[  Thread starts at 
https://lists.freebsd.org/pipermail/freebsd-net/2017-December/049470.html 
 ]


(#) there is a *dramatic* performance loss (TCP) when:

(-) fetching files from outside through PF/extIF via bridge to jail

…


Thanks for your suggestions so far, but I am lost here. Any ideas?


It seems to me some kind of bug in the PF.
I personally never tried it, I use ipfw and it works just fine.


Before testing IPFW (which I have never used before) I'd like to ask 
the experts in freebsd...@freebsd.org about possible tests/tweaks 
regarding PF.



OK, too complicated setups; I am not getting it fully.
Can you please just describe the one case that doesn’t work well in 
all detail and ignore all the others for a moment?


(a) what’s the external host interface?
(b) pf runs on the base system?
(c) you are bridging into a VNET-jail?  How exactly?  Are you bridging 
to epairs?

(d) where exactly are you NATing?
(e) why are you bridging and NATing?  That makes little sense to me.  
Couldn’t you NAT and forward or just bridge?

(f) what’s inside the VNET jail?  Another pf or anything?
(g) out of curiosity, does dmesg on the base system indicate anything?


To understand your performance problem better:

(1) you are doing a fetch of a rather large file to test from within the 
VNET jail?  Or what are you fetching?  Are you using fetch?

(2) if you fetch from within the same VNET jail does that perform?
(3) if you fetch something to the VNET jail from the base system just 
going through your internal setup but not leaving the machine, does that 
still perform?
(4) if you fetch something to the VNET jail from the same LAN (if 
possible to test) does that perform?
(5) if you fetch something to the VNET jail from a close by location 
does that make a difference to something on the other side of the 
planet?



/bz


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Only last IP frag sent if ARP entry absent

[Bjoern A. Zeeb]

On 17 Aug 2017, at 21:16, Gopakumar Pillai wrote:


Hi FreeBSD Networking Gurus,
I came across an issue with an old version of FreeBSD and looking at 
the latest FreeBSD code, seems it exists even now. I am assuming that 
this issue is not reported.


Observation:
When a ping was performed with larger payload than MTU, the first ping 
failed when the ARP entry was absent for that IP.


That is because ping/ICMP has no retransmit.


Noticed on the wire that the last IP fragment was sent for the first 
request and then the subsequent requests were fine.


Root Cause:
  * ip_output fragments the packets and loops through the fragments to 
send them to ether_output.
  * ether_output does an arpresolve and if there is no existing ARP 
entry it'll return EWOULDBLOCK after sending ARP Request.
  * ether_output ignores the error and propagates success to ip_output 
and it continues to send the remaining fragments.
  * llentry keeps only one mbuf and the last fragment is retained when 
the ARP Reply comes and the fragment is sent.


Yes, according to the spec (RFC) we are supposed to throw the packet 
away entirely and simply report that to the next upper layer.  However 
over the years people realised that this sucks for a TCP SYN packet with 
a retransmit timer and hence we store one of them.


A large UDP packet would btw see the same behaviour to your ping.   
There’s no guarantee any of these packets will not be dropped anywhere 
on the network, so we can as well.


Just my 2ct

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Remove flowtable from HEAD

[Bjoern A. Zeeb]

On 10 Jul 2017, at 14:25, Bjoern A. Zeeb wrote:


Hi,

I have a review pending to remove flowtable from head.  Now is the 
time to speak up if, after the inpcb caching went in a while ago, you 
still have a good reason for it to stay in the tree.


Also review would be highly appreciated :)  
https://reviews.freebsd.org/D11448


And there was silence for more than 2 weeks after talking about this for 
ages, so it’s gone:


https://svnweb.freebsd.org/changeset/base/321618


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPsec tunnel mode with gif

[Bjoern A. Zeeb]

On 20 Jul 2017, at 22:02, Kajetan Staszkiewicz wrote:

Yet for a reason beyond my understanding FreeBSD handbook proposes a 
3rd mode:
using a GIF tunnel together with IPSec tunnel mode. I really don't 
understand
how is that supposed to work. People On The Internet also seem not to 
be able

..

Am I wrong? Or is the Handbook wrong?


The handbook is outdated and I think what you are referring to is from 
the early days of the IPv6/IPsec stack implementation times probably 
during FreeBSD 4.


What you are doing (gre/gif inside transport mode to possibly get a 
link-state change as well, or BGP over transport mode directly is both 
fine.



I think the short answer:  updates to the handbook would be very 
welcome!


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Remove flowtable from HEAD

[Bjoern A. Zeeb]

Hi,

I have a review pending to remove flowtable from head.  Now is the time 
to speak up if, after the inpcb caching went in a while ago, you still 
have a good reason for it to stay in the tree.


Also review would be highly appreciated :)  
https://reviews.freebsd.org/D11448



/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Enable IPv6 Privacy Extensions by default

[Bjoern A. Zeeb]

On 11 Jun 2017, at 19:59, Tijl Coosemans wrote:

> Hi,
>
> I recently got a new modem/router from my ISP that supports IPv6.  Added
> ifconfig_em0_ipv6="inet6 accept_rtadv" and rtsold_enable="YES" to
> /etc/rc.conf like the handbook says and now all my FreeBSD systems have
> an IPv6 address. \o/
>
> I also added these lines to /etc/sysctl.conf to enable temporary
> addresses:
>
> net.inet6.ip6.use_tempaddr=1
> net.inet6.ip6.prefer_tempaddr=1
>
> Shouldn't these be enabled by default?  There was a proposal 9 years ago
> that didn't get any objections but it seems it wasn't committed:
> https://lists.freebsd.org/pipermail/freebsd-net/2008-June/018381.html
>
> If there are no objections, I'll make the change in a week or so.

Object :)

Check the rc.conf ipv6_privacy option rather than setting the sysctl manually.

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Public IPv6s fail on KVM bridge with "No buffer space available"

[Bjoern A. Zeeb]

On 24 May 2017, at 10:17, William Gathoye wrote:


In this use case, you make the assumption that my gateway is actually
the first one to respond, this is why you select only the first answer
using -c1. But as you can see below, if I remove that argument, 
several
routers are answering to me (seems sensible to me), how can I be sure 
my

gateway is actually the first device that answers?


You cannot.  It’s all about latency and where your time goes.  Switch 
buffers, distance, NICs, input paths, CPU loads, .. lots of things can 
change the timing of a packet.



PING6(56=40+8+8 bytes) fe80::ff:fec2:e61d%vtnet0 --> ff02::2%vtnet0
16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=0 hlim=64
time=0.292 ms
16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=0 hlim=64
time=0.355 ms(DUP!)
16 bytes from fe80::2ff::feff:fffd%vtnet0, icmp_seq=0 hlim=64
time=2.970 ms(DUP!)
16 bytes from fe80::2ff::feff:fffe%vtnet0, icmp_seq=0 hlim=64
time=5.964 ms(DUP!)
16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=1 hlim=64
time=0.314 ms
16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=1 hlim=64
time=0.389 ms(DUP!)
16 bytes from fe80::2ff::feff:fffd%vtnet0, icmp_seq=1 hlim=64
time=3.222 ms(DUP!)
16 bytes from fe80::2ff::feff:fffe%vtnet0, icmp_seq=1 hlim=64
time=6.382 ms(DUP!)

How can I understand the "DUP!" statement here? I assume these are due
because we are using multicast here end the ICMP reply are echoes to
each others? Right?


The DUP! here in case is indeed as you get 4 replies for each request 
you are sending out.  It’s not “each other”, it’s one request to 
the multicast address, 4 unicast replies to you.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Committing a new 25G/40G/100G Ethernet Driver

[Bjoern A. Zeeb]

On 24 Mar 2017, at 2:39, Somayajulu, David wrote:


Hi All,
I have a brand new Cavium 25G/40G/100G Ethernet Driver to commit to 
HEAD.
The patch generated using "svn diff"   is about 22Mb. Per gnn's advice 
I have tried to submit the patch via Phabricator at 
https://reviews.freebsd.org/differential/diff/create/ for review. The 
file uploads fine but I get the following error "413 Request Entry Too 
Large".  I would appreciate if someone can help me circumvent this 
problem. Also would it be o.k if I break the patch into smaller 
portions and submit to Phabricator ?



Try contacting that alias:  
https://www.freebsd.org/administration.html#t-phabric-admin


They should be able to help.

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Duplicate MAC addresses in VNET epair interaces

[Bjoern A. Zeeb]

On 14 Feb 2017, at 9:26, Giulio Ferro wrote:


Hi Bjoern, thanks for your reply...

the idea is sound, but unfortunately setting the mac address of the 
epair interface

inside the jail doesn't work:

ifconfig epair0b ether ether 02:ff:e0:00:00:0b
ifconfig: can't set link-level netmask or broadcast


Two “ether”s there but I assume that’s a copy and paste issue?




I've tried manually, in the rc.conf file 
(ifconfig_epair0b="ether..."), and in the /etc/start_if.epair0b file,
but neither of these three ways actually work to set the mac address 
of the epair interface within the jail.


On the other hand, no problem setting the mac of epair in the host...


And that’s what you should do.  Despite epairs being virtual 
interfaces, think of them as hardware that you are only “loaning” to 
the vnet-jail but don’t want the jail to mess with all the hw 
settings.


And you probably want to change the ether addresses on both ends anyway.

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Duplicate MAC addresses in VNET epair interaces

[Bjoern A. Zeeb]

On 6 Feb 2017, at 18:53, Giulio Ferro wrote:


Hi all,


Setup:

11.0-STABLE FreeBSD 11.0-STABLE #0 r312338: Tue Jan 17 12:29:38 UTC 
2017



I've set up two freebsd hosts, each of which has  a single VNET jail.

On each host I've created 2 epair interfaces.

Host A

- epair0a, epair1a on the host

- epair0b, epair1b on the jail


Host B

- epair0a, epair10a on the host

- epair0b, epair10b on the jail


What I noticed is that on both hosts, each epair interface has the 
same MAC address:



…>


(same behavior on the epair interfaces on the jail side)


As you can see, the mac addresses seems to depend on the order of the 
creation of the epair, not on the name or address



This is a potentially bad behavior, because if I want to bridge say 
epair1a on A with epair10a on B with a VPN or


a physical connection giving 192.168.1.1 to epair1b and 192.168.1.2 to 
epair10b, I won't be able to make them


talk to each other since they have the same MAC address.


My question is: is this a bug or something I'm doing wrong? If there 
any workaround I can use?



From the man page:

 Like any other Ethernet interface, an epair needs to have a 
network
 address.  Each epair will be assigned a locally administered 
address by
 default, that is only guaranteed to be unique within one network 
stack.
 To change the default addresses one may use the SIOCSIFADDR 
ioctl(2) or

 ifconfig(8) utility.

I thought someone patched it a few years ago to have a pseudo-random 
part to make collisions less likely and use the FreeBSD vendor space, 
but it seems that never happened for epair (or didn’t make it into the 
tree).


ifconfig epair[ab] ether 02:xx:xx:xx:xx  is your friend for now.

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: unable to use BPF Just-In-Time compiler

[Bjoern A. Zeeb]

On 19 Sep 2016, at 16:04, Jung-uk Kim wrote:


On 09/17/2016 17:11, Bjoern A. Zeeb wrote:

On 15 Sep 2016, at 5:32, KrishnamRaju ErapaRaju wrote:


Hi,

I want to use BPF JIT Kernel APIs in FreeBSD(like: bpf_jitter(),
etc..), for implementing TCP connection packet filtering.

I have followed below instructions as specified in:
https://lists.freebsd.org/pipermail/freebsd-current/2005-December/058603.html


STEPS followed:
-
cp /usr/src/sys/amd64/conf/GENERIC /usr/src/sys/amd64/conf/MYKERNEL

And added below line in MYKERNEL config file.
options BPF_JITTER


I think you want

device bpf_jitter

The options line to my understanding only turns it on by default.


"options BPF_JITTER" works.  I don't know why the OP thinks that it
doesn't work, though.


Ok, let’s see;  if you boot your own kernel, what does

sysctl net.bpf_jitter.enable

say?

/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: unable to use BPF Just-In-Time compiler

[Bjoern A. Zeeb]

On 15 Sep 2016, at 5:32, KrishnamRaju ErapaRaju wrote:


Hi,

I want to use BPF JIT Kernel APIs in FreeBSD(like: bpf_jitter(), 
etc..), for implementing TCP connection packet filtering.


I have followed below instructions as specified in: 
https://lists.freebsd.org/pipermail/freebsd-current/2005-December/058603.html


STEPS followed:
-
cp /usr/src/sys/amd64/conf/GENERIC /usr/src/sys/amd64/conf/MYKERNEL

And added below line in MYKERNEL config file.
options BPF_JITTER


I think you want

device bpf_jitter

The options line to my understanding only turns it on by default.



make buildkernel KERNCONF=MYKERNEL
make installkernel KERNCONF=MYKERNEL
reboot

But after reboot the flag BPF_JITTER is not getting enabled(all the 
code inside "#ifdef BPF_JITTER" is not getting executed).


Am I missing something?

Also it looks like there are not many updates to BPF JIT code since 
2005, is it stable? anyone using it?


Thanks,
Krishna.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dupliceated icmp echo request

[Bjoern A. Zeeb]

On 13 Sep 2016, at 15:39, Hannes Mehnert wrote:


hello,

(sorry in case this is the wrong mailing list)


freebsd-net might be better; which I put on CC:.


while doing some network testing, I discovered that my FreeBSD 
(r304285,

but likely earlier + released ones as well) sends out two
(bytewise-)identical ICMP echo requests shortly after each other when 
I
ping the broadcast (IPv4) address on an interface [tested with: 
tap,em,iwm].


This behaviour does not meet my expectations - is there any specific
reason for this behaviour; it behaves well (sending out a single ICMP
echo request) if I ping a unicast host.


Asking for a command line seems strange;  but given I am replying, is 
there any delay between the two packets?  If you ktrace ping, do you see 
multiple send calls for the same data?


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Request for VIMAGE testing in 11.0-ALPHA6 and later

[Bjoern A. Zeeb]

Hi,

during the last weeks and months a lot of changes went into the tree to
allow a top-to-bottom network stack teardown to stabilize VNET
shutdown and plug some memory leaks.

In addition some missing parts were virtualised or the virtualisation
was fixed, e.g., pf and ipfilter, ipfw log interface.

I have done some testing and stress testing but it's impossible to catch 
all combinations and setups or even options.  So once 11.0-ALPHA6 is

out please do test (or if you want to do so now r302302 or later).

These changes are only and will only be in FreeBSD 11 for the time being.

You will still need to compile your own kernel;  GENERIC will not have
VIMAGE enabled for 11.0 as that requires at least a performance
analysis (due to extra layer of indirection).   It will also still
print the "experimental" feature line, as we do not want to commit to
KPI/KBI or other things yet and we feel more testing would be good.
I would advise to start testing on dedicated test-systems and not
necessarily production servers but obviously that is your choice.

Also if you are using ports that bring their own ifnet interfaces and
you are experiencing problems please let us know.

If you find problems please file a bug report and make sure to set
"vimage" in the Keywords field but feel also free to post to
freebsd-virtualisation@ which I'll be monitoring.

Thanks a lot to everyone!

Bjoern

--
Bjoern A. Zeeb r15:7
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D1944: PF and VIMAGE fixes

[bz (Bjoern A. Zeeb)]

bz added a comment.


  Can I have you guys have a look at https://reviews.freebsd.org/D6924
  
  Thanks

REVISION DETAIL
  https://reviews.freebsd.org/D1944

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: nvass-gmx.com, trociny, kristof, gnn, zec, rodrigc, glebius, eri, bz
Cc: ryan_timewasted.me, mmoll, javier_ovi_yahoo.com, farrokhi, julian, robak, 
freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: panic with tcp timers

[Bjoern A. Zeeb]

On 17 Jun 2016, at 4:53, Gleb Smirnoff wrote:


  Hi!

  At Netflix we are observing a race in TCP timers with head.
The problem is a regression, that doesn't happen on stable/10.
The panic usually happens after several hours at 55 Gbit/s of
traffic.

What happens is that tcp_timer_keep finds t_tcpcb being
NULL. Some coredumps have tcpcb already initialized,
with non-NULL t_tcpcb and in TCPS_ESTABLISHED state. Which
means that other CPU was working on the tcpcb while
the faulted one was working on the panic. So, this all looks
like a use after free, which conflicts with new allocation.

Comparing stable/10 and head, I see two changes that could
affect that:

- callout_async_drain
- switch to READ lock for inp info in tcp timers

That's why you are in To, Julien and Hans :)

We continue investigating, and I will keep you updated.
However, any help is welcome. I can share cores.


There’s also the change to no longer mark the zones NO_FREE.
In theory I was convinced at the time that it should not be an issue 
anymore.


If I had overlooked something or follow-up timer changes invalidated 
assumptions then that could also be trouble.


That said, I was not able to get any related panics or log entries 
anymore lately (but I am currently slightly behind head with my branch).


We should get the problem fixed however and not try to “paint over” 
again.


/bz
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D1944: PF and VIMAGE fixes

[bz (Bjoern A. Zeeb)]

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

VNET teardown changes (part I)

[Bjoern A. Zeeb]

Hi,

sorry for the cross-post;  Reply-To set.

I extracted a patch from projects VNET which tries to get the VNET teardown
more robust (and in a next step plug the remaining [TCP] memory leaks).

If anyone has an interest in testing some parts on a non-production setup
(you have been warned) please do so and report back to me (privately) in case
of success or panics.

There is more to come.

https://people.freebsd.org/~bz/20160222-01-projects-vnets.diff

Thanks,
Bjoern
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: pf not seeing inbound packets coming from IPSec on epair interface

[Bjoern A. Zeeb]

> On 18 Jan 2016, at 16:13 , Andreas Longwitz  wrote:
> 
> in the situation
>IPSec --> epair0a --> epair0b
> pf does not see inbound packets on the interface epair0b, because the
> epair driver does not clear the flag PACKET_TAG_IPSEC_IN_DONE when he
> transfers a packet from epair0a to epair0b. The following patch for
> FreeBSD 10 works for me and is adapted from
>   lists.freebsd.org/pipermail/freebsd-net/2012-January/031161.html:

Where does epair get the packet from?  A physical interface bridged to epair?

If anything should clear that;  I guess it’s the bridge interface?

Hmm, but then if you are using epairs to cross between network stacks, you are 
changing boundries, indeed, so if you’d run ipsec on a single epair between two 
VNETs, that might be interesting as well?

I guess we’ll need to find a couple of these places (epair, bridge, netgraph, 
…)  and make sure we strip all of the tags IFF we change the VNET?


/bz


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: A bug in udp6_input() - should use proto instead of ip6->ip6_nxt

[Bjoern A. Zeeb]

> On 31 Aug 2015, at 04:05 , Tiwei Bie  wrote:
> 
> I found a bug in udp6_input(). The 'proto' parameter should be used to
> get the protocol number (UDP or UDPLITE), instead of ip6->ip6_nxt.
> 
> Because ip6->ip6_nxt may be the protocol number of extension header,
> such as:
> 
> If a UDP packet is an "atomic" fragment, frag6_input() will return
> directly, and ip6->ip6_nxt will be IPPROTO_FRAGMENT (if the first
> extension header is the fragment header) instead of IPPROTO_UDP or
> IPPROTO_UDPLITE:

Hmm, that might be a bug elsewhere but atomic fragments are soon to go away 
again; wish people would listen in first place;  but anyway.

There are more of these bugs that came with the UDP-Lite code, such as 4mapped 
addresses are not handled correctly in the output path, etc.

Can you open a bug for this and we can attach all the UDP-Lite fixes to it to 
properly document them and get them through review in a few days and committed?


Thanks,
Bjoern
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

UDP6 locking improvement

[Bjoern A . Zeeb]

Hi,

based on some work I have done a few years back I have updated an UDP6 locking 
change and it’s at the “it compiles” stage.  I have not re-read it yet.  I’ll 
have to split it up into a couple of changes for PB as it also fixes:
- some UDP-Lite bug(s)
- some control mbuf leak
- something else I forgot already

and then re-post the rest into PB as well.


The old description in p4 was like:

! MFp4 bz_ipv6_fast:
!
!   Migrate udp6_send v4mapped code to udp6_output saving us a re-lock and
!   further simplifying the af handling code by eliminating AF_INET checks
!   at the tail end of the function.
!
!   Rework output path locking similar to UDP4 allowing for better
!   parallelism (see r222488).
!
!   Cleanup early initializations, comments, …
!
!   Sponsored by:   The FreeBSD Foundation
!   Sponsored by:   iXsystems


The new version is here:

https://people.freebsd.org/~bz/20150828-01-udp6-locking.diff

Anyone who wants to give it a read-through or bashing it through a pps 
framework is welcome!   I’ll try to do some of that hopefully over the weekend 
myself.

Bjoern
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ssh over WAN: TCP window too small

[Bjoern A. Zeeb]

 On 25 Aug 2015, at 22:47 , Chris Stankevitz ch...@stankevitz.com wrote:
 
 Hi,
 
 # cat /dev/urandom | ssh root@host 'cat  /dev/null'
 
 I use the above ssh command over a high-BDP WAN link (80 ms @ 100 Mbps).  
 tcpdump shows I am TCP window limited to 64 KBytes (yielding 5 Mbps).  iperf 
 with default options gets the window opened to 500 KBytes (yielding 35 Mbps).
 
 Both sides of the connection: FreeBSD 10.1 w/default sshd options (except I 
 permit root login).  In particular, HPN is not disabled.
 
 Can anyone explain my abysmally small TCP window?
 
 Can anyone recommend some tools/tricks to figure out what in FreeBSD and/or 
 base SSH is limiting the send/recv buffer and/or TCP window?

if you have the memory, try these sysctls:

kern.ipc.maxsockbuf=146800640
net.inet.tcp.recvbuf_max=67108864
net.inet.tcp.sendbuf_max=67108864
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Updated] D1777: Associated fix for arp/nd6 timer usage.

[bz (Bjoern A. Zeeb)]

bz added a comment.

Hiren, it only took us 4 years to trigger this?  Can people actually 
easily/reliably reproduce it?

REVISION DETAIL
  https://reviews.freebsd.org/D1777

To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz
Cc: bz, emaste, hiren, julian, hselasky, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Changed Subscribers] D1777: Associated fix for arp/nd6 timer usage.

[bz (Bjoern A. Zeeb)]

bz added a subscriber: bz.
bz added a reviewer: bz.
bz added a comment.

It smells like a lle_refcnt bug to me and I have send a private email to errs 
to understand the problem better (and also if other optional kernel options 
might have been used while this was experienced).

REVISION DETAIL
  https://reviews.freebsd.org/D1777

To: rrs, jhb, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz
Cc: bz, emaste, hiren, julian, hselasky, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes

[bz (Bjoern A. Zeeb)]

bz added a comment.

I have raised my concerns about the change a few weeks ago elsewhere already 
but gnn mentioned a possible idea today to keep it clean(er).  I'll let him 
follow-up here.

REVISION DETAIL
  https://reviews.freebsd.org/D1761

To: hselasky, rmacklem, rrs, glebius, gnn, emaste, rwatson, imp, adrian, bz
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Reopened] D1309: VIMAGE PF fixes #1

[bz (Bjoern A. Zeeb)]

bz reopened this revision.
bz added a comment.
This revision is now accepted and ready to land.

Even if this would have been merged properly and not broken the build there's 
still stuff that is wrong for initialisation with different net contexts in 
this and that needs to be fixed properly.

REVISION DETAIL
  https://reviews.freebsd.org/D1309

To: rodrigc, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo, 
adrian, bz, gnn, hiren, rwatson
Cc: freebsd-virtualization, freebsd-pf, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 routes leaking between FIBs?

[Bjoern A. Zeeb]

 On 29 Dec 2014, at 16:03 , Alan Somers asom...@freebsd.org wrote:
 
 On Sun, Dec 28, 2014 at 3:16 AM, Bjoern A. Zeeb b...@freebsd.org wrote:
 
 People simply broke it (again).  Please file a bug report.   You may mention 
 that there are regression test scripts in src/tools/ somewhere to test all 
 the cases for IPv6.
 
 Sounds like those tests need to be merged into the ATF tests at
 tests/sys/netinet/fibs_test.sh so they'll run continuously.

Probably but they also need multiple machines (or network stacks), access to 
privileged services (ifconfig, ipfw, …), and I have no clue how to do all this 
with ATF.   Be my guest :-)

— 
Bjoern A. Zeeb  Charles Haddon Spurgeon:
Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Updated] D1388: IP6: Turned on verbose logging for fragment handling code

[bz (Bjoern A. Zeeb)]

bz added a comment.

I somehow would expect a comment to be updated somewhere referencing RFC5722?

Appart from that no objections though I have only skimmed through and not 
properly reviewed this.

REVISION DETAIL
  https://reviews.freebsd.org/D1388

To: kibab, bz
Cc: ae, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 routes leaking between FIBs?

[Bjoern A. Zeeb]

 On 29 Dec 2014, at 19:17 , Julian Elischer jul...@freebsd.org wrote:
 
 On 12/30/14 1:59 AM, Jason Healy wrote:
 On Dec 29, 2014, at 1:28 AM, Julian Elischer jul...@freebsd.org wrote:
 
 to some extent this is what it was written for.. teh fib code was written 
 for Ironport/Cisco for separating the management port from the data ports 
 onn their appliances, however the VNET code that came later is an even 
 cleaner way of doing it and FIBs were only used by Ironport because VNET 
 was not yet available.Have you tried vnet jails for interface isolation?
 I freely admit that I haven’t.  I’m just coming over to FreeBSD and while 
 I’m aware of jails, I thought of them more as service isolation than for 
 routing.
 
 I’m searching around for a moment, and I’m not 100% sure this is going to 
 work for my use case.  Can you confirm that jails would be the most 
 appropriate way to solve my problem?  These are the major requirements:
 
  - A router/firewall that will perform NAT from an internal RFC1918 space to 
 public IPv4, as well as stateful firewalling of IPv6 packets passed to it.
 
  - 3 interfaces:
1) Transit interface (10g, packets to/from PF are received/sent on this 
 interface)
2) PFsync (to connect to a second box for active-active PF)
3) Management (LAN side only)
 the only hitch may be the pfsync stuff.. I have no idea about how virtualised 
 that is and I never use pf..or pfsync.

pf and VNETs are a cause for panic at the moment;  don’t go that route (yet).

 Basically you can assign a complatly separate network stack to teh management 
 interface, (or the other ones)
 and run whatever the appliation is in the jail..  it's still possible to 
 communicate with the jailed processes using shared files or fifos, but they 
 have a completely separate network stack and are therefore completely unaware 
 of the management interface.
 Each jail (if enabled with vnet option) has itsl own interfaces, routing 
 tables, firewall(s) etc.
 
 
 
  - Separate routing tables for the transit and management interfaces, so 
 that the transit interface can have a default route that is distinct from 
 that of the management network.
 
 It sounds to me that if I ran this as a jail, I’d need to throw the 10g 
 transit interface and the pfsync interface into the jail, and leave the 
 management interface on the host.  I’d probably need to run PF in the jail 
 as well?  Or are we just using the jail to isolate the routing tables, and 
 I’d still run PF on the host?
 
 I’m happy to provide more details on the setup in case there’s a better way 
 to architect this.  I’m a Debian/OpenBSD guy, so I’m sorry if I don’t have 
 all the terminology sorted out yet...
 
 I will still file a bug against the FIB code, as it sounds like that’s not 
 working as intended/designed.
 
 Thanks,
 
 Jason
 
 
 
 
 
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

— 
Bjoern A. Zeeb  Charles Haddon Spurgeon:
Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: setfib and RSTs

[Bjoern A. Zeeb]

 On 29 Dec 2014, at 21:03 , Nikolay Denev nde...@gmail.com wrote:
 
 No, no PR yet, but I will file one. I wanted to collect some more data
 first.
 
 So, I've did some dtrace digging :
 
 [20:54][root@nas:~]#cat reset.d
 #!/usr/sbin/dtrace -s
 
 fbt:kernel:tcp_dropwithreset:entry
 {
printf(reason %d fib %d src_port %d dst_port %d, args[4], args[2] ?
 args[2]-t_inpcb-inp_inc.inc_fibnum : -1, ntohs(args[1]-th_sport),
 ntohs(args[1]-th_dport));
 /* stack(); */
 }
 …

 The port numbers here match RST packets that I'm seeing with tcpdump in
 another window.
 reason 3 is BANDLIM_RST_CLOSEDPORT (from icmp_var.h)
 Looking at tcp_input.c I see that there are cases where the INPCB does not
 exists, and from what I see this is how the FIB gets determined.
 Also here I see that tcp_dropwithreset() is called with tcpcb set to NULL,
 so probably this is why the FIB is not found.
 
 Why this is happening, I have no idea yet.

Could you also check for the mbuf *m and the fibnum from the pkthdr there?

It might be even more interesting to see this for tcp_respond and the following 
ip_output as well, in case you want to keep state in the d script;  otherwise 
just tcp_dropwithreset and/or tcp_respond should be fine.

Usually I would expect for the tcp_dropwithreset case that inp will be NULL in 
tcp_respond, the mbuf *m and th will be valid and thus the FIB number from the 
incoming mbuf would be re-used as the mbuf will be re-used, but for that the 
mbuf needs to be properly tagged on receive.

/bz

— 
Bjoern A. Zeeb  Charles Haddon Spurgeon:
Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPv6 routes leaking between FIBs?

[Bjoern A. Zeeb]

 On 28 Dec 2014, at 03:19 , Jason Healy jhe...@logn.net wrote:
 
 Hello,
 
 Trying out FreeBSD for the first time to build a firewall box that’s 
 multi-core and runs PF.  I’m very interested in the FIB code, as it lines up 
 well with the way my core networking equipment works and should allow me to 
 route traffic on an interface that’s logically separate from the management 
 interfaces.
 
 I’ve been playing for a bit with the FIB features, but I’m getting hung up on 
 IPv6.  I’m trying to set up two interfaces on my box to each have a different 
 FIB, and to not leak routes between the interfaces:
 
 # sysctl net.add_addr_allfibs=0
 # ifconfig em1 inet 192.0.2.1/24 fib 1
 # ifconfig em1 inet6 2001:db8:dead:beef::1/64 fib 1
 # ifconfig em2 inet 203.0.113.1/24 fib 2
 # ifconfig em2 inet6 2001:db8:cafe:babe::1/64 fib 2
 
 If I then check the routing tables for each FIB, here’s what I get:
 
 # setfib -F 1 netstat -rn
 
 Routing tables (fib: 1)
 
 Internet:
 DestinationGatewayFlags  Netif Expire
 192.0.2.0/24   link#2 U   em1
 192.0.2.1  link#2 UHS lo0
 
 Internet6:
 Destination   Gateway   Flags  
 Netif Expire
 2001:db8:cafe:babe::/64   link#3U   
 em2
 2001:db8:dead:beef::/64   link#2U   
 em1
 2001:db8:dead:beef::1 link#2UHS 
 lo0
 fe80::%em1/64 link#2U   
 em1
 fe80::a00:27ff:fef6:162a%em1  link#2UHS 
 lo0
 fe80::%em2/64 link#3U   
 em2
 fe80::%lo0/64 link#5U   
 lo0
 
 
 # setfib -F 2 netstat -rn
 
 Routing tables (fib: 2)
 
 Internet:
 DestinationGatewayFlags  Netif Expire
 203.0.113.0/24 link#3 U   em2
 203.0.113.1link#3 UHS lo0
 
 Internet6:
 Destination   Gateway   Flags  
 Netif Expire
 2001:db8:cafe:babe::/64   link#3U   
 em2
 2001:db8:cafe:babe::1 link#3UHS 
 lo0
 2001:db8:dead:beef::/64   link#2U   
 em1
 fe80::%em1/64 link#2U   
 em1
 fe80::%em2/64 link#3U   
 em2
 fe80::a00:27ff:fe62:d267%em2  link#3UHS 
 lo0
 fe80::%lo0/64 link#5U   
 lo0
 
 
 Note that as expected, the IPv4 routes are constrained to their FIB 
 (192.0.2.0 to FIB 1 and 203.0.113.0 to FIB 2).  However, the IPv6 routes 
 (deadbeef and cafebabe) leak between the FIBs; both prefixes that I add are 
 listed in both FIBs (as well as the link-local stuff).
 
 According to:
 
  
 https://www.freebsd.org/news/status/report-2012-01-2012-03.html#Multi-FIB:-IPv6-Support-and-Other-Enhancements
 
 IPv6 parity is claimed for the FIB code, so I’m not sure if I’m doing it 
 wrong, or if there’s a problem with the FIB code and IPv6 routes.
 
 Thanks in advance for any help or clarification!


People simply broke it (again).  Please file a bug report.   You may mention 
that there are regression test scripts in src/tools/ somewhere to test all the 
cases for IPv6.


— 
Bjoern A. Zeeb  Charles Haddon Spurgeon:
Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: RFC: Enabling VIMAGE in GENERIC

[Bjoern A. Zeeb]

On 30 Nov 2014, at 10:04 , Julian Elischer jul...@freebsd.org wrote:

 On 11/29/14, 5:28 PM, Craig Rodrigues wrote:
 On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer jul...@freebsd.org 
 mailto:jul...@freebsd.org wrote:
 
 
  also look at the following: (a little dated)
 
  http://p4web.freebsd.org/@md=dcd=//depot/projects/vimage/cdf=//depot/projects/vimage/porting_to_vimage.txtc=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22
 
 
 This is a useful document.  I put it on the wiki: 
 https://wiki.freebsd.org/VIMAGE/porting-to-vimage
 
 Thanks.. wow, did I actually know ALL that only 5 years ago?
 Scary.  probbaly worth having someone who is currently active and up to date 
 look at it to see if it's all still correct..
 especially the module load/unload stuff.

Yeah I popped it up in a browser window to read through it once I have a short 
break to do that.

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: VIMAGE UDP memory leak fix

[Bjoern A. Zeeb]

On 21 Nov 2014, at 08:25 , Robert N. M. Watson rwat...@freebsd.org wrote:

 
 On 20 Nov 2014, at 23:29, Marko Zec z...@fer.hr wrote:
 
 Can folks take a look at this?
 
 https://reviews.freebsd.org/D1201
 
 All UMA zones used in the network stack have been marked as
 UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might
 not hurt to provide more insight why and how it suddenly became safe to
 remove that flag?
 
 Historically, this was (if I recall) a property of the way data was exported 
 for netstat, which depended on memory stability of various data types. We 
 have worked quite hard to remove the causes of those sorts of dependencies by 
 introducing stronger reference and memory ownership models throughout the 
 stack -- in the case of inpcbs, for example, we introduced a true reference 
 model during the multiprocessing scalability work (which, it should be 
 pointed out, was enormously painful and took years to shake the bugs out of 
 due to complexity/subtlety). It may be that it is now safe to remove 
 UMA_ZONE_NOFREE for some of the types where it was previously required -- but 
 it's definitely something you want to do intentionally and in the context of 
 a careful analysis to convince yourself that all the causes have been 
 addressed. A fair amount of stress testing in low-memory conditions wouldn't 
 hurt either...

I had convinced myself for UDP many years ago that it was ok to remove it.  
People have touched the code however so it’s definitively worth re-checking 
again.

For TCP we clearly cannot do it (yet, and couldn’t back then).   But TCP was 
the only of the few cases I had left unfixed back then.  Can’t remember what 
the others were (was like 3 or 4 of them;  could also be some of the fixes were 
indeed committed back then.


— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: VIMAGE + pf security fix?

[Bjoern A. Zeeb]

On 21 Nov 2014, at 08:06 , Craig Rodrigues rodr...@freebsd.org wrote:

 On Thu, Nov 20, 2014 at 10:07 AM, Craig Rodrigues rodr...@freebsd.org
 wrote:
 
 On Wed, Nov 19, 2014 at 6:05 AM, Bjoern A. Zeeb b...@freebsd.org wrote:
 
 
 For people to use pf with VIMAGE we first MUST have the security fix
 imported that I pointed out a couple of times in the past.
 
 
 At this link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830
 
 I see the security issue mentioned, but I can't find the patch that fixes
 the problem.
 Where is the patch?
 
 
 I read this link:
 http://esec-lab.sogeti.com/post/2010/12/09/CVE-2010-3830-iOS-4.2.1-packet-filter-local-kernel-vulnerability
 
 and I think this is the fix:
 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_ioctl.c?rev=1.236content-type=text/x-cvsweb-markup
 
 but I can’t even apply that patch to our pf_ioctl.c.

to my best knowledge we have never pulled a fix for this in.  The last “sync” 
of pf was way before that vulnerability (unless I completely missed something).

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPsec is very broken...

[Bjoern A. Zeeb]

On 20 Nov 2014, at 21:35 , John-Mark Gurney j...@funkthat.com wrote:

 The first major issue I ran across was transport mode...  ae@ has been
 nice enough to get ICMP working in transport mode for IPv4 and IPv6,
 but it looks like TCP is still broken.  I haven't tested UDP yet...
 So, IPsec even w/o crypto is fundamentally broken here... It's clear
 that not many people run transport mode…

Or that some people lately broke the code.


 If someone could create a good test suite that ensures makes sure basic
 IPsec traffic passes, that would be a huge win for us.  The tests
 should test a complete cross product of: { tunnel, transport } x
 { TCP, UDP, ICMP, any others? } x { IPv4, IPv6 }.  Please add to this
 list.

 + SCTP + IPcomp + IPv4/IPv6 mixes inside/outside + properly working enc(4)

If you get all that then add IPIP (gif) and GRE on the inside as well.

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: RFC: Enabling VIMAGE in GENERIC

[Bjoern A. Zeeb]

On 19 Nov 2014, at 03:28 , Craig Rodrigues rodr...@freebsd.org wrote:

 
 (6)  Ask clusteradm to run one of the machines they use
  for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide
  feedback.

For people to use pf with VIMAGE we first MUST have the security fix imported 
that I pointed out a couple of times in the past.

It won’t matter on the firewalls with just a VIMAGE enabled kernel but using 
VIMAGE + pf inside a jail (once that really works if it doesn’t already) will 
allow everyone how can administer pf inside the jail to take over the entire 
machine otherwise.

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: RFC: Enabling VIMAGE in GENERIC

[Bjoern A. Zeeb]

On 19 Nov 2014, at 23:14 , Craig Rodrigues rodr...@freebsd.org wrote:

 On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney j...@funkthat.com wrote:
 
 
 Yes, we need a man page talking about this feature first, how to enable
 it, compile it into the kernel, how to manage it, what subsystems it
 interacts w/, what sysctl nodes it provides, etc.
 
 
 Marko,
 
 Do you have any text which can be put into a vnet(9) man page?
 It doesn't have to be perfect, but just something that we can start from.
 
 I tried looking at some of the notes and presentations that you have done
 on VIMAGE:
 https://wiki.freebsd.org/?action=fullsearchcontext=180value=VIMAGEtitlesearch=Titles
 
 but didn’t see anything that could be readily turned into a man page.


https://people.freebsd.org/~bz/20100530-02.vnet.9.html

The man page should be in that perforce branch you converted to github.


— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: RFC: Enabling VIMAGE in GENERIC

[Bjoern A. Zeeb]

On 17 Nov 2014, at 11:20 , Willem Jan Withagen w...@digiware.nl wrote:

 I think I understand your critique, but then on the other hand I wonder
 where the reluctance is As I read it, things are going to be enabled
 in CURRENT only (for the time). Which is exactly for the reasons you
 worry about: Is it going to be reliable enough??

No, the answer to that still is “no” in it’s current state and we know that.

I think one of the main problems is that no one has been able to pull the
thing to the end in the last three years.  Why should it happen within 6 weeks 
now?

I think it would be a really good idea to do that but the current TODO list,
I think, is by far not sufficing.

There’s a second problem we’ll hit in that same timeframe:  general network
stack breakage;  we’ll hit the times when we’ll not be sure if things broke
because of VIMAGE or are also broken in the normal network stack.   There’ll
be a lot of regression test writing and debugging to be done.


That all said, I’d like to see it happen as well, but I’d love to have a lot
of the issues being addressed first before putting a date on it to enable
it in GENERIC in HEAD.

/bz

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD]

[Bjoern A. Zeeb]

On 06 Nov 2014, at 01:10 , George Neville-Neil g...@neville-neil.com wrote:

 On 5 Nov 2014, at 9:20, Alexander V. Chernikov wrote:
 
 On 05.11.2014 19:39, George Neville-Neil wrote:
 Howdy,
 
 Last night (Pacific Time) I committed a change so that GENERIC, on HEAD has 
 the netmap
 device enabled.  This is to increase the breadth of our testing of that 
 feature prior
 to the release of FreeBSD 11.
 
 In two weeks I will enable IPSec by default, again in preparation for 11.
 Please don't.
 
 While I love to be able to use IPSEC features on unmodified GENERIC kernel, 
 simply enabling
 IPSEC is not the best thing to do in terms of performance.
 
 Current IPSEC locking model is pretty complicated and is not scalable enough.
 It looks like it requires quite a lot of man-hours/testing to be reworked to 
 achieve good performance and I'm not sure
 if making it enabled by default will help that.
 
 Current IPv4/IPv6 stack code with some locking modifications is able to 
 forward 8-10MPPS on something like 2xE2660.
 I'm in process of merging these modification in proper way to our HEAD, 
 progress can be seen in projects/routing.
 While rmlocked radix/lle (and ifa_ref / ifa_unref, and bunch of other) 
 changes are not there yet, you can probably get
 x2-x4 forwarding/output performance for at least IPv4 traffic (e.g. 2-3mpps 
 depending on test conditions).
 
 In contrast, I haven't seen IPSEC being able to process more than 200kpps 
 for any kind of workload.
 
 What we've discussed with glebius@ and jmg@ at EuroBSDCon was to modify PFIL 
 to be able to monitor/enforce
 hooks ordering and make IPSEC code usual pfil consumer. In that case, 
 running GENERIC with IPSEC but w/o any SA
 won't influence packet processing path.  This also simplifies the process of 
 making IPSEC loadable.
 
 
 How soon do you think the pfil patch would be ready?  That sounds like a good 
 first step
 towards making all this enabled in HEAD so that we can make sure that IPSec 
 gets the broad
 testing that it needs.

I don’t think making IPsec an pfil consumer is actually feasible but that’s a 
different story.


 Also, if folks who know about these problems can send workloads and test 
 descriptions to the
 list that would be very helpful.
 
 Specific drivers and hardware types would be most helpful as this may be 
 device related
 as well.
 
 I will turn this on on some machines in the network test lab to see what I 
 can see.

What you would want for the moment is a single read-mostly (read-lockless, 
read-non-atomic) integer that tells you if you have any policy in the system;  
that’s for your branch statement.   That’s probably the closest you can get to 
enabling it cheaply in GENERIC without doing much.

There’s a tradeoff in that for a few packets the policy might not be effective 
immediately but given the amount of time it takes to “install” the policy 
thinking about any instant real-time guarantees here is not feasible anyway.


Just my 2cts.

Bjoern


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Enabling VIMAGE by default for FreeBSD 11?

[Bjoern A. Zeeb]

On 16 Oct 2014, at 08:52 , Dag-Erling Smørgrav d...@des.no wrote:

 Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net writes:
 Also if people are seriously thinking about virtualising pf we need to
 import the openbsd/apple pf fix from a few years ago because otherwise
 people in virtualised stacks with a /dev/pf can do ugly things.  I
 think it’s been this one:
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3830
 
 There are other serious issues with our current pf (checksum corruption)
 which I think can only be resolved by importing a newer version.

Sorry, but you lost context.  I was talking about security implications in 
VIMAGE context, not about random bugs.

— 
Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org