kernel panic while using tcpdump
Hi, We are using a lot of i386 computers as routers for out network. All of those routers are using FreeBSD from 4.x to 7.x (exept 5.x) We are having problem with kernel panic on routers based on 6.x and 7.x while using tcpdump or trafshow. It is not that always we got kernel panics. We got them in random occurence. Some time i can tcpdump for a minute and turn it off and again while i am testing packets comming thru iface for an hour, and nothin happens. But sometime i run tcpdump and after few second i got kernel panic. It happens mostly when i am trying to close tcpdump with ctrl-c. It happens also with trafshow3 which we are using to track transfers. It happens on 6.x series and i thought that maybe there is bug in this line and i have tryied 7.x line i got kernel panics also. The problem is that i can't really get message when it happens because those routers are in remote places and after 15 second they are rebooting (and that is great:) Is there any way to save this message to a file that i could paste over here ? Could some one help me to diagnoze this behaviour ? We are using i386 arch on all routers. The hardware is totally different from quite old parts to quite new dell. What is strange on 4.x we never hit such a kernel panic. We are using mostly fxp NIC on all routers with some exeptions and i have started wondering that maybe fxp driver has some bug or bpf code. Thanks for any help in diagnosing this panics. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic while using tcpdump
Bartosz Giza wrote: Hi, We are using a lot of i386 computers as routers for out network. All of those routers are using FreeBSD from 4.x to 7.x (exept 5.x) We are having problem with kernel panic on routers based on 6.x and 7.x while using tcpdump or trafshow. It is not that always we got kernel panics. We got them in random occurence. Some time i can tcpdump for a minute and turn it off and again while i am testing packets comming thru iface for an hour, and nothin happens. But sometime i run tcpdump and after few second i got kernel panic. It happens mostly when i am trying to close tcpdump with ctrl-c. It happens also with trafshow3 which we are using to track transfers. It happens on 6.x series and i thought that maybe there is bug in this line and i have tryied 7.x line i got kernel panics also. The problem is that i can't really get message when it happens because those routers are in remote places and after 15 second they are rebooting (and that is great:) Is there any way to save this message to a file that i could paste over here ? Could some one help me to diagnoze this behaviour ? We are using i386 arch on all routers. The hardware is totally different from quite old parts to quite new dell. What is strange on 4.x we never hit such a kernel panic. We are using mostly fxp NIC on all routers with some exeptions and i have started wondering that maybe fxp driver has some bug or bpf code. Thanks for any help in diagnosing this panics. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Coverity problems?
Hi, I got a link to this article via ACM TechNews: http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229%0Acid=RSSfeed_IWK_All Linux came in with far fewer defects than average as did a number of other open source projects. The version 2.6 of the Linux kernel had a security bug rate of .127 per thousand lines of code. The kernel scan covered 3,639,322 lines of code. As exposures were identified by repeated scans, 452 defects have been fixed by kernel developers; 48 have been verified but not yet fixed; another 413 remain to be verified and fixed, according to code scanning results posted on the Coverity Web site. FreeBSD, sometimes posed as an alternative to Linux, has been slower to respond to the Coverity scans. In 1,582,166 lines of code, it has fixed zero defects, verified six and has another 605 to go. These numbers seem strange and out of proportion. I know there has been prior cooperation with Coverity - is this just old data? signature.asc Description: OpenPGP digital signature
Re: Coverity problems?
On Fri, 11 Jan 2008, Mark Linimon wrote: On Fri, Jan 11, 2008 at 09:12:27PM +0100, Ivan Voras wrote: These numbers seem strange and out of proportion. I know there has been prior cooperation with Coverity - is this just old data? IIRC Coverity is not tracking our use of their software, at least in those statistics. Someone was telling me yesterday that was because we have our own copy of the Coverity server which we use, rather than accessing the one on their site that generates the statistics. Someone, please correct me if I'm wrong. You're right. See the January 11, 2008 note here: http://scan.coverity.com/ -Warren Block * Rapid City, South Dakota USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Coverity problems?
On Fri, Jan 11, 2008 at 09:12:27PM +0100, Ivan Voras wrote: These numbers seem strange and out of proportion. I know there has been prior cooperation with Coverity - is this just old data? IIRC Coverity is not tracking our use of their software, at least in those statistics. Someone was telling me yesterday that was because we have our own copy of the Coverity server which we use, rather than accessing the one on their site that generates the statistics. Someone, please correct me if I'm wrong. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Coverity problems?
Mark Linimon wrote: On Fri, Jan 11, 2008 at 09:12:27PM +0100, Ivan Voras wrote: These numbers seem strange and out of proportion. I know there has been prior cooperation with Coverity - is this just old data? IIRC Coverity is not tracking our use of their software, at least in those statistics. Someone was telling me yesterday that was because we have our own copy of the Coverity server which we use, rather than accessing the one on their site that generates the statistics. Someone, please correct me if I'm wrong. You are correct; we've had a private coverity server doing nightly runs long before coverity setup this service (the project has their own license through the FreeBSD Foundation). I have no idea why coverity continues to do freebsd runs as the results are also not meaningful because their default models generate false positives that we've long since filtered out. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Coverity problems?
On Fri, Jan 11, 2008 at 02:57:04PM -0600, Mark Linimon wrote: On Fri, Jan 11, 2008 at 09:12:27PM +0100, Ivan Voras wrote: These numbers seem strange and out of proportion. I know there has been prior cooperation with Coverity - is this just old data? IIRC Coverity is not tracking our use of their software, at least in those statistics. Someone was telling me yesterday that was because we have our own copy of the Coverity server which we use, rather than accessing the one on their site that generates the statistics. Someone, please correct me if I'm wrong. Yes, also take a look at http://www.informationweek.com/blog/main/archives/2008/01/oops_look_at_th.html Corrections to the article by the same author. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpBRv8hdM7mL.pgp Description: PGP signature
netgraph question
Hello folks, I am looking at writing an application program to tap certain ipv6 packets (say icmpv6) using netgraph. The application has to do some processing, before kernel can proceed with those packets. I have vaguely understood netgraph, and I see that I need a ng_socket node in the application, an ng_bpf node, and an ng_ether or ng_iface node in the kernel. My question is. would I need to create such nodes for each interface. Then it becomes unscalable.. Can I have just one socket, bpf, iface node that can tap icmpv6 packets on all interfaces? I'll reiterate if this question was not clear. Any help would be greatly appreciated... Otherwise I'll have to end up using raw sockets.. Thanks, Subhash ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netgraph question
Hi Subhash, Subhash Gopinath wrote: Hello folks, I am looking at writing an application program to tap certain ipv6 packets (say icmpv6) using netgraph. The application has to do some processing, before kernel can proceed with those packets. I have vaguely understood netgraph, and I see that I need a ng_socket node in the application, an ng_bpf node, and an ng_ether or ng_iface node in the kernel. My question is. would I need to create such nodes for each interface. Then it becomes unscalable.. Can I have just one socket, bpf, iface node that can tap icmpv6 packets on all interfaces? The PFIL(9) interface might also be of interest to you. If all you need to do is packet interception and then allow/deny packets based on the results of some processing, PFIL might be the way to go. We wrote some code (SIFTR [1]) which uses PFIL in a similar capacity and you may want to refer to it as an example. Cheers, Lawrence [1] http://caia.swin.edu.au/urp/newtcp/tools.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
