Re: FreeBSD CURRENT stabilization cycle

[Franco Fichtner]

Hi,

And whom do you want to „stab“ with this? ;)

Why not do the same thing that ports does and call this „monthly“ which is 
pretty much what it is and easy to understand and you can have one build at the 
end of that week?


Cheers,
Franco

> On 24. Feb 2024, at 12:51, Kirill Ponomarev  wrote:
> 
> On 02/23, Mark Millard wrote:
>> Gleb Smirnoff  wrote on
>> Date: Sat, 24 Feb 2024 04:32:52 UTC :
>> 
>>> More seriously speaking, I
>>> actually hope that in some future snapshots.FreeBSD.org will start using 
>>> these
>>> points for snapshot generation.
>> 
>> How about also the likes of:
>> 
>> https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/
>> 
>> for pkgbase (various "aarch64" replacements too)?
> 
> yes, great idea, base_stabweek or similar is something I'd vote for.

Re: security/clamav: /var/run on TMPFS renders the port broken by design

[Franco Fichtner]

Hi,

> On 29. Aug 2022, at 8:24 AM, FreeBSD User  wrote:
> 
> Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var 
> reside on a memory
> disk and the way NanoBSD handles /var, contradicts some claims that is is 
> 'unsupported' to put
> /var on a volatile memory infrastructure.

I fully agree with the situation that at least NanoBSD has always been a valid
use case for this and don't see the need to "recycle" contents in /var/run and
let alone assume software that state inside /var/run is not volatile.

Milage varies for other /var related subdirectories of course, but people using
a /var MFS type setup have managed the situation for many years anyway with all
of its ups and downs.

The situation is a bit sloppy on the ClamAV end and has been for a couple of
releases assuming this and that and failing on tmpfs nodes, not bootstrapping
required things in the first place, but let's just assume that is the case for
other software as well now or in the future.

> what (fatal?) implications does it have to create some folders by port's 
> rc-script in /var/run
> or whatever folder is needed to be on a volatile memory device for FreeBSD 
> base system's mtree
> infrastructure?

So the obvious "separation of concerns" solution isn't something that was being
discussed here seeing that this is a ports/packages related issue:

The fix in all cases is to upgrade/reinstall the package in question, so
the knowledge of these required directories is buried inside the +POST_INSTALL
script but you cannot easily re-run these scripts since there is no command
option for it.  Obviously this beats having a copy of the package lying around
just to reinstall it on a reboot...

In the past you were able to extract them from "pkg info --raw $packagename",
and run them in the shell but that workaround is no longer feasible for LUA
scripting was added since pkg uses internal definitions in the ports tree
provided scripts.

Whether or not someone will have to script something to rerun the +POST_INSTALL
on reboot shouldn't stop from adding a pkg script run option to enable the 
former.

Solutions not involving the actual ports scripts seem to be over-engineering
when trying to record "unknown state" for a "reproducible outcome".  ;)


Cheers,
Franco

Re: git non-time-sequential logs

[Franco Fichtner]

> On 4. Jan 2021, at 7:52 PM, Enji Cooper  wrote:
> 
> The point is to stop looking at git like svn: commits should be done as 
> larger bodies of work (merge commits), as opposed to single atomic commits.

Er, uh, no.  ;)

The author date stays the same, the committer date is sequential except
that it indicates the local time of the committer doing the cherry-pick
instead of the central server as opposed to svn:

# git log --format=fuller


Cheers,
Franco

___
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: Enabling AESNI by default

[Franco Fichtner]

https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12=95b37a4ed741fd116809d0f2cb295c4e9977f5b6

may have subtly broken a number of IPsec installations by stalling active
connections after certain amounts of traffic transferred.  We're still
trying to confirm, but it looks like this had an overall impact on 12.0
and 12.1 except that only one person in OPNsense traced it back to aesni.ko
to our knowledge to effective work around an apparent issue there.

If that is not the actual fix, the problem still exists in 12.2 and onward ;)

https://github.com/opnsense/core/issues/4415

To answer the question: I guess so, yes, enable for all to have proper errata
and increased "test" coverage...


Cheers,
Franco

