Re: bridge(4) and IPv6 broken?

[Jan Bramkamp]

On 02.01.24 00:40, Lexi Winter wrote:

hello,

i'm having an issue with bridge(4) and IPv6, with a configuration which
is essentially identical to a working system running releng/14.0.

ifconfig:

lo0: flags=1008049 metric 0 mtu 16384
options=680003
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
groups: lo
nd6 options=21
pflog0: flags=1000141 metric 0 mtu 33152
options=0
groups: pflog
alc0: flags=1008943 
metric 0 mtu 1500

options=c3098
ether 30:9c:23:a8:89:a0
inet6 fe80::329c:23ff:fea8:89a0%alc0 prefixlen 64 scopeid 0x3
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=1
wg0: flags=10080c1 metric 0 mtu 1420
options=8
inet 172.16.145.21 netmask 0x
inet6 fd00:0:1337:cafe:::829a:595e prefixlen 128
groups: wg
tunnelfib: 1
nd6 options=101
bridge0: flags=1008843 metric 
0 mtu 1500
options=0
ether 58:9c:fc:10:ff:b6
inet 10.1.4.101 netmask 0xff00 broadcast 10.1.4.255
inet6 2001:8b0:aab5:104:3::101 prefixlen 64
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap0 flags=143
ifmaxaddr 0 port 6 priority 128 path cost 200
member: alc0 flags=143
ifmaxaddr 0 port 3 priority 128 path cost 55
groups: bridge
nd6 options=1
tap0: flags=9903 metric 0 mtu 1500
options=8
ether 58:9c:fc:10:ff:89
groups: tap
media: Ethernet 1000baseT 
status: no carrier
nd6 options=29
IPv6 enabled interfaces need a link-local address for normal operation. 
Please set the auto-linklocal flag on the bridge and try again.

Re: Office Hours today @ 18:00 UTC - Core Candidates

[Jan Bramkamp]

On 28.05.20 04:01, Philip Paeps wrote:


On 2020-05-27 22:35:14 (+0800), Allan Jude wrote:

Sorry for the late notice, I thought I sent this last week.

After the slate of candidates was finalized last week, I invited all of
them to join a live stream today at 18:00 UTC to answer questions from
the FreeBSD Community.


Do you ever plan to schedule one of these at a time that works for 
those of us in the eastern hemisphere?


18:00 UTC is 02:00 in Hong Kong, Taiwan and China, 03:00 in Japan and 
04:00 in the east of Australia to name but a couple of places where we 
have sizeable (or at least non-zero) populations of FreeBSD developers.
If I remeber correctly the second office hour our was held at 02:00 UTC 
and wasn't well attended. Are you asking for future office hours to 
rotate between a set of timeslots so that everyone has to suffer equally 
or for chance to pose questions to the core candidates?

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

Re: CFT: if_bridge performance improvements

[Jan Bramkamp]

On 16.04.20 08:34, Pavel Timofeev wrote:


вт, 14 апр. 2020 г., 12:51 Kristof Provost :


Hi,

Thanks to support from The FreeBSD Foundation I’ve been able to work
on improving the throughput of if_bridge.
It changes the (data path) locking to use the NET_EPOCH infrastructure.
Benchmarking shows substantial improvements (x5 in test setups).

This work is ready for wider testing now.

It’s under review here: https://reviews.freebsd.org/D24250

Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
Patches for stable/12:
https://people.freebsd.org/~kp/if_bridge/stable_12/

I’m not currently aware of any panics or issues resulting from these
patches.

Do note that if you run a Bhyve + tap on bridges setup the tap code
suffers from a similar bottleneck and you will likely not see major
improvements in single VM to host throughput. I would expect, but have
not tested, improvements in overall throughput (i.e. when multiple VMs
send traffic at the same time).

Best regards,
Kristof


Hi!
Thank you for your work!
Do you know if epair suffers from the same issue as tap?


As Kirstof Provost said if_epair locks has per CPU locks, but a problem 
exists a layer about the epair driver. At leas on FreeBSD 12.0 and 12.1 
all the packet processing happens in a single netisr thread that becomes 
CPU bound and limits how fast useful traffic can move through epair 
interfaces. Afaik TCP doesn't benifit from multiple netisr threads, but 
unorderer protocols (e.g. UDP) could profit from multiple threads.



