Re: Caveat emptor: Beware of ZFS on HEAD

2017-07-16 Thread Andriy Gapon
On 12/07/2017 23:20, Peter Wemm wrote:
> We mostly run HEAD in the freebsd.org cluster.  Sometime in the last few 
> weeks 
> an ugly zfs problem has surfaced. If a redundant volume is degraded, zfs 
> panics on boot.  If a drive fails while running, or is manually put offline, 
> zfs 
> panics the same way.
> 
> I do not have a smoking gun, but I am suspicious of the June 28th commits 
> (starting at r320156) and their follow-ups. eg: r320452.
> 
> https://bugs.freebsd.org/220691
> 
> I believe single disk systems will *not* be affected by this - the panic only 
> happens when a raidz (and presumably mirror) degrades.  Your laptop etc 
> should 
> be fine.
> 
> I apologize for being vague - I do not know more. Folks running HEAD should 
> take appropritate precautions (eg: keeping a known-good kernel.old and 
> modules 
> around).  This is always advisable when running HEAD anyway, particularly so 
> now.  For us, a kernel.old from June 18th worked fine.
> 

My apologies for the bug.
Everyone affected, could you please test the patch from the bug report?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220691#c3
Thank you!

-- 
Andriy Gapon
___
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: netgraph: documentation issue? What kernel options? Where to find?

2017-07-16 Thread O. Hartmann
Am Sun, 16 Jul 2017 16:29:40 -0600
Ian Lepore  schrieb:

> On Sun, 2017-07-16 at 22:48 +0200, O. Hartmann wrote:
> > For a small SoC based system, I use a highly customised static kernel
> > and build the
> > system via NanoBSD with no kernel modules.
> > 
> > Tyring to track down some network issues with recent CURRENT I
> > figured out, that when
> > using the ppp client to connect via modem to the ISP and there is no 
> > 
> > options NETGRAPH_ETHER
> > options NETGRAPH_PPPOE
> > 
> > in the kernel configuration, the resulting system fails to establish
> > a ppp session. The
> > man page states, that a netgraph node is established, but as hard as
> > I look, I can not
> > find any(!) information in the man pages what options are
> > necessary/optional to provide
> > the correct module statically.
> > 
> > The same is for many other NETGRAPH_XXX features. Starting from man
> > page "man 4
> > netgraph", section "SEE ALSO", I started tweaking the kernel with
> > NETGRAPH_XXX, i.e.
> > ng_vlan -> NETGRAPH_VLAN until the compiler bails out with an error,
> > for instance
> > ng_car -> NETGRAPH_CAR.
> > 
> > I tried to find out what options cover which netgraph module but
> > there is - right,
> > nothing I can find on a direct route.
> > 
> > Since netgraph isn't so brand new (I guess ~ 2000 from the PDFs I
> > found on the network),
> > there must be some documentation other than "reading the source
> > code".
> > 
> > Please give me some hints where to find the entry point for the
> > appropriate documented
> > options for netgraph modules.
> > 
> > Obviously, some ng_xxx modules are prerequisite for some services to
> > work properly, as
> > ppp - but I can't find any hints for "options NETGRAPH_ETHER" or
> > "options NETGRAPH_PPPOE"
> > in the manpages (looked at ppp, pppoed). 
> > 
> > Thanks in advance,
> > kind regards
> > 
> > Oliver
> >   
> 
> I can't help with anything specific to netgraph or its [lack of] docs.
> 
> For the general question "How do I know what undocumented device or
> option statement to put in my kernel config to get x" a good place
> to start is /usr/src/sys/conf/NOTES.  It's supposed to contain all the
> options and devices (except some machine/arch-specific stuff).  If you
> don't find it in NOTES, try "grep -i x *" in that dir, you may find
> the thing you're looking for in 'options' or 'files' and get some clues
> that way.

Yes, correct and I did this, too, but pulling in all of the options resulted in 
failues,
as far as I know NETGRAPH_CAR bailed out (with -DNO_CLEAN, I must confess).

> 
> For the netgraph stuff, I see that in NOTES it tells you how to find
> the manpages for netgraph things, so I guess I accidentally did answer
> that part too.  :)