> On 31. Dec 2020, at 9:07 PM, Shawn Webb  wrote:
> 
> On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote:
>> We've had the AESNI module for quite a few years now, and it has not
>> caused any problems.
>> 
>> I am wondering if there are any objections to including it in GENERIC,
>> so that users get the benefit without having to have the "tribal
>> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
>> you need to load aesni.ko'
>> 
>> Userspace crypto that uses openssl or similar libraries is already
>> taking advantage of these CPU instructions if they are available, by
>> excluding this feature from GENERIC we are just causing the "out of the
>> box" experience to by very very slow for crypto.
>> 
>> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
>> device:
>> 
>> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
>> 
>> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
>> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
>> --group_reporting --fallocate=none --runtime=60 --time_based
>> 
>> 
>> stock:
>> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
>> 
>> with aesni.ko loaded:
>> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
>> 
>> 
>> Does anyone have a compelling reason to deny our users the 5x speedup?
> 
> Note: HardenedBSD has had AESNI enabled on amd64 for nearly six years.
> Not a single complaint.
> 
> For reference, HardenedBSD commit:
> a5aabd1c8dcc2a5097de56c54ec2a1c8d9352896
> 
> Thanks,
> 
> -- 
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
> 
> GPG Key ID:  0xFF2E67A277F8E1FA
> GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
> https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

___
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: SVN r353868 breaks net/intel-em-kmod

[Franco Fichtner]

> On 24. Oct 2019, at 7:56 PM, Gleb Smirnoff  wrote:
> 
> On Thu, Oct 24, 2019 at 11:12:10AM -0400, Michael Butler wrote:
> M> The removal of these KPIs yields:
> M> 
> M> link_elf_obj: symbol if_multiaddr_array undefined
> M> linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type
> 
> What's the reason to keep these outside of the tree drivers?

Unmodified and newer drivers for older FreeBSD versions.

In particular, 11.x had unfortunate and latent regressions
regarding link negotiation (chipset subset) and netmap support.


Cheers,
Franco
___
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: Testing requested: Hybrid ISO/USB boot

[Franco Fichtner]

Hi Benno,

> On 23. Mar 2018, at 8:50 AM, Franco Fichtner <fra...@lastsummer.de> wrote:
> 
> APU1C boot: aborts with "Invalid partition" 3x, then "No /boot/loader"
> and then escapes to "FreeBSD/x86 boot" etc.

Small follow-up: the hybrid-bootonly.iso goes blank on this one due to
no dual boot / serial settings.  Cannot conform nor deny at this point.


Cheers,
Franco
___
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: Testing requested: Hybrid ISO/USB boot

[Franco Fichtner]

Hi Benno,

> On 22. Mar 2018, at 7:06 PM, Benno Rice  wrote:
> 
> I’ve been working on the ability to create hybrid ISO/HDD boot images for 
> x86, a la what Linux systems do with ISOHYBRID. The general theory seems to 
> be that ISO images have a 32KB hunk of zeroes at the front that they 
> generally ignore so we’ll stick something in there that can handle booting if 
> need be. The cases generally break down as follows:

Very cool!

I ported the patch to 11.1-RELEASE and built an OPNsense image[1]
based on the commands enclosed.

(I'm not entirely sure if the porting was ok as there were quite
a few challenges... but for the sake of testing...)

Bhyve boot: ok

VirtualBox boot: ok (when using extension .iso)

APU1C boot: aborts with "Invalid partition" 3x, then "No /boot/loader"
and then escapes to "FreeBSD/x86 boot" etc.

It's an UEFI style ISO[2] so not sure if this is problematic.

I have other hardware to try and your image, but that's for later.


Cheers,
Franco

--
[1] 
https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-18.1.5-OpenSSL-dvd-amd64.iso.bz2
[2] https://github.com/opnsense/tools/blob/master/build/dvd.sh

___
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 has a politics problem

[Franco Fichtner]

Hi there,

> On 4. Mar 2018, at 10:02 PM, Jeff Roberson  wrote:
> 
> First of all this is really not an appropriate forum for this discussion.

Nobody discusses it elsewhere.  "Decisions" are made between closed doors.
How anyone would think this doesn't blow up later is at least unreasonable.

> There is a lot of catastrophizing going on in the dialog, especially that on 
> third party sites and among non-committers.

This is where the project friction is at.  In a perfect world you don't
need users, external contributors and fresh ideas to keep a project moving
forward, but we are not in a perfect world.

I personally find it silly to keep begging for 6 years for someone to commit
something.  It has gotten to a point where I'd rather not bother to contribute
because working around issues is less time-consuming.

In community management terms, that's a major flaw.