I have only tested with iperf (using multiple connections) between the 
FreeBSD 12.x host and a vnet enabled jail connected via an epair 
interface and maxed out at about 1-2Gb/s depending on the CPUs single 
threaded throughput.


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

Re: FreeBSD Office Hours: April 1, 2020 18:00 UTC

[Jan Bramkamp]

On 02.04.20 09:56, Ihor Antonov wrote:

On 2020-04-01 16:01, Allan Jude wrote:

On 2020-03-29 20:25, Allan Jude wrote:

Our first FreeBSD Office Hours event was a success with over 60 people
in attendance.

I've not had time to edit and post the video yet, but it is available in
the DVR buffer on the streaming page:

https://live.freebsd.org/FreeBSD/officehours/

Hi Allan,

Is there a recording available? I missed the event :(


The recording is at:https://live.freebsd.org/FreeBSD/officehours/ .

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

Re: TLS certificates for NFS-over-TLS floating client

[Jan Bramkamp]

On 20.03.20 20:45, John-Mark Gurney wrote:

Jan Bramkamp wrote this message on Fri, Mar 20, 2020 at 18:51 +0100:

On 20.03.20 02:44, Russell L. Carter wrote:

Here I commit heresy, by A) top posting, and B) by just saying, why
not make it easy, first, to tunnel NFSv4 sessions through
e.g. net/wireguard or sysutils/spiped?  NFS is point to point.
Security infrastructure that actually works understands the shared
secret model.

VPN tunneling doesn't provide the security that most people thinks it
does...  It requires complicated configuration, and often doesn't
provide e2e protections.
I fully agree that IPsec is a bitch to configure, but IPsec tranport 
mode between NFSv4 client and server would provide end to end encryption.

Why not use IPsec in transport mode instead of a tunnel? It avoids
unnecessary overhead and is already implemented in the kernel. It should
be enough to "just" require IPsec for TCP port 2049 and run a suitable
key exchange daemon.

Because IPsec is a PITA to configure and work, and lots of consumer OSes
don't make it at all easy.

Does any consumer OS support NFSv4 over TLS?

Also, you forget that FreeBSD has ktls, which usees the same crypto
offload engine that IPsec does, so it will effectively have similar
overhead, and might actually perform better due to TLS having a 16k
record encryption size vs IPsec limiting itself to packet size, usually
1500, though possibly 9k if you're using jumbo frames...
I compared IPsec to userspace tunnels like spiped or wireguard-go not 
kTLS. If kTLS can use LRO/TSO etc. it would avoid even more overhead.

I fully support doing NFS over TLS.
I would love to run NFS over TLS, but it isn't implemented yet and afaik 
kTLS only accelerates TLS sending and would require a userspace proxy to 
receive TLS at the moment while IPsec transport mode is just a nasty 
fight with strongSwan away.

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

Re: TLS certificates for NFS-over-TLS floating client

[Jan Bramkamp]

On 20.03.20 02:44, Russell L. Carter wrote:

Here I commit heresy, by A) top posting, and B) by just saying, why
not make it easy, first, to tunnel NFSv4 sessions through
e.g. net/wireguard or sysutils/spiped?  NFS is point to point.
Security infrastructure that actually works understands the shared
secret model.


Why not use IPsec in transport mode instead of a tunnel? It avoids 
unnecessary overhead and is already implemented in the kernel. It should 
be enough to "just" require IPsec for TCP port 2049 and run a suitable 
key exchange daemon.


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

Re: kqueue send over unix socket?

[Jan Bramkamp]

On 12.03.19 22:52, Aki Tuomi wrote:
> Hi!
> 
> I am trying exactly that.

As others have already stated kqueue file descriptors can leave the
process that created them (neither through file descriptor passing nor
through inheritance). Can you tell us why you want to send the kqueue
file descriptor to an other process? What do you want to accomplish?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ix SR-IOV working

[Jan Bramkamp]

