The following reply was made to PR kern/122109; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, m.dyadche...@211.ru
Cc:
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Wed, 22 Sep 2010 01:24:40 +0400
Problem can be fi
The following reply was made to PR kern/157379; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:
Subject: Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat
Date: Mon, 30 May 2011 15:23:34 +0400
This see
The following reply was made to PR kern/122109; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, m.dyadche...@211.ru, a...@freebsd.org
Cc:
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Fri, 03 Jun 2011 10:08:13 +0400
On 06.10.2011 14:42, Oleg Strizhak wrote:
> Hello, Andrey V. Elsukov!
>
> You wrote on 06.10.2011 at 13:38:
>
>> On 06.10.2011 12:29, Oleg Strizhak wrote:
>>> After an investigation I've found out a very strange situation - it
>>> seems to me, that ipfw nat drops
>>> some (type 11?) icmp reply pa
Blog Tieng Viet wrote:
> Dear all,
>
> I am using IPFW in FreeBSD 7.3-RELEASE.
> I have some problems as following:
>
> Limit src address may not work well:
>
> For example, I want to limit google robot not over 1 connection establishment:
>
> ${fwcmd} add 5625 pass tcp from 66.249.0.0/16 to m
Pawel Tyll wrote:
> Hi lists,
>
> Are there any plans to implement IPv6 tables in ipfw? It would seem
> that our gov. may want to force us into IPv6 in 6 months ;)
I've got working implementation for IPv4+IPv6 and interface tables:
15:56 [0] zfsbase# /usr/obj/usr/src/sbin/ipfw/ipfw table 2 list
1
Hello everyone.
Final patch version now uses single IP_FW3 socket option.
Together with other changes this makes me think such changes should be
reviewed by a wider number of people. If there are no
objections/comments I plan to commit this on tuesday.
Changes:
* Tables (actually, radix trees) ar
Bjoern A. Zeeb wrote:
> On 25. Dec 2011, at 17:47 , Pawel Tyll wrote:
>
>> Hi Alexander,
>>
>>> Changes:
>>> * Tables (actually, radix trees) are now created/freed on demand.
>> Does this mean IPFW_TABLES_MAX can now be safely set to arbitrarily
>> high number that would allow flexible numberin
On 27.12.2011 04:54, Pawel Tyll wrote:
Hi lists,
Are there any profiling tools in the system or ports that would allow
me to determine how much processing is being done per packet and how
long does it take? I would like to predict possible PPS load for my
system and perhaps locate and remo
Mike Tancsa wrote:
> On 12/27/2011 6:36 AM, Alexander V. Chernikov wrote:
>>> Is IPFW efficient enough to firewall 2x10GE (in+out) interfaces
>>> without much latency increase, when running on modern hardware
>>> with Intel NICs? Majority of processing
On 24.04.2012 19:26, Hiroki Sato wrote:
Hi,
I created the attached patch to make the current ipfw0
pseudo-interface clonable. The functionality of ipfw0 logging
interface is not changed by this patch, but the ipfw0
pseudo-interface is not created by default and can be created with
the
On 24.04.2012 21:05, Hiroki Sato wrote:
"Alexander V. Chernikov" wrote
in<4f96d11b.2060...@freebsd.org>:
me> On 24.04.2012 19:26, Hiroki Sato wrote:
me> > Hi,
me> >
me> >I created the attached patch to make the current ipfw0
me> >ps
On 16.05.2012 16:07, Daniel Kalchev wrote:
Hello,
I am having an persistent problem when using tables with ipfw. On a
number of routers, built with various FreeBSD versions, with ipfw as
loadable module or statically compiled, the problem remains the same.
From time to time, ipfw spews erro
On 09.06.2012 01:56, Sami Halabi wrote:
Hi,
I Manage a FreeBSD server as an edge router& firewall.
the setup has 10G interfaces (ixgbe-82599EB) and 1G interfaces(em-82571EB&
bce-BCM5709) connected to 10G/1G switches.
With the following setup i get higher cpu usage:
bce1-upstream provider with
arg from any to table(1) in recv bce1
It is often a good idea to split in/out rules initially (e.g. skipto
1 ip from any to any out)
You can send me your ipfw config and we can discuss it more detailed.
any other advices?
Sami
On Sat, Jun 9, 2012 at 1:15 PM, Alexander V. Chernikov
mail
On 27.04.2012 03:44, Hiroki Sato wrote:
"Alexander V. Chernikov" wrote
in<4f96e71b.9020...@freebsd.org>:
me> On 24.04.2012 21:05, Hiroki Sato wrote:
me> > "Alexander V. Chernikov" wrote
me> > in<4f96d11b.2060...@freebsd.org>:
me>
The following reply was made to PR kern/156770; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, al...@alter.org.ua
Cc:
Subject: Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement
and several extensions
Date: Fri, 15 Jun 201
The following reply was made to PR kern/169206; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, pi...@pixel.org.pl
Cc:
Subject: Re: kern/169206: [ipfw] ipfw does not flush entries in table
Date: Wed, 20 Jun 2012 18:29:18 +0400
Is it possib
On 19.06.2012 12:56, Sami Halabi wrote:
Hi,
I want to ask aout VNET jails, i read somehwre that I'm able to run IPFW,
but not PF firewall in a cnet jail.
is that correct?
i want a vnet jail basicly for nat, so natd with ipfw + ipdivert is my
1) You can do nat without vnet.
2) ipfw nat is curre
On 01.07.2012 23:09, Luigi Rizzo wrote:
On Sun, Jul 01, 2012 at 03:54:35PM +, melif...@freebsd.org wrote:
Synopsis: [ipfw] [dummynet] [patch]: performance improvement and several
extensions
Responsible-Changed-From-To: freebsd-ipfw->melifaro
Responsible-Changed-By: melifaro
Responsible-Cha
On 10.07.2012 03:18, Rolf Grossmann wrote:
Hi,
I've started switching my machines to in-kernel nat and I've run into a
case where I need to tell the nat instance which packets to treat as
incoming and which as outgoing. With natd I've been able to use divert
with different ports and in_port and
On 19.10.2012 18:05, Andre Oppermann wrote:
On 19.10.2012 14:18, Andrey V. Elsukov wrote:
On 19.10.2012 16:02, Andre Oppermann wrote:>>
http://people.freebsd.org/~ae/pfil_forward.diff
Also we have done some tests with the ixia traffic generator connected
via 10G network adapter. Tests have sho
Hello list!
Currently most ipfw operations with dynamic states (keep-state,
check-state, limit) are serialized via IPFW_DYN_LOCK() which is per-vnet
mutex lock.
As a result, performance is limited to the same ~650kpps as in routing
(in several cases).
Patch changes the following:
* global lo
On 14.11.2012 00:16, Alfred Perlstein wrote:
Alexander, this is awesome.
On 11/13/12 11:28 AM, Alexander V. Chernikov wrote:
Hello list!
Currently most ipfw operations with dynamic states (keep-state,
check-state, limit) are serialized via IPFW_DYN_LOCK() which is
per-vnet mutex lock.
As a
On 14.11.2012 19:47, Gleb Smirnoff wrote:
On Tue, Nov 13, 2012 at 11:28:23PM +0400, Alexander V. Chernikov wrote:
A> So, we can do the following:
A> 1) lock increments/decrements via some separate mutex
A> 2) do nothing
A> 3) take some combined approach:
4) Take it via uma
On 27.11.2012 09:54, Gleb Smirnoff wrote:
On Tue, Nov 27, 2012 at 02:30:51AM +0400, Alexander V. Chernikov wrote:
A> On 14.11.2012 19:47, Gleb Smirnoff wrote:
A> > On Tue, Nov 13, 2012 at 11:28:23PM +0400, Alexander V. Chernikov wrote:
A> > A> So, we can do the following
On 10.06.2012 18:20, Alexander V. Chernikov wrote:
On 27.04.2012 03:44, Hiroki Sato wrote:
"Alexander V. Chernikov" wrote
in<4f96e71b.9020...@freebsd.org>:
me> On 24.04.2012 21:05, Hiroki Sato wrote:
Proof-of-concept patch attached.
Hopefully, libcap code is easily exte
On 03.12.2012 12:11, Gleb Smirnoff wrote:
On Sun, Dec 02, 2012 at 04:48:18AM +0400, Alexander V. Chernikov wrote:
A> On 10.06.2012 18:20, Alexander V. Chernikov wrote:
A> > On 27.04.2012 03:44, Hiroki Sato wrote:
A> >> "Alexander V. Chernikov" wrote
A> >>
On 06.12.2012 13:13, Ermal Luçi wrote:
Hello,
i was looking at ipfw dynamic code for dynamic states/rules and see that it
unconditionally schedules a callout even if there is not work to do.
Wouldn't it be best to reschedule it when there is something to do to avoid
having a useless
callout/eve
On 07.12.2012 16:27, Andrey V. Elsukov wrote:
Hi All,
We have discovered that ipfw(4) shows very low performance results with
our rules. One of the biggest problems is rules with O_IP6_XXX_ME
opcode. They checks match or not match packet's addresses with locally
configured IPv6 addresses.
For I
On 25.12.2012 18:58, Fabian Wenk wrote:
Hello
To test tables with IPv6 for use with fail2ban (see thread "IPv6
Support" [1]), I tried it out on a FreeBSD 9.1-RELEASE (r244668) system.
Not all possible rules with tables which include IPv6 addresses seem to
work.
[1] http://sourceforge.net/mai
Hello list!
This is the obvious thing which should be done at least 5 years ago.
There are several PRs like kern/102471 and kern/121122 with similar
functionality.
Given patch adds setting DSCP support (O_SETDSCP) which works for both
IPv4 and IPv6 packets. Fast checksum recalculation (RFC 1624)
On 14.03.2013 17:56, Eggert, Lars wrote:
Hi,
Hello.
interpreting these bits as a TOS field has been deprecated since RFC2474 was
published in 1998. Since then, we've been having a DSCP codepoint and ECN bits
in the IP header.
Yes. I'm going to commit DSCP-based approach, so I'm grabbing all
On 20.03.2013 01:49, naPtu 3ah wrote:
problem is still here
router5:/etc@[23:05] # ipfw show 12000-12200
12101 96 7236 count ip from any to 91.222.49.77 out via em0
12102 116147632355 allow ip from any to table(11) out via em0
12140 0 0 count ip from any to 91.2
On 24.04.2013 23:09, Luigi Rizzo wrote:
On Wed, Apr 24, 2013 at 08:46:01PM +0400, Alexander V. Chernikov wrote:
On 24.04.2013 20:23, Luigi Rizzo wrote:
...
vesrion) in the middle of the next week.
hmmm this is quite a large change, and from the description it
is a bit unclear to me how
On 25.04.2013 00:23, Luigi Rizzo wrote:
On Wed, Apr 24, 2013 at 11:50:48PM +0400, Alexander V. Chernikov wrote:
On 24.04.2013 23:09, Luigi Rizzo wrote:
On Wed, Apr 24, 2013 at 08:46:01PM +0400, Alexander V. Chernikov wrote:
On 24.04.2013 20:23, Luigi Rizzo wrote:
...
Well, actually I&#
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19.11.2013 23:55, ￖzkan KIRIK wrote:
> Hi,
>
> I'm using kernel FreeBSD 10.0-BETA3 #2 r257635 kernel. I am trying
> to add port number to ipfw tables. But there is something strange
> : Problem is easily repeatable.
>
> #ipfw table 1 flush #ipfw t
0.2.3.01
inet_pton() does not recognize this as valid IPv4 address, so it is
treated as usigned unteger key. It looks like this behavior is mentioned
in STANDARDS section.
> # ./ipfw table 1 list
> 0.0.0.10/32 0
>
>
>
>
> On Sat, Nov 23, 2013 at 11:09 PM, Alexander V. Cherni
On 27.11.2013 11:56, Ian Smith wrote:
On Tue, 26 Nov 2013 12:48:01 +, Ben Morrow wrote:
> To: freebsd-sta...@freebsd.org
Restoring cc ipfw@ and others after the inet_pton side?thread in
stable@. grepping /usr/src for inet_pton suggests that a behavioural
change in inet_pton at this stage
The following reply was made to PR kern/122963; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, zub...@advancedhosters.com
Cc:
Subject: Re: kern/122963: [ipfw] tcpdump does not show packets redirected
by 'ipfw fwd' on proper interfa
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw
On 02.08.2014 10:33, Luigi Rizzo wrote:
>
>
>
> On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov
> mailto:melif...@freebsd.org>> wrote:
>
> Hello all.
>
> I'm currently working on to enhance ipfw in some areas.
> The most notable
On 02.08.2014 12:33, Alexander V. Chernikov wrote:
On 02.08.2014 10:33, Luigi Rizzo wrote:
On Fri, Aug 1, 2014 at 11:08 PM, Alexander V. Chernikov
mailto:melif...@freebsd.org>> wrote:
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most n
On 04.08.2014 15:58, Luigi Rizzo wrote:
> On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote:
>> On 02.08.2014 12:33, Alexander V. Chernikov wrote:
>>> On 02.08.2014 10:33, Luigi Rizzo wrote:
>>>>
>>>>
>>>> O
Hello list.
(sorry for posting twice, patch seems to be too big to be posted as
attachment).
I've been hacking ipfw for a while and It seems there is something ready
to test/review in projects/ipfw branch.
Main user-visible changes are related to tables:
1) Tables are now identified by nam
On 14.08.2014 13:23, Luigi Rizzo wrote:
On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
Hello list.
I've been hacking ipfw for a while and It seems there is something
ready to test/review in projects/ipfw branch.
On 14.08.2014 14:44, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
On 14.08.2014 13:23, Luigi Rizzo wrote:
On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru&g
On 14.08.2014 15:15, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
On 14.08.2014 14:44, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru&g
On 14.08.2014 16:08, Marko Zec wrote:
On Thu, 14 Aug 2014 15:52:34 +0400
"Alexander V. Chernikov" wrote:
On 14.08.2014 15:15, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov
mailto:melif...@yandex-team.ru>> wrote:
On 14.08.2014 14:44, L
On 14.08.2014 16:08, Willem Jan Withagen wrote:
On 2014-08-14 13:15, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov <
melif...@yandex-team.ru> wrote:
On 14.08.2014 14:44, Luigi Rizzo wrote:
On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov &
On 14.08.2014 15:52, Alexander V. Chernikov wrote:
> On 14.08.2014 15:15, Luigi Rizzo wrote:
>>
>>
>>
>> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov
>> mailto:melif...@yandex-team.ru>> wrote:
>>
>> On 14.08.2014 14:44, Luigi Rizzo
On 08.08.2014 16:11, Dmitry Selivanov wrote:
04.08.2014 23:51, Alexander V. Chernikov пишет:
On 04.08.2014 15:58, Luigi Rizzo wrote:
On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov wrote:
On 02.08.2014 12:33, Alexander V. Chernikov wrote:
On 02.08.2014 10:33, Luigi Rizzo
On 15.08.2014 18:19, Dmitry Selivanov wrote:
15.08.2014 17:25, Alexander V. Chernikov пишет:
On 08.08.2014 16:11, Dmitry Selivanov wrote:
04.08.2014 23:51, Alexander V. Chernikov пишет:
On 04.08.2014 15:58, Luigi Rizzo wrote:
On Mon, Aug 04, 2014 at 01:44:26PM +0400, Alexander V. Chernikov
On 15.08.2014 19:20, Alexander V. Chernikov wrote:
On 15.08.2014 18:19, Dmitry Selivanov wrote:
15.08.2014 17:25, Alexander V. Chernikov пишет:
On 08.08.2014 16:11, Dmitry Selivanov wrote:
04.08.2014 23:51, Alexander V. Chernikov пишет:
On 04.08.2014 15:58, Luigi Rizzo wrote:
On Mon, Aug 04
On 19.08.2014 20:06, Dmitry Selivanov wrote:
19.08.2014 17:50, Alexander V. Chernikov пишет:
On 15.08.2014 19:20, Alexander V. Chernikov wrote:
On 15.08.2014 18:19, Dmitry Selivanov wrote:
15.08.2014 17:25, Alexander V. Chernikov пишет:
On 08.08.2014 16:11, Dmitry Selivanov wrote
On 11.09.2014 19:01, Freddie Cash wrote:
Good morning everyone,
Just wondering if I'm doing things wrong, or if those two features (rule
sets and auto incrementing rule numbers) just don't play well together.
Until now, I've used the auto-incrementing feature to minimize the amount
of work I ne
On 18.09.2014 20:26, Freddie Cash wrote:
> [Not sure if this is more appropriate for the -ipfw or -stable mailing
> lists.]
>
>
> 64-bit FreeBSD 10.0-p7
>
> Dual-core AMD Opteron 1218 CPU @ 2.6 GHz
> 2 GB of DDR2 RAM
> Intel i350-T4 quad-port gigabit NIC using igb(4)
>
> Each of the gigabit NI
On 18.09.2014 23:30, Freddie Cash wrote:
> Aha! I believe I've found the cause of our current issue.
>
> In an effort to allow reloading of the firewall rules during the day
> without disconnecting anyone (dropping TCP connections), I started playing
> with rule sets. And everything appeared to
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
What has changed:
Main user-visible changes are related to tables:
* Tables are now identified by names, not numbers. There can be up to
65k tables with up to 63-byte long names.
* Tables are now set-aware (defaul
On 05.10.2014 14:13, Willem Jan Withagen wrote:
On 5-10-2014 4:18, John W. O'Brien wrote:
On 10/4/14 8:35 AM, Alexander V. Chernikov wrote:
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
Alexander,
Nice job..
The change list looks impressive.
Real
On 05.10.2014 20:33, Jan Bramkamp wrote:
On 04.10.2014 14:35, Alexander V. Chernikov wrote:
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next
week.
What has changed:
Main user-visible changes are related to tables:
* Tables are now identified by names, not nu
On 04 Oct 2014, at 16:35, Alexander V. Chernikov wrote:
> Hi,
>
> I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
Merged in r 272840.
>
> What has changed:
>
> Main user-visible changes are related to tables:
>
> * Tables are now
On 11.10.2014 18:15, David Wolfskill wrote:
On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote:
Hi,
I'm going to merge projects/ipfw branch to HEAD in the middle of next week.
OK; I was able to build & install head @r272938 this morning on my
laptop; on rebo
30.04.2015, 15:31, "David Wolfskill" :
> From /var/crash/core.txt.6:
>
> Thu Apr 30 05:21:22 PDT 2015
>
> FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #47 r282269M/282269:1100071: Thu
> Apr 30 05:07:08 PDT 2015
> r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64
>
> panic: re
23.05.2015, 03:58, "hiren panchasara" :
> On 05/21/15 at 02:05P, hiren panchasara wrote:
>> On 05/21/15 at 12:42P, hiren panchasara wrote:
>>> Getting back to this now to see if I can avoid ipfw on outgoing packets.
>>>
>>> @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf)
>>> hook_func
03.08.2015, 17:14, "Ian Smith" :
> On Mon, 3 Aug 2015 17:38:18 +0800, Julian Elischer wrote:
> > my reading of the code I can see that 'ipfw delete 100-300' doesn't
> > work (well I know it doesn't work, but I had thought it was a bug),
> > Now I see that its just 'not supported'
I implemented t
03.08.2015, 22:57, "Julian Elischer" :
> On 8/3/15 10:50 PM, Alexander V. Chernikov wrote:
>> 03.08.2015, 17:14, "Ian Smith" :
>>> On Mon, 3 Aug 2015 17:38:18 +0800, Julian Elischer wrote:
>>> > my reading of the code I can see that 'ipf
13.08.2015, 18:19, "Julian Elischer" :
> On 8/13/15 10:41 PM, Ian Smith wrote:
>> On Thu, 13 Aug 2015 16:30:15 +0200, Luigi Rizzo wrote:
>> > On Thu, Aug 13, 2015 at 4:00 PM, Ian Smith wrote:
>> > > On Thu, 13 Aug 2015 12:24:31 +0800, Julian Elischer wrote:
>> > > > BTW, any ideas as t
13.08.2015, 18:21, "Luigi Rizzo" :
> On Thu, Aug 13, 2015 at 5:18 PM, Julian Elischer wrote:
>> On 8/13/15 10:41 PM, Ian Smith wrote:
>>> On Thu, 13 Aug 2015 16:30:15 +0200, Luigi Rizzo wrote:
>>> > On Thu, Aug 13, 2015 at 4:00 PM, Ian Smith
>>> wrote:
>>> > > On Thu, 13 Aug 2015 12:24:3
13.08.2015, 18:22, "Alexander V. Chernikov" :
> 13.08.2015, 18:21, "Luigi Rizzo" :
>> On Thu, Aug 13, 2015 at 5:18 PM, Julian Elischer wrote:
>>> On 8/13/15 10:41 PM, Ian Smith wrote:
>>>> On Thu, 13 Aug 2015 16:30:15 +0200, Luigi Rizzo wrot
03.11.2015, 17:05, "David Wolfskill" :
> This was on my laptop; yesterday, it built & booted:
>
> FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #230
> r290270M/290270:1100085: Mon Nov 2 05:03:07 PST 2015
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64
>
> OK
13.01.2016, 22:56, "Karim Fodil-Lemelin" :
> Hi,
>
> I've hit a very interesting problem with ipfw-nat and local TCP traffic
> that has enough TCP options to hit a special case in m_megapullup().
> Here is the story:
>
> I am using the following NIC:
>
> igb0@pci0:4:0:0: class=0x02 card=0x8
02.05.2018, 06:32, "Julian Elischer" :
> On 2/5/18 1:05 am, Julian Elischer wrote:
>> On 1/5/18 11:03 pm, Rodney W. Grimes wrote:
Many years ago I added code to ipfw so that if -q was set it would
not
complain about
things that were unimportant, nor would it return an error
> On 27 Aug 2022, at 15:48, Michael Pounov wrote:
>
> Hello all
>
> I want to propose one new feature about IPFW. FWSync driver exchange dynamic
> state and aliase records between routers.
> If you have interest about such feature to be implemented at FreeBSD code
> base. You are fill free
74 matches
Mail list logo
