Hello!
We don't need ELF relocations!
We want better loop control!
No so little parameters,
Verifier! Leave our code alone!
On Tue, 10 Sep 2024 06:38:50 +
"Poul-Henning Kamp" wrote:
> ----
> Vadim Goncharov writes:
>
> > I've put a sketch of design to https://github.com/nuclight/bpf64
> > with files:
>
> Counter proposal:
>
> 1. Define the Lua execution e
On Tue, 10 Sep 2024 12:24:07 +
"Poul-Henning Kamp" wrote:
> ----
> Vadim Goncharov writes:
>
> > It's easy for your Lua code (or whatever) code to hang kernel by
> > infinite loop. Or crash it by access on arbitrary pointer.
>
> Lua has p
On Tue, 10 Sep 2024 13:59:02 +0100
David Chisnall wrote:
> On 10 Sep 2024, at 12:45, Vadim Goncharov
> wrote:
> >
> > It's easy for your Lua code (or whatever) code to hang kernel by
> > infinite loop. Or crash it by access on arbitrary pointer. That's
&g
On Tue, 10 Sep 2024 14:41:20 +
"Gavin D. Howard" wrote:
> Hello,
>
> New user here, not a contributor.
>
> > Ensuring kernel stability? Just don't allow arbitrary pointers,
> > like original BPF. Guaranteed termination time? It's possible if
> > you place some restrictions. For example, don
On Tue, 10 Sep 2024 15:58:25 +0100
David Chisnall wrote:
> On 10 Sep 2024, at 14:44, Vadim Goncharov
> wrote:
> >
> > I am not an experience assembler user and don't understand how
> > Spectre works - that's why I've written RFC letter even before spec
e real subject? Or
even bikesheds are in short supply now?
> On Tuesday, September 10, 2024, Vadim Goncharov
> wrote:
>
> > On Tue, 10 Sep 2024 15:58:25 +0100
> > David Chisnall wrote:
> >
> > > On 10 Sep 2024, at 14:44, Vadim Goncharov
> > > wrote:
On Wed, 11 Sep 2024 10:14:44 +0800
Philip Paeps wrote:
> On 2024-09-11 06:12:28 (+0800), Vadim Goncharov wrote:
> > David Chisnall wrote:
> >> BPF can be loaded only by root, who can also load kernel modules
> >> and map /dev/[k]mem, and FreeBSD does not prote
On Wed, 11 Sep 2024 12:21:09 +0100
David Chisnall wrote:
> On 11 Sep 2024, at 10:06, Vadim Goncharov
> wrote:
> >
> > But then a possibility to give this to non-root is. And many things
> > are considered vulnerabilitites even if they are only available to
> > roo
On Tue, 10 Sep 2024 16:55:15 -0800
Rob Wing wrote:
> On Tuesday, September 10, 2024, Vadim Goncharov
> wrote:
> >
> >
> > What's the point to waste resources on writing thing that is known
> > to be not accepted to base system from the very beginning?
>
in pfSense ipfw users are actually only it's authors (all
others see web interface), so it's better and more practical to not rely on
such complex solution, but rather on something more simple and specialized for
their needs. Such as your proposed ipfw contexts.
--
WBR, Vadim Goncharov.
cks.
> 2) Set if_bpf pointer IFF there are some consumers (and set it back to
> NULL when all consumers are detached). This should work well for 'main'
> BPF DLT, but single (currently, 802.11) interface can hold more than one
> DLTs. Probably we can save dst pointer pass
ray in 2^16 space. So the only other problem which could be is when some
mbuf exists too long to survive 32767 interfaces creates and destroys, which
is very unlikely.
Unfortunatelly, I don't know how to write per-CPU code, so I can't give you
a PoC patch, but I hope I've explained idea
, I have heard once man needing something like tcpdump for Unix socket. Is
something convenient like this is possible?..
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
__
more detailed.
--
WBR, Vadim Goncharov
ipfwpcap.patch
Description: Binary data
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
that should be another commit, as not a user-visible
change.
--
WBR, Vadim Goncharov
ipfwpcap.patch
Description: Binary data
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
and for my system with 64 virtual interfaces?
Surely, per-core thread is enough - why have too much synchronization
overhead?..
A computer is a state machine. Threads are for people who can't program
state machines. (c) Alan Cox
--
WBR, Vadim
L2 interaction is interesting. How it should work in case of
planned separation of routing and ARP tables?..
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
e to have
'setfib tablearg' together with reserving 16 bits for FIB number - some
systems with hundreds of vlans will want to have more than 256 tables, I
think...
Interaction with the ARP layer/ LL layer would need to be
revisited as well. Qing Li has been working on this
that next hop.
I DO however thing that the arp stuff should nto be accessing its
data via the routing table.
Surely, routing table should contain a cached pointer to an entry in L2
table (ARP in case of Ethernet), to not do double lookups. But still
separate those tables...
--
WBR, Vadim Gonc
on. If you are monitoring in userland, Snort
of course will not have enough time to process all of your data, so why
not simply put at least two machines in parallel, one for each mirrored
line?
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org ma
ample is enough to you? What exactly do you need? May be you'd rather
write some simpler expressions for in-kernel filtering instead of
heavy-weighted Snort?
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
07.01.08 @ 03:41 Andre Oppermann wrote:
Vadim Goncharov wrote:
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is
.8:80 8080
This allows to add redirections "on the fly" without need to restart entire
node breaking current connections.
The "list_redirects" keyword prints table of all redirects (no matter what
type) in a pretty human-readable format. This can be used to obtain ID of
specific r
ipfw could this for you.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
iple streams and message record
separation (I don't need other SCTP features currently). Where can I find
answers to these questions, like it was with W.R.Stevens books for TCP ?..
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.ANTI-EC
cks I want
>> with basic SCTP SEQPACKET benefits: multiple streams and message
>> record
>> separation (I don't need other SCTP features currently). Where can I
>> find
>> answers to these questions, like it was with W.R.Stevens books for
>> TCP ?..
> Have
t's
>>>> structure which I can later use to quickly dispatch events.
>>>>
>>>> And, of course, all this usual C10K-problem-solving-TCP-server
>>>> tricks I want
>>>> with basic SCTP SEQPACKET benefits: multiple streams and message
>
.94
"PIP supported variable length addressing in 16-bit units, separation
of addresses from identifiers, support for provider selection, mobility,
and efficient forwarding." Looks good, instead of IPv6...
And for more than 10 years of developing, with spam and hackers, IPv6 still
assumes
Hi!
The issue seems to be reprodusable on 7.0 - see kern/121693.
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
The following reply was made to PR kern/121693; it has been noted by GNATS.
From: Vadim Goncharov <[EMAIL PROTECTED]>
To: Gael Roualland <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: kern/121693: in kernel alias_irc nat double panic
Date: Fri, 14 Mar 2008 17:02:47 +06
The following reply was made to PR kern/121693; it has been noted by GNATS.
From: Vadim Goncharov <[EMAIL PROTECTED]>
To: Gael Roualland <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kern/121693: in kernel alias_irc nat double panic
Date: Fri, 14 Mar 2
apply it and then reinstall it.
> that reminds me I need to merge this back to RELENG_7
Oh, and to RELENG_6 please, too. Then PR 120720 can be said to fully closed,
yes.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.ANTI-ECOLOGY][F
n recv fxp0
> Other than the ability to track traffic through each port, of course.
The first becomes significantly faster when you have hundreds of rules.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.
CP options can't be used with UDP
> rules".
This is behaviour of ipfw2 - options are independently ANDed. Thus, man page
explicitly says:
established
Matches TCP packets that have the RST or ACK bits set.
So, it is obvious that udp packet will not match and thus
socket.
But if that's a middle of connection, how would you do? Kernel sockets assume
they've acted in a conversation from the very beginning SYN's, so if you
redirect such packet, socket will not understand it.
If you yopu want to simply close/reset connection, however, this can be done
s
can be seen by the
> interface the bpf is bound to?
AFAIK, no.
> This means that the interface does it's normal work and the packet
> will be deliverd to SOCK_STREAM bound to it.
What exactly is your task? May be it is worth consider some other ways if
additional details are known.
--
ther that rule is valid mix or not,
so it just must not comlain. Of course, then it is user responsibilty to check.
As always, Unix assumes you know what you do - if you rm a file, you can't
undelete it.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator o
hat association. If it is your own-written
application - no problem.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
___
freebsd-net@freebsd.org mailing list
y # divert unmarked traffic to node
deny all from any to any tagged $bad
allow all from any to any tagged $good keep-state
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lied to the packet using
+.Cm tag
+rule action parameter or set somewhere in another part of the kernel
+network subsytem using
+.Xr mbuf_tags 9
+facility.
.It Cm tcpack Ar ack
TCP packets only.
Match if the TCP header acknowledgment number field is set to
--
WBR, Vadim Goncharov
and 'output' path of ipfw for routed packets, etc ?).
A question about features: is it worth adding functionality of matching
range of tags? For example:
ipfw add pass ip from any to any tagged 1-5,10,20
--
WBR, Vadim Goncharov
___
freebsd-net
works.
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
l situation where it can be useful,
as tables already contain IP adresses. Can you give a real-life
example where it helps ?
--
WBR, Vadim Goncharov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubs
f -S -Wall -mtty-char -man \
-Tascii | /usr/bin/col | more -s
Please especially test tags with non-zero tag_len, if you can (though it's
not needed for ipfw).
P.S. BTW, what is correct subject prefix for new contributions? I think
[PATCH] is not correct as these are new files, not patch :)
q(4) here, of course).. the only thing to note that packets
# to both directions of our router are sent to only one pipe, but for
# my example it's enough
ipfw add 600 pipe 40 ip from any to any tagged 412
--
WBR, Vadim Goncharov
___
freebsd-ne
12.06.06 @ 10:12 Ganbold wrote:
Vadim Goncharov wrote:
Hello All!
I wrote new netgraph(4) node, called ng_tag, able to match packets by
their mbuf_tags(9) and assign new tags to mbufs. This can be used for
many things in the kernel network subsystem, but particularly useful
with recently
g.kld (immediate file).
Another possibility you should mention is using both firewalls at the same
time, ipfw and pf. The rule order traversal, AFAIK, depends on order of
module loading, so you should experiment a little with it.
--
WBR, Vadim Gonc
ether[60:4]=0x6173683d)
) ||
(ether[2:2]=57 &&
ether[40:4]=0x000d &&
ether[44]=0x06 &&
ether[53:4]=0x4000)"
Note the last OR block in expression - this is translation of that "not
sure" checking request pa
13.06.06 @ 01:57 Ulrich Spoerlein wrote:
Vadim Goncharov wrote:
I hope that my explanation was helpful enough to understand :) Also, if
you will be using
7.0, include BPF_JITTER in your kernel config as this will enable
native code-compiling for
bpf and ng_bpf - this will speed things up
13.06.06 @ 01:57 Ulrich Spoerlein wrote:
Vadim Goncharov wrote:
I hope that my explanation was helpful enough to understand :) Also, if
you will be using
7.0, include BPF_JITTER in your kernel config as this will enable
native code-compiling for
bpf and ng_bpf - this will speed things up
weekend. I am currently working on ng_tag(4)
netgraph node which could deal with tags (see
http://antigreen.org/vadim/freebsd/ng_tag/) - I think, in theory it is
possible to tag-based routing inside netgraph onto netgraph interfaces.
--
WBR, Vadim
l, in fact I do, but I want packets to be able to
use two or more diverse paths of equivalent cost.
You can try to use ng_one2many(4) netgraph node for simple round-robin, if
this all what you want.
--
WBR, Vadim Goncharov
___
freebsd-net@freebs
On Sat, 21 Dec 2024 16:34:25 + (UTC)
"Bjoern A. Zeeb" wrote:
> On Tue, 17 Dec 2024, Mark Johnston wrote:
>
> > Lately I've been working on adding FIB awareness to bind(2) and
> > inpcb lookup. Below I'll describe the project a bit. Any
> > feedback/comments/suggestions would be appreciated.
On Mon, 23 Dec 2024 13:29:01 +0300
"Andrey V. Elsukov" wrote:
> On 21.12.2024 19:34, Bjoern A. Zeeb wrote:
> > How much use are FIBs still these days? Half of the original use cases
> > I can think of could easily and better be overcome by using vnet jails
> > with a physical or virtual interfac
On Thu, 16 Jan 2025 10:54:50 -0300
"Soni \"It/Its\" L." wrote:
> we would like to propose an experiment where we treat ipsec as an
> address family, similar to tcp/ip or tcp/ipv6 but with tcp/ipsec instead.
>
> traditionally, ipsec is something the sysadmin configures between
> systems. well,
56 matches
Mail list logo