On 10.08.18 04:38, Pete Wright wrote:
> hello,
> 
> i have a newly provisioned VPS system from Vultr which comes stock with
> a 10Gbe ix interface:
> 
> ix0@pci0:1:0:0: class=0x02 card=0x082315d9 chip=0x15578086 rev=0x01
> hdr=0x00
>     vendor = 'Intel Corporation'
>     device = '82599 10 Gigabit Network Connection'
>     class  = network
>     subclass   = ethernet
> 
> 
> it is currently running 11-STABLE but was curious if there are any
> reports of people successfully running SR-IOV under CURRENT with this
> hardware and driver?  On both 11.2-RELEASE and 11-STABLE, after running
> iovctl to bring up the interface results in the NIC hanging - for
> example like so:
> 
> $ sudo iovctl -C -f /etc/iovctl.conf
> iovctl: Failed to configure SR-IOV: No space left on device
> 
> 

I got the same error from a X540-AT2, but it didn't hang afterward. The
NIC physical function worked just fine, but I found no way to create
virtual functions. In the end i grabbed two dual port 1Gb/s cards and
passed those to bhyve.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE

[Jan Bramkamp]

On 28.02.18 18:03, Hadi Rezaee wrote:

Hello there,
My laptop is running FreeBSD-12 CURRENT, and i hadnt any problem with my 
graphic before upgrading drm-next (g20180117_3 -> 4.11.g20180224). But 
now it getting failed. Tried to build from source, but same result.

Laptop model: Lenovo E470


I just updated both the 12-current base system and the 
graphics/drm-next-kmod port on my Thinkpad T470s. The resulting system 
works except for the already documented regression in the VA API 
affecting hardware accelerated video playback in mpv.

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

Re: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE

[Jan Bramkamp]

On 25.02.18 16:48, Johannes M Dieterich wrote:

Dear all,

Please CC me as I am not subscribed.

On behalf of the FreeBSDDesktop team and thanks to the tireless efforts
of Johannes Lundberg and Hans Petter Selasky (hselasky), I am pleased to
report that the graphics/drm-next-kmod port just received an update to
Linux level 4.11 KMS/DRM for amdgpu, radeon, and i915 for both recent
CURRENT and 11-STABLE.

We have tested this on a range of hardware ourselves:
* Haswell
* Broadwell
* Skylake
* Evergreen
* Kaveri (both radeon and amgpu KMS)
* Carrizo
* Polaris

Needless to say, the possible space of hardware this could run on is
significantly larger. Hence, if you find issues and/or want to propose
patches, please do so at our development github:

https://github.com/FreeBSDDesktop/kms-drm

We absolutely do welcome contributions!

Johannes


Thx for your hard work. The drm-next-kmod port enabled me to finally 
replace my ageing Thinkpad X220 with newer hardware.


The latest update (g20180117_3 -> 4.11.g20180224) to the drm-next-kmod 
port introduced a regression which causes Xorg on my T470s running 
12-current from a few days ago to fail at startup stating that it didn't 
find any screen.

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

Re: openssl in base should install c_rehash

[Jan Bramkamp]

On 08.02.18 14:24, Ulrich Spörlein wrote:

Hey,

c_rehash has somehow disappeared from the base system. We still install the
manpage it seems, but the tool itself is missing. Can we have that back?


root@acme:/etc/ssl# locate c_rehash
...
/usr/share/openssl/man/man1/c_rehash.1.gz
/usr/src/crypto/openssl/doc/apps/c_rehash.pod
/usr/src/secure/usr.bin/openssl/man/c_rehash.1


The port seems to install it just fine:

root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
/usr/ports/security/openssl/pkg-plist:bin/c_rehash
/usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz

It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm reading the
history with git pickaxe right).


The LibreSSL port lacks a c_rehash script as well. Putting c_rehash back 
into base wouldn't solve the problem because it requires Perl 5.

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

Re: Lenovo T470s Questions

[Jan Bramkamp]

On 02.02.18 03:13, Bridger Dyson-Smith wrote:

Hi list and Michael -

I received a T470s at work and decided to jump into the CURRENT end of the
FreeBSD pool. I have a weird acpi_ibm issue and I'm not sure where to start
trying to diagnose the issue.

# uname -a
FreeBSD spanner 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328126: Thu Jan 18
15:25:44 UTC 2018 r...@releng3.nyi.freebsd.org:/
usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

I've loaded acpi_ibm via /boot/loader.conf:
acpi_ibm_load="YES"

and the module shows as being loaded:
# kldstat | grep acpi_ibm
81 0x8278e000 7570 acpi_ibm.ko

