Project

General

Profile

Actions

Bug #1914

closed

warning: nested extern declaration of 'lwkt_replymsg'

Added by srussell over 13 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hi,

Im upgrading DFBSD from 2.4 to 2.8. I compiled with success the GENERIC
kernel. But when I take this configuration and add the firewall and
IPDIVERT changes, I'm getting this:

/usr/src/sys/netinet/ip_divert.c: In function 'div_attach':
/usr/src/sys/netinet/ip_divert.c:437: warning: implicit declaration of
function 'lwkt_replymsg'
/usr/src/sys/netinet/ip_divert.c:437: warning: nested extern declaration
of 'lwkt_replymsg'
  • Error code 1

Here is my changes to the GENERIC kernel (<=my kernel):

< #cpu I486_CPU
< #cpu I586_CPU
---

cpu I486_CPU
cpu I586_CPU

< #makeoptions DEBUG=-g #Build kernel with gdb(1) debug
symbols
---

makeoptions DEBUG=-g #Build kernel with gdb(1) debug

symbols

< options COMPAT_LINUX

< #device uhid # "Human Interface Devices"
---

device uhid # "Human Interface Devices"

< options IPFIREWALL #firewall
< options IPFIREWALL_VERBOSE #enable logging to syslogd(8)
< options IPFIREWALL_FORWARD #enable transparent proxy support
< options IPV6FIREWALL #firewall for IPv6
< options IPV6FIREWALL_VERBOSE
< options IPDIVERT #divert sockets
< device pf
< device pfsync
< device pflog

I've searched and found no issue on this. Anybody can help?

Thanks

SR

Actions #1

Updated by justin over 13 years ago

On Sat, November 20, 2010 2:42 pm, Stephane Russell wrote:

Hi,

Im upgrading DFBSD from 2.4 to 2.8. I compiled with success the GENERIC
kernel. But when I take this configuration and add the firewall and
IPDIVERT changes, I'm getting this:

