Re: ping -R output?

[Peter Libassi]

like this? ( ping from 192.168.3.1 -> (192.168.3.2/172.16.42.1) -> 172.16.42.2

root@bsd1:~ # ping -R 172.16.42.2
PING 172.16.42.2 (172.16.42.2): 56 data bytes
64 bytes from 172.16.42.2: icmp_seq=0 ttl=63 time=1.280 ms
RR: 172.16.42.1
172.16.42.2
192.168.3.2
192.168.3.1
64 bytes from 172.16.42.2: icmp_seq=1 ttl=63 time=1.238 ms  (same route)
64 bytes from 172.16.42.2: icmp_seq=2 ttl=63 time=1.100 ms  (same route)
64 bytes from 172.16.42.2: icmp_seq=3 ttl=63 time=1.210 ms  (same route)
64 bytes from 172.16.42.2: icmp_seq=4 ttl=63 time=1.156 ms  (same route)

/Peter

> 14 okt. 2020 kl. 09:05 skrev Julian Elischer :
> 
> Can someone send me the output of a ping -R , starting with FreeBSD machine, 
> through a second FreeBSD machine and bouncing back from a third FreeBSD 
> machine?  I don't have three in a row like that anywhere. Probably best to 
> send it back through the list so I people can see if i get an answer.
> 
> 
> Thanks, Julian
> 
> 
> 
> ___
> 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"

wireguard integration D26137 connectivity test

[Peter Libassi]

I can confirm that the issue reported in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247853 
 is now resolved.

Thanks
Peter
___
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"

wireguard integration D26137 test on 13-CURRENT r364973

[Peter Libassi]

I had a first look at the latest version of the wireguard kernel integration. 
There was some findings that may need attention.

buildkernel stops with kernel option INVARIANTS enabled:

--- all_subdir_if_wg ---
/usr/src/sys/dev/if_wg/module/if_wg_session.c:1639:22: error: unused variable 
'e' [-Werror,-Wunused-variable]
struct wg_endpoint *e = wg_mbuf_endpoint_get(m);
^
2 errors generated.
*** [if_wg_session.o] Error code 1


buildkernel KERNCONF="GENERIC-NODEBUG" works fine.

I managed to figure out these options to the ifconfig command:

# ifconfig wg create private-key AtT4BNuidrJrDGZUH1Ddd4e6D0HMCq3Z+KawQVZQqXU= 
listen-port  peer public-key bmUgcaOtlEFcIoSlwPQ3qO/c14nJHYr+a7Ms/kJmOFA= 
endpoint 192.168.4.4: allowed-ips 10.2.3.0/24

which seems to get everything in place. However peer-list shows the allowed ips 
in a funny way:
# ifconfig wg0 peer-list

[Peer]
PublicKey = bmUgcaOtlEFcIoSlwPQ3qO/c14nJHYr+a7Ms/kJmOFA
Endpoint = 192.168.4.4:
AllowedIPs = 0.0.10.2/24

and if you specify two allowed-ips in the wg create peer section it gets worse:
# ifconfig wg create ……. allowed-ips 10.2.3.0/24 allowed-ips 10.11.12.0/24
# ifconfig wg0 peer-list

[Peer]
PublicKey = bmUgcaOtlEFcIoSlwPQ3qO/c14nJHYr+a7Ms/kJmOFA
Endpoint = 192.168.4.4:
AllowedIPs = 0.0.10.11/24, 0.0.10.11/24


Otherwise this looks really nice! Next i’ll try some connectivity tests.

/Peter


___
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: ip(8) in base

[Peter Libassi]

From a consumer view I think we should be conservative and not add any 
additional commands that operates in an area where there already exists well 
known commands. Not sure i understand what new features you are contributing, 
but the sound of it i guess it has to do with IP routing and fib’s. If this is 
the case i would like to see this introduced in to route(8) and netstat(1)

/Peter

> 16 aug. 2020 kl. 11:11 skrev Alexander V. Chernikov :
> 
> I want to introduce ip(8) or something similar in base.
> Basically, I need some userland tool to explicitly operates on nexthops, 
> nexthop groups and fib lookup algorithms.
> 
> The existing tools are not well suited for the job: route(8) may be a 
> candidate, but (a) it would either add another bunch of  options or 
> drastically change the tool by introducing [route nhop add], [route nhgroup 
> add] and (b) listing is traditionally done by netstat(8).
> 
> I feel like there is a need of some cli tool that provides the ability to 
> easily extend it by having separate namespaces for each sub-command (hello, 
> ifconfig).
> 
> Naming is hard. I can, for example, use "rt" as a name to address my use 
> cases.
> However, given the kernel interfaces for managing nexthops/nexhop groups are 
> the same as with routes/arp/ndp, why not spending some additional time and 
> support operating on routes and neighbors and name it ip?
> 
> Though, that arises multiple questions.
> Are we comfortable with ip(8) as a name in general?
> If we are, what’s our take on having the compatible interface with Linux 
> ip(8)? 
> 
> Any comments/feedback is welcome :-)
> 
> 
> Appendix 
> List of commands I need implemented
> 
> cmd [-46m] nhop create [gw XX] [iface YYY] [mtu YYY] [reject] [proxyfib Y] 
> [fib X][ipv4] [ipv6]
> cmd [-46m] nhop delete nhop_id
> cmd -46m nhop list 
> cmd -j nhop list # json 
> 
> cmd -46m nhgroup create nhops 1,2,3,4,5,6 [fib X]
> cmd -46 nhgroup create nhops 1=100,2=100,3=200,4=100 [proxyfib Y][fib X]
> cmd -46 nhroup list
> cmd -46 nhgroup delete nhgroup_id
> 
> cmd -46 fib algo list
> cmd -46 fib algo set algo dpdk_lpm6 fib 0
> cmd -46 fib algo set algo auto fib 0
> 
> 
> /Alexander
> ___
> 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: Wireguard kernel module