However, I don't have any of the sysctl knobs available; e.g.
# sysctl -a | grep acpi_ibm
#

or
  # sysctl dev.acpi_ibm.0.fan_speed
sysctl: unknown oid 'dev.acpi_ibm.0.fan_speed'

I've (tried) to look through the commit messages on svn-src-head, but I'm
not seeing anything specifically related to acpi work, or I just don't know
what I'm looking at (a definite possibility).


I made the same discovery on my T470s running FreeBSD 12-CURRENT. It has 
been a long time since Thinkpads were designed by IBM. The fan control 
works just fine without any special purpose module. The acpi_ibm module 
main usecase for me was always handling the special button events, but 
these days they are just secondary function on the regular function 
keys. Who needs an additional row of buttons on >2k€ laptop when you can 
waste the space on a large useless trackpad.

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

Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host

[Jan Bramkamp]

On 06.09.17 17:45, tech-lists wrote:

On 06/09/2017 16:23, Jan Bramkamp wrote:

I'm running OpenBSD 6.1 (with two virtual CPU cores) as bhyve guest on
FreeBSD 11.1. The only problem I encountered is that it requires an
external grub bootloader because the OpenBSD EFI boot code is
incompatible with the bhyve EFI boot ROM.

Hi,

Which external grub bootloader did you use? Was it sysutils/grub2-bhyve ?
I use the sysutils/grub2-bhyve port to load the OpenBSD kernel and runit 
for process supervision to keep the bhyve guest running unless the bhyve 
exit code signals an intend to perform shutdown. This allows the VMs to 
reboot themselves.

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

Re: openbsd 6.0 or 6.1 guest on freebsd-12 (current) host

[Jan Bramkamp]

On 05.09.17 19:21, tech-lists wrote:

Hello freebsd-virtualization@

[also cc'd to freebsd-current],

I'd like to run openbsd 6.0 or 6.1 guest under a 12-current bhyve
system. I'd like it to run two cpus, so to use the openbsd smp kernel. I
can see, from searching various mailing lists that there have been
issues in getting openbsd to boot. Have these issues been fixed?

Also, is there a howto for this? I found one here:
http://www.allanjude.com/bsd/virtualization-host-bhyve.html but there's
no date on the document, it's not on the official freebsd sites and so
have no idea if the information is still current.

I realise that HardenedBSD has fixed some issues with this, but I can't
easily change the host to that OS unfortunately.

thanks,
I'm running OpenBSD 6.1 (with two virtual CPU cores) as bhyve guest on 
FreeBSD 11.1. The only problem I encountered is that it requires an 
external grub bootloader because the OpenBSD EFI boot code is 
incompatible with the bhyve EFI boot ROM.

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

Re: Passwordless accounts vi ports!

[Jan Bramkamp]

On 11/08/16 07:05, O. Hartmann wrote:

I just checked the security scanning outputs of FreeBSD and found this
surprising result:

[...]
Checking for passwordless accounts:
polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin
pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin
saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh
clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin
bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin
[...]

Obviously, some ports install accounts but do not secure them as there is an
empty password.


Are you certain that the ports didn't use "*" as crypted hash which 
isn't a valid hash for any supported algorithm and prevents password 
based authentication for the account?


FreeBSD also uses two passwd files (and compiles them into databases for 
fast lookups). The old /etc/passwd is world readable but contains no 
passwords and the real /etc/master.passwd which is only accessible by 
root. If you run `getent passwd`  the missing password field is replaced 
with "*" which can confuse buggy scripts.

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

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Jan Bramkamp]

On 18/06/16 17:15, Alan Somers wrote:

On Thu, Jun 16, 2016 at 7:20 AM, Chris H  wrote:

On Wed, 15 Jun 2016 08:03:55 -0400 Nikolai Lifanov 
wrote


On 06/14/2016 21:05, Marcelo Araujo wrote:

2016-06-15 8:17 GMT+08:00 Chris H :


On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo 
wrote


Hey,

Thanks for the CFT Craig.

2016-06-09 14:41 GMT+08:00 Xin Li :




On 6/8/16 23:10, Craig Rodrigues wrote:

Hi,

I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
current.

In latest current, it should be possible to put in /etc/rc.conf:

