Re: [Panic] Dummynet/IPFW related recurring crash.
On Sat, Feb 19, 2011 at 8:40 PM, Jack Vogel jfvo...@gmail.com wrote: I've never seen a trace like this, and no absolutely nothing about dummynet, sorry. If it is in some way em's fault, then making sure you have the latest code would be a good idea. I have a test driver that is under selective test, it does effect the code path that you seem to be in, so it might be worth a try. If you want to try it early just pipe up and I'll send it. Jack I was actually going to suggest Pawl try a different network device if possible. I'm using dummynet on a network gateway equipped with on-board bge(4). I haven't had any crashes, but then again, I'm not seeing that many packets either. -Brandon ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: [Panic] Dummynet/IPFW related recurring crash.
On Sun, Jan 23, 2011 at 7:08 PM, Pawel Tyll pt...@nitronet.pl wrote: On Fri, Jan 7, 2011, Brandon Gooch jamesbrandongo...@gmail.com wrote: It's likely that the mbuf handling problem (in em_refresh_mbufs()) is triggered by the processing you're doing with ipfw (or elsewhere for that matter), so, yes, I think it's a bug fixed in the revision discussed. When you update and test, please let us know. Also, don't forget to submit a follow-up to your PR. Unfortunately bad news: Machine fell after 14 days, 22:31:42 for the same reason according to what was left of panic screen. It didn't do a dump, nor reboot as is customary since some time on S3420GP boards (and other Intel server boards, since colleague has dual-cpu board from same epoch). What can I try next? I'm not sure. Perhaps there is another code path in the em(4) driver that leads to the same, bad-pointer state. I'll have to defer to Jack Vogel or Luigi Rizzo for potential insight into the issue. Please provide as much information as possible (even if it comes down to taking a photo of the console, or transcribing the backtrace). FYI, I haven't been able to test this on any of my setups yet... -Brandon ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: [Panic] Dummynet/IPFW related recurring crash.
On Fri, Jan 7, 2011 at 10:14 AM, Pawel Tyll pt...@nitronet.pl wrote: One more question tough, I have 4 identical machines, also with em-driven NICs - yet this is the only one that dies like this. OTOH Other machines don't do traffic shaping and do not use ipfw that extensively. Does this match your theory? It's likely that the mbuf handling problem (in em_refresh_mbufs()) is triggered by the processing you're doing with ipfw (or elsewhere for that matter), so, yes, I think it's a bug fixed in the revision discussed. When you update and test, please let us know. Also, don't forget to submit a follow-up to your PR. Thanks! -Brandon ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: [Panic] Dummynet/IPFW related recurring crash.
2011/1/6 Pawel Tyll pt...@nitronet.pl: Hi lists, I've reported this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 and ever since 8.1-RELEASE this machine keeps panicking every two weeks or so. Any help will be much appreciated. I'll be happy to provide any more info to help tracking this down. Might this be an issue with the em(4) driver? It may be that it's fixed: http://svn.freebsd.org/viewvc/base?view=revisionsortby=daterevision=216440 -Brandon ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: layer2 ipfw 'fwd' support
On Fri, Oct 8, 2010 at 10:55 AM, Eduardo Meyer dudu.me...@gmail.com wrote: On Thu, Oct 7, 2010 at 10:23 PM, Eduardo Meyer dudu.me...@gmail.com wrote: [SNIP] Luiz has added it to: http://loos.no-ip.org:280/lusca_bridge.diff I have tested and it works pretty well. I hope someone can add it to -HEAD, so we won't loose it again. With time, ipfw code changes and such great patches like Rizzo's and Julian's stop working one day. It's bad we miss such great functionality. Sounds like a reasonable request. I hope it is considered. Thank you again everyone envolved. Thanks goes to you for your persistence in getting this working. Adrian / Luiz / Julian, With this patch fwd does it's job on L2, ordinary proxy works like a charm. But TPROXY won't work. It would be perfect to have both features together. If you can suggest any further tests or changes I will be pleased to test. To be clear, are we getting to the point of having the capability in ipfw of doing something like this in pf: ... pass in quick on $INT_IF route-to lo0 inet proto tcp from any to 127.0.0.1 port 3128 keep state ... ...thus allowing true, transparent proxying? I really thought that this was possible already with ipfw :( I need to do some more reading... I would be very interested in obtaining details on your final setup, once everything is in place and fully functioning :) -Brandon ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: phantom rules
On Thu, Sep 9, 2010 at 8:17 AM, Gareth de Vaux b...@lordcow.org wrote: Hi all, for some reason these rules get loaded on boot up before the ones I specify in a file: 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 I just flush this manually but how do I stop the behaviour properly? My rc.conf entries: firewall_enable=YES firewall_type=/usr/local/etc/firewall firewall_logging=YES I would begin by reading: $ man 7 firewall $ man 5 rc.conf $ less /etc/rc.firewall I think the source of /etc/rc.firewall may be most enlightening in regard to the behavior in question (setup_loopback(), setup_ipv6_mandatory(), etc...). Have fun, and don't get discouraged (speaking from experience) :) -Brandon ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