[Peter Libassi]

Ok!, Then I would need instructions how i get that diff in to the src tree :-) 
any pointers to documentation will be helpful.

Thanks
Peter

> 25 juli 2020 kl. 12:34 skrev Goran Mekić :
> 
> On Sat, Jul 25, 2020 at 12:32:00PM +0200, Peter Libassi wrote:
>> I got information that there are work on a kernel module for Wireguard 
>> https://reviews.freebsd.org/D25425 <https://reviews.freebsd.org/D25425>
>> 
>> Where can I download and test this?  I have a spare amd64 currently running 
>> 13.0-CURRENT r363439 available for test purposes.
> There's a "Download Raw Diff" on the right of the page you linked. Or
> are you looking for something else?
> 
> Regards,
> meka

___
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"

Wireguard kernel module

[Peter Libassi]

I got information that there are work on a kernel module for Wireguard 
https://reviews.freebsd.org/D25425  

Where can I download and test this?  I have a spare amd64 currently running 
13.0-CURRENT r363439 available for test purposes.

/Peter


___
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

[Peter Libassi]

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 


/Peter


> 21 juli 2020 kl. 22:23 skrev John-Mark Gurney :
> 
> Marko Zec wrote this message on Tue, Jul 21, 2020 at 11:31 +0200:
>> On Tue, 21 Jul 2020 02:16:55 -0700
>> John-Mark Gurney  wrote:
>> 
>>> I'm running:
>>> FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362596: Thu Jun 25
>>> 05:02:51 UTC 2020
>>> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>>> amd64
>>> 
>>> and I'm working on improve the if_ure driver.  I've put together a
>>> little script that I've attached that I'm using to test the driver..
>>> It puts a couple ue interfaces each into their own jail, configures
>>> them, and tries to pass traffic.  This assumes that the two interfaces
>>> are connected together.
>>> 
>>> Pretty regularly when destroying the jails, I get the following
>>> panic: CURVNET_SET at /usr/src/sys/netinet/in_mcast.c:626
>>> inm_release() curvnet=0 vnet=0xf80154c82a80
>> 
>> Perhaps the attached patch could help? (disclaimer: not even
>> compile-tested)
> 
> The patch compiled, but it just moved the panic earlier than before.
> 
> #4  0x80bc2123 in panic (fmt=)
>at ../../../kern/kern_shutdown.c:839
> #5  0x80d61726 in inm_release_task (arg=, 
>pending=) at ../../../netinet/in_mcast.c:633
> #6  0x80c2166a in taskqueue_run_locked (queue=0xf800033cfd00)
>at ../../../kern/subr_taskqueue.c:476
> #7  0x80c226e4 in taskqueue_thread_loop (arg=)
>at ../../../kern/subr_taskqueue.c:793
> 
> Now it panics at the location of the new CURVNET_SET and not the
> old one..
> 
> Ok, decided to dump the contents of the vnet, and it looks like
> it's a use after free:
> (kgdb) print/x *(struct vnet *)0xf8012a283140
> $2 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de}, 
> vnet_magic_n = 0xdeadc0de, 
>  vnet_ifcnt = 0xdeadc0de, vnet_sockcnt = 0xdeadc0de, vnet_state = 0xdeadc0de, 
> vnet_data_mem = 0xdeadc0dedeadc0de, 
>  vnet_data_base = 0xdeadc0dedeadc0de, vnet_shutdown = 0xde}
> 
> The patch did seem to make it happen quicker, or maybe I was just more
> lucky this morning...
> 
>>> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
>>> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:394
>>> #2  0x80bc6250 in kern_reboot (howto=260)
>>>at /usr/src/sys/kern/kern_shutdown.c:481
>>> #3  0x80bc66aa in vpanic (fmt=, ap=>> out>) at /usr/src/sys/kern/kern_shutdown.c:913
>>> #4  0x80bc6403 in panic (fmt=)
>>>at /usr/src/sys/kern/kern_shutdown.c:839
>>> #5  0x80d6553b in inm_release (inm=0xf80029043700)
>>>at /usr/src/sys/netinet/in_mcast.c:630
>>> #6  inm_release_task (arg=, pending=)
>>>at /usr/src/sys/netinet/in_mcast.c:312
>>> #7  0x80c2521a in taskqueue_run_locked
>>> (queue=0xf80003116b00) at /usr/src/sys/kern/subr_taskqueue.c:476
>>> #8  0x80c26294 in taskqueue_thread_loop (arg=)
>>>at /usr/src/sys/kern/subr_taskqueue.c:793
>>> #9  0x80b830f0 in fork_exit (
>>>callout=0x80c26200 , 
>>>arg=0x81cf4f70 ,
>>> frame=0xfe0049e99b80) at /usr/src/sys/kern/kern_fork.c:1052
>>> #10 
>>> (kgdb) 
>>> 
>>> I have the core files so I can get additional information.
>>> 
>>> Let me know if you need any additional information.
>>> 
>> 
> 
>> Index: sys/netinet/in_mcast.c
>> ===
>> --- sys/netinet/in_mcast.c   (revision 363386)
>> +++ sys/netinet/in_mcast.c   (working copy)
>> @@ -309,8 +309,10 @@
>>  IN_MULTI_LOCK();
>>  SLIST_FOREACH_SAFE(inm, &inm_free_tmp, inm_nrele, tinm) {
>>  SLIST_REMOVE_HEAD(&inm_free_tmp, inm_nrele);
>> +CURVNET_SET(inm->inm_ifp->if_vnet);
>>  MPASS(inm);
>>  inm_release(inm);
>> +CURVNET_RESTORE();
>>  }
>>  IN_MULTI_UNLOCK();
>> }
> 
> 
> -- 
>  John-Mark Gurney Voice: +1 415 225 5579
> 
> "All that I will do, has been done, All that I have, has not."
> ___
> 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"