nis_ypldap_enable="YES"
to activate the ypldap daemon.

When set up properly, it should be possible to log into FreeBSD, and

have

the backend password database come from an LDAP database such
as OpenLDAP

There is some documentation for setting this up, but it is OpenBSD

specific:


http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
http://puffysecurity.com/wiki/ypldap.html#2

I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
information
does not apply.  I figure that openldap from ports should work fine.

I was wondering if there is someone out there familiar enough with

LDAP

and has a setup they can test this stuff out with, provide feedback,

and

help
improve the documentation for FreeBSD?


Looks like it would be a fun weekend project.  I've cc'ed a potential
person who may be interested in this as well.

But will this worth the effort? (I think the current implementation
would do everything with plaintext protocol over wire, so while it
extends life for legacy applications that are still using NIS/YP, it
doesn't seem to be something that we should recommend end user to use?)



I can see two good point to use ypldap that would be basically for users
that needs to migrate from NIS to LDAP or need to make some integration
between legacy(NIS) and LDAP during a transition period to LDAP.

As mentioned, NIS is 'plain text' not safe by its nature, however there

are

still lots of people out there using NIS, and ypldap(8) is a good tool to
help these people migrate to a more safe tool like LDAP.





I would also be interested in hearing from someone who can see if
ypldap can work against a Microsoft Active Directory setup?


Cheers,



All my tests were using OpenLDAP, I used the OpenBSD documentation to

setup

everything, and the file share/examples/ypldap/ypldap.conf can be a good
start to anybody that wants to start to work with ypldap(8).

Would be nice hear from other users how was their experience using ypldap
with MS Active Directory and perhaps some HOWTO how they made all the

setup

would be amazing to have.

Also, would be useful to know who are still using NIS and what kind of
setup(user case), maybe even the reason why they are still using it.


Honestly, I think the best way to motivate people to do the right
thing(tm) Would be to remove Yellow Pages from the tree, entirely. :-)
It's been dead for *years*, and as you say, isn't safe, anyway..



Yes, I have a plan for that, but I don't believe it will happens before
FreeBSD 12-RELEASE.



Please don't, at least for now. NIS is fast, simple, reliable, and works
on first boot without additional software. I have passwords in
Kerberos, so the usual cons doesn't apply. This is very valuable to me.

It's not hurting anyone. What's the motivation behind removing it?


In all honesty, my comment was somewhat tongue-in-cheek. But from
a purely maintenance POV, at this point in time. I think the Yellow
Pages are better suited for the ports tree, than in $BASE.



It will be hard to wean people off of NIS as long as KGSSAPI is
disabled in GENERIC.  Does anybody know why it isn't enabled by
default?


Because it's just a `kldload kgssapi` away. Put it in loader.conf or 
rc.conf depending on your needs/preferences.

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

Re: 11.0-ALPHA4 and VIMAGE

[Jan Bramkamp]

On 20/06/16 18:05, Bjoern A. Zeeb wrote:

Hi,

On 20 Jun 2016, at 15:37, Ernie Luzar wrote:


Hello list;

I have installed 11.0-ALPHA4-i386-20160617-r301975 to test VIMAGE.
I have read previous list posts saying vimage was going to be part of
the base system in 11.0.  When I configure a jail with vnet I get a
error typical of vimage not being compiled into the kernel.

To me it looks like vimage is not part of the base system in 11.0.

What is the status of vimage in 11.0?


I am not sure anyone said that it would be in GENERIC for 11.0.

The plan is to have it more stable and leak a lot less memory possibly
and some bits made it in to HEAD over the last months already, another
patch for a top-down teardown is in the review system, and I am
currently working on fixing a lot of pf.


Is there any hope reliable VIMAGE support will make it into the 11.0 
release?

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

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Jan Bramkamp]

On 10/06/16 16:29, Peter Wemm wrote:

On 6/9/16 6:49 PM, Matthew Seaman wrote:

On 09/06/2016 18:34, Craig Rodrigues wrote:

There is still value to ypldap as it is now, and getting feedback from
users (especially Active Directory) would be very useful.
If someone could document a configuration which uses IPSEC or OpenSSH
forwarding, that would be nice.

In future, maybe someone in OpenBSD or FreeBSD will implement things
like
LDAP over SSL.


