> 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 ty
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
anothe
Hi Adrian,
On 11 Nov 2014, at 22:22, Adrian Chadd 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
On 11 Nov 2014, at 22:48, Adrian Chadd 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
Hi Luigi,
On 12 Nov 2014, at 00:00, Luigi Rizzo 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
> On 19 Feb 2015, at 00:41, Xin Li 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
> On 19 Feb 2015, at 02:27, Davide Italiano wrote:
>
> On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall wrote:
>> The PAGER was less for about half a year and reverted. Please see:
>>
>> https://svnweb.freebsd.org/base?view=revision&revision=242643
>> __
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:
>>>
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 wrote:
>
>
>> On Oct 30, 2015, a
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 unti
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 t
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,
> 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 corp
> 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 corp
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 mai
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
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*_out
> On 14 Nov 2016, at 2:36 PM, Andrey V. Elsukov 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 t
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
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
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, s
Hi Luigi,
On 09 Jun 2014, at 14:37, Luigi Rizzo 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.freeb
Hi Kristian,
On 17 Jul 2014, at 01:12, Kristian K. Nielsen 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 20 Jul 2014, at 15:39, Mike. 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 OpenB
Hi Julian,
On 21 Jul 2014, at 05:15, Julian Elischer 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
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 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
> 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
> 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 expec
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.
> T
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
> gener
Hi Benno,
> On 23. Mar 2018, at 8:50 AM, Franco Fichtner 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
https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12&id=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 ha
> 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
t
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 infrastructur
35 matches
Mail list logo