Are you using both ipfw and pf? Most of those options are for ipfw (I
think). I had trouble with ipfw not working when I upgraded to 2.6 (I
haven't moved that box to 2.8 yet), though I think it wasn't during
compilation but when running it later.

This is not a direct solution to your problem, but my fix was to comment
out all the IPFIREWALL and IPDIVERT stuff and put this in /etc/rc.conf:

gateway_enable="YES"
pf_enable="YES"
pflog_enable="YES"

And this in /etc/pf.conf

extif="em0"
intif="nfe0"
nat on $extif from 192.168.0.0/24 to any -> ($extif)

I'm just using this box for NAT. If you're doing the same, this should
work for you as a replacement strategy.

Actions #2

Updated by dillon over 13 years ago

:Hi,
:
:Im upgrading DFBSD from 2.4 to 2.8. I compiled with success the GENERIC
:kernel. But when I take this configuration and add the firewall and
:IPDIVERT changes, I'm getting this:
:
:/usr/src/sys/netinet/ip_divert.c: In function 'div_attach':
:/usr/src/sys/netinet/ip_divert.c:437: warning: implicit declaration of
:function 'lwkt_replymsg'
:/usr/src/sys/netinet/ip_divert.c:437: warning: nested extern declaration
:of 'lwkt_replymsg'
:*** Error code 1
:
:Here is my changes to the GENERIC kernel (<=my kernel):

Bug in the sources with those options.  I will commit a fix for
the compile error and MFC it to 2.8.
-Matt
Actions #3

Updated by srussell over 13 years ago

I'm using ipfw since always. Maybe I should take a look at pf. I first
compiled the kernel without the pf devices. I than activated the pf
devices in case they would be some dependency fulfilled.

Thanks,

SR

Justin C. Sherrill a écrit :

On Sat, November 20, 2010 2:42 pm, Stephane Russell wrote:

Hi,

Im upgrading DFBSD from 2.4 to 2.8. I compiled with success the GENERIC
kernel. But when I take this configuration and add the firewall and
IPDIVERT changes, I'm getting this:

Are you using both ipfw and pf? Most of those options are for ipfw (I
think). I had trouble with ipfw not working when I upgraded to 2.6 (I
haven't moved that box to 2.8 yet), though I think it wasn't during
compilation but when running it later.

This is not a direct solution to your problem, but my fix was to comment
out all the IPFIREWALL and IPDIVERT stuff and put this in /etc/rc.conf:

gateway_enable="YES"
pf_enable="YES"
pflog_enable="YES"

And this in /etc/pf.conf

extif="em0"
intif="nfe0"
nat on $extif from 192.168.0.0/24 to any -> ($extif)

I'm just using this box for NAT. If you're doing the same, this should
work for you as a replacement strategy.

Actions #4

Updated by srussell over 13 years ago

I couldn't make my ipfw work again, it was causing a page faults
somewhere. So I've applied what you suggested with success. Thank you
very much!

SR

Le 2010-11-20 17:18, Justin C. Sherrill a écrit :

On Sat, November 20, 2010 2:42 pm, Stephane Russell wrote:

Hi,

Im upgrading DFBSD from 2.4 to 2.8. I compiled with success the GENERIC
kernel. But when I take this configuration and add the firewall and
IPDIVERT changes, I'm getting this:

Are you using both ipfw and pf? Most of those options are for ipfw (I
think). I had trouble with ipfw not working when I upgraded to 2.6 (I
haven't moved that box to 2.8 yet), though I think it wasn't during
compilation but when running it later.

This is not a direct solution to your problem, but my fix was to comment
out all the IPFIREWALL and IPDIVERT stuff and put this in /etc/rc.conf:

gateway_enable="YES"
pf_enable="YES"
pflog_enable="YES"

And this in /etc/pf.conf

extif="em0"
intif="nfe0"
nat on $extif from 192.168.0.0/24 to any -> ($extif)

I'm just using this box for NAT. If you're doing the same, this should
work for you as a replacement strategy.

Actions #5

Updated by srussell over 13 years ago

I tried to go further with pf. I started to test some firewall functionalities
to reimplement my ipfw firewall. The natting is working well. But DFBSD crashes
when I activate some type of filtering. Here is my last configuration file:

1 table <crackers> persist file "/etc/pf/crackers.db"
2 table <volume> persist file "/etc/pf/volume.db"
3 set skip on lo0
4 scrub in
5 nat on $ext_if from $lan_net -> ($ext_if)
6 #block in
7 block in quick from urpf-failed
8 block in quick on ext_if from <crackers>
9 block out quick on ext_if to <volume>
10 pass in on $int_if from $lan_net
11 pass out on $int_if to $lan_net
12 pass out on $ext_if proto { tcp udp icmp } all modulate state

This configuration causes a page fault. I didn't activate the line 6 yet,
because I wanted to test pass rules before closing everything. When the line 12
is commented, everything seems to work fine. But when I activate it, DFBSD
crashes with this message (copied by hand):

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3e
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc03a5ee2
stack pointer = 0x10:0xc7d4e9a4
frame pointer = 0x10:0xc7d4ea18
code segment = base 0x0, limit 0xffffff, type 0x16 = DPL 0, pres 1, def 32 1, gran 1
processor eflags = interrupt enabled, resume, 10PL = 0
currentthread = pri 12

kernel:type 12 trap, code=0
Stopped at pf_new_inst 0x2e: cmpb $0x1,0x3e(%ebx)

Actions #6

Updated by srussell about 13 years ago

After an upgrade to DragonFly 2.10 and the latest pf it contains, the problem
remains. I get reboots with no apparent reasons and crashes. Sometime both one
after the other. More details to come, I'll try to get more details and some
stack traces.

Actions #7

Updated by srussell over 12 years ago

  • Description updated (diff)
  • Status changed from New to Closed

It looks like there is no more panics when activating my PF ruleset with DragonFly 3.0. Though, after many tests, even the example firewall settings given at the end of this page: http://www.openbsd.org/faq/pf/filter.html, didn't work right for me. But no panics are happening anymore, except for one caused by a buffer overflow, that I couldn't reproduce afterward.

Actions #8

Updated by srussell almost 11 years ago

  • Description updated (diff)
  • Status changed from Closed to In Progress
  • Assignee deleted (0)

I finally found what is causing constant reboots on my pf configuration. I replaced this configuration:

pass out on $ext_if inet proto { tcp udp icmp } all modulate state

with this:

pass out on $ext_if inet proto { tcp udp icmp } all keep state

So it seems that de "modulate" state is the root of the problem. Since I replaced it by "keep state", my firewall is working normally without panic or unwanted reboots.

Actions #9

Updated by srussell almost 11 years ago

  • Status changed from In Progress to Closed
Actions

Also available in: Atom PDF