What advantages does ypldap offer over nss-pam-ldapd (in ports) ?
nss-pam-ldapd can use both ldap+STARTTLS or ldaps to encrypt data in
transit, and I find it works very well for using OpenLDAP as a central
account database.  I believe it works with AD, but haven't tried that
myself.

Cheers,

Matthew




We used nss-pam-ldapd quite successfully in the freebsd.org cluster
during our transition away from YP/NIS, for what it's worth.


Did you try the OpenLDAP nssov overlay? It replaces nslcd by 
reimplementing the protocol spoken between nslcd and nss_ldap/pam_ldap 
directly inside slapd. This allows slapd to cache or replicate the data 
locally without resorting to the broken nscd.

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

Re: CURRENT: ipfw: problems with timeouts and worse network performance

[Jan Bramkamp]

On 20/05/16 15:51, Vladimir Zakharov wrote:

On Fri, May 20, 2016, Jan Bramkamp wrote:

On 20/05/16 14:54, Vladimir Zakharov wrote:

Hello

On Fri, May 20, 2016, O. Hartmann wrote:

I reported earlier about broken pipes in ssh sessions to remote hosts,
which occur on an erratic basis. i'm investigating this problem now and
it seems that it is also ipfw-related, but I'm not sure. This problem
is present since a couple of weeks now.


Maybe this could help...

I've also experienced problems with broken pipes in ssh sessions some
time ago. Setting in sysctl.conf

net.inet.ip.fw.dyn_ack_lifetime=3600

fixed problem for me. I didn't experiment with the value though. So,
possibly, changing default value (300s) to 1 hour is overkill :).


By default the OpenSSH SSH client is configured to use TCP keepalives.
Those should produce enough packets at a short enough interval to keep
the dynamic IPFW state established.

Does your traffic pass through libalias?

I guess not. How can I be sure?


Libalias is used by ipfw and the old userland natd to implement IPv4 
NAT. It requires unmodified access to all packets including their 
headers. LRO and TSO coalesce packets to reduce save CPU time but the 
process is loses some of the information required by libalias. Unless 
your ruleset uses ipfw in-kernel NAT or diverts traffic to natd you 
don't have to worry about libalias.


Use `kldstat -v | grep libalias` to check for libalias in the running 
kernel and `pgrep natd` to search for running natd instances.

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

Re: CURRENT: ipfw: problems with timeouts and worse network performance

[Jan Bramkamp]

On 20/05/16 14:54, Vladimir Zakharov wrote:

Hello

On Fri, May 20, 2016, O. Hartmann wrote:

I reported earlier about broken pipes in ssh sessions to remote hosts,
which occur on an erratic basis. i'm investigating this problem now and
it seems that it is also ipfw-related, but I'm not sure. This problem
is present since a couple of weeks now.


Maybe this could help...

I've also experienced problems with broken pipes in ssh sessions some
time ago. Setting in sysctl.conf

net.inet.ip.fw.dyn_ack_lifetime=3600

fixed problem for me. I didn't experiment with the value though. So,
possibly, changing default value (300s) to 1 hour is overkill :).


By default the OpenSSH SSH client is configured to use TCP keepalives. 
Those should produce enough packets at a short enough interval to keep 
the dynamic IPFW state established.


Does your traffic pass through libalias?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HPN and None options in OpenSSH

[Jan Bramkamp]

On 24/01/16 15:50, Dag-Erling Smørgrav wrote:

Slawa Olhovchenkov  writes:

Can you do some small discurs about ssh+kerberos?
I am try to use FreeBSD with $HOME over kerberoized NFS.
For kerberoized NFS gssd need to find cache file "called
/tmp/krb5cc_, where  is the effective uid for the RPC
caller" (from `man gssd`).

sshd contrary create cache file for received ticket called
/tmp/krb5cc_XXX (random string, created by krb5_cc_new_unique). Is
this strong security  requirement or [FreeBSD/upstream] can be patched
(or introduce option) to use /tmp/krb5cc_ as cache file for
received ticket?


I wasn't aware of that.  It should be easy to patch, but in the
meantime, you can try something like this in .bashrc or whatever:

krb5cc_uid="/tmp/krb5cc_$(id -u)"
if [ -n "${KRB5CCNAME}" -a "${KRB5CCNAME}" != "${krb5ccuid}" ] ; then
 if mv "${KRB5CCNAME}" "${krb5ccuid}" ; then
 export KRB5CCNAME="${krb5ccuid}"
 else
 echo "Unable to rename krb5 credential cache" >&2
 fi
fi
unset krb5ccuid


If $KRB5CCNAME is set during PAM session setup than the pam_exec module 
might allow a reliable implementation along those lines:


  - Stop if $KRBCCNAME is invalid (klist -t)
  - Stop if /tmp/krb5cc_$UID is already valid and has enough time left
  - Copy the ticket to /tmp and rename it to /tmp/krb5cc_$UID.

Keep in mind that this approach leaves valid tickets in /tmp after the 
SSH session ends while OpenSSH normally does its best to tie forwarded 
tickets to a SSH session.

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

Re: IoT OS

[Jan Bramkamp]

On 21/01/16 17:19, Mathieu Prevot wrote:

Dear all,

I would like to connect several connected object (with homogeneous or
heterogenous hardare: intel edison,  samsung artik, apple AX, intel core,
etc) so the calculation needs, the storage/memory, the connection, etc are
decoupled; hence we can reach an ecosystem with several clouds.

How do you recommend to reach that ? from the kernel, a module, or
eventually a software ?


Your message contains neither enough information nor a precise enough 
question for anyone to provide you a helpful answer.


Please describe your problem in sufficient detail and reformulate your 
question. If you still think these mailing lists (current@ and hackers@) 
are a good audience for your question afterward ask them again.

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

Re: libXO-ification - Why - and is it a symptom of deeper issues?

[Jan Bramkamp]

On 15/11/15 13:54, Dan Partelly wrote:

2. I have seen the idea that this makes the information dumped by utilities in 
the base easily accessible programatically. OK, maybe it does , but
it doesn't fit with the current paradigm of "tool | filter | tool” at all. 
There are no tools able to accept JSON and filter it in any meaningful way, and I
dont see too many ppl changing their code to read JSON instead of text.  I 
don't even see the base tools changing. This output may be useful in corner 
cases only.


There is jq [https://stedolan.github.io/jq/]. You can think of it as sed 
+ awk + grep for streams of JSON objects.

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

Re: OpenSSH HPN

[Jan Bramkamp]

On 11/11/15 09:27, Ben Woods wrote:

On Wednesday, 11 November 2015, John-Mark Gurney  wrote:


Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:

I have to agree that there are cases when the NONE cipher makes sense,

and

it is up to the end user to make sure they know what they are doing.

Personally I have used it at home to backup my old FreeBSD server (which
does not have AESNI) over a dedicated network connection to a backup

server

using rsync/ssh. Since it was not possible for anyone else to be on that
local network, and the server was so old it didn't have AESNI and would
soon be retired, using the NONE cipher sped up the transfer

significantly.

If you have a trusted network, why not just use nc?



Honest answer: ignorance of how I can use netcat together with rsync.


Sounds like you're looking for rsyncd instead of rsync over ssh (minus 
encryption).

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

Re: request for crypto hardware...