> I would urge everyone to be calm and patient.  This is an important dialog 
> and it's bound to be bumpy.  I also strongly urge people to refrain from 
> discussing it further on technical lists where it is counter productive and 
> unwelcome.

So you are saying "shut up" and be patient like we've never been patient in
the last couple of years?  That's bold, but unfortunately also consistent MO.


Cheers,
Franco
___
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: cve-2017-13077 - WPA2 security vulni

[Franco Fichtner]

> On 17. Oct 2017, at 12:32 AM, Cy Schubert  wrote:
> 
> I'll test it when I get home tonight. The WiFi here at the tech park is open 
> so, I couldn't test here.

Tested:

hostapd 2.6_1
wpa_supplicant  2.6_2

No apparent issues with the ports, preliminary connectivity
checks work as expected.  Started a public CFT over at OPNsense
to gather more feedback.


Cheers,
Franco
___
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: cve-2017-13077 - WPA2 security vulni

[Franco Fichtner]

> On 16. Oct 2017, at 10:19 PM, Cy Schubert  wrote:
> 
> It doesn't, which is why I patched the port at lunch today. It's a quick win 
> with the time I had.

Thank you, much appreciated.  Will give it some testing.

> I think we should update base to 2.6 and apply the patches.

Sounds like a plan when the port gives no apparent issues.


Cheers,
Franco
___
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: cve-2017-13077 - WPA2 security vulni

[Franco Fichtner]

> On 16. Oct 2017, at 8:50 PM, Cy Schubert  wrote:
> 
> Eight patches have been posted so, it should be easy to patch 2.5, MFC, and 
> bring head up to 2.6 later. This should avoid the risk of possible 
> regressions.

Nope, does not apply easily.  Refactoring changed contexts, function names
and variable usage logic between 2.5 and 2.6.


Cheers,
Franco
___
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"

Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

[Franco Fichtner]

Hi all,

I would like to ask for someone with the internal knowledge of the
subsystem to take a look at the following bug:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

This has been triggering on over a dozen FreeBSD 11.0 (OPNSense 17.1)
installations in the field within two weeks of having been updated
to 11.0.

What debug info do you need and how can we otherwise help?


Thanks,
Franco
___
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: netpfil with if_output and ip(6)_output

[Franco Fichtner]

Hi all,

> On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov  wrote:
> 
> I have some thought related to your proposal.
> What you think if we will introduce new KPI to work with fwd_tags?
> With such KPI we can make fwd_tags opaque for PFIL consumers and handle
> tags identically in all *proto*_output() routines.

The proposed changes are now available at:

https://reviews.freebsd.org/D8877


Cheers,
Franco
___
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: netpfil with if_output and ip(6)_output

[Franco Fichtner]

> On 14 Nov 2016, at 2:36 PM, Andrey V. Elsukov <butc...@yandex-team.ru> wrote:
> 
> On 14.11.2016 16:13, Franco Fichtner wrote:
>>> void ip6_flush_fwdtag(struct mbuf *m);
>> 
>> This looks reasonable, thank you.  How would we proceed with the
>> implementation / porting of ipfw to the new framework?
>> 
> 
> Both ipfw and pf needs some patches. Also the generic *proto*_output
> should be modified. Currently I'm busy with IPsec related work, so if
> you will do this it will be very cool :)
> But if not, I can do some work after 2-3 weeks.

I will close the previous review and start on your proposal.  Should
have something concrete next week.


Many thanks,
Franco
___
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: netpfil with if_output and ip(6)_output

[Franco Fichtner]

Hi Andrey,

> On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov  wrote:
> 
> I have some thought related to your proposal.
> What you think if we will introduce new KPI to work with fwd_tags?
> With such KPI we can make fwd_tags opaque for PFIL consumers and handle
> tags identically in all *proto*_output() routines.
> 
> For first glance I can propose the following:
> 
> /* ip_var.h */
> #define   IP_HAS_NEXTHOP(m)   ((m)->m_flags & M_IP_NEXTHOP)
> int ip_set_fwdtag(struct mbuf *m, struct sockaddr_in *dst,
>u_short ifidx);
> int ip_get_fwdtag(struct mbuf *m, struct sockaddr_in *dst,
>u_short *ifidx);
> void ip_flush_fwdtag(struct mbuf *m);
> 
> 
> /* ip6_var.h */
> #define   IP6_HAS_NEXTHOP(m)  ((m)->m_flags & M_IP6_NEXTHOP)
> int ip6_set_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst,
>u_short ifidx);
> int ip6_get_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst,
>u_short *ifidx);
> void ip6_flush_fwdtag(struct mbuf *m);