No, not exactly,
it doesn't tell me which NETGRAPH_XXX I need for a certain service so I have to 
do
experiments: starting the service with a full install of all modules and see 
what modules
gets kloaded and then put the appropriate option into the kernel.

In my situation, using ppp/pppoe failed silently when disabling options 
NETGRAPH_ETHER,
NETGRAPH_PPPOE and the refering kernel modules weren't present.

Since I fight a problem with VLANs and routing on CURRENT, I'd appreciate a 
more dense
documentation - or a hint.

> 
> -- Ian


Thank you very much for the patience,

kind regards

Oliver

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpPL7gaDvmLA.pgp
Description: OpenPGP digital signature


Attn: CI/Jenkins people; Run bhyve instance for testing pf

2017-07-16 Thread Panagiotes Mousikides

Hello everybody!

I am working on adding tests to the FreeBSD test suite for testing pf, 
the network packet filter.


These tests need at least two machines running and connected to each 
other, with one machine generating network traffic and the other running 
pf and filtering the traffic.  I am looking for a way to fire off a 
bhyve instance to serve as the second machine, the first being the 
actual machine I am running the tests on. This should be done completely 
automatically, with scripts to configure all network interfaces and to 
preferably also set up an SSH server on the bhyve instance.


This bhyve instance could start off as running the latest stable version 
of FreeBSD, or it could be configured to run a snapshot of the 
development tree.  The aim is to have the desired version of FreeBSD 
that we want to test running on it.  Ideally this would be done in such 
a way that we can reuse the machine for further tests, instead of 
rebuilding everything from scratch for each test.


What I am looking for is the best way to do this, preferably so that it 
can be easily integrated into the CI work being done at Jenkins.  What 
do you think?  Any input is welcome!


All the best,
Panagiotes

___
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: netgraph: documentation issue? What kernel options? Where to find?

2017-07-16 Thread Ian Lepore
On Sun, 2017-07-16 at 22:48 +0200, O. Hartmann wrote:
> For a small SoC based system, I use a highly customised static kernel
> and build the
> system via NanoBSD with no kernel modules.
> 
> Tyring to track down some network issues with recent CURRENT I
> figured out, that when
> using the ppp client to connect via modem to the ISP and there is no 
> 
> options   NETGRAPH_ETHER
> options   NETGRAPH_PPPOE
> 
> in the kernel configuration, the resulting system fails to establish
> a ppp session. The
> man page states, that a netgraph node is established, but as hard as
> I look, I can not
> find any(!) information in the man pages what options are
> necessary/optional to provide
> the correct module statically.
> 
> The same is for many other NETGRAPH_XXX features. Starting from man
> page "man 4
> netgraph", section "SEE ALSO", I started tweaking the kernel with
> NETGRAPH_XXX, i.e.
> ng_vlan -> NETGRAPH_VLAN until the compiler bails out with an error,
> for instance
> ng_car -> NETGRAPH_CAR.
> 
> I tried to find out what options cover which netgraph module but
> there is - right,
> nothing I can find on a direct route.
> 
> Since netgraph isn't so brand new (I guess ~ 2000 from the PDFs I
> found on the network),
> there must be some documentation other than "reading the source
> code".
> 
> Please give me some hints where to find the entry point for the
> appropriate documented
> options for netgraph modules.
> 
> Obviously, some ng_xxx modules are prerequisite for some services to
> work properly, as
> ppp - but I can't find any hints for "options NETGRAPH_ETHER" or
> "options NETGRAPH_PPPOE"
> in the manpages (looked at ppp, pppoed). 
> 
> Thanks in advance,
> kind regards
> 
> Oliver
> 

I can't help with anything specific to netgraph or its [lack of] docs.

For the general question "How do I know what undocumented device or
option statement to put in my kernel config to get x" a good place
to start is /usr/src/sys/conf/NOTES.  It's supposed to contain all the
options and devices (except some machine/arch-specific stuff).  If you
don't find it in NOTES, try "grep -i x *" in that dir, you may find
the thing you're looking for in 'options' or 'files' and get some clues
that way.

For the netgraph stuff, I see that in NOTES it tells you how to find
the manpages for netgraph things, so I guess I accidentally did answer
that part too.  :)

-- Ian
___
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: Inter-VLAN routing on CURRENT: any known issues?