[Jan Bramkamp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07.02.2015 03:35, John-Mark Gurney wrote:
 I have some plans to improve the opencrypto framework in FreeBSD
 later this year.  This will require invasive changes to the various
 drivers. So, I'd like to line up hardware/volunteers before then.
 
 If you would like to see your hardware tested and verified to work 
 with the new changes, please contact me w/ either a donation of 
 hardware, money to purchase hardware, or if you have hardware,
 that you volunteer to test changes.
 
 I currently have the following hardware: aesni
 
 I do not have the following hardware: hifn ubsec padlock (VIA C3,
 C7 and Eden) cesa (Marvell, missing man page) glxsb (AMD Geode LX,
 such as Sokris Net5501, missing man page) safe (SafeNet) sec
 (Freescale, missing man page) cryptocteon (Cavium Octeon, missing
 man page) nlmsec (mips/nlm/dev/sec/nlmsec.c, missing man page) 
 rmisec (mips/rmi/dev/sec/rmisec.c, missing man page)

I can send you some VIA C7 padlock hardware and test changes on a VIA
Nano.
Would an IGEL Thinclient with a 1GHz VIA C7 CPU, 256MiB DDR2 SO-DIMM
RAM, a CF slot, 2.5 PATA and PXE capable 100Mb/s Ethernet NIC help?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJU1j6VAAoJEL3T4KNA/nyDfuIP/1WPXyTbEq1sLEmGpYwUqlRm
GvYypRCbd1YitMUHOHVApUt19JznPNM72TpECUwacpUySfPj8DjErBMRWROd8WBv
mWCyA7OJ665NCIBiq/EZLkHPu0/ftDE78xfPYkVy69i+2nriqZdUTh2wOh5SH6hl
fm2ibph75fCbAB9ttUG+bdgU2wY+2xOVeSnv5AihwphvuRR89eWHHeyIGrKPH5b8
W3YwbNOQp4tPeZg6I5MokB5LMZsHV4DIfmSWzLq4Rd2h89ZsH83Kfe3k9bKJlLVc
Ft+w197G5rz0cq7dszWV+jcWbAOF4frzWLGrzIThEucic1tjeetkLAvSjp9xOK30
pmPgMN/UrfWGBScRnWvhC5nwXz2NQlRbXvLhI2345tMqYZMgPSYTwA9yyj6ME17V
aAlR9asnTLU1Xa5YbAl+U9mMD19ejyf09q1BCJWr4oSVQUHLF1MEF/Pht73rk1kU
VLdjvDgt/vDartFmygzbYA2CiHxkGqWa8e6+4upnuoirIK49mzQz0oa5RXLAvuJ2
Pwt1VD4d2YDlv6KfI6f2sItk7LiXISpK9exl2fyLD1nYCHSOYsHmBTPoJjwcKiAb
SKeQwm9xfib5Py4FJEosKsAod2X8Dhbiox0iDfJIf9cs0ivlWmNzTv9VZuN8kz91
Zbwrxw/0/kJQcMh2fv8h
=ghNW
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: RES: KQueue vs Select (NetMap)

[Jan Bramkamp]

On 29.05.2014 06:57, Fred Pedrisa wrote:
 Hello,
 
 There are 4 threads, and a total of 32 FDs. What do you think ?
 
 -Mensagem original-
 De: owner-freebsd-curr...@freebsd.org
 [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Adrian Chadd
 Enviada em: quinta-feira, 29 de maio de 2014 01:52
 Para: Fred Pedrisa
 Cc: freebsd-current; Jan Bramkamp
 Assunto: Re: KQueue vs Select (NetMap)
 
 If your netmap thread(s) just have one or two FDs in some low range (say,
 under FD 8 or 10) - no.
 
 If you have a whole bunch of active FDs and your netmap threads get FDs that
 are high - then yes. select() operates on a bitmap of FD numbers. So if your
 netmap FD is like, FD 8 and it's the highest FD that you're interested in,
 select() only has to scan up to that FD. So it scans up to 8 FDs. If you
 have a very active program and it has thousands of FDs open, select() has to
 check all the FDs in the bitmap to see if they're set before getting to your
 netmap FD.

If your threads use just a handful of small FDs than you shouldn't see
any performance difference between select()/poll() and kqueue(). But
kqueue() can block on multiple event types. This can simply your netmap
threads main loop. It sometimes even enables you to get by with just one
type of main loop instead of multiple different main loops for different
interfaces e.g. one for timers, one for sockets and one for files.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: KQueue vs Select (NetMap)

[Jan Bramkamp]

On 29.05.2014 03:04, Fred Pedrisa wrote:
 Hey Guys,

  

 How does kQueue performs over select with netmap ?
You are asking for a comparison between apples and oranges. Netmap is an
API for high performance access to the low-level features of modern
NICs. It works on batches of frames in hardware queues.

The kqueue() and kevent() system calls are an event notification API. It
is mostly used by application dealing with a large amount of
non-blocking sockets (or other file descriptors). It reduces overhead
inherent in select() and poll() by preserving state between calls. It
also supports multiple types of events (read ready, write ready, timer
expired, async i/o, etc.).

Afaik the netmap pseudo-device supports only select() and poll(). This
is no performance problem because every thread will only deal with a
small number of file descriptors to netmap devices.

Netmap is designed to bypass the FreeBSD IP stack (for most frames).
Kqueue is designed to scale to many sockets per process within the
FreeBSD IP stack.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org