This looks reasonable, thank you.  How would we proceed with the
implementation / porting of ipfw to the new framework?

> Since I'm not quite aware how PF handles PACKET_TAG_IPFORWARD tags, you
> can modify this to fully cover its needs.

Right now, it doesn't, which is the original problem: PACKET_TAG_IPFORWARD
aligns well with netpfil, now we only need pf to do the same (and
maybe the new ipfw net64 code at some point as well).

ipfw only requires the forwarding address, pf will want to select
the outgoing interface in the same step so the KPI already covers
that.

As a note, set_fwdtag will have to be able to (safely) rewrite the
internal structure, in case one filter overwrites the decision of
the other, or we call flush + set again?

Another small oddity is the flipping of M_FASTFWD_OURS which is
write only for forwarding, but overwriting with another all requires
to unset it.  Should M_FASTFWD_OURS set/unset be part of the KBI as
well?


Cheers,
Franco
___
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"

netpfil with if_output and ip(6)_output

[Franco Fichtner]

Hi current,

There is a growing concern over usability of netpfil with
several premature exits out of the framework that would
seem to try to provide consistent policy enforcement on
traffic, namely:

if_output: called by pf route-to type tags, in 12-CURRENT
also from ipfw nat64 -- if_output in the netpfil in hook
skips pending hooks in the IN direction and all of the OUT
direction.

ip(6)_output: several callers in both ipfw and pf -- skips
all pending netpfil hooks in the IN direction.

The problem is elevated by the fact that we can use
pf and ipfw together, in a number of use cases leading
up to as much as 75% of the netpfil hook chain skipped.

I'm not saying that these are bugs as that has likely been
the default behaviour for years, but it also looks like
this is quite fixable yielding several benefits:

o getting rid of duplicated ip_output code in netpfil
o straightening out packet policy application
o improving usefulness of joint ipfw + pf scenarios

This is a real concern for our OPNsense users, who e.g. run
captive portals based on ipfw, but can't run multi-WAN
setups with pf at the same time--two use cases which run
perfectly fine as stand-alone configurations.

I've opened a review to start removal of if_output from the
pf code with a conservative first batch, which would eventually
enable ipfw and pf redirect packets using the same PACKET_TAG_IPFORWARD
mechanism.  It was met with multiple opinions, but no agenda out
of the current situation:

https://reviews.freebsd.org/D8109

Since the discussion went stale, I would like to pose three
questions to a wider audience:

Is there interest in keeping the netpfil framework consistent
for use with either ipfw or pf?

Is there interest in keeping the netpfil framework consistent
for use with ipfw and pf running at the same time?

Is there anyone willing to review and guide work towards
correcting these oddities?


Thanks,
Franco
___
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"

rtsold debug message level

[Franco Fichtner]

Hi,

There is an informational message rtsold that should
be considered debug, details here:

https://reviews.freebsd.org/D8108

Pardon my question: is this the right place, and/or
who should I contact?


Thanks,
Franco
___
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: GOST in OPENSSL_BASE

[Franco Fichtner]

> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev  wrote:
> 
> It is trivial to play MTIM with this protocol and in fact, there are 
> commercially available “solutions” for “securing one’s corporate network” 
> that doe exactly that. Some believe this is with the knowledge and approval 
> of the corporation, but who is to say what the black box actually does and 
> whose interests it serves?

It's also trivial to ignore that pinning certificates and using client
certificates can actually help a great deal to prevent all of what you
just said.  ;)

The bottom line is not having GOST support readily available could alienate
a whole lot of businesses.  Not wanting those downstream use cases will make
those shift elsewhere and the decision will be seen as an overly political
move that in no possible way reflects the motivation of community growth.


Cheers,
Franco
___
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: GOST in OPENSSL_BASE

[Franco Fichtner]

> On 12 Jul 2016, at 11:59 AM, Daniel Kalchev  wrote:
> 
> It is trivial to play MTIM with this protocol and in fact, there are 
> commercially available “solutions” for “securing one’s corporate network” 
> that doe exactly that. Some believe this is with the knowledge and approval 
> of the corporation, but who is to say what the black box actually does and 
> whose interests it serves?

It's also trivial to ignore that pinning certificates and using client
certificates can actually help a great deal to prevent all of what you
just said.  ;)