2017-07-16 Thread O. Hartmann
Am Sun, 16 Jul 2017 23:14:41 +0200
Frank Steinborn  schrieb:

> O. Hartmann  wrote:
> > I have not have any success on this and I must ask now, to not make a fool 
> > out of my
> > self, whether the concept of having several vlan over one single NIC is 
> > possible with
> > FreeBSD (12-CURRENT, as of today, r321055.
> > 
> > Since it is even not possible to "route" from a non-tagged igb1 to a tagged 
> > vlan
> > igb1.2 or igb1.66 (for instance) on the same NIC, I have a faint suspect 
> > that I'm
> > doing something terribly wrong.
> > 
> > I think everyone working with vlan should have those problems, but since I 
> > can not
> > find anything on the list, I must do something wrong - my simple conclusion.
> > 
> > What is it?  
> 
> Do you have enabled net.inet.ip.forwarding?
> 

Of course I have. As I stated earlier, ICMP pings from on VLAN to another over 
this
router works, but any IP (UDP, TCP) is vanishing into thin air.

I don't have a FBSD-11-STABLE reference system at hand, so that I can check 
with another
revision/major release of the OS, but I work on that. 

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpsFj63_E5Rs.pgp
Description: OpenPGP digital signature


Re: Inter-VLAN routing on CURRENT: any known issues?

2017-07-16 Thread O. Hartmann
Am Sun, 16 Jul 2017 23:14:41 +0200
Frank Steinborn  schrieb:

> O. Hartmann  wrote:
> > I have not have any success on this and I must ask now, to not make a fool 
> > out of my
> > self, whether the concept of having several vlan over one single NIC is 
> > possible with
> > FreeBSD (12-CURRENT, as of today, r321055.
> > 
> > Since it is even not possible to "route" from a non-tagged igb1 to a tagged 
> > vlan
> > igb1.2 or igb1.66 (for instance) on the same NIC, I have a faint suspect 
> > that I'm
> > doing something terribly wrong.
> > 
> > I think everyone working with vlan should have those problems, but since I 
> > can not
> > find anything on the list, I must do something wrong - my simple conclusion.
> > 
> > What is it?  
> 
> Do you have enabled net.inet.ip.forwarding?
> 


... aber selbstverständlich doch, das ist das erste seit nunmehr 20 Jahren 
FreeBSD, was
auf einem Router eingestellt wird ...

Wie ich bereits beschrieben habe: pingen (ICMP) auf andere VLANs geht, nur 
keine IP
Dienste - und das mit oder ohne eingeschalteter IPFW.

Grüße,

oh



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp5SoJDaNM66.pgp
Description: OpenPGP digital signature


Re: Inter-VLAN routing on CURRENT: any known issues?

2017-07-16 Thread Frank Steinborn
O. Hartmann  wrote:
> I have not have any success on this and I must ask now, to not make a fool 
> out of my
> self, whether the concept of having several vlan over one single NIC is 
> possible with
> FreeBSD (12-CURRENT, as of today, r321055.
> 
> Since it is even not possible to "route" from a non-tagged igb1 to a tagged 
> vlan igb1.2
> or igb1.66 (for instance) on the same NIC, I have a faint suspect that I'm 
> doing
> something terribly wrong.
> 
> I think everyone working with vlan should have those problems, but since I 
> can not find
> anything on the list, I must do something wrong - my simple conclusion.
> 
> What is it?

Do you have enabled net.inet.ip.forwarding?

___
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: Attn: CI/Jenkins people; Run bhyve instance for testing pf

2017-07-16 Thread Alan Somers
On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides
 wrote:
> Hello everybody!
>
> I am working on adding tests to the FreeBSD test suite for testing pf, the
> network packet filter.
>
> These tests need at least two machines running and connected to each other,
> with one machine generating network traffic and the other running pf and
> filtering the traffic.  I am looking for a way to fire off a bhyve instance
> to serve as the second machine, the first being the actual machine I am
> running the tests on. This should be done completely automatically, with
> scripts to configure all network interfaces and to preferably also set up an
> SSH server on the bhyve instance.
>
> This bhyve instance could start off as running the latest stable version of
> FreeBSD, or it could be configured to run a snapshot of the development
> tree.  The aim is to have the desired version of FreeBSD that we want to
> test running on it.  Ideally this would be done in such a way that we can
> reuse the machine for further tests, instead of rebuilding everything from
> scratch for each test.
>
> What I am looking for is the best way to do this, preferably so that it can
> be easily integrated into the CI work being done at Jenkins.  What do you
> think?  Any input is welcome!
>
> All the best,
> Panagiotes

It's possible to setup CI systems that involve multiple machines
networked together.  I've done it.  But it's complicated, fragile, and
slow.  I advise you to consider very carefully whether you truly need
multiple VMs.  What about creating an epair(4)?  You could run pf on
epair0b and generate traffic from epair0a.  That would be faster than
spinning up VMs, and would be very easy to integrate into any other CI
system.  Would that work?

-Alan
___
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: Inter-VLAN routing on CURRENT: any known issues?

2017-07-16 Thread O. Hartmann
Am Fri, 14 Jul 2017 15:00:30 +0300
"Andrey V. Elsukov"  schrieb:

> On 14.07.2017 14:42, O. Hartmann wrote:
> > I use in-kernel NAT. IPFW is performing NAT. In firewall type "OPEN" from 
> > the
> > vanilla rc.conf, IPFW has instance "nat 123" which provides then NAT.  
> 
> I never used default config types for firewall, so, it would be nice to
> see what rules do you have.
> 
> # ipfw show
> # ipfw nat show config
> 
> >> VLANs work on the layer2  
> > According to 1):
> > 
> > I consider the settings of the switch now as correct. I have no access to 
> > the
> > router right now. But I did short experiments yesterday evening and it is
> > weird: loged in on thr router, I can ping every host on any VLAN, so ICMP
> > travel from the router the right way to its destination and back.
> > 
> > From any host on any VLAN that is "trunked" through the router, I can ping 
> > any
> > other host on any other VLAN, preferrably not on the same VLAN. By cutting 
> > off
> > the trunk line to the router, pinging stops immediately.
> > 
> > From any host on any VLAN I can ping any host which is NATed on the outside
> > world.
> > 
> > From the router itself, I can ssh into any host on any VLAN providing ssh
> > service. That said, according to question 3), NAT is considered to be setup
> > correctly.
> > 
> > Now the strange things: Neither UDP, nor TCP services "flow" from hosts on 
> > one
> > VLAN to hosts on a different VLAN. Even ssh doens't work. 
> > When loged in onto the router, I can't "traceroute" any host on any VLAN.  
> 
> This is most likely due to the problem with firewall rules.
> If you set net.inet.ip.firewall.enable=0, does it solve the problem with
> TCP/UDP between hosts on a different VLANs?
> 
> > According to question 2), the ability to ping from, say, a host on VLAN 
> > 1000 to
> > another host on VLAN 2 passing through the router would indicate that both
> > sides know their routes to each other. Or am I wrong?  
> 
> Yes.
> 
> > I got words from Sean bruno that there might be a problem with the Intel 
> > i210
> > chipset in recent CURRENT - and the hardware on the PCEngine APU 2C4 is 
> > three
> > i210. I'm aware of the problem since r320134 (the oldest CURRENT I started
> > experimenting with the VLAN trunking).  
> 
> It is very strange problems, why ICMP works, but TCP/UDP does not? :)
> You can try to disable any type of offloading for the card, there were
> some problems in the past with checksum offlading, that may lead to the
> problems with TCP, but this usually should be noticeable in the tcpdump
> output.
> 

