Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
Synopsis: [ipfw] [panic] freebsd 7.0 panic with mpd State-Changed-From-To: open-patched State-Changed-By: oleg State-Changed-When: Fri Apr 25 10:20:48 UTC 2008 State-Changed-Why: In private discussion PR author confirms that suggested patch did help. Responsible-Changed-From-To: freebsd-ipfw-oleg Responsible-Changed-By: oleg Responsible-Changed-When: Fri Apr 25 10:20:48 UTC 2008 Responsible-Changed-Why: see above. http://www.freebsd.org/cgi/query-pr.cgi?pr=121955 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
Trouble fixed by updating to FreeBSD 7.0-STABLE. Now: # uptime 1:14PM up 4:41, 2 users, load averages: 0.00, 0.00, 0.00 Let's look, that will be further. -- реклама --- Научим каждого зарабатывать на колебаниях курсов валют. Запись на бесплатный семинар http://www.fxclub.org/condition_howtrade_freeseminar/ ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
I can not answer this for sure but trying it out is for free :) but it will not help here I guess Even if I believe the problem is in ipfw you probably should try to isolate if it is in any means related to mpd, probably you can run your ppp from another server and run ipfw only on this one, after that you know more you are with 7-R or 7-Stable? I use FreeBSD 7.0-RELEASE. And don't want use stable, because it is high probability to get dump on another problems. :) On Friday I shall try the considered variants and write results. Andrey and AT Matik: my name is João, this is my company email address Sorry. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
I did tuning, that was in my other letters (net.isr.direct=0, tuning in /boot/loader.conf) And received panic after 12 minutes: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xf2a9864 fault code = supervisor read, page not present instruction pointer = 0x20:0xc7d1a95f stack pointer = 0x28:0xed8ccae4 frame pointer = 0x28:0xed8ccbd8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: net) trap number = 12 panic: page fault cpuid = 0 Uptime: 12m14s Physical memory: 1015 MB Dumping 67 MB: (CTRL-C to abort) 52 36 20 4 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc055a0b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc055a379 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07ac59c in trap_fatal (frame=0xed8ccaa4, eva=254449764) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07ac800 in trap_pfault (frame=0xed8ccaa4, usermode=0, eva=254449764) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc07ad182 in trap (frame=0xed8ccaa4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc079431b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc7d1a95f in ?? () Previous frame inner to this frame (corrupt stack?) Also I fix ipfw.sh and remove all queues from it. Used only pipes. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
The following reply was made to PR kern/121955; it has been noted by GNATS. From: Alexander Shulikov [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd Date: Mon, 24 Mar 2008 10:07:14 +0200 I receive new dump with mpd-4.4 and FreeBSD 7.0-RELEASE: # kgdb /usr/obj/usr/src/sys/kkk/kernel.debug /var/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc062ffa1 esp = 0xe3fedf40 ebp = 0xe3fee264 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 3m19s Physical memory: 1015 MB Dumping 62 MB: (CTRL-C to abort) (CTRL-C to abort) 47 (CTRL-C to abort) 31 15 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc055a0b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc055a379 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07ac2ab in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:928 #4 0xc062ffa1 in ipfw_chk (args=0xe3fee27c) at /usr/src/sys/netinet/ip_fw2.c:2303 #5 0xc0634771 in ipfw_check_out (arg=0x0, m0=0xe3fee380, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:251 #6 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3fee410, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #7 0xc0638ee2 in ip_output (m=0xc3f82600, opt=0x0, ro=0xe3fee3e4, flags=1, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:438 #8 0xc0628cf6 in dummynet_send (m=0xc3f82600) at /usr/src/sys/netinet/ip_dummynet.c:840 #9 0xc062b23c in dummynet_io (m=0xc3f82600, dir=1, fwa=0xe3fee578) at /usr/src/sys/netinet/ip_dummynet.c:1373 #10 0xc063489e in ipfw_check_out (arg=0x0, m0=0xe3fee67c, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:289 #11 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3fee70c, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #12 0xc0638ee2 in ip_output (m=0xc3f82600, opt=0x0, ro=0xe3fee6e0, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:438 #13 0xc069aa55 in tcp_respond (tp=0x0, ipgen=0xc3f96031, th=0xc3f96045, m=0xc3f82600, ack=2416490148, seq=0, flags=Variable flags is not available. ) at /usr/src/sys/netinet/tcp_subr.c:572 #14 0xc0692ab6 in tcp_dropwithreset (m=0xc3f82600, th=0xc3f96045, tp=0x0, tlen=1, rstreason=3) at /usr/src/sys/netinet/tcp_input.c:2470 #15 0xc0695933 in tcp_input (m=0xc3f82600, off0=20) at /usr/src/sys/netinet/tcp_input.c:851 #16 0xc06375e8 in ip_input (m=0xc3f82600) at /usr/src/sys/netinet/ip_input.c:665 #17 0xc05f8195 in netisr_dispatch (num=2, m=0xc3f82600) at /usr/src/sys/net/netisr.c:185 #18 0xc0628d22 in dummynet_send (m=0xc3f82600) at /usr/src/sys/netinet/ip_dummynet.c:846 #19 0xc062b23c in dummynet_io (m=0xc3f82600, dir=2, fwa=0xe3feea08) at /usr/src/sys/netinet/ip_dummynet.c:1373 #20 0xc06345b7 in ipfw_check_in (arg=0x0, m0=0xe3feeb0c, ifp=0xc3c6bc00, dir=1, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:163 #21 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3feeb64, ifp=0xc3c6bc00, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78 #22 0xc0637121 in ip_input (m=0xc3f82600) at /usr/src/sys/netinet/ip_input.c:417 #23 0xc05f8195 in netisr_dispatch (num=2, m=0xc3f82600) at /usr/src/sys/net/netisr.c:185 #24 0xc060d2c4 in ng_iface_rcvdata (hook=0xc3ee6400, item=0xc40917c0) at /usr/src/sys/netgraph/ng_iface.c:757 #25 0xc060704d in ng_apply_item (node=0xc4097b00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #26 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #27 0xc060704d in ng_apply_item (node=0xc4791c00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #28 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #29 0xc060c049 in ng_car_rcvdata (hook=0xc429d900, item=0xc40917c0) at /usr/src/sys/netgraph/ng_car.c:368 #30 0xc060704d in ng_apply_item (node=0xc4791d00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #31 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #32 0xc060704d in ng_apply_item (node=0xc4791c00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #33 0xc0609cb9 in ng_snd_item (item=0xc40917c0
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
On Monday 24 March 2008 07:11:15 Andrey V. Elsukov wrote: Alexander Shulikov wrote: For bug kern/121955: ([ipfw] [panic] freebsd 7.0 panic with mpd) I receive new dump with mpd-4.4 and FreeBSD 7.0-RELEASE: Did you reset sysctl variable `net.inet.ip.fw.one_pass` into zero? There is well known double panic with dummynet, when packet re injected into pipe again and again. Check your rules. what do you mean? By setting to 0 the packages are not re-injected into the pipe but go through other existing rules after the matching pipe, or not? -- Atenciosamente, J.M. Responsável Plantão Site Support Matik Infomatik Internet Technology (18)3551.8155 (18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
On Monday 24 March 2008 12:46:41 Alexander Shulikov wrote:
Interesting changelog in cvs:
Revision 1.114: download - view: text, markup, annotated - select for diffs
Tue Dec 25 09:36:51 2007 UTC (2 months, 4 weeks ago) by oleg
Branches: MAIN
Diff to: previous 1.113: preferred, colored
Changes since revision 1.113: +22 -7 lines
Workaround p-numbytes overflow, which can result in infinite loop inside
dummynet module (prerequisite is using queues with fat pipe).
PR: kern/113548
nice, this was in december right and after this date the problem still ocurres
with dynamic pipes (mask src|dst-ip 0xfff)
2008/3/24, Alexander Shulikov [EMAIL PROTECTED]:
In real script I have in and out. But some ip's for the same speed I
add in table, and then do:
# 512/128
${fwcmd} pipe 357 config bw 128Kbit/s queue 100 mask src-ip 0x
${fwcmd} pipe 358 config bw 512Kbit/s queue 100 mask dst-ip 0x
${fwcmd} add pipe 357 ip from table(3) to any in
${fwcmd} add pipe 358 ip from any to table(3) out
IPs for individual speed added as in example in previous letter, but
with in/out.
But what can I do for resolve this problem. Now I have server with
FreeBSD 6.2 and copy of this configs - and all works fine. o_O
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 11:51:44 Alexander Shulikov wrote:
# sysctl -a | grep one_pass
net.inet.ip.fw.one_pass: 0
Yes - it eq 0. But I need it for next situation: all net I need
shape at one speed, but invididual ip addresses to another speed.
For example,
ipfw pipe 1 config bw 10Mbit/s queue 100
ipfw pipe 2 config bw 10Mbit/s queue 100
ipfw add pipe 1 ip from 192.168.1.0/24 to any
ipfw add pipe 2 ip from any to 192.168.1.0/24
ipfw pipe 3 config bw 1Mbit/s queue 100
ipfw pipe 4 config bw 1Mbit/s queue 100
ipfw add pipe 3 ip from 192.168.1.1/32 to any
ipfw add pipe 4 ip from any to 192.168.1.1/32
that should work, I have similar setups running fine
the /32 mask you should not need but I am missing the in/out
definition in your rules
..
Also this configuration work in FreeBSD 6.2. (May be in 6.2 smaller
call tree?)
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote:
AT Matik wrote:
what do you mean? By setting to 0 the packages are not
re-injected into the pipe but go through other existing
rules after the matching pipe, or not?
When you reset net.inet.ip.fw.one_pass to zero, packets return
back into ipfw to the next rule after dummynet/netgraph. And
if you have similar rules packets will be passed into
dummynet/netgraph again.
This is example how to get double fault (from mail archive):
jaaa well but that is the famous bw 0 example which is not valid,
as by itself certainly an invalid config, not connected to the
existing problem the reporter has I guess
João
ifconfig em0 192.168.0.2/24
kldload ipfw
kldload dummynet
sysctl net.inet.ip.fw.one_pass=0
ipfw pipe 2 config bw 0
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ping 192.168.0.1
--
Atenciosamente, J.M.
Responsável Plantão Site Support Matik
Infomatik Internet Technology
(18)3551.8155 (18)8112.7007
http://info.matik.com.br
A mensagem foi scaneada pelo sistema de e-mail e pode ser
considerada segura. Service fornecido pelo Datacenter Matik
https://datacenter.matik.com.br
--
Atenciosamente, J.M.
Responsável Plantão Site Support Matik
Infomatik Internet Technology
(18)3551.8155 (18)8112.7007
http://info.matik.com.br
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada
segura. Service fornecido pelo Datacenter Matik
https://datacenter.matik.com.br
--
Atenciosamente, J.M.
Responsável Plantão
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
By default I have:
# sysctl kern.ipc.nmbclusters
kern.ipc.nmbclusters: 25600
# sysctl net.inet.ip.intr_queue_maxlen
net.inet.ip.intr_queue_maxlen: 50
What range of value is optimal to try?
Also I add to loader.conf:
kern.maxusers=1536
kern.ipc.maxpipekva=3200
net.graph.maxalloc=2048
(but it was added after panic's)
Other thing, that I want to try - net.isr.direct - 0? May be it
temprorary resolved problem, because packet will be going to queue for
processing.
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 12:11:44 Alexander Shulikov wrote:
In real script I have in and out. But some ip's for the same speed I
add in table, and then do:
# 512/128
${fwcmd} pipe 357 config bw 128Kbit/s queue 100 mask src-ip 0x
${fwcmd} pipe 358 config bw 512Kbit/s queue 100 mask dst-ip 0x
${fwcmd} add pipe 357 ip from table(3) to any in
${fwcmd} add pipe 358 ip from any to table(3) out
IPs for individual speed added as in example in previous letter, but
with in/out.
But what can I do for resolve this problem. Now I have server with
FreeBSD 6.2 and copy of this configs - and all works fine. o_O
well I use the above different, first I define the pipe and second the bw
anyway I do not use tables
also seems you use long queues so may be you like to tune
net.inet.ip.intr_queue_maxlen and mbuf of your machine
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 11:51:44 Alexander Shulikov wrote:
# sysctl -a | grep one_pass
net.inet.ip.fw.one_pass: 0
Yes - it eq 0. But I need it for next situation: all net I need shape
at one speed, but invididual ip addresses to another speed.
For example,
ipfw pipe 1 config bw 10Mbit/s queue 100
ipfw pipe 2 config bw 10Mbit/s queue 100
ipfw add pipe 1 ip from 192.168.1.0/24 to any
ipfw add pipe 2 ip from any to 192.168.1.0/24
ipfw pipe 3 config bw 1Mbit/s queue 100
ipfw pipe 4 config bw 1Mbit/s queue 100
ipfw add pipe 3 ip from 192.168.1.1/32 to any
ipfw add pipe 4 ip from any to 192.168.1.1/32
that should work, I have similar setups running fine
the /32 mask you should not need but I am missing the in/out definition
in your rules
..
Also this configuration work in FreeBSD 6.2. (May be in 6.2 smaller
call tree?)
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote:
AT Matik wrote:
what do you mean? By setting to 0 the packages are not
re-injected into the pipe but go through other existing rules
after the matching pipe, or not?
When you reset net.inet.ip.fw.one_pass to zero, packets return
back into ipfw to the next rule after dummynet/netgraph. And if
you have similar rules packets will be passed into
dummynet/netgraph again.
This is example how to get double fault (from mail archive):
jaaa well but that is the famous bw 0 example which is not valid, as
by itself certainly an invalid config, not connected to the existing
problem the reporter has I guess
João
ifconfig em0 192.168.0.2/24
kldload ipfw
kldload dummynet
sysctl net.inet.ip.fw.one_pass=0
ipfw pipe 2 config bw 0
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ping 192.168.0.1
--
Atenciosamente, J.M.
Responsável Plantão Site Support Matik
Infomatik Internet Technology
(18)3551.8155 (18)8112.7007
http://info.matik.com.br
A mensagem foi scaneada pelo sistema de e-mail e pode ser
considerada segura. Service fornecido pelo Datacenter Matik
https://datacenter.matik.com.br
--
Atenciosamente, J.M.
Responsável Plantão Site Support Matik
Infomatik Internet Technology
(18)3551.8155 (18)8112.7007
http://info.matik.com.br
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada
segura. Service
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
On Monday 24 March 2008 16:08:10 Alexander Shulikov wrote:
By default I have:
# sysctl kern.ipc.nmbclusters
kern.ipc.nmbclusters: 25600
hard to say, do you checked netstat -m if you get to your limit? If you get
there set it higher
# sysctl net.inet.ip.intr_queue_maxlen
net.inet.ip.intr_queue_maxlen: 50
seems to be the default
try 128, 256, 512
What range of value is optimal to try?
Also I add to loader.conf:
kern.maxusers=1536
I guess maxusers does not help for your setup and probably you should let the
system selftune itself
kern.ipc.maxpipekva=3200
net.graph.maxalloc=2048
(but it was added after panic's)
I believe both do not help anything for ipfw
Other thing, that I want to try - net.isr.direct - 0? May be it
temprorary resolved problem, because packet will be going to queue for
processing.
I guess this does not help dummynet either
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 12:11:44 Alexander Shulikov wrote:
In real script I have in and out. But some ip's for the same speed I
add in table, and then do:
# 512/128
${fwcmd} pipe 357 config bw 128Kbit/s queue 100 mask src-ip 0x
${fwcmd} pipe 358 config bw 512Kbit/s queue 100 mask dst-ip 0x
${fwcmd} add pipe 357 ip from table(3) to any in
${fwcmd} add pipe 358 ip from any to table(3) out
IPs for individual speed added as in example in previous letter, but
with in/out.
But what can I do for resolve this problem. Now I have server with
FreeBSD 6.2 and copy of this configs - and all works fine. o_O
well I use the above different, first I define the pipe and second the bw
anyway I do not use tables
also seems you use long queues so may be you like to tune
net.inet.ip.intr_queue_maxlen and mbuf of your machine
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 11:51:44 Alexander Shulikov wrote:
# sysctl -a | grep one_pass
net.inet.ip.fw.one_pass: 0
Yes - it eq 0. But I need it for next situation: all net I need
shape at one speed, but invididual ip addresses to another speed.
For example,
ipfw pipe 1 config bw 10Mbit/s queue 100
ipfw pipe 2 config bw 10Mbit/s queue 100
ipfw add pipe 1 ip from 192.168.1.0/24 to any
ipfw add pipe 2 ip from any to 192.168.1.0/24
ipfw pipe 3 config bw 1Mbit/s queue 100
ipfw pipe 4 config bw 1Mbit/s queue 100
ipfw add pipe 3 ip from 192.168.1.1/32 to any
ipfw add pipe 4 ip from any to 192.168.1.1/32
that should work, I have similar setups running fine
the /32 mask you should not need but I am missing the in/out
definition in your rules
..
Also this configuration work in FreeBSD 6.2. (May be in 6.2
smaller call tree?)
2008/3/24, AT Matik [EMAIL PROTECTED]:
On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote:
AT Matik wrote:
what do you mean? By setting to 0 the packages are not
re-injected into the pipe but go through other existing
rules after the matching pipe, or not?
When you reset net.inet.ip.fw.one_pass to zero, packets
return back into ipfw to the next rule after
dummynet/netgraph. And if you have similar rules packets
will be passed into
dummynet/netgraph again.
This is example how to get double fault (from mail archive):
jaaa well but that is the famous bw 0 example which is not
valid, as by itself certainly an invalid config, not connected
to the existing problem the reporter has I guess
João
ifconfig em0 192.168.0.2/24
kldload ipfw
kldload dummynet
sysctl net.inet.ip.fw.one_pass=0
ipfw pipe 2 config bw 0
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ipfw add 2 pipe 2 ip from any to any
ping 192.168.0.1
--
Atenciosamente, J.M.
Responsável Plantão Site Support Matik
Infomatik Internet Technology
(18)3551.8155 (18)8112.7007
http://info.matik.com.br
Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd
On Monday 24 March 2008 17:00:43 Alexander Shulikov wrote: 2008/3/24, AT Matik [EMAIL PROTECTED]: On Monday 24 March 2008 16:08:10 Alexander Shulikov wrote: By default I have: # sysctl kern.ipc.nmbclusters kern.ipc.nmbclusters: 25600 hard to say, do you checked netstat -m if you get to your limit? If you get there set it higher When It works - there is alright. But when panic - I can't to see it. I guess it will not grow so fast from one moment to another Other thing, that I want to try - net.isr.direct - 0? May be it temprorary resolved problem, because packet will be going to queue for processing. I guess this does not help dummynet either Alexander Motin (mpd server and partially netgraph developer) say thing, that probably trouble in depth of stack. And may be net.isr.direct=0 will help to process packets from queue, but not at the arrival time. Or no? I can not answer this for sure but trying it out is for free :) but it will not help here I guess Even if I believe the problem is in ipfw you probably should try to isolate if it is in any means related to mpd, probably you can run your ppp from another server and run ipfw only on this one, after that you know more you are with 7-R or 7-Stable? Andrey and AT Matik: my name is João, this is my company email address Can we talk via jabber or icq? (for decrease traffic in conference, but send in conference result) ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br -- Atenciosamente, J.M. Responsável Plantão Site Support Matik Infomatik Internet Technology (18)3551.8155 (18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