The bottom line is not having GOST support readily available could alienate
a whole lot of businesses.  Not wanting those downstream use cases will make
those shift elsewhere and the decision will be seen as an overly political
move that in no possible way reflects the motivation of community growth.


Cheers,
Franco
___
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"

ng_ether(4) performance implications

[Franco Fichtner]

Hi all,

I'm working on FreeBSD-based configuration code dating back more
than 5 years.  Although this code uses NETGRAPH compiled into the
kernel, it also makes use of NGM_ETHER_DETACH and a self-rolled
NGM_ETHER_ATTACH to avoid having netgraph-attached interfaces when
mpd isn't needed.

In 2016, how is the state of ng_ether(4) performance to assert
whether this approach is actually useful or not.

Seeing that NGM_ETHER_ATTACH is not available and should usefulness
be implicated, would code for NGM_ETHER_ATTACH be merged into
FreeBSD?


Thanks,
Franco
___
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: buildincludes: don't know how to make libelf.h etc.

[Franco Fichtner]

Hi Bryan,

Apologies for the delay.  Yes, this is still happening.

This is the script I'm using with some trampoline things in
a makefile and a common.sh script.  It works on releng/10.1 and
releng/10.2 without modification:

https://github.com/opnsense/tools/blob/master/build/base.sh

In any of the 11-CURRENT revisions of the last two weeks I've
ran into this issue for buildworld, but not for buildkernel.

If I run this command sequence in a shell directly, 11-CURRENT
builds fine.

My latest step was filtering the environment while calling
buildworld and I've had no issues.  While it's true that the
environment is polluted with variables for various build
steps, it feels like a regression, because that wasn't needed
on 10.x at all.

I've double-checked by running the unfiltered script again
and it runs into the same issues as described in the original
message.

What is the stance regarding environment poisoning and the
source tree build framework?  Is this a best effort setup
or does identifying the bad env variables matter?  I can
probably chase them down if needed.

> On 10 Nov 2015, at 1:21 AM, Bryan Drewery  wrote:
> 
> What exact release of 10.1 are you on? The release, or somewhere in head
> during the 10.1 lifecycle?

10.1-RELEASE-p24

> What revision were you trying to build?

Any of the HEAD revisions of the last two weeks, sorry for
not being more specific here, but this wasn't related to any
specific code churn.

> What do you have in /etc/make.conf and /etc/src.conf?

https://github.com/opnsense/tools/blob/master/config/latest/make.conf
https://github.com/opnsense/tools/blob/master/config/latest/src.conf

> What exact command did you run?

See above.

> Can you provide a full buildworld log please?

Only if really needed.


Cheers,
Franco
___
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"

buildincludes: don't know how to make libelf.h etc.

[Franco Fichtner]

Hi everyone,