I have not have any success on this and I must ask now, to not make a fool out 
of my
self, whether the concept of having several vlan over one single NIC is 
possible with
FreeBSD (12-CURRENT, as of today, r321055.

Since it is even not possible to "route" from a non-tagged igb1 to a tagged 
vlan igb1.2
or igb1.66 (for instance) on the same NIC, I have a faint suspect that I'm doing
something terribly wrong.

I think everyone working with vlan should have those problems, but since I can 
not find
anything on the list, I must do something wrong - my simple conclusion.

What is it?

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpDBY3Opn8QH.pgp
Description: OpenPGP digital signature


netgraph: documentation issue? What kernel options? Where to find?

2017-07-16 Thread O. Hartmann
For a small SoC based system, I use a highly customised static kernel and build 
the
system via NanoBSD with no kernel modules.

Tyring to track down some network issues with recent CURRENT I figured out, 
that when
using the ppp client to connect via modem to the ISP and there is no 

options NETGRAPH_ETHER
options NETGRAPH_PPPOE

in the kernel configuration, the resulting system fails to establish a ppp 
session. The
man page states, that a netgraph node is established, but as hard as I look, I 
can not
find any(!) information in the man pages what options are necessary/optional to 
provide
the correct module statically.

The same is for many other NETGRAPH_XXX features. Starting from man page "man 4
netgraph", section "SEE ALSO", I started tweaking the kernel with NETGRAPH_XXX, 
i.e.
ng_vlan -> NETGRAPH_VLAN until the compiler bails out with an error, for 
instance
ng_car -> NETGRAPH_CAR.

I tried to find out what options cover which netgraph module but there is - 
right,
nothing I can find on a direct route.

Since netgraph isn't so brand new (I guess ~ 2000 from the PDFs I found on the 
network),
there must be some documentation other than "reading the source code".

Please give me some hints where to find the entry point for the appropriate 
documented
options for netgraph modules.

Obviously, some ng_xxx modules are prerequisite for some services to work 
properly, as
ppp - but I can't find any hints for "options NETGRAPH_ETHER" or "options 
NETGRAPH_PPPOE"
in the manpages (looked at ppp, pppoed). 

Thanks in advance,
kind regards

Oliver



pgp_OmyTJ8W7A.pgp
Description: OpenPGP digital signature


Fw: Re: Problem with make installworld et alii

2017-07-16 Thread Filippo Moretti



- Forwarded Message -From: Michael Butler 
To: Filippo Moretti ; 
Current Sent: Sunday, July 9, 2017, 4:50:13 PM 
GMT+2Subject: Re: Problem with make installworld et alii
You need to a build newer than SVN r320652 to fix this ..

On 07/09/17 10:43, Filippo Moretti wrote:
> FreeBSD sting 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320360: Mon Jun 26 
> 15:49:29 UTC 2017    
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  i386After 
> compiling world and kernel I cannot make install world with the following 
> error:Fatal error cannot allocate read line in initial thread at line 392 in 
> file /use/src/lib/libthr/thread/thr_init.c (errorno=12)PID 42315 (cc) uid 0: 
> exited on signal 6 (core dumped)
> make:  "/usr/src/share/mk/bsd.compiler.mk" line 145 : Unable to determine 
> compiler type for CC=cc . Consider settingCOMPILER_TYPE

This error is still present with r321039MsincerelyFilippo
___
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"

cc(1) errors in libc includes

2017-07-16 Thread Florian Limberger

Hi -current,

today I built -CURRENT for the first time in a VM and installed from nfs
mounts. But now cc(1) from base seems to be broken, as it fails
compiling a simple hello-world program with errors in include files from
the libc. The previously installed clang40 works just fine for this
task, but since I lost track of -CURRENT around the time of the ino64
changes, I don't necessarily trust it to do the right thing.

Do you have any solutions for me how to get the compiler working again?

Below the uname info and the actual error messages:

> # uname -a
> FreeBSD nachtschatten 12.0-CURRENT FreeBSD 12.0-CURRENT #1 
aa8f1c64d43(master): Sun Jul 16 09:41:10 UTC 2017 
root@:/usr/obj/usr/src/sys/GENERIC-NODEBUG  amd64


> # cat test.c
> #include 
>
> int
> main(void)
> {
> printf("hello, world!\n");
> }
> # cc test.c
> In file included from test.c:1:
> In file included from /usr/include/stdio.h:41:
> /usr/include/sys/_types.h:117:19: error: array is too large (128 
elements)

> char__mbstate8[128];
>^~~
> In file included from test.c:1:
> /usr/include/stdio.h:139:22: error: array is too large (3 elements)
> unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
> ^
> /usr/include/stdio.h:140:22: error: array is too large (1 elements)
> unsigned char _nbuf[1]; /* guarantee a getc() buffer */
> ^
> /usr/include/stdio.h:290:24: error: integer constant expression 
evaluates to value 3 that cannot be represented in a 32-bit unsigned 
integer type