I'm trying to build 11-CURRENT, but seeing missing header files
in lib/libelf, lib/libdwarf and lib/nucurses during a seemingly
simple `make buildworld' run.

The include files land e.g. in a tmp/legacy/usr/include object
path and copying them manually fixes that particular issue until
the next error is triggered.

I'm currently using 10.1 to build 11-CURRENT.  Has anyone else
seen this or has any idea how to solve this?


Cheers,
Franco
___
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: Segmentation fault running ntpd

[Franco Fichtner]

Well, it’s on stable/10 since September 16 and somebody reported that
this particular branch would not trigger the crash along with HEAD,
but any 10.x would.  Can’t find the reference right now though.


> On 30 Oct 2015, at 10:24 am, NGie Cooper <yaneurab...@gmail.com> wrote:
> 
> 
>> On Oct 30, 2015, at 02:18, Franco Fichtner <fra...@lastsummer.de> wrote:
>> 
>> Hi all,
>> 
>> I did a quick test build and this seems to solve the ntpd crash issue
>> on top of releng/10.1.
> 
> Makes sense … looking through my email r287591 was never MFCed back to 
> stable/9 or stable/10 :/ .
> HTH,
> -NGie
> ___
> 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"

___
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: Segmentation fault running ntpd

[Franco Fichtner]

Hi all,

I did a quick test build and this seems to solve the ntpd crash issue
on top of releng/10.1.


Cheers,
Franco

> On 30 Oct 2015, at 10:09 am, NGie Cooper  wrote:
> 
> 
>> On Oct 30, 2015, at 02:05, Dag-Erling Smørgrav  wrote:
>> 
>> NGie Cooper  writes:
>>> Dag-Erling Smørgrav  writes:
 David Wolfskill  writes:
> pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
 Did you find a solution?  [...]
>>> https://svnweb.freebsd.org/changeset/base/287591 ?
>> 
>> Are you certain?  The commit message does not mention David or ntpd.
> 
> That commit was pretty involved. Peter documented the issue in the thread 
> titled "ABORT! ABORT! Re: HEADS UP: this month's cluster refresh” that was 
> sent to the internal list.
> ___
> 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"

___
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: default pager (csh)

[Franco Fichtner]

 On 19 Feb 2015, at 02:27, Davide Italiano dav...@freebsd.org wrote:
 
 On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall mcdou...@egr.msu.edu wrote:
 The PAGER was less for about half a year and reverted.  Please see:
 
 https://svnweb.freebsd.org/base?view=revisionrevision=242643
 ___
 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
 
 OK, I think this ends the discussion =)

Nope, not good enough.  The way I see it we achieved nothing
despite the fact that several bugs are on the table.

Now that we all agree more(1) is the way to go, can we please fix
colouring and the pager quit issue for man pages using sensible
options in more(1)?

Other's should speak up for their woes with the FreeBSD defaults
too.  The defaults are supposed to be the best we can do.  Right
now, we can actually do better.  :)


Cheers,
Franco
___
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: default pager (csh)

[Franco Fichtner]

 On 19 Feb 2015, at 00:41, Xin Li delp...@delphij.net wrote:
 
 Other behavioral difference are trivial (or people care less to speak up).

more(1) with man(1) is suboptimal when skipping to the end it
quits the pager and one can't scroll back.

 I use less(1) instead of more(1) on all systems I have, so if some
 brave soul wants to make the change I'd say just go for it! but
 that's my $0.02 only.

DragonFly made the pager change a while back last year.  I do
carry these modifications for OPNsense as well.


Cheers,
Franco
___
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: netmap: extension to store user data per packet/slot?

[Franco Fichtner]

Hi Luigi,

On 12 Nov 2014, at 00:00, Luigi Rizzo ri...@iet.unipi.it wrote:

 apparently you want some user-defined metadata to move
 along with the packet, but i do not think it is
 reasonable to put it in the slots.
 If we do that, what about timestamps, flow IDs,
 interface and queue index and all the rest of the things that
 we normally find in an mbuf/skbuf ? This is not
 going to scale.

that's true.  I'm only suggesting a small extension to be used
freely, but would never consider increasing the slot size beyond
32 bytes in any case.  Keeping it sleek is obviously important.

 Also consider that at some point you may use a different
 arrangement (with packets passed along VALE switches
 or physical interfaces etc.) i believe the most
 reasonable place to put the extra info is at the end
 of the packet and possibly bump the length in the slot
 so you are safe in case the packet is copied.

I dont believe dirtying the cache lines in the actual packet
buffer is a wise choice, but it certainly works.

 There is no timestamp appended to the packet at the moment,
 it was a feature i thought somebody may want to have,
 but between the relative scarcity of hardware that provides
 per-packet timestamps, and the questionable usefulness
 of the same, i doubt it will be available.

It is a useful feature to have receive timestamps per packet
for better accounting, but I can see it being too mystical in
its current form inside the packet buffer.  It's still in my
TODO list to investigate the impact, but a system certainly
works without that extra bit of resolution.

For now, I'll go with Adrians suggestion and keep track of the
buffer index inside the first process away from netmap(4)
itself.  This setup breaks for non-circular pipe arrangements,
but the load-balancing use case at hand is alright.


Cheers,
Franco
___
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

netmap: extension to store user data per packet/slot?

[Franco Fichtner]

Hi Luigi,
hi all,

so I was running into logistics issues with netmap(4)
with regard to zero-copy and redirection through pipes:
working on a load-balancing framework revealed that it
is very hard to track a packet's origins to later move
it onward to the respective outgoing interface, be it
another device or the host stack.

Long story short: user data needs to be stored for the
packet buffer or slot.

There are three ways that I can see so far:

(1) Allocate a netmap pipe pair for each interface,
in case of transparent mode also a pipe for the
host stack each.  That's a lot of pipes and
most likely insane, but it won't extend the ABI.

(2) Store the additional data in the actual buffer.
That is sort of ok, but seems sluggish WRT cache
behaviour -- maybe the buffer won't be read but
it needs to be written.  Sure, we can store it at
the end, but there already resides the packet
timestamp if enabled (if I recall correctly).
Wouldn't extend the ABI per se, but might collide
with the timestamping

(3) Make room in struct netmap_slot itself like this:

diff --git a/sys/net/netmap.h b/sys/net/netmap.h
index 15ebf73..d0a9c0e 100644
--- a/sys/net/netmap.h
+++ b/sys/net/netmap.h
@@ -147,6 +147,7 @@ struct netmap_slot {
uint16_t len;   /* length for this slot */
uint16_t flags; /* buf changed, etc. */
uint64_t ptr;   /* pointer for indirect buffers */
+   uint64_t userdata;  /* reserved storage for caller */
 };

It could also be broken down in two fields with uint32_t
each; not sure what would be more sensible.  This of course
requires an API bump, although it should be backwards
compatible.

Any feedback on this is highly appreciated.


Cheers,
Franco
___
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: netmap: extension to store user data per packet/slot?

[Franco Fichtner]

Hi Adrian,

On 11 Nov 2014, at 22:22, Adrian Chadd adr...@freebsd.org wrote:

 ... I'm confused. Do you have the slot id already, right? Why not
 allocate an array of userdata pointers somewhere else and just use the
 netmap slot id as an indirection into that?

The slot id is per ring and there are a lot of them.  In case of
zero-copy the slot changes at least 1.  Consider two processes
for the load balancing case.  Process 1 attaches to the devices
and Process 2 only has a a pipe pair for receiving and sending
packets back to Process 1 after processing, because only that
process has access to the real devices:

em0, em1, etc. --RX/TX-- Process 1 --pipe pair-- Process 2
(Hardware)(Balancer)  (Worker)

There is no way to trace packet origin back to em0 or em1 after
pushing the packets through the pipe pair unless either the
pipes are unique for each device or there is another means to
keep its state.

Should, however, the buffer id be unique that would make it
easy to do what you suggest, but I don't know the netmap(4)
internals by heart.

It seems a wee unnatural to rebuild tracing of packets in
userland when netmap(4) has all the infrastructure needed to
deal with this effectively, but I'm not opposed to doing that
to avoid API/ABI changes.  Speaking of those, should volatile
internals change regarding the buffer id that would also break
the attempts to deal with the issue consistently.


Cheers,
Franco
___
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: netmap: extension to store user data per packet/slot?

[Franco Fichtner]

On 11 Nov 2014, at 22:48, Adrian Chadd adr...@freebsd.org wrote:

 Ah, I see. You're missing some unique identifier for each netmap
 buffer. I thought there was one already. Silly me.

Exactly, and, no, thank you for making clear what is needed.  :)

A little more on this: I think struct netmap_slot is convenient
due to the fact that in zero-copy one wouldn't want to mess with
the actual buffer for speed and userland code already touches slot
internals for each ring transition so there is no performance
degradation.

The key benefit is that if userland can use this storage freely
netmap(4) doesn't get in the way of building complex setups that
require decoupled logic and each ring hop may alter the state
as required.


Cheers,
Franco
___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Franco Fichtner]

Hi Julian,

On 21 Jul 2014, at 05:15, Julian Elischer jul...@freebsd.org wrote:

 Most people I talk to just use ipfw and couldn't care whether pf lives or 
 dies.  They have simple requirements and almost any filter would suffice.  I 
 haven't found anything I'd want to use pf for that ipfw doesn't allow me to 
 do. There are things pf does that ipfw doesn't... I just never want them..

this is quite insightful.  The gist of this discussion and the apparent
lack of upgrades to pf(4) seem to indicate that:

(a) other packet filters do the required jobs equally or better
or performance doesn't matter at all.

(b) for more progressive setups and requirements, FreeBSD servers
may as well be complemented with commercial firewalls, hand-rolled
or non-FreeBSD solutions

Is that somewhat accurate, or is there more to the story?


Cheers,
Franco
___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Franco Fichtner]

On 20 Jul 2014, at 15:39, Mike. the.li...@mgm51.com wrote:

 imho, the root problem here is that an effort to implement a single
 feature improvement (multi-threading) has caused the FreeBSD version
 of pf to apparently reach a near-unmaintainable position in the
 FreeBSD community because improvements from OpenBSD can no longer be
 ported over easily.   FreeBSD's pf has been put in a virtual
 isolation chamber due to the multi-threaded enhancement.
 
 Was it worth it?

Yes.  This happened *three times* in BSD land now.  How much more
proof does it take to make that clear?

FWIW, I'm still volunteering, but I think the direction this
discussion is going is that there is no clear direction, which makes
this a tad less effective than it could be.  ;)


Cheers,
Franco
___
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: Future of pf / firewall in FreeBSD ? - does it have one ?

[Franco Fichtner]

Hi Kristian,

On 17 Jul 2014, at 01:12, Kristian K. Nielsen free...@com.jkkn.dk wrote:

 a) First of all - are any actively developing pf in FreeBSD?

not directly related to FreeBSD, but I was planning to bring
DragonFly's pf to a new feature state.  We've had a little bit
of discussion over the recent DF SMP fixes on an OpenBSD mailing
list, but the outcome was a tad disappointing to say the least.

 b) We are a major release away from OpenBSD (5.6 coming soon) - is
 following OpenBSD's pf the past? - should it be?

Yes and no.  :) I still stand by my claim that SMP is the fork
on the road for pf development; having three major BSDs tackling
the work in some way or another (NetBSD chose npf, but that's a
different story).

We should merge newer features for sure, but we have to establish
that the forking of pf was an inevitable process and that the
custom SMP bits are not going away and need to be maintained
separately/individually.

 c) We never got the new syntax from OpenBSD 4.7's pf - at the time a long 
 discussion on the pf-mailing list flamed the new syntax saying it would cause 
 FreeBSD administrators too much headache. Today on the list it seems everyone 
 wants it - so would we rather stay on a dead branch than keep up with the 
 main stream?

I'd say many people are comfortable with an old state of pf (silent
majority), but that shouldn't keep us from catching up with newer
features (and of course bugfixes).

 d) Anyone working on bringing FreeBSD up to pf 5.6? - seem dead on the 
 pf-list.

Not exactly, but I have a strong interest in this happening and
am able to help.  :)

 e) OpenBSD is retiring ALTQ entirely - any thoughts on that?
 http://undeadly.org/cgi?action=articlesid=20140419151959

The reasoning is sound.  I think the direction is good, although
one probably can't rip out ALTQ just like that in FreeBSD.

 f) IPv6 support?- it seem to be more and more challenged in the current 
 version of pf in FreeBSD and I am (as well as others) introducing more and 
 more IPv6 in networks.
 E.x. Bugs #179392, #172648, #130381, #127920 and more seriously #124933, 
 which is the bug on not handling IPv6 fragments which have been open since 
 2008 and where the workaround is necessity to leave an completely open hole 
 in your firewall ruleset to allow all fragments. According to comment in the 
 bug, this have been long gone in OpenBSD.

Needs to be taken care of.  Getting more and more important.  ;)

 g) Performance, can we live with pf-performance that compared to OpenBSD is 
 slower by a factor of 3 or 4, even after the multi-core support in FreeBSD 10?
 (Henning Brauer noted that in this talk at 
 http://tech.yandex.ru/events/yagosti/ruBSD/talks/1488/ (at 33:18 and 36:53)) 
 - credit/Jim Thompson

A factor 3 or 4 times is the proverbial it's one louder.  SMP
scaling can reach more performance im the long run, and pf can
still be tweaked to increase atomic performance, although the
physical algorithm limits are a lot more finite than with SMP.

 h) Bringing back patches from pfSense?

Those patches are not available anymore since pfSense changed the
visibility of the pfsense-tools.git.  I would welcome to see those
patches trickle back under a standard BSD license for review and
inclusion when viable.

But first of all, we need those patches back.


Cheers,
Franco
___
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: netmap(4) transparent mode

[Franco Fichtner]

Hi Luigi,

On 09 Jun 2014, at 14:37, Luigi Rizzo ri...@iet.unipi.it wrote:

 ​ack, thanks -- we are merging a few fixes to netmap these days
 so yours will go in soon

brilliant, thanks.  :)


Cheers,
Franco
___
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

netmap(4) transparent mode

[Franco Fichtner]

Hi,

here's a revised version of a patch to address a couple
of issues with the transparent mode of netmap(4), which
doesn't work in current and older stable branches:

https://github.com/fichtner/freebsd/commit/b00580b03bf9dd847e4238dc0faabb349b1852a1.patch

Posting this to a wider audience now, since I have no
feedback from the maintainer yet.  Luigi is CC'ed again.


Cheers,
Franco
___
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