> ...) __printflike(3, 4);
>   ^
> /usr/include/stdio.h:292:18: error: integer constant expression 
evaluates to value 2 that cannot be represented in a 32-bit unsigned 
integer type

> __scanflike(2, 0);
> ^
> /usr/include/stdio.h:293:61: error: integer constant expression 
evaluates to value 1 that cannot be represented in a 32-bit unsigned 
integer type

> int  vscanf(const char * __restrict, __va_list) __scanflike(1, 0);
> ^
> /usr/include/stdio.h:295:30: error: integer constant expression 
evaluates to value 3 that cannot be represented in a 32-bit unsigned 
integer type

> __va_list) __printflike(3, 0);
> ^
> /usr/include/stdio.h:297:18: error: integer constant expression 
evaluates to value 2 that cannot be represented in a 32-bit unsigned 
integer type

> __scanflike(2, 0);
> ^
> /usr/include/stdio.h:361:69: error: integer constant expression 
evaluates to value 2 that cannot be represented in a 32-bit unsigned 
integer type
> int  vdprintf(int, const char * __restrict, __va_list) 
__printflike(2, 0);

> ^
> /usr/include/stdio.h:364:62: error: integer constant expression 
evaluates to value 2 that cannot be represented in a 32-bit unsigned 
integer type

> int  dprintf(int, const char * __restrict, ...) __printflike(2, 3);
>  ^
> /usr/include/stdio.h:371:56: error: integer constant expression 
evaluates to value 2 that cannot be represented in a 32-bit unsigned 
integer type

> int  asprintf(char **, const char *, ...) __printflike(2, 3);
>^
> /usr/include/stdio.h:381:19: error: integer constant expression 
evaluates to value 2 that cannot be represented in a 32-bit unsigned 
integer type

> __printflike(2, 0);
>  ^
> 12 errors generated.

Regards


flo
___
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: ipfw_netflow in base/head r320944 & r321008

2017-07-16 Thread Trond Endrestøl
On Sun, 16 Jul 2017 10:43+0200, Trond Endrestøl wrote:

> At boot time /etc/rc display this message:
> 
> /etc/rc: WARNING: $ipfw_netflow_enable is not set properly - see rc.conf(5).
> 
> This was introduced in r320944 and corrected to some extent in 
> r321008.
> 
> Nevertheless, a default value for ipfw_netflow_enable should be 
> provided:
> 
> Index: etc/defaults/rc.conf
> ===
> --- etc/defaults/rc.conf  (revision 321041)
> +++ etc/defaults/rc.conf  (working copy)
> @@ -195,6 +195,7 @@
>   # of state tables at shutdown and boot
>  ipfs_program="/sbin/ipfs"# where the ipfs program lives
>  ipfs_flags=""# additional flags for ipfs

> +ipfw_netflow_enable="NO" # Set yo YES to enable ipfw netflow.

Typo fixed:

+ipfw_netflow_enable="NO"   # Set to YES to enable ipfw netflow.

>  pf_enable="NO"   # Set to YES to enable packet filter 
> (pf)
>  pf_rules="/etc/pf.conf"  # rules definition file for pf
>  pf_program="/sbin/pfctl" # where the pfctl program lives

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
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"


ipfw_netflow in base/head r320944 & r321008

2017-07-16 Thread Trond Endrestøl
At boot time /etc/rc display this message:

/etc/rc: WARNING: $ipfw_netflow_enable is not set properly - see rc.conf(5).

This was introduced in r320944 and corrected to some extent in 
r321008.

Nevertheless, a default value for ipfw_netflow_enable should be 
provided:

Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf(revision 321041)
+++ etc/defaults/rc.conf(working copy)
@@ -195,6 +195,7 @@
# of state tables at shutdown and boot
 ipfs_program="/sbin/ipfs"  # where the ipfs program lives
 ipfs_flags=""  # additional flags for ipfs
+ipfw_netflow_enable="NO"   # Set yo YES to enable ipfw netflow.
 pf_enable="NO" # Set to YES to enable packet filter (pf)
 pf_rules="/etc/pf.conf"# rules definition file for pf
 pf_program="/sbin/pfctl"   # where the pfctl program lives

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
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"