From julian at elischer.org Fri Aug 1 01:50:42 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 1 01:50:49 2008 Subject: ipfw add skipto tablearg.... Message-ID: <48926C02.6030308@elischer.org> looking int he code I noticed that the following command gave no error but didn't work.. ipfw add 1000 skipto tablearg ip from any to table(31) and as I have a use for that, I implemented it.. see attached patch... (hopefully not stripped) Of course it is hoped that the rules you are skipping to are nearby as it iterates through the rules following the skipto to find the target, but.... if you had a thousand table entries and wanted to sort them into 20 buckets, it could save you puting them into 20 different tables and doing 20 table lookups on them. here I sort into two categories.. possibly already a win.. julian@trafmon2:cat ipfw-test.sh #!/bin/sh ipfw add 100 skipto 10000 ip from any to not 1.1.1.0/24 ipfw add 1000 skipto tablearg ip from any to "table(31)" ipfw add 2000 drop ip from any to any ipfw add 2001 drop ip from any to any ipfw add 3000 drop ip from any to any ipfw add 3001 drop ip from any to any ipfw add 10000 count ip from any to any ipfw table 31 add 1.1.1.1 2000 ipfw table 31 add 1.1.1.2 3000 julian@trafmon2: ping 1.1.1.1 [...] (2 packets bounced) julian@trafmon2: ping 1.1.1.2 [...] (12 packets bounced) julian@trafmon2: ipfw show 00100 220 19633 skipto 10000 ip from any to not 1.1.1.0/24 01000 14 1176 skipto tablearg ip from any to table(31) 02000 2 168 deny ip from any to any 02001 0 0 deny ip from any to any 03000 12 1008 deny ip from any to any 03001 0 0 deny ip from any to any 10000 209 18549 count ip from any to any 65535 1751 153792 allow ip from any to any comments? -------------- next part -------------- Index: ip_fw2.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.186 diff -u -r1.186 ip_fw2.c --- ip_fw2.c 9 May 2008 23:02:57 -0000 1.186 +++ ip_fw2.c 1 Aug 2008 01:15:06 -0000 @@ -1738,10 +1738,11 @@ */ static struct ip_fw * -lookup_next_rule(struct ip_fw *me) +lookup_next_rule(struct ip_fw *me, u_int32_t tablearg) { struct ip_fw *rule = NULL; ipfw_insn *cmd; + u_int16_t rulenum; /* look for action, in case it is a skipto */ cmd = ACTION_PTR(me); @@ -1751,10 +1752,18 @@ cmd += F_LEN(cmd); if (cmd->opcode == O_TAG) cmd += F_LEN(cmd); - if ( cmd->opcode == O_SKIPTO ) - for (rule = me->next; rule ; rule = rule->next) - if (rule->rulenum >= cmd->arg1) + if (cmd->opcode == O_SKIPTO ) { + if (tablearg != 0) { + rulenum = (u_int16_t)tablearg; + } else { + rulenum = cmd->arg1; + } + for (rule = me->next; rule ; rule = rule->next) { + if (rule->rulenum >= rulenum) { break; + } + } + } if (rule == NULL) /* failure or not a skipto */ rule = me->next; me->next_rule = rule; @@ -2475,7 +2484,7 @@ f = args->rule->next_rule; if (f == NULL) - f = lookup_next_rule(args->rule); + f = lookup_next_rule(args->rule, 0); } else { /* * Find the starting rule. It can be either the first @@ -3226,9 +3235,13 @@ if (cmd->opcode == O_COUNT) goto next_rule; /* handle skipto */ - if (f->next_rule == NULL) - lookup_next_rule(f); - f = f->next_rule; + if (cmd->arg1 == IP_FW_TABLEARG) { + f = lookup_next_rule(f, tablearg); + } else { + if (f->next_rule == NULL) + lookup_next_rule(f, 0); + f = f->next_rule; + } goto again; case O_REJECT: From silby at silby.com Fri Aug 1 05:35:28 2008 From: silby at silby.com (Mike Silbersack) Date: Fri Aug 1 05:35:35 2008 Subject: TCP zombie connections with 7-RELEASE and STABLE from 15th june In-Reply-To: <20080718135931.GA48087@cicely7.cicely.de> References: <20080718135931.GA48087@cicely7.cicely.de> Message-ID: On Fri, 18 Jul 2008, Bernd Walter wrote: > 443 is a self written server, but it also happens with port 80 and > sslproxy. > The client is a telnet, which disconnects directly after connecting, > so the disconnect is initiated from the client, which seems to be > important for this problem to trigger. > > You can see that the FIN handshake completes and netstat on the > client box shows the connection in TIME_WAIT. > The server however has the connection still in ESTABLISHED state. Well, syncookies allow the ack of the 3WHS to establish a connection. Just a quick look at your tcpdump shows that since you aren't sending any data you are not advancing the sequence number. As a result, it looks like one of the ACKs the client sends during connection shutdown may actually be causing the server to re-establish the connection. You might want to file a PR with exact instructions (and code) that'll easily reproduce this so that it can be solved at some point in the future. I don't have time to look into it now, although I'd be happy to code review a fix! -Mike From freebsd at meijome.net Fri Aug 1 06:50:56 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Fri Aug 1 06:51:03 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48922C27.8090005@elischer.org> References: <48918DB5.7020201@wubethiopia.com> <20080731102116.GA32671@tin.it> <48922C27.8090005@elischer.org> Message-ID: <20080801162411.0bb87b55@ayiin> On Thu, 31 Jul 2008 14:18:31 -0700 Julian Elischer wrote: > Paolo Pisati wrote: > > On Thu, Jul 31, 2008 at 01:02:29PM +0300, Mike Makonnen wrote: > >> While I have not done extensive testing, preliminary tests are encouraging > >> and it seems to work, so I thought I'd announce it to the rest of the world > >> in case anyone else is interested in this kind of application. > > > > That's a much needed addition to ipfw and FreeBSD in general, thanks > > for the hard work. > > I wonder how it would go as a netgraph node? +1 :) _________________________ {Beto|Norberto|Numard} Meijome "Life is just what happens to you, While your busy making other plans..." John Lennon I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From lapo at lapo.it Fri Aug 1 09:30:41 2008 From: lapo at lapo.it (Lapo Luchini) Date: Fri Aug 1 09:30:48 2008 Subject: Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default In-Reply-To: <484E0C08.1060800@FreeBSD.org> References: <484E0C08.1060800@FreeBSD.org> Message-ID: Doug Barton wrote: > The "normal" EUI-64-based address will still be configured, but there > will also be a random identifier added to the interface as an alias, > and outgoing traffic will go out from that address. Be prepared to question about it, though ;-) http://www.sixxs.net/faq/connectivity/?faq=rfc3041 -- Lapo Luchini - http://lapo.it/ From mtm at wubethiopia.com Fri Aug 1 10:16:00 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Fri Aug 1 10:16:06 2008 Subject: Application layer classifier for ipfw In-Reply-To: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> References: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> Message-ID: <4892E3BE.2030900@wubethiopia.com> Ermal Lu?i wrote: >> Hi, >> >> An Internet Cafe I do some work for was recently having problems with >> very slow internet access. It turns out customers were running P2P file >> sharing applications which were hogging all the bandwidth. I looked for >> programs that would allow me to shape traffic according to the >> application layer protocol, but couldn't find any for FreeBSD. I found a >> couple: l7-filter and ipp2p, but these are Linux specific. So, I decided >> to write one. The result is ipfw-classifyd : >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >> >> As the name implies it uses ipfw(4) to implement a userland daemon that >> classifies TCP and UDP packets according to regular expression patterns >> for various protocols. It's intended to be used with divert(4) sockets >> and dummynet(4) so you can do traffic shaping depending on the >> application level protocol. The protocol patterns are from the l7-filter >> project. >> >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >> reads its configuration file for a list of protocols and ipfw(8) rules. >> Then, when it detects a matching session it re-injects the packet back >> at the specified rule number. The tarball has a sample configuration >> file and firewall script to get you started. >> >> While I have not done extensive testing, preliminary tests are >> encouraging and it seems to work, so I thought I'd announce it to the >> rest of the world in case anyone else is interested in this kind of >> application. >> >> Comments and suggestions highly appreciated. >> > > Thanks for this. > I have a question, you remove a flow from if you see a FIN for the TCP > case and only on overlapping flow for either TCP/UDP how do the other > flows expire i am missing that part? > > No, you're not missing anything. It's on my TODO list. I wanted to get this out and get feedback as early as possible, so I released it as soon as I had it basically working. I'm thinking of storing some session information for the flow (like a timestamp for the last packet seen) and implementing a garbage collector thread that removes sessions that have been idle for some period of time. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From mtm at wubethiopia.com Fri Aug 1 10:18:21 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Fri Aug 1 10:18:27 2008 Subject: Application layer classifier for ipfw In-Reply-To: <489224F2.3050508@yan.com.br> References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> Message-ID: <4892E456.5080408@wubethiopia.com> Daniel Dias Gon?alves wrote: > You will go to develop a version to work with PF ? > I don't know what's needed to get it to work with pf, but if it's not too much work, sure. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From mtm at wubethiopia.com Fri Aug 1 10:30:51 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Fri Aug 1 10:30:57 2008 Subject: Application layer classifier for ipfw In-Reply-To: <4891CD13.20600@freebsdbrasil.com.br> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> Message-ID: <4892E735.1000105@wubethiopia.com> Patrick Tracanelli wrote: > Mike Makonnen escreveu: >> Hi, >> >> An Internet Cafe I do some work for was recently having problems with >> very slow internet access. It turns out customers were running P2P >> file sharing applications which were hogging all the bandwidth. I >> looked for programs that would allow me to shape traffic according >> to the application layer protocol, but couldn't find any for FreeBSD. >> I found a couple: l7-filter and ipp2p, but these are Linux specific. >> So, I decided to write one. The result is ipfw-classifyd : >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >> >> As the name implies it uses ipfw(4) to implement a userland daemon >> that classifies TCP and UDP packets according to regular expression >> patterns for various protocols. It's intended to be used with >> divert(4) sockets and dummynet(4) so you can do traffic shaping >> depending on the application level protocol. The protocol patterns >> are from the l7-filter project. >> >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >> reads its configuration file for a list of protocols and ipfw(8) >> rules. Then, when it detects a matching session it re-injects the >> packet back at the specified rule number. The tarball has a sample >> configuration file and firewall script to get you started. >> >> While I have not done extensive testing, preliminary tests are >> encouraging and it seems to work, so I thought I'd announce it to the >> rest of the world in case anyone else is interested in this kind of >> application. >> >> Comments and suggestions highly appreciated. >> >> Cheers. > > Wont compile on RELENG_6 but is working perfectly on REL_7. I am > trying hard with ssh, soulseek and msn. Its working like a charm with > the suggested rc.firewall. Can you email me the compile error? > > I have configured ipfw-classfyd.conf changing the rules, for a number > of L7 patterns, and now I try to understand why the "diverted" rules > only match if the rule number is 1 after the configured, ie, I put > soulseek to 65530 and a rule wont match there, but the very same rule > matches 65531. I will read the code, but it seems that reinjection of > the packet is made +1, correct? > The application doesn't do that, it's the firewall that does that. Basically, when ipfw(4) diverts a packet to the application it includes the rule that caused the packet to be diverted (so that when it gets it back it knows where to continue processing from). When it gets the packet back it continues processing the packet at the rule *after* the one that caused it to be diverted (otherwise the packet would get diverted in an endless loop). In the sample script rule 1000 is the rule that passes the packets that do not get diverted, so I configured ipfw-classifyd to modify the information that comes with the packet to point to rule 1000 (in classifyd.conf). So, when ipfw(4) gets the packet back it continues processing it at the next rule after 1000, which is the rule that sends all diverted packets through the pipe. Hope that helps. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From ticso at cicely7.cicely.de Fri Aug 1 11:50:16 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Fri Aug 1 11:50:23 2008 Subject: TCP zombie connections with 7-RELEASE and STABLE from 15th june In-Reply-To: References: <20080718135931.GA48087@cicely7.cicely.de> Message-ID: <20080801115007.GA76575@cicely7.cicely.de> On Fri, Aug 01, 2008 at 12:08:38AM -0500, Mike Silbersack wrote: > > > On Fri, 18 Jul 2008, Bernd Walter wrote: > > >443 is a self written server, but it also happens with port 80 and > >sslproxy. > >The client is a telnet, which disconnects directly after connecting, > >so the disconnect is initiated from the client, which seems to be > >important for this problem to trigger. > > > >You can see that the FIN handshake completes and netstat on the > >client box shows the connection in TIME_WAIT. > >The server however has the connection still in ESTABLISHED state. > > Well, syncookies allow the ack of the 3WHS to establish a connection. > Just a quick look at your tcpdump shows that since you aren't sending any > data you are not advancing the sequence number. As a result, it looks > like one of the ACKs the client sends during connection shutdown may > actually be causing the server to re-establish the connection. Ah - that makes sense. > You might want to file a PR with exact instructions (and code) that'll > easily reproduce this so that it can be solved at some point in the > future. I don't have time to look into it now, although I'd be happy to > code review a fix! Thank you - I will file a PR. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From eksffa at freebsdbrasil.com.br Fri Aug 1 14:31:37 2008 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Fri Aug 1 14:31:46 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48922E9D.1020507@elischer.org> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> Message-ID: <48931E09.70407@freebsdbrasil.com.br> I guess I need some help here. How can I increase (and what should I be aware) the input queue? Under 20Mbit/s of load, I have the following problem: Aug 1 11:14:45 ourofino last message repeated 5828 times Aug 1 11:14:45 ourofino ipfw-classifyd: MATCH edonkey(50000): 88.165.54.165:50286 -> 88.165.54.165:42074 Aug 1 11:14:45 ourofino ipfw-classifyd: packet dropped: input queue full Where should I start from? -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From eksffa at freebsdbrasil.com.br Fri Aug 1 15:08:33 2008 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Fri Aug 1 15:08:40 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48931E09.70407@freebsdbrasil.com.br> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <48931E09.70407@freebsdbrasil.com.br> Message-ID: <489326B3.4030306@freebsdbrasil.com.br> Patrick Tracanelli escreveu: > I guess I need some help here. How can I increase (and what should I be > aware) the input queue? > > Under 20Mbit/s of load, I have the following problem: > > Aug 1 11:14:45 ourofino last message repeated 5828 times > Aug 1 11:14:45 ourofino ipfw-classifyd: MATCH edonkey(50000): > 88.165.54.165:50286 -> 88.165.54.165:42074 > Aug 1 11:14:45 ourofino ipfw-classifyd: packet dropped: input queue full > > Where should I start from? > I have raised the queue lenght a lot, up to 40960, and the behavior was the same. Ill keep trying and let you know if any success. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From petri at helenius.fi Fri Aug 1 15:14:39 2008 From: petri at helenius.fi (Petri Helenius) Date: Fri Aug 1 15:14:47 2008 Subject: Application layer classifier for ipfw In-Reply-To: <489326B3.4030306@freebsdbrasil.com.br> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <48931E09.70407@freebsdbrasil.com.br> <489326B3.4030306@freebsdbrasil.com.br> Message-ID: <48932850.9090104@helenius.fi> Patrick Tracanelli wrote: > > I have raised the queue lenght a lot, up to 40960, and the behavior > was the same. Ill keep trying and let you know if any success. > No queue depth is going to help you if you receive more data than you can process. Pete From eksffa at freebsdbrasil.com.br Fri Aug 1 15:19:00 2008 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Fri Aug 1 15:19:06 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48932850.9090104@helenius.fi> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <48931E09.70407@freebsdbrasil.com.br> <489326B3.4030306@freebsdbrasil.com.br> <48932850.9090104@helenius.fi> Message-ID: <48932924.2070102@freebsdbrasil.com.br> Petri Helenius escreveu: > Patrick Tracanelli wrote: >> >> I have raised the queue lenght a lot, up to 40960, and the behavior >> was the same. Ill keep trying and let you know if any success. >> > No queue depth is going to help you if you receive more data than you > can process. > > Pete From here, where I see (userland perspective) CPU usage is not an issue (yet?). classifyd is demanding low CPU: 6386 root 2 108 0 7496K 6668K RUN 0:11 0.04% ipfw-classifyd But maybe you mean something else. -- Patrick Tracanelli From eculp at encontacto.net Fri Aug 1 15:27:04 2008 From: eculp at encontacto.net (eculp) Date: Fri Aug 1 15:27:11 2008 Subject: Application layer classifier for ipfw In-Reply-To: <4892E456.5080408@wubethiopia.com> References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> Message-ID: <20080801094626.18943vxiypbkcts0@econet.encontacto.net> Quoting Mike Makonnen : > Daniel Dias Gon?alves wrote: >> You will go to develop a version to work with PF ? >> > I don't know what's needed to get it to work with pf, but if it's not too > much work, sure. That would be great, Mike. I'm seeing more and more bandwidth being used with p2p that I haven't been able to control with pf. The thought has entered my mind to change back to ipfw that I used for many years before changing to pf maybe 3 years ago. I also found dummynet to be easy and practical to set up for both incoming and outgoing connections. Something else I haven't figured out how to do the same with altq, if even possible. In fact, if I am able to control p2p with pf I may not even need bidirectional bandwidth limits. Thanks for sharing your very practical solution to a real world problem. Have a great weekend. ed > > Cheers. > > -- > Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc > mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 > FreeBSD | http://www.freebsd.org > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From oliver at hotracer.de Fri Aug 1 15:30:06 2008 From: oliver at hotracer.de (Oliver) Date: Fri Aug 1 15:30:12 2008 Subject: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections Message-ID: <200808011530.m71FU5et015816@freefall.freebsd.org> The following reply was made to PR kern/123881; it has been noted by GNATS. From: Oliver To: bug-followup@FreeBSD.org, tom@tomkarpik.com Cc: Subject: Re: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections Date: Fri, 01 Aug 2008 17:05:10 +0200 I tried to reproduce this. You can log this issue when you also set net.inet.tcp.log_in_vain=2 the dmesg output shows for each connection attempt to sendmail TCP: [127.0.0.1]:58148 to [127.0.0.1]:113 tcpflags 0x2; tcp_input: Connection attempt on closed port if you start inetd/auth (113) the sendmail deamon answers the same speed it does with net.inet.tcp.blackhole=0 If you don't want to use auth, sendmail can be configured to set the timeout for ident to 0s which results in ident checking disabled or you can reduce the default value of 5 seconds. O Timeout.ident=0s so tcp.blackhole works as expected and perhaps this can be closed. Greetings, Oliver From eksffa at freebsdbrasil.com.br Fri Aug 1 15:36:30 2008 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Fri Aug 1 15:36:43 2008 Subject: Application layer classifier for ipfw In-Reply-To: <20080801094626.18943vxiypbkcts0@econet.encontacto.net> References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> Message-ID: <48932D3E.7090709@freebsdbrasil.com.br> eculp escreveu: > Quoting Mike Makonnen : > >> Daniel Dias Gon?alves wrote: >>> You will go to develop a version to work with PF ? >>> >> I don't know what's needed to get it to work with pf, but if it's not too >> much work, sure. > > That would be great, Mike. I'm seeing more and more bandwidth being > used with p2p that I haven't been able to control with pf. The thought > has entered my mind to change back to ipfw that I used for many years > before changing to pf maybe 3 years ago. I also found dummynet to be > easy and practical to set up for both incoming and outgoing > connections. Something else I haven't figured out how to do the same > with altq, if even possible. In fact, if I am able to control p2p with > pf I may not even need bidirectional bandwidth limits. > > Thanks for sharing your very practical solution to a real world > problem. Have a great weekend. If it could be rewritten as a netgaph node, maybe it could tag the classified packets, and tagging be compatible with both pf and ipfw (under discretionary user choice with configuration switchs), so both ipfw or pf could be used. However a lot of work has to be done before. It works better on i386 than amd64 right now, wont compile on RELENG_6 without modifying some gcc tweaks, etc. I hope enhacing it can be a GSoC project in the future, or we (community) can raise some funds to make it happen faster. It is really a long-time needed feature to FreeBSD. -- Patrick Tracanelli From ermal.luci at gmail.com Fri Aug 1 15:50:18 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Fri Aug 1 15:50:26 2008 Subject: Application layer classifier for ipfw In-Reply-To: <4892E3BE.2030900@wubethiopia.com> References: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> <4892E3BE.2030900@wubethiopia.com> Message-ID: <9a542da30808010850o22ebbe4er4e56e6f700a37c5e@mail.gmail.com> On Fri, Aug 1, 2008 at 12:21 PM, Mike Makonnen wrote: > Ermal Lu?i wrote: >>> >>> Hi, >>> >>> An Internet Cafe I do some work for was recently having problems with >>> very slow internet access. It turns out customers were running P2P file >>> sharing applications which were hogging all the bandwidth. I looked for >>> programs that would allow me to shape traffic according to the >>> application layer protocol, but couldn't find any for FreeBSD. I found a >>> couple: l7-filter and ipp2p, but these are Linux specific. So, I decided >>> to write one. The result is ipfw-classifyd : >>> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >>> >>> As the name implies it uses ipfw(4) to implement a userland daemon that >>> classifies TCP and UDP packets according to regular expression patterns >>> for various protocols. It's intended to be used with divert(4) sockets >>> and dummynet(4) so you can do traffic shaping depending on the >>> application level protocol. The protocol patterns are from the l7-filter >>> project. >>> >>> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >>> reads its configuration file for a list of protocols and ipfw(8) rules. >>> Then, when it detects a matching session it re-injects the packet back >>> at the specified rule number. The tarball has a sample configuration >>> file and firewall script to get you started. >>> >>> While I have not done extensive testing, preliminary tests are >>> encouraging and it seems to work, so I thought I'd announce it to the >>> rest of the world in case anyone else is interested in this kind of >>> application. >>> >>> Comments and suggestions highly appreciated. >>> >> >> Thanks for this. >> I have a question, you remove a flow from if you see a FIN for the TCP >> case and only on overlapping flow for either TCP/UDP how do the other >> flows expire i am missing that part? >> >> > > No, you're not missing anything. It's on my TODO list. I wanted to get > this out and get feedback as early as possible, so I released it as soon as > I had it basically working. I'm thinking of storing some session > information > for the flow (like a timestamp for the last packet seen) and implementing > a garbage collector thread that removes sessions that have been idle for > some period of time. > BTW, why not make it a port?! -- Ermal From eksffa at freebsdbrasil.com.br Fri Aug 1 15:59:07 2008 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Fri Aug 1 15:59:15 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48922E9D.1020507@elischer.org> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> Message-ID: <4893328C.2040105@freebsdbrasil.com.br> Julian Elischer escreveu: > Patrick Tracanelli wrote: >> Mike Makonnen escreveu: >>> Hi, >>> >>> An Internet Cafe I do some work for was recently having problems with >>> very slow internet access. It turns out customers were running P2P >>> file sharing applications which were hogging all the bandwidth. I >>> looked for programs that would allow me to shape traffic according >>> to the application layer protocol, but couldn't find any for FreeBSD. >>> I found a couple: l7-filter and ipp2p, but these are Linux specific. >>> So, I decided to write one. The result is ipfw-classifyd : >>> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >>> >>> As the name implies it uses ipfw(4) to implement a userland daemon >>> that classifies TCP and UDP packets according to regular expression >>> patterns for various protocols. It's intended to be used with >>> divert(4) sockets and dummynet(4) so you can do traffic shaping >>> depending on the application level protocol. The protocol patterns >>> are from the l7-filter project. >>> >>> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >>> reads its configuration file for a list of protocols and ipfw(8) >>> rules. Then, when it detects a matching session it re-injects the >>> packet back at the specified rule number. The tarball has a sample >>> configuration file and firewall script to get you started. >>> >>> While I have not done extensive testing, preliminary tests are >>> encouraging and it seems to work, so I thought I'd announce it to the >>> rest of the world in case anyone else is interested in this kind of >>> application. >>> >>> Comments and suggestions highly appreciated. >>> >>> Cheers. >> >> Wont compile on RELENG_6 but is working perfectly on REL_7. I am >> trying hard with ssh, soulseek and msn. Its working like a charm with >> the suggested rc.firewall. >> >> I have configured ipfw-classfyd.conf changing the rules, for a number >> of L7 patterns, and now I try to understand why the "diverted" rules >> only match if the rule number is 1 after the configured, ie, I put >> soulseek to 65530 and a rule wont match there, but the very same rule >> matches 65531. I will read the code, but it seems that reinjection of >> the packet is made +1, correct? > > > yes, > the idea is: > If you get the sockaddr for the received packet, and use it unmodified > when reinjecting the packet, > then it will continue on at the next rule. > so since the rule number is "unchanged" we need to add 1 to it > to say where to start from.. > > hope that helps.. Perfect. Thanks. To let you know of my current (real world) tests: - Wireless Internet Provider 1: - 4Mbit/s of Internet Traffic - Classifying default protocols + soulseek + ssh - Classifying 100Mbit/s of dump over ssh Results in: No latency added, very low CPU usage, no packets dropping. - Wireless ISP 2: - 21 Mbit/s of Internet Traffic - Classifying default protocols + soulseek + ssh Results in: No tcp or udp traffic at all; everything that gets diverted never comes out of the divert socket, and ipfw-classifyd logs Aug 1 12:07:35 ourofino last message repeated 58 times Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule 1000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule 50000) Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert socket: Operation not permitted Aug 1 12:18:50 ourofino last message repeated 90 times Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full Aug 1 12:19:11 ourofino last message repeated 94 times Raised queue len a lot (up to 40960), when the application starts it uses up to 25% CPU and a second after that, CPU usage gets lower the 0.1%. So far, this is what I have in real world enviroments. -- Patrick Tracanelli From gavin at FreeBSD.org Fri Aug 1 17:53:43 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Aug 1 17:53:49 2008 Subject: kern/123256: [wpi] panic: blockable sleep lock with wpi(4) Message-ID: <200808011753.m71Hrhuf028802@freefall.freebsd.org> Synopsis: [wpi] panic: blockable sleep lock with wpi(4) Responsible-Changed-From-To: gavin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri Aug 1 17:42:56 UTC 2008 Responsible-Changed-Why: Over to maintainers. Hopefully the backtrace is enough to understand what is happening here. http://www.freebsd.org/cgi/query-pr.cgi?pr=123256 From mtm at wubethiopia.com Sat Aug 2 11:21:57 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Sat Aug 2 11:22:03 2008 Subject: Application layer classifier for ipfw In-Reply-To: <4893328C.2040105@freebsdbrasil.com.br> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> Message-ID: <4894447C.3000800@wubethiopia.com> Patrick Tracanelli wrote: > > To let you know of my current (real world) tests: > > - Wireless Internet Provider 1: > - 4Mbit/s of Internet Traffic > - Classifying default protocols + soulseek + ssh > - Classifying 100Mbit/s of dump over ssh > > Results in: > No latency added, very low CPU usage, no packets dropping. > > - Wireless ISP 2: > - 21 Mbit/s of Internet Traffic > - Classifying default protocols + soulseek + ssh > > Results in: > No tcp or udp traffic at all; everything that gets diverted never > comes out of the divert socket, and ipfw-classifyd logs > > Aug 1 12:07:35 ourofino last message repeated 58 times > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella > (rule 1000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule > 50000) > Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert > socket: Operation not permitted > Aug 1 12:18:50 ourofino last message repeated 90 times Hmmm... this part means that the call to sendto(2) to write the packet back into network stack failed. This explains why you are not seein g any traffic comming back out of the divert socket, but I don't see why it would suddenly fail with a permission error. Could this be a kernel bug? > Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full > Aug 1 12:19:11 ourofino last message repeated 94 times > > Raised queue len a lot (up to 40960), when the application starts it > uses up to 25% CPU and a second after that, CPU usage gets lower the > 0.1%. This looks like a deadlock. If it weren't able to process packets fast enough the cpu usage should be high even as it's spewing "packet dropped" messages. Can you send me some more information like memory usage and the firewall script you are using? How much of the 21Mbits/s of traffic is P2P? If you reduce the number of protocols you are trying to match against does the behavior change? Using netstat -w1 -I can you tell me how many packets per second we're talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the log file seem to show that the daemon is running for approx. 34 sec. before the first "unable to write to write to divert socket" message. Is it passing traffic during this time? Thanks. I've uploaded a newer version. Can you try that also please. It includes: o SIGHUP forces it to re-read its configuration file o rc.d script o minor optimization (calls pthread_cond_signal with the mutex unlocked) o code cleanup Also, for your convenience I have attached a patch against the earlier version that removes a debugging printf that should remove spammage to your log files (the current version has it removed already). Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org -------------- next part -------------- --- classifyd.c.orig 2008-08-02 11:11:33.000000000 +0300 +++ classifyd.c 2008-08-02 11:10:52.000000000 +0300 @@ -334,10 +334,6 @@ if ((error) == 0) { \ (flow)->if_fwrule = (proto)->p_fwrule; \ (pkt)->fp_saddr.sin_port = (flow)->if_fwrule; \ - syslog(LOG_NOTICE, "MATCH %s(%d): %s:%d -> %s:%d\n", \ - (proto)->p_name, (flow)->if_fwrule, \ - inet_ntoa((key)->ik_src), ntohs((key)->ik_sport), \ - inet_ntoa((key)->ik_dst), ntohs((key)->ik_dport)); \ } else if ((error) != REG_NOMATCH) { \ regerror((error), &(proto)->p_preg, (regerr), sizeof((regerr))); \ syslog(LOG_WARNING, "error matching %s:%d -> %s:%d against %s: %s", \ From mtm at wubethiopia.com Sat Aug 2 11:25:06 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Sat Aug 2 11:25:13 2008 Subject: Application layer classifier for ipfw In-Reply-To: <9a542da30808010850o22ebbe4er4e56e6f700a37c5e@mail.gmail.com> References: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> <4892E3BE.2030900@wubethiopia.com> <9a542da30808010850o22ebbe4er4e56e6f700a37c5e@mail.gmail.com> Message-ID: <4894456F.6060607@wubethiopia.com> Ermal Lu?i wrote: > On Fri, Aug 1, 2008 at 12:21 PM, Mike Makonnen wrote: > >> Ermal Lu?i wrote: >> >>> Thanks for this. >>> I have a question, you remove a flow from if you see a FIN for the TCP >>> case and only on overlapping flow for either TCP/UDP how do the other >>> flows expire i am missing that part? >>> >>> >>> >> No, you're not missing anything. It's on my TODO list. I wanted to get >> this out and get feedback as early as possible, so I released it as soon as >> I had it basically working. I'm thinking of storing some session >> information >> for the flow (like a timestamp for the last packet seen) and implementing >> a garbage collector thread that removes sessions that have been idle for >> some period of time. >> >> > > BTW, why not make it a port?! > That's the plan as soon as I'm happy with it. I've created a sourceforge project (I just haven't had time to set it up yet), and in a few weeks I'll submit a port for it. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From mtm at wubethiopia.com Sat Aug 2 11:27:18 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Sat Aug 2 11:27:25 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48932D3E.7090709@freebsdbrasil.com.br> References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> <48932D3E.7090709@freebsdbrasil.com.br> Message-ID: <489445F8.3080100@wubethiopia.com> Patrick Tracanelli wrote: > eculp escreveu: >> Quoting Mike Makonnen : >> >>> Daniel Dias Gon?alves wrote: >>>> You will go to develop a version to work with PF ? >>>> >>> I don't know what's needed to get it to work with pf, but if it's >>> not too >>> much work, sure. >> >> That would be great, Mike. I'm seeing more and more bandwidth being >> used with p2p that I haven't been able to control with pf. The >> thought has entered my mind to change back to ipfw that I used for >> many years before changing to pf maybe 3 years ago. I also found >> dummynet to be easy and practical to set up for both incoming and >> outgoing connections. Something else I haven't figured out how to do >> the same with altq, if even possible. In fact, if I am able to >> control p2p with pf I may not even need bidirectional bandwidth limits. >> >> Thanks for sharing your very practical solution to a real world >> problem. Have a great weekend. > > If it could be rewritten as a netgaph node, maybe it could tag the > classified packets, and tagging be compatible with both pf and ipfw > (under discretionary user choice with configuration switchs), so both > ipfw or pf could be used. I'll look into this when I have time. > > However a lot of work has to be done before. It works better on i386 > than amd64 right now, wont compile on RELENG_6 without modifying some > gcc tweaks, etc. Do you have a patch :-) ? Barring that, can you email me a copy of the build output? > > I hope enhacing it can be a GSoC project in the future, or we > (community) can raise some funds to make it happen faster. It is > really a long-time needed feature to FreeBSD. > Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From ermal.luci at gmail.com Sat Aug 2 11:34:10 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Sat Aug 2 11:34:16 2008 Subject: Application layer classifier for ipfw In-Reply-To: <489445F8.3080100@wubethiopia.com> References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> <48932D3E.7090709@freebsdbrasil.com.br> <489445F8.3080100@wubethiopia.com> Message-ID: <9a542da30808020434w4954924dued75202ad34d44ba@mail.gmail.com> On Sat, Aug 2, 2008 at 1:33 PM, Mike Makonnen wrote: > Patrick Tracanelli wrote: >> >> eculp escreveu: >>> >>> Quoting Mike Makonnen : >>> >>>> Daniel Dias Gon?alves wrote: >>>>> >>>>> You will go to develop a version to work with PF ? >>>>> >>>> I don't know what's needed to get it to work with pf, but if it's not >>>> too >>>> much work, sure. >>> >>> That would be great, Mike. I'm seeing more and more bandwidth being used >>> with p2p that I haven't been able to control with pf. The thought has >>> entered my mind to change back to ipfw that I used for many years before >>> changing to pf maybe 3 years ago. I also found dummynet to be easy and >>> practical to set up for both incoming and outgoing connections. Something >>> else I haven't figured out how to do the same with altq, if even possible. >>> In fact, if I am able to control p2p with pf I may not even need >>> bidirectional bandwidth limits. As for pf(4) i have mostly finished divert support on pf. The number on the protocol means a dummynet queue/pipe instead of a rule number for ipfw. Surely with dummynet(4) support into pf(4) too. I will polish the patch and post it later on. >>> >>> Thanks for sharing your very practical solution to a real world problem. >>> Have a great weekend. >> >> If it could be rewritten as a netgaph node, maybe it could tag the >> classified packets, and tagging be compatible with both pf and ipfw (under >> discretionary user choice with configuration switchs), so both ipfw or pf >> could be used. > This means doing regex in kernel or just a daemon as mpd on top of netgraph? > I'll look into this when I have time. >> >> However a lot of work has to be done before. It works better on i386 than >> amd64 right now, wont compile on RELENG_6 without modifying some gcc tweaks, >> etc. > > Do you have a patch :-) ? Barring that, can you email me a copy of the build > output? >> >> I hope enhacing it can be a GSoC project in the future, or we (community) >> can raise some funds to make it happen faster. It is really a long-time >> needed feature to FreeBSD. >> > > Cheers. > > -- > Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc > mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 > FreeBSD | http://www.freebsd.org > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From ermal.luci at gmail.com Sat Aug 2 11:41:45 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Sat Aug 2 11:41:52 2008 Subject: Application layer classifier for ipfw In-Reply-To: <9a542da30808020434w4954924dued75202ad34d44ba@mail.gmail.com> References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> <48932D3E.7090709@freebsdbrasil.com.br> <489445F8.3080100@wubethiopia.com> <9a542da30808020434w4954924dued75202ad34d44ba@mail.gmail.com> Message-ID: <9a542da30808020441k300ce778kdb84f9d4914b6891@mail.gmail.com> One thing, can you please make the SYN/ACK table optional since on pf(4) you have the info from the state table when a tcp connection is established. On Sat, Aug 2, 2008 at 1:34 PM, Ermal Lu?i wrote: > On Sat, Aug 2, 2008 at 1:33 PM, Mike Makonnen wrote: >> Patrick Tracanelli wrote: >>> >>> eculp escreveu: >>>> >>>> Quoting Mike Makonnen : >>>> >>>>> Daniel Dias Gon?alves wrote: >>>>>> >>>>>> You will go to develop a version to work with PF ? >>>>>> >>>>> I don't know what's needed to get it to work with pf, but if it's not >>>>> too >>>>> much work, sure. >>>> >>>> That would be great, Mike. I'm seeing more and more bandwidth being used >>>> with p2p that I haven't been able to control with pf. The thought has >>>> entered my mind to change back to ipfw that I used for many years before >>>> changing to pf maybe 3 years ago. I also found dummynet to be easy and >>>> practical to set up for both incoming and outgoing connections. Something >>>> else I haven't figured out how to do the same with altq, if even possible. >>>> In fact, if I am able to control p2p with pf I may not even need >>>> bidirectional bandwidth limits. > > As for pf(4) i have mostly finished divert support on pf. The number > on the protocol means a dummynet queue/pipe instead of a rule number > for ipfw. > Surely with dummynet(4) support into pf(4) too. I will polish the > patch and post it later on. > >>>> >>>> Thanks for sharing your very practical solution to a real world problem. >>>> Have a great weekend. >>> >>> If it could be rewritten as a netgaph node, maybe it could tag the >>> classified packets, and tagging be compatible with both pf and ipfw (under >>> discretionary user choice with configuration switchs), so both ipfw or pf >>> could be used. >> > > This means doing regex in kernel or just a daemon as mpd on top of netgraph? > >> I'll look into this when I have time. >>> >>> However a lot of work has to be done before. It works better on i386 than >>> amd64 right now, wont compile on RELENG_6 without modifying some gcc tweaks, >>> etc. >> >> Do you have a patch :-) ? Barring that, can you email me a copy of the build >> output? >>> >>> I hope enhacing it can be a GSoC project in the future, or we (community) >>> can raise some funds to make it happen faster. It is really a long-time >>> needed feature to FreeBSD. >>> >> >> Cheers. >> >> -- >> Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc >> mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 >> FreeBSD | http://www.freebsd.org >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > Ermal > -- Ermal From smithi at nimnet.asn.au Sat Aug 2 12:55:11 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Aug 2 12:55:18 2008 Subject: Application layer classifier for ipfw In-Reply-To: <4892E735.1000105@wubethiopia.com> Message-ID: On Fri, 1 Aug 2008, Mike Makonnen wrote: > Patrick Tracanelli wrote: > > Mike Makonnen escreveu: > >> Hi, > >> > >> An Internet Cafe I do some work for was recently having problems with > >> very slow internet access. It turns out customers were running P2P > >> file sharing applications which were hogging all the bandwidth. I > >> looked for programs that would allow me to shape traffic according > >> to the application layer protocol, but couldn't find any for FreeBSD. > >> I found a couple: l7-filter and ipp2p, but these are Linux specific. > >> So, I decided to write one. The result is ipfw-classifyd : > >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 This is great, Mike. I've been 'waiting for this' for a very similar situation for months now, getting by with dummynet bandwidth limiting and wondering about weighted queuing, but this is a much sharper tool. > >> As the name implies it uses ipfw(4) to implement a userland daemon > >> that classifies TCP and UDP packets according to regular expression > >> patterns for various protocols. It's intended to be used with > >> divert(4) sockets and dummynet(4) so you can do traffic shaping > >> depending on the application level protocol. The protocol patterns > >> are from the l7-filter project. Any GPL issues with using these patterns? > >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It > >> reads its configuration file for a list of protocols and ipfw(8) > >> rules. Then, when it detects a matching session it re-injects the > >> packet back at the specified rule number. The tarball has a sample > >> configuration file and firewall script to get you started. I was confused by 'back at the specified rule number' too, especially as you used a rule 1000 in the example, being the rule handling NON matched packets. So I had a browse through the code, finding: /* * Inform divert(4) what rule to send it to by * modifying the port number of the associated sockaddr_in * structure. Note: we subtract one from the ipfw(4) rule * number because processing in ipfw(4) will start with * the next rule *after* the supplied rule number. */ if (flow->if_fwrule != 0) { pkt->fp_saddr.sin_port = flow->if_fwrule; goto enqueue; } and noticed that we weren't subtracting one .. I don't believe it's quite correct to say 'ipfw will start with the next rule after the supplied rule number'. If there were (legitimately) multiple rules having the same number (either divert rules themselves or at the target rule), the ipfw divert-return code skips past duplicates to the next rule that has a higher rule number, which may not amount to the same thing. (Sorry, Julian made me study ipfw execution behaviour months ago :) I thought at first that this behaviour is fine, and just needed a bit better describing. But I'm starting to wonder if subtracting one isn't really a better idea? > >> While I have not done extensive testing, preliminary tests are > >> encouraging and it seems to work, so I thought I'd announce it to the > >> rest of the world in case anyone else is interested in this kind of > >> application. > >> > >> Comments and suggestions highly appreciated. > >> > >> Cheers. > > > > Wont compile on RELENG_6 but is working perfectly on REL_7. I am > > trying hard with ssh, soulseek and msn. Its working like a charm with > > the suggested rc.firewall. > Can you email me the compile error? I'd like to run it on a 4.8 filtering bridge .. ah, never mind :) > > I have configured ipfw-classfyd.conf changing the rules, for a number > > of L7 patterns, and now I try to understand why the "diverted" rules > > only match if the rule number is 1 after the configured, ie, I put > > soulseek to 65530 and a rule wont match there, but the very same rule > > matches 65531. I will read the code, but it seems that reinjection of > > the packet is made +1, correct? > > > The application doesn't do that, it's the firewall that does that. > Basically, when > ipfw(4) diverts a packet to the application it includes the rule > that caused the packet to be diverted (so that when it gets it back it knows > where to continue processing from). When it gets the packet back it > continues > processing the packet at the rule *after* the one that caused it to be > diverted Rather, 'at the first rule having a higher rule number than the one ..' > (otherwise the packet would get diverted in an endless loop). In the sample > script rule 1000 is the rule that passes the packets that do not get > diverted, so > I configured ipfw-classifyd to modify the information that comes with the > packet to point to rule 1000 (in classifyd.conf). So, when ipfw(4) gets the > packet back it continues processing it at the next rule after 1000, which is > the rule that sends all diverted packets through the pipe. Yeah figuring out how rule 1000 had anything to do with it confused me at first, when any number after the divert rule/s would do. I think it may need stating really explicitly, something perhaps better put than: The rule number configured for the specified traffic type is that of the last rule number *before* the target ipfw rule for a match. Which is still harder to describe (or get one's head around) than being able to specify the desired target rule number in the config file? As long as you don't subtract one for the non-match packets reinjected normally, and do subtract one from the matching packet's config rule, so directly skipping to the specified rule, it would need an awful lot less explaining to users .. > Hope that helps. Oh yes :) Might even have to upgrade that bridge at long last. cheers, Ian From mtm at wubethiopia.com Sat Aug 2 12:55:20 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Sat Aug 2 12:55:27 2008 Subject: Application layer classifier for ipfw In-Reply-To: <4894447C.3000800@wubethiopia.com> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> Message-ID: <48945A79.50300@wubethiopia.com> Mike Makonnen wrote: > Patrick Tracanelli wrote: >> >> To let you know of my current (real world) tests: >> >> - Wireless Internet Provider 1: >> - 4Mbit/s of Internet Traffic >> - Classifying default protocols + soulseek + ssh >> - Classifying 100Mbit/s of dump over ssh >> >> Results in: >> No latency added, very low CPU usage, no packets dropping. >> >> - Wireless ISP 2: >> - 21 Mbit/s of Internet Traffic >> - Classifying default protocols + soulseek + ssh >> >> Results in: >> No tcp or udp traffic at all; everything that gets diverted never >> comes out of the divert socket, and ipfw-classifyd logs >> >> Aug 1 12:07:35 ourofino last message repeated 58 times >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella >> (rule 1000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >> 50000) >> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >> socket: Operation not permitted >> Aug 1 12:18:50 ourofino last message repeated 90 times > > Hmmm... this part means that the call to sendto(2) to write the packet > back into network stack failed. This explains why you are not seein g > any traffic comming back out of the divert socket, but I don't see why > it would suddenly fail with a permission error. Could this be a kernel > bug? >> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue >> full >> Aug 1 12:19:11 ourofino last message repeated 94 times >> >> Raised queue len a lot (up to 40960), when the application starts it >> uses up to 25% CPU and a second after that, CPU usage gets lower the >> 0.1%. > > This looks like a deadlock. If it weren't able to process packets fast > enough the cpu usage should be high even as it's spewing "packet > dropped" messages. Can you send me some more information like memory > usage and the firewall script you are using? How much of the 21Mbits/s > of traffic is P2P? If you reduce the number of protocols you are > trying to match against does the behavior change? Using netstat -w1 > -I can you tell me how many packets per second we're > talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the > log file seem to show that the daemon is running for approx. 34 sec. > before the first "unable to write to write to divert socket" message. > Is it passing traffic during this time? Thanks. > > I've uploaded a newer version. Can you try that also please. It includes: > o SIGHUP forces it to re-read its configuration file > o rc.d script > o minor optimization (calls pthread_cond_signal with the mutex > unlocked) > o code cleanup > > Also, for your convenience I have attached a patch against the earlier > version that removes a debugging printf that should remove spammage to > your log files (the current version has it removed already). > Ooops, a few minutes after I sent this email I found a couple of bugs (one major, and one minor). They were in the original tarball as well as the newer one I uploaded earlier today. I've uploaded a fixed version of the code. Can you try that instead please. Also, to help track down performance issues I've modified the Makefile to build a profiled version of the application so you can use gprof(1) to figure out where any problems lie. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From julian at elischer.org Sun Aug 3 08:06:01 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 3 08:06:13 2008 Subject: Developers adding global variables. Message-ID: <489566F5.9040308@elischer.org> If you are adding globals to the networking code, (or if you have added soem globals in the last few months, could you make sure that I am aware of them? marko Zec and I are trying to keep teh Vimage tree in perforce in sync with -current but there is noo automatic way that we would be noticfied of the sudden appearance of a new global variable in the networking code. Today I noticed tcp_do_ecn and tcp_ecn_maxretries but only because of their proximity to another change. thanks Julian From eugen at kuzbass.ru Sun Aug 3 08:06:57 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Aug 3 08:07:06 2008 Subject: permissions on /etc/namedb Message-ID: <20080803073803.GA10321@grosbein.pp.ru> Hi! I need /etc/namedb to be owned by root:bind and have permissions 01775, so bind may write to it but may not overwrite files that belong to root here, and I made it so. Suprise! # /etc/rc.d/named restart Stopping named. Waiting for PIDS: 1892. etc/namedb changed gid expected 0 found 53 modified permissions expected 0755 found 01775 modified Starting named. I dislike it very much when a system thinks it knows better what user needs. Also, I do not want to move a place where bind writes its files to another location just because system does not want it to write here. Why was this done such way, do I miss something? Eugene Grosbein From samflanker at gmail.com Sun Aug 3 08:21:45 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Sun Aug 3 08:21:51 2008 Subject: problem with iwn interface Message-ID: <48956A7C.90107@gmail.com> Hello My problem appears when using the |net-p2p/qbittorrent| for downloading media-data from the torrent trackers. here are some outputs ---------------------------------------------------------------------- # uname -a FreeBSD spectrum 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Jul 18 22:39:18 MSD 2008 root@spectrum:/usr/obj/usr/src/sys/SPECTRUM i386 ---------------------------------------------------------------------- ---------------------------------------------------------------------- Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 63 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 66 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:32 spectrum last message repeated 2 times Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 67 Aug 3 11:39:32 spectrum kernel: iwn0: error, INTR=2000000 STATUS=0x0 ---------------------------------------------------------------------- ---------------------------------------------------------------------- 64 bytes from 213.180.204.8: icmp_seq=718 ttl=57 time=124.113 ms 64 bytes from 213.180.204.8: icmp_seq=719 ttl=57 time=100.074 ms 64 bytes from 213.180.204.8: icmp_seq=720 ttl=57 time=107.891 ms 64 bytes from 213.180.204.8: icmp_seq=721 ttl=57 time=136.788 ms 64 bytes from 213.180.204.8: icmp_seq=722 ttl=57 time=149.726 ms 64 bytes from 213.180.204.8: icmp_seq=723 ttl=57 time=129.400 ms ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ---------------------------------------------------------------------- ---------------------------------------------------------------------- iwn0: flags=8c43 metric 0 mtu 1500 ether 00:1d:e0:9b:b0:86 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid cargo channel 7 (2442 Mhz 11g) bssid 00:12:6b:63:17:10 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 50 bmiss 10 scanvalid 60 protmode CTS roaming MANUAL ---------------------------------------------------------------------- please, any solutions? /Vladimir Ermakov From samflanker at gmail.com Sun Aug 3 08:32:24 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Sun Aug 3 08:32:31 2008 Subject: iwn0: received beacon Message-ID: <489566C9.8040406@gmail.com> Hello My problem appears when using the |net-p2p/qbittorrent| for downloading media-data from the torrent trackers. here are some outputs ---------------------------------------------------------------------- # uname -a FreeBSD spectrum 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Jul 18 22:39:18 MSD 2008 root@spectrum:/usr/obj/usr/src/sys/SPECTRUM i386 ---------------------------------------------------------------------- ---------------------------------------------------------------------- Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 63 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 62 Aug 3 11:39:31 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 66 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 64 Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 65 Aug 3 11:39:32 spectrum last message repeated 2 times Aug 3 11:39:32 spectrum kernel: iwn0: received beacon from 00:11:6b:63:47:12 rssi 67 Aug 3 11:39:32 spectrum kernel: iwn0: error, INTR=2000000 STATUS=0x0 ---------------------------------------------------------------------- ---------------------------------------------------------------------- 64 bytes from 213.180.204.8: icmp_seq=718 ttl=57 time=124.113 ms 64 bytes from 213.180.204.8: icmp_seq=719 ttl=57 time=100.074 ms 64 bytes from 213.180.204.8: icmp_seq=720 ttl=57 time=107.891 ms 64 bytes from 213.180.204.8: icmp_seq=721 ttl=57 time=136.788 ms 64 bytes from 213.180.204.8: icmp_seq=722 ttl=57 time=149.726 ms 64 bytes from 213.180.204.8: icmp_seq=723 ttl=57 time=129.400 ms ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ---------------------------------------------------------------------- ---------------------------------------------------------------------- iwn0: flags=8c43 metric 0 mtu 1500 ether 00:1d:e0:9b:b0:86 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid cargo channel 7 (2442 Mhz 11g) bssid 00:12:6b:63:17:10 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 50 bmiss 10 scanvalid 60 protmode CTS roaming MANUAL ---------------------------------------------------------------------- please, any solutions? /Vladimir Ermakov From rwatson at FreeBSD.org Sun Aug 3 10:32:17 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 3 10:32:24 2008 Subject: Developers adding global variables. In-Reply-To: <489566F5.9040308@elischer.org> References: <489566F5.9040308@elischer.org> Message-ID: On Sun, 3 Aug 2008, Julian Elischer wrote: > If you are adding globals to the networking code, (or if you have added soem > globals in the last few months, could you make sure that I am aware of them? > > marko Zec and I are trying to keep teh Vimage tree in perforce in sync with > -current but there is noo automatic way that we would be noticfied of the > sudden appearance of a new global variable in the networking code. > > Today I noticed tcp_do_ecn and tcp_ecn_maxretries but only because of their > proximity to another change. While not a universal solution, one technique you could use to catch things like this is to compare the set of symbols in a !virtualization kernel with those in a virtualization kernels, perhaps using nm(1), and compare that difference set over time. Not perfect, but it would allow you to look for things that have been missed. FWIW, I have no immediate plans to add any global variables to the network stack. Robert N M Watson Computer Laboratory University of Cambridge From smithi at nimnet.asn.au Sun Aug 3 13:05:44 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Aug 3 13:05:51 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080803073803.GA10321@grosbein.pp.ru> Message-ID: On Sun, 3 Aug 2008, Eugene Grosbein wrote: > I need /etc/namedb to be owned by root:bind and have permissions 01775, > so bind may write to it but may not overwrite files that belong to root > here, and I made it so. Suprise! > > # /etc/rc.d/named restart > Stopping named. > Waiting for PIDS: 1892. > etc/namedb changed > gid expected 0 found 53 modified > permissions expected 0755 found 01775 modified > Starting named. Are you running /etc/namedb linked to chroot'd /var/named/etc/namedb? If so, that'd be mtree restoring perms from /etc/mtree/BIND.chroot.dist I couldn't get rndc trace running to named.run for ages, same problem: bind user couldn't write to (default) /var/named/etc/namedb/named.run unless it already existed, owned by bind. Added to /etc/rc.d/named: touch /var/named/etc/namedb/named.run chown bind /var/named/etc/namedb/named.run # bind:wheel 644 and now trace and querylog are happy, so I am. Running latest 5-STABLE here but I see no changes in 7 or HEAD cvs related to this. Suppose I should do up a PR with a patch, unless someone knows a better way? I don't know if this helps with whatever file/s you want bind to write, or whether there are other files bind writes needing similar treatment. > I dislike it very much when a system thinks it knows better what user needs. > Also, I do not want to move a place where bind writes its files to another > location just because system does not want it to write here. > Why was this done such way, do I miss something? I'm usually glad that FreeBSD's bind setup tends to paranoia :) cheers, Ian From mtm at wubethiopia.com Sun Aug 3 13:44:16 2008 From: mtm at wubethiopia.com (Mike Makonnen) Date: Sun Aug 3 13:44:22 2008 Subject: Application layer classifier for ipfw In-Reply-To: References: Message-ID: <4895B799.6070508@wubethiopia.com> Ian Smith wrote: > On Fri, 1 Aug 2008, Mike Makonnen wrote: > > Patrick Tracanelli wrote: > > > Mike Makonnen escreveu: > > >> Hi, > > >> > > >> An Internet Cafe I do some work for was recently having problems with > > >> very slow internet access. It turns out customers were running P2P > > >> file sharing applications which were hogging all the bandwidth. I > > >> looked for programs that would allow me to shape traffic according > > >> to the application layer protocol, but couldn't find any for FreeBSD. > > >> I found a couple: l7-filter and ipp2p, but these are Linux specific. > > >> So, I decided to write one. The result is ipfw-classifyd : > > >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 > > This is great, Mike. I've been 'waiting for this' for a very similar > situation for months now, getting by with dummynet bandwidth limiting > and wondering about weighted queuing, but this is a much sharper tool. > > > >> As the name implies it uses ipfw(4) to implement a userland daemon > > >> that classifies TCP and UDP packets according to regular expression > > >> patterns for various protocols. It's intended to be used with > > >> divert(4) sockets and dummynet(4) so you can do traffic shaping > > >> depending on the application level protocol. The protocol patterns > > >> are from the l7-filter project. > > Any GPL issues with using these patterns? > I don't believe so. > > >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It > > >> reads its configuration file for a list of protocols and ipfw(8) > > >> rules. Then, when it detects a matching session it re-injects the > > >> packet back at the specified rule number. The tarball has a sample > > >> configuration file and firewall script to get you started. > > I was confused by 'back at the specified rule number' too, especially as > you used a rule 1000 in the example, being the rule handling NON matched > packets. So I had a browse through the code, finding: > > /* > * Inform divert(4) what rule to send it to by > * modifying the port number of the associated sockaddr_in > * structure. Note: we subtract one from the ipfw(4) rule > * number because processing in ipfw(4) will start with > * the next rule *after* the supplied rule number. > */ > if (flow->if_fwrule != 0) { > pkt->fp_saddr.sin_port = flow->if_fwrule; > goto enqueue; > } > > and noticed that we weren't subtracting one .. > The comment is wrong. It was for a prior version of the code. Initially, I had the configuration file specify the rule number that passes the diverted packets to dummynet(4). The code (as the comment says) would subtract 1 from the number when it wrote the packet back, but I wasn't sure how ipfw(4) would react to a possibly non-existant rule so changed it to its current form. However, after thinking about it some more I think it is more intuitive and easier to understand if the configuration file specified the rule that passes the diverted packet to the pipe or queue. > I don't believe it's quite correct to say 'ipfw will start with the next > rule after the supplied rule number'. If there were (legitimately) > multiple rules having the same number (either divert rules themselves or > at the target rule), the ipfw divert-return code skips past duplicates > to the next rule that has a higher rule number, which may not amount to > the same thing. > > (Sorry, Julian made me study ipfw execution behaviour months ago :) > > I thought at first that this behaviour is fine, and just needed a bit > better describing. But I'm starting to wonder if subtracting one isn't > really a better idea? > I'm leaning in the same direction. > > >> While I have not done extensive testing, preliminary tests are > > >> encouraging and it seems to work, so I thought I'd announce it to the > > >> rest of the world in case anyone else is interested in this kind of > > >> application. > > >> > > >> Comments and suggestions highly appreciated. > > >> > > >> Cheers. > > > > > > Wont compile on RELENG_6 but is working perfectly on REL_7. I am > > > trying hard with ssh, soulseek and msn. Its working like a charm with > > > the suggested rc.firewall. > > Can you email me the compile error? > > I'd like to run it on a 4.8 filtering bridge .. ah, never mind :) > > > > I have configured ipfw-classfyd.conf changing the rules, for a number > > > of L7 patterns, and now I try to understand why the "diverted" rules > > > only match if the rule number is 1 after the configured, ie, I put > > > soulseek to 65530 and a rule wont match there, but the very same rule > > > matches 65531. I will read the code, but it seems that reinjection of > > > the packet is made +1, correct? > > > > > The application doesn't do that, it's the firewall that does that. > > Basically, when > > ipfw(4) diverts a packet to the application it includes the rule > > that caused the packet to be diverted (so that when it gets it back it knows > > where to continue processing from). When it gets the packet back it > > continues > > processing the packet at the rule *after* the one that caused it to be > > diverted > > Rather, 'at the first rule having a higher rule number than the one ..' > > > (otherwise the packet would get diverted in an endless loop). In the sample > > script rule 1000 is the rule that passes the packets that do not get > > diverted, so > > I configured ipfw-classifyd to modify the information that comes with the > > packet to point to rule 1000 (in classifyd.conf). So, when ipfw(4) gets the > > packet back it continues processing it at the next rule after 1000, which is > > the rule that sends all diverted packets through the pipe. > > Yeah figuring out how rule 1000 had anything to do with it confused me > at first, when any number after the divert rule/s would do. I think it > may need stating really explicitly, something perhaps better put than: > > The rule number configured for the specified traffic type is that of > the last rule number *before* the target ipfw rule for a match. > > Which is still harder to describe (or get one's head around) than being > able to specify the desired target rule number in the config file? > > As long as you don't subtract one for the non-match packets reinjected > normally, and do subtract one from the matching packet's config rule, > so directly skipping to the specified rule, it would need an awful lot > less explaining to users .. > > > Hope that helps. > > Oh yes :) Might even have to upgrade that bridge at long last. > > Glad to hear people are finding it useful :-) Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From eugen at kuzbass.ru Sun Aug 3 15:20:41 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Aug 3 15:20:48 2008 Subject: permissions on /etc/namedb In-Reply-To: References: <20080803073803.GA10321@grosbein.pp.ru> Message-ID: <20080803144719.GA33577@svzserv.kemerovo.su> On Sun, Aug 03, 2008 at 10:32:22PM +1000, Ian Smith wrote: > > I need /etc/namedb to be owned by root:bind and have permissions 01775, > > so bind may write to it but may not overwrite files that belong to root > > here, and I made it so. Suprise! > > > > # /etc/rc.d/named restart > > Stopping named. > > Waiting for PIDS: 1892. > > etc/namedb changed > > gid expected 0 found 53 modified > > permissions expected 0755 found 01775 modified > > Starting named. > > Are you running /etc/namedb linked to chroot'd /var/named/etc/namedb? > If so, that'd be mtree restoring perms from /etc/mtree/BIND.chroot.dist I just have 'named_enable="YES"' in /etc/rc.conf, it's 6.3-STABLE and stock bind9. I could set named_chroot_autoupdate="NO", but I see now it won't mount devfs into chroot are in that case. Eugene Grosbein From smithi at nimnet.asn.au Sun Aug 3 16:02:03 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Aug 3 16:02:10 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080803144719.GA33577@svzserv.kemerovo.su> Message-ID: On Sun, 3 Aug 2008, Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 10:32:22PM +1000, Ian Smith wrote: > > > > I need /etc/namedb to be owned by root:bind and have permissions 01775, > > > so bind may write to it but may not overwrite files that belong to root > > > here, and I made it so. Suprise! > > > > > > # /etc/rc.d/named restart > > > Stopping named. > > > Waiting for PIDS: 1892. > > > etc/namedb changed > > > gid expected 0 found 53 modified > > > permissions expected 0755 found 01775 modified > > > Starting named. > > > > Are you running /etc/namedb linked to chroot'd /var/named/etc/namedb? > > If so, that'd be mtree restoring perms from /etc/mtree/BIND.chroot.dist > > I just have 'named_enable="YES"' in /etc/rc.conf, it's 6.3-STABLE > and stock bind9. I could set named_chroot_autoupdate="NO", > but I see now it won't mount devfs into chroot are in that case. So hacking /etc/rc.d/named in chroot_autoupdate to do something like: files_bind_writes='named.run' # whatever for f in ${files_bind_writes}; do touch ${named_chrootdir}/etc/namedb/${f} chown bind:wheel ${named_chrootdir}/etc/namedb/${f} done wouldn't work for you? cheers, Ian From remko at FreeBSD.org Sun Aug 3 16:03:26 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sun Aug 3 16:03:38 2008 Subject: i386/126214: txpower problem with Atheros wifi card Message-ID: <200808031603.m73G3Q07043743@freefall.freebsd.org> Synopsis: txpower problem with Atheros wifi card Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sun Aug 3 16:03:26 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=126214 From rwatson at FreeBSD.org Sun Aug 3 16:26:50 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 3 16:27:04 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080630091033.P3968@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> Message-ID: On Mon, 30 Jun 2008, Robert Watson wrote: > On Sun, 29 Jun 2008, Robert Watson wrote: > >> An FYI on the state of things here: in the last month, John has updated a >> number of device drivers to be MPSAFE, and the USB work remains in-flight. >> I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and >> I catch up on driver state, and will likely send out an update next week >> regarding which device drivers remain on the kill list, and generally what >> the status of this project is. > > Here's the revised list of drivers that will have their build disabled in > the next week (subject to an appropriate block of time for me): A quick update: I had postponed removing IFF_NEEDSGIANT while awaiting the apparently forthcoming USB stack commit. Since it appears slow in coming, I will move ahead and disconnect non-USB drivers that require IFF_NEEDSGIANT in the coming week, but will leave the IFF_NEEDSGIANT infrastructure there, along with the current USB drivers that depend on it, until the USB merge is done. Robert N M Watson Computer Laboratory University of Cambridge From eugen at kuzbass.ru Sun Aug 3 16:56:21 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Aug 3 16:56:28 2008 Subject: permissions on /etc/namedb In-Reply-To: References: <20080803144719.GA33577@svzserv.kemerovo.su> Message-ID: <20080803165617.GA45778@svzserv.kemerovo.su> > So hacking /etc/rc.d/named in chroot_autoupdate to do something like: > > files_bind_writes='named.run' # whatever > for f in ${files_bind_writes}; do > touch ${named_chrootdir}/etc/namedb/${f} > chown bind:wheel ${named_chrootdir}/etc/namedb/${f} > done > > wouldn't work for you? I don't like the idea to write fixed list of file names; I'd like to use file system permissions to give bind right to write to directory, they (perms) exist exactly for that. Eugene Grosbein From dougb at FreeBSD.org Sun Aug 3 17:31:06 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Aug 3 17:31:13 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080803073803.GA10321@grosbein.pp.ru> References: <20080803073803.GA10321@grosbein.pp.ru> Message-ID: <4895EB57.2000801@FreeBSD.org> Eugene Grosbein wrote: > Hi! > > I need /etc/namedb to be owned by root:bind and have permissions 01775, > so bind may write to it but may not overwrite files that belong to root > here, and I made it so. I understand your frustration with something having changed that you did not expect. I would like to ask you though, what are you trying to accomplish here? What you suggested isn't really good from a security perspective because if an attacker does get in they can remove files from the directory that are owned by root and replace them with their own versions. If you give me a better idea what you're trying to do then I can give you some suggestions on how to make it happen. > I dislike it very much when a system thinks it knows better what user needs. So do I. :) In this case however I wanted to set up a system that is extremely secure by default so that the average user can be comfortable starting named in its default configuration. Obviously expert users can tweak the thing themselves. > Also, I do not want to move a place where bind writes its files to another > location just because system does not want it to write here. That's up to you of course, but it's definitely more secure in the long run to do it that way. hth, Doug -- This .signature sanitized for your protection From smithi at nimnet.asn.au Sun Aug 3 18:05:27 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Aug 3 18:05:34 2008 Subject: Application layer classifier for ipfw In-Reply-To: <4895B799.6070508@wubethiopia.com> Message-ID: On Sun, 3 Aug 2008, Mike Makonnen wrote: > Ian Smith wrote: > > On Fri, 1 Aug 2008, Mike Makonnen wrote: > > > Patrick Tracanelli wrote: > > > > Mike Makonnen escreveu: [..] > > /* > > * Inform divert(4) what rule to send it to by > > * modifying the port number of the associated sockaddr_in > > * structure. Note: we subtract one from the ipfw(4) rule > > * number because processing in ipfw(4) will start with > > * the next rule *after* the supplied rule number. > > */ > > if (flow->if_fwrule != 0) { > > pkt->fp_saddr.sin_port = flow->if_fwrule; > > goto enqueue; > > } > > > > and noticed that we weren't subtracting one .. > > > > The comment is wrong. It was for a prior version of the code. Initially, > I had the configuration file specify the rule number that passes the > diverted packets to dummynet(4). The code (as the comment says) would > subtract 1 from the number when it wrote the packet back, but I wasn't > sure how ipfw(4) would react to a possibly non-existant rule so changed >From my reading, that shouldn't be a problem. But I'm reading 5-STABLE sources and haven't access to my 7.0 system this week to try it out, and I could be entirely mistaken anyway! I guess it might be worth checking that the target rule number isn't less than the divert rule number that got us here, to guard against loops that $anyone might try to configure? > it to its current form. However, after thinking about it some more I > think it is more intuitive and easier to understand if the configuration > file specified the rule that passes the diverted packet to the pipe or > queue. Yes, the rule to skipto on a match, anyway. I can see doing plenty of other stuff with this than necessarily (immediately) queueing packets; depending on protocols detected you might count, log, pipe, queue with some weight, just pass, deny, test against various src/dst, whatever. > > I thought at first that this behaviour is fine, and just needed a bit > > better describing. But I'm starting to wonder if subtracting one isn't > > really a better idea? > > > > I'm leaning in the same direction. Worth a try? One thing you might test is whether it still works with net.inet.ip.fw.one_pass=1 ? That's only supposed to affect dummynet pipe diversion, but there's a bit of XXX code in after_ip_checks in ip_fw2.c (in 5-STABLE anyway) that makes me wonder about that .. > Glad to hear people are finding it useful :-) Only conceptually so far, but that's fun enough for now, while I'm really supposed to be relocating a server by sometime last week :) cheers, Ian From eugen at kuzbass.ru Sun Aug 3 18:50:40 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Aug 3 18:50:47 2008 Subject: permissions on /etc/namedb In-Reply-To: <4895EB57.2000801@FreeBSD.org> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> Message-ID: <20080803183346.GA53252@svzserv.kemerovo.su> On Sun, Aug 03, 2008 at 10:31:03AM -0700, Doug Barton wrote: > >I need /etc/namedb to be owned by root:bind and have permissions 01775, > >so bind may write to it but may not overwrite files that belong to root > >here, and I made it so. > I understand your frustration with something having changed that you > did not expect. I would like to ask you though, what are you trying to > accomplish here? What you suggested isn't really good from a security > perspective because if an attacker does get in they can remove files > from the directory that are owned by root and replace them with their > own versions. Can he? Doesn't sticky bit on the directory prevent him from that? > If you give me a better idea what you're trying to do then I can give > you some suggestions on how to make it happen. Well, I just want bind be allowed to write to is working directory. Yes, it's possible to redefine it but I'd rather avoid this, to not break existing setups. > >I dislike it very much when a system thinks it knows better what user > >needs. > > So do I. :) In this case however I wanted to set up a system that is > extremely secure by default so that the average user can be > comfortable starting named in its default configuration. I agree completly. > Obviously expert users can tweak the thing themselves. So, the question is: how to tweak? > >Also, I do not want to move a place where bind writes its files to another > >location just because system does not want it to write here. > > That's up to you of course, but it's definitely more secure in the > long run to do it that way. But that way prevents named to write to its working directory, this bothers me. Eugene Grosbein From fox at verio.net Sun Aug 3 19:21:48 2008 From: fox at verio.net (David DeSimone) Date: Sun Aug 3 19:21:55 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080803183346.GA53252@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> Message-ID: <20080803192140.GJ13898@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eugene Grosbein wrote: > > I need /etc/namedb to be owned by root:bind and have permissions > 01775, so bind may write to it but may not overwrite files that belong > to root here, and I made it so. Can't you just modify /etc/mtree/BIND.chroot.dist so that it sets the permissions you desire? - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIlgVEFSrKRjX5eCoRAseOAJ9cnYx4WtYSUsUj5wDxqSitCx42hACfWIzu 0DoLbIKoc4WlseGNU6HttFE= =yQIW -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From eugen at kuzbass.ru Mon Aug 4 02:56:26 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Aug 4 02:56:33 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080803192140.GJ13898@verio.net> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <20080803192140.GJ13898@verio.net> Message-ID: <20080804025622.GA2278@svzserv.kemerovo.su> On Sun, Aug 03, 2008 at 02:21:41PM -0500, David DeSimone wrote: > > I need /etc/namedb to be owned by root:bind and have permissions > > 01775, so bind may write to it but may not overwrite files that belong > > to root here, and I made it so. > > Can't you just modify /etc/mtree/BIND.chroot.dist so that it sets the > permissions you desire? Yes, that might be way to go. Eugene Grosbein From dougb at FreeBSD.org Mon Aug 4 05:54:08 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 4 05:54:15 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080803183346.GA53252@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> Message-ID: <4896997D.8060001@FreeBSD.org> Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 10:31:03AM -0700, Doug Barton wrote: > >>> I need /etc/namedb to be owned by root:bind and have permissions 01775, >>> so bind may write to it but may not overwrite files that belong to root >>> here, and I made it so. >> I understand your frustration with something having changed that you >> did not expect. I would like to ask you though, what are you trying to >> accomplish here? What you suggested isn't really good from a security >> perspective because if an attacker does get in they can remove files >> from the directory that are owned by root and replace them with their >> own versions. > > Can he? Doesn't sticky bit on the directory prevent him from that? That's a question that you can and should answer for yourself. (In fact one could argue that you should have answered that for yourself before you tried to set it up that way, but I digress.) :) >> If you give me a better idea what you're trying to do then I can give >> you some suggestions on how to make it happen. > > Well, I just want bind be allowed to write to is working directory. I think that your idea of "BIND's working directory" is probably flawed, but if what you want is to make /etc/namedb writable by the bind user and have it persist from boot to boot someone else already told you how to do that, so good luck. Doug PS, if you get pWn3d I don't want to hear any whinging. :) -- This .signature sanitized for your protection From eugen at kuzbass.ru Mon Aug 4 06:07:02 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Aug 4 06:07:09 2008 Subject: permissions on /etc/namedb In-Reply-To: <4896997D.8060001@FreeBSD.org> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> Message-ID: <20080804060658.GA19639@svzserv.kemerovo.su> On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: > >>>I need /etc/namedb to be owned by root:bind and have permissions 01775, > >>>so bind may write to it but may not overwrite files that belong to root > >>>here, and I made it so. > >>I understand your frustration with something having changed that you > >>did not expect. I would like to ask you though, what are you trying to > >>accomplish here? What you suggested isn't really good from a security > >>perspective because if an attacker does get in they can remove files > >>from the directory that are owned by root and replace them with their > >>own versions. > > > >Can he? Doesn't sticky bit on the directory prevent him from that? > > That's a question that you can and should answer for yourself. That was rhetorical quostion - I wished to give you a chance to correct yourself :-) Cheer :-) > (In fact one could argue that you should have answered that for yourself > before you tried to set it up that way, but I digress.) :) I knew right answer before tried to set up that way. > >>If you give me a better idea what you're trying to do then I can give > >>you some suggestions on how to make it happen. > > > >Well, I just want bind be allowed to write to is working directory. > > I think that your idea of "BIND's working directory" is probably > flawed That's not my idea. From /var/log/messages: Aug 3 15:02:18 host named[657]: the working directory is not writable > but if what you want is to make /etc/namedb writable by the > bind user and have it persist from boot to boot someone else already > told you how to do that, so good luck. Sigh... I have to study mtree now. And for what reason? Just because the system thinks it knows better what user needs. Eugene Grosbein From dougb at FreeBSD.org Mon Aug 4 06:39:21 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 4 06:39:34 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080804060658.GA19639@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> Message-ID: <4896A416.80602@FreeBSD.org> Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: > >>>>> I need /etc/namedb to be owned by root:bind and have permissions 01775, >>>>> so bind may write to it but may not overwrite files that belong to root >>>>> here, and I made it so. >>>> I understand your frustration with something having changed that you >>>> did not expect. I would like to ask you though, what are you trying to >>>> accomplish here? What you suggested isn't really good from a security >>>> perspective because if an attacker does get in they can remove files >>> >from the directory that are owned by root and replace them with their >>>> own versions. >>> Can he? Doesn't sticky bit on the directory prevent him from that? >> That's a question that you can and should answer for yourself. > > That was rhetorical quostion - I wished to give you a chance > to correct yourself :-) Cheer :-) mkdir teststicky chmod 1755 teststicky/ cd teststicky/ sudo touch foofile ls -la . total 6 drwxr-xr-t 2 dougb dougb 512 Aug 3 23:21 ./ -rw-r--r-- 1 root dougb 0 Aug 3 23:21 foofile rm foofile override rw-r--r-- root/wheel for foofile? y ls -la total 6 drwxr-xr-t 2 dougb dougb 512 Aug 3 23:22 ./ You might also want to read sticky(8), especially the bit where it says, "A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is ... the owner of the directory ..." >>>> If you give me a better idea what you're trying to do then I can give >>>> you some suggestions on how to make it happen. >>> Well, I just want bind be allowed to write to is working directory. >> I think that your idea of "BIND's working directory" is probably >> flawed > > That's not my idea. From /var/log/messages: > > Aug 3 15:02:18 host named[657]: the working directory is not writable That is a quaint reminder of a simpler time. It's far better nowadays to separate the idea of configuration directories and directories that named should write to. (One could easily make the argument that this division should have been enforced from the start, and personally I never liked having named dropping stuff all over my config directory, but I digress.) >> but if what you want is to make /etc/namedb writable by the >> bind user and have it persist from boot to boot someone else already >> told you how to do that, so good luck. > > Sigh... I have to study mtree now. If it takes you more than 5 minutes, give up. :) > And for what reason? Just because the system thinks it knows better what user needs. You previously agreed with me that the defaults should be appropriate for non-expert users, and I would still argue that they are. Also, I'm not sure whether you've actually looked at the default named.conf or not, but the two most common files that someone would want to write are the dump and statistics files, and there are already suitable paths for those files provided, and the bind user can actually write to them by default. It would be trivial to expand those examples to other things that are of particular interest to you. Meanwhile, it's obvious to me that you are determined to go a certain direction with this, so once again I wish you luck. Doug -- This .signature sanitized for your protection From eugen at kuzbass.ru Mon Aug 4 07:55:14 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Aug 4 07:55:21 2008 Subject: permissions on /etc/namedb In-Reply-To: <4896A416.80602@FreeBSD.org> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> Message-ID: <20080804075510.GA28531@svzserv.kemerovo.su> On Sun, Aug 03, 2008 at 11:39:18PM -0700, Doug Barton wrote: > >>>>>I need /etc/namedb to be owned by root:bind and have permissions 01775, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>>so bind may write to it but may not overwrite files that belong to root > >>>>>here, and I made it so. > >>>>I understand your frustration with something having changed that you > >>>>did not expect. I would like to ask you though, what are you trying to > >>>>accomplish here? What you suggested isn't really good from a security > >>>>perspective because if an attacker does get in they can remove files > >>>>from the directory that are owned by root and replace them with their > >>>>own versions. > >>>Can he? Doesn't sticky bit on the directory prevent him from that? > >>That's a question that you can and should answer for yourself. > > > >That was rhetorical quostion - I wished to give you a chance > >to correct yourself :-) Cheer :-) > > mkdir teststicky > chmod 1755 teststicky/ > cd teststicky/ > sudo touch foofile > > ls -la . > total 6 > drwxr-xr-t 2 dougb dougb 512 Aug 3 23:21 ./ > -rw-r--r-- 1 root dougb 0 Aug 3 23:21 foofile > > rm foofile > override rw-r--r-- root/wheel for foofile? y > > ls -la > total 6 > drwxr-xr-t 2 dougb dougb 512 Aug 3 23:22 ./ > > You might also want to read sticky(8), especially the bit where it > says, "A file in a sticky directory may only be removed or renamed by > a user if the user has write permission for the directory and the user > is ... the owner of the directory ..." Please reread the first line of quoted text in this message. Root is the owner of /etc/namedb for my case, and bind only have right to write to its own files and create new, not touch root-owned files. > >>I think that your idea of "BIND's working directory" is probably > >>flawed > >That's not my idea. From /var/log/messages: > >Aug 3 15:02:18 host named[657]: the working directory is not writable > That is a quaint reminder of a simpler time. [skip] > Also, I'm not sure whether you've actually looked at the default > named.conf or not, but the two most common files that someone would > want to write are the dump and statistics files, and there are already > suitable paths for those files provided, and the bind user can > actually write to them by default. It would be trivial to expand those > examples to other things that are of particular interest to you. The default named.conf contains the following line: directory "/etc/namedb"; That is "the working directory" which is not writable to bind by default, hence mentioned line in /var/log/messages. I dislike when default configuration emits such warnings. So I decided to make it writable in hope this setup will save me from future problems while still secure. Eugene Grosbein From eugen at kuzbass.ru Mon Aug 4 08:48:42 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Aug 4 08:48:49 2008 Subject: permissions on /etc/namedb In-Reply-To: References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> Message-ID: <20080804084833.GA35267@svzserv.kemerovo.su> On Mon, Aug 04, 2008 at 10:44:59AM +0200, Remko Lodder wrote: > I like the unwriteable /etc/namedb directory for bind, so that one is > "forced" to create directories for bind, which it has write access to. You > do not want to clobber the /etc/namedb directory with files (imo) ;) Should we change our default src/etc/namedb/named.conf in the Repository so that named won't warn about unwriteable "working directory"? Eugene Grosbein From randy at psg.com Mon Aug 4 08:53:10 2008 From: randy at psg.com (Randy Bush) Date: Mon Aug 4 08:53:21 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080804084833.GA35267@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> Message-ID: <4896C374.803@psg.com> my fix to all this has been /usr/ports/dns/unbound (cache only) or /usr/ports/dns/nsd (auth only) and the developers/porters are constructive and friendly randy From remko at elvandar.org Mon Aug 4 08:57:57 2008 From: remko at elvandar.org (Remko Lodder) Date: Mon Aug 4 08:58:04 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080804084833.GA35267@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> Message-ID: On Mon, August 4, 2008 10:48 am, Eugene Grosbein wrote: > On Mon, Aug 04, 2008 at 10:44:59AM +0200, Remko Lodder wrote: > >> I like the unwriteable /etc/namedb directory for bind, so that one is >> "forced" to create directories for bind, which it has write access to. >> You >> do not want to clobber the /etc/namedb directory with files (imo) ;) > > Should we change our default src/etc/namedb/named.conf in the Repository > so that named won't warn about unwriteable "working directory"? > > Eugene Grosbein > Hi, I dont think so.. I think the current default is fine, if you want to write files to it, then you need to change things, best is to use seperated directories. Note that you need to change things anyway because the server listens on localhost by default. So, if you want things differently; you have to customize it. Sounds like a fair deal to me ;) (the defaults that is) -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From remko at elvandar.org Mon Aug 4 09:00:04 2008 From: remko at elvandar.org (Remko Lodder) Date: Mon Aug 4 09:00:10 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080804075510.GA28531@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> Message-ID: On Mon, August 4, 2008 9:55 am, Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 11:39:18PM -0700, Doug Barton wrote: > >> >>>>>I need /etc/namedb to be owned by root:bind and have permissions >> 01775, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >>>>>so bind may write to it but may not overwrite files that belong to >> root >> >>>>>here, and I made it so. >> >>>>I understand your frustration with something having changed that you >> >>>>did not expect. I would like to ask you though, what are you trying >> to >> >>>>accomplish here? What you suggested isn't really good from a >> security >> >>>>perspective because if an attacker does get in they can remove files >> >>>>from the directory that are owned by root and replace them with >> their >> >>>>own versions. >> >>>Can he? Doesn't sticky bit on the directory prevent him from that? >> >>That's a question that you can and should answer for yourself. >> > >> >That was rhetorical quostion - I wished to give you a chance >> >to correct yourself :-) Cheer :-) >> >> mkdir teststicky >> chmod 1755 teststicky/ >> cd teststicky/ >> sudo touch foofile >> >> ls -la . >> total 6 >> drwxr-xr-t 2 dougb dougb 512 Aug 3 23:21 ./ >> -rw-r--r-- 1 root dougb 0 Aug 3 23:21 foofile >> >> rm foofile >> override rw-r--r-- root/wheel for foofile? y >> >> ls -la >> total 6 >> drwxr-xr-t 2 dougb dougb 512 Aug 3 23:22 ./ >> >> You might also want to read sticky(8), especially the bit where it >> says, "A file in a sticky directory may only be removed or renamed by >> a user if the user has write permission for the directory and the user >> is ... the owner of the directory ..." > > Please reread the first line of quoted text in this message. > Root is the owner of /etc/namedb for my case, and bind only have right > to write to its own files and create new, not touch root-owned files. > >> >>I think that your idea of "BIND's working directory" is probably >> >>flawed >> >That's not my idea. From /var/log/messages: >> >Aug 3 15:02:18 host named[657]: the working directory is not writable >> That is a quaint reminder of a simpler time. > > [skip] > >> Also, I'm not sure whether you've actually looked at the default >> named.conf or not, but the two most common files that someone would >> want to write are the dump and statistics files, and there are already >> suitable paths for those files provided, and the bind user can >> actually write to them by default. It would be trivial to expand those >> examples to other things that are of particular interest to you. > > The default named.conf contains the following line: > > directory "/etc/namedb"; > > That is "the working directory" which is not writable to bind by default, > hence mentioned line in /var/log/messages. I dislike when default > configuration emits such warnings. So I decided to make it writable > in hope this setup will save me from future problems while still secure. > > Eugene Grosbein > _______________________________________________ Hello, I like the unwriteable /etc/namedb directory for bind, so that one is "forced" to create directories for bind, which it has write access to. You do not want to clobber the /etc/namedb directory with files (imo) ;) Cheers remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From eugen at kuzbass.ru Mon Aug 4 09:09:53 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Aug 4 09:09:59 2008 Subject: permissions on /etc/namedb References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> Message-ID: <4896C759.D7FD6E8B@kuzbass.ru> Remko Lodder wrote: > > Should we change our default src/etc/namedb/named.conf in the Repository > > so that named won't warn about unwriteable "working directory"? > > I dont think so.. I think the current default is fine, if you want to > write files to it, then you need to change things, best is to use > seperated directories. Note that you need to change things anyway because > the server listens on localhost by default. So, if you want things > differently; you have to customize it. Sounds like a fair deal to me ;) > (the defaults that is) Perhaps, then there should be a note in a comment for "directory" line about all this stuff and named's warning in the log? This warning may be quite confusing. Eugene Grosbein From smithi at nimnet.asn.au Mon Aug 4 10:57:24 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Aug 4 10:57:31 2008 Subject: permissions on /etc/namedb In-Reply-To: <4896A416.80602@FreeBSD.org> Message-ID: On Sun, 3 Aug 2008, Doug Barton wrote: > Eugene Grosbein wrote: > > On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: [..] > >>> Well, I just want bind be allowed to write to is working directory. > >> I think that your idea of "BIND's working directory" is probably > >> flawed > > > > That's not my idea. From /var/log/messages: > > > > Aug 3 15:02:18 host named[657]: the working directory is not writable > > That is a quaint reminder of a simpler time. It's far better nowadays > to separate the idea of configuration directories and directories that > named should write to. (One could easily make the argument that this > division should have been enforced from the start, and personally I > never liked having named dropping stuff all over my config directory, > but I digress.) In the olden days (bind 4) named.run, named.stats and named_dump.db were all written to /var/tmp .. perhaps because it had the sticky bit set? > >> but if what you want is to make /etc/namedb writable by the > >> bind user and have it persist from boot to boot someone else already > >> told you how to do that, so good luck. > > > > Sigh... I have to study mtree now. > > If it takes you more than 5 minutes, give up. :) > > > And for what reason? Just because the system thinks it knows better what user needs. > > You previously agreed with me that the defaults should be appropriate > for non-expert users, and I would still argue that they are. With the notable exception of making standard functions rndc trace and querylog work, writing to the default file named.run, which named wants to write in 'the working directory'. You'll have seen my solution to that, touching named.run in case it doesn't exist then chown'ing it to bind:wheel in /etc/rc.d/named, which I don't think endangers security. I've not been able to find another solution, and there's no equivalent of dump-file and statistics-file for the trace/querylog file (that I can find) but perhaps you know some way the directory to write this file can be specified in named.conf? Maybe to /var/named/var/log ? > Also, I'm not sure whether you've actually looked at the default > named.conf or not, but the two most common files that someone would > want to write are the dump and statistics files, and there are already > suitable paths for those files provided, and the bind user can > actually write to them by default. It would be trivial to expand those > examples to other things that are of particular interest to you. That's what I thought, but my extensive reading hasn't shown me how to do that for named.run, so I'd appreciate a clue for a better solution. cheers, Ian From bugmaster at FreeBSD.org Mon Aug 4 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:08:21 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200808041106.m74B6wSC082137@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card 98 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard 59 problems total. From eksffa at freebsdbrasil.com.br Mon Aug 4 13:36:29 2008 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Mon Aug 4 13:36:36 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48945A79.50300@wubethiopia.com> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> Message-ID: <48970597.3030407@freebsdbrasil.com.br> Mike Makonnen escreveu: > Mike Makonnen wrote: >> Patrick Tracanelli wrote: >>> >>> To let you know of my current (real world) tests: >>> >>> - Wireless Internet Provider 1: >>> - 4Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> - Classifying 100Mbit/s of dump over ssh >>> >>> Results in: >>> No latency added, very low CPU usage, no packets dropping. >>> >>> - Wireless ISP 2: >>> - 21 Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> >>> Results in: >>> No tcp or udp traffic at all; everything that gets diverted never >>> comes out of the divert socket, and ipfw-classifyd logs >>> >>> Aug 1 12:07:35 ourofino last message repeated 58 times >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella >>> (rule 1000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >>> 50000) >>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>> socket: Operation not permitted >>> Aug 1 12:18:50 ourofino last message repeated 90 times >> >> Hmmm... this part means that the call to sendto(2) to write the packet >> back into network stack failed. This explains why you are not seein g >> any traffic comming back out of the divert socket, but I don't see why >> it would suddenly fail with a permission error. Could this be a kernel >> bug? >>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue >>> full >>> Aug 1 12:19:11 ourofino last message repeated 94 times >>> >>> Raised queue len a lot (up to 40960), when the application starts it >>> uses up to 25% CPU and a second after that, CPU usage gets lower the >>> 0.1%. >> >> This looks like a deadlock. If it weren't able to process packets fast >> enough the cpu usage should be high even as it's spewing "packet >> dropped" messages. Can you send me some more information like memory >> usage and the firewall script you are using? How much of the 21Mbits/s >> of traffic is P2P? If you reduce the number of protocols you are >> trying to match against does the behavior change? Using netstat -w1 >> -I can you tell me how many packets per second we're >> talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the >> log file seem to show that the daemon is running for approx. 34 sec. >> before the first "unable to write to write to divert socket" message. >> Is it passing traffic during this time? Thanks. >> >> I've uploaded a newer version. Can you try that also please. It includes: >> o SIGHUP forces it to re-read its configuration file >> o rc.d script >> o minor optimization (calls pthread_cond_signal with the mutex >> unlocked) >> o code cleanup >> >> Also, for your convenience I have attached a patch against the earlier >> version that removes a debugging printf that should remove spammage to >> your log files (the current version has it removed already). >> > > Ooops, a few minutes after I sent this email I found a couple of bugs > (one major, and one minor). They were in the original tarball as well as > the newer one I uploaded earlier today. I've uploaded a fixed version of > the code. Can you try that instead please. > > Also, to help track down performance issues I've modified the Makefile > to build a profiled version of the application so you can use gprof(1) > to figure out where any problems lie. > > Cheers. > On gcc 3.4.6, -Wno-pointer-sign compiler switch is unknown and therefore compiling fails: cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c classifyd.c cc1: error: unrecognized command line option "-Wno-pointer-sign" *** Error code 1 Stop in /usr/home/setup/ipfw-classifyd. If removed, does compile fine. On amd64 does not compile: cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers -Werror -Wall -Wno- format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer -arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunus ed-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer -sign -fPIC -pipe -c classifyd.c cc1: warnings being treated as errors classifyd.c: In function 'write_pthread': classifyd.c:813: warning: format '%d' expects type 'int', but argument 4 has type 'size_ t' *** Error code 1 The rules Im running: 00001 1379 320702 fwd 192.168.100.11 ip from any to { 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp0 00002 0 0 fwd 192.168.100.11 ip from any to { 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp2 00003 39137 7760042 fwd 189.52.140.1 ip from 189.52.140.10 to any out via fxp0 00004 34462 10801535 fwd 189.52.140.3 ip from 189.52.140.11 to any out via fxp0 00005 68780 29374414 fwd 189.52.140.1 ip from 189.52.140.18 to any out via fxp0 00006 12154 2003678 fwd 189.52.140.3 ip from 189.52.140.19 to any out via fxp0 00500 4741 770166 divert 7777 tcp from any to any via fxp0 00501 172 38599 divert 7777 udp from any to any via fxp0 49999 823215 453482966 allow ip from any to any 65535 0 0 allow ip from any to any Memory usage while running classifyd: Mem: 67M Active, 27M Inact, 44M Wired, 24K Cache, 111M Buf, 859M Free Swap: 1024M Total, 1024M Free classifyd's CPU usage: 5198 root 3 20 0 6132K 5420K kserel 1:14 24.52% ipfw-classifyd System load averga for 5 minutes is 0.2 while not running classifyd and 0.8 while running. Logs with the latest (downloaded a few minutes ago) code: Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule 50000) Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule 50000) Aug 4 10:15:36 ourofino ipfw-classifyd: packet dropped: input queue full Aug 4 10:16:07 ourofino last message repeated 1594 times Aug 4 10:16:19 ourofino last message repeated 766 times I miss the debug lines! ;D # netstat -w1 -I fxp0 input (fxp0) output packets errs bytes packets errs bytes colls 535 0 286009 515 0 165965 0 416 0 347448 456 0 153585 0 444 0 309008 449 0 185087 0 493 0 190090 474 0 202637 0 547 0 197882 562 0 233751 0 409 0 288318 461 0 249421 0 434 0 173193 464 0 261512 0 437 0 246516 450 0 258908 0 458 0 200348 481 0 157800 0 423 0 250006 427 0 97723 0 367 0 261323 349 0 96405 0 592 0 178843 556 0 91032 0 450 0 248174 432 0 112650 0 390 0 244258 349 0 106532 0 442 0 303159 392 0 125664 0 407 0 237804 350 0 84367 0 460 0 207586 456 0 86633 0 364 0 200758 366 0 99798 0 313 0 241031 325 0 85746 0 463 0 248284 470 0 113385 0 With above protocols, wont matter if I run with the default queue len, with -q 4096 or -q 40960. Its always never enough and I get the "input queue full" logs. However, if I remove add only 1 or 2 protocols (tried bittorrend only and later, edonkey only), things do work fine, for a few seconds, but than: Aug 4 10:22:58 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:24:32 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:28:02 ourofino ipfw-classifyd: unable to write to divert socket: Invalid argument Aug 4 10:28:33 ourofino last message repeated 20 times Aug 4 10:29:03 ourofino last message repeated 18 times Aug 4 10:29:05 ourofino kernel: pid 5654 (ipfw-classifyd), uid 0: exited on signal 6 (core dumped) Aug 4 10:30:06 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 4 10:30:08 ourofino ipfw-classifyd: packet dropped: input queue full Aug 4 10:30:09 ourofino last message repeated 186 times Aug 4 10:30:17 ourofino ipfw-classifyd: unable to write to divert socket: Invalid argument Aug 4 10:30:27 ourofino last message repeated 2 times Aug 4 10:32:43 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule 50000) Aug 4 10:33:04 ourofino ipfw-classifyd: unable to write to divert socket: Invalid argument Aug 4 10:33:22 ourofino last message repeated 11 times Aug 4 10:33:23 ourofino kernel: pid 5901 (ipfw-classifyd), uid 0: exited on signal 6 (core dumped) I get the " unable to write to divert socket: Invalid argument" constantly and when classifyd dies (core dump with signal 6) I get the following debug output: Assertion failed: (datalen >= 0), function classify_pthread, file classifyd.c, line 646. What other useful output I can send you? -- Patrick Tracanelli From ady at freebsd.ady.ro Mon Aug 4 13:56:50 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Mon Aug 4 13:56:58 2008 Subject: permissions on /etc/namedb In-Reply-To: References: <4896A416.80602@FreeBSD.org> Message-ID: <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> Hi, On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith wrote: > On Sun, 3 Aug 2008, Doug Barton wrote: > > Eugene Grosbein wrote: > > > On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote: > [..] > > >>> Well, I just want bind be allowed to write to is working directory. > > >> I think that your idea of "BIND's working directory" is probably > > >> flawed > > > > > > That's not my idea. From /var/log/messages: > > > > > > Aug 3 15:02:18 host named[657]: the working directory is not writable > > > > That is a quaint reminder of a simpler time. It's far better nowadays > > to separate the idea of configuration directories and directories that > > named should write to. (One could easily make the argument that this > > division should have been enforced from the start, and personally I > > never liked having named dropping stuff all over my config directory, > > but I digress.) > > In the olden days (bind 4) named.run, named.stats and named_dump.db were > all written to /var/tmp .. perhaps because it had the sticky bit set? > > > >> but if what you want is to make /etc/namedb writable by the > > >> bind user and have it persist from boot to boot someone else already > > >> told you how to do that, so good luck. > > > > > > Sigh... I have to study mtree now. > > > > If it takes you more than 5 minutes, give up. :) > > > > > And for what reason? Just because the system thinks it knows better > what user needs. > > > > You previously agreed with me that the defaults should be appropriate > > for non-expert users, and I would still argue that they are. > > With the notable exception of making standard functions rndc trace and > querylog work, writing to the default file named.run, which named wants > to write in 'the working directory'. You'll have seen my solution to > that, touching named.run in case it doesn't exist then chown'ing it to > bind:wheel in /etc/rc.d/named, which I don't think endangers security. > > I've not been able to find another solution, and there's no equivalent > of dump-file and statistics-file for the trace/querylog file (that I Quoting from a default distributed /etc/namedb/named.conf: options { // Relative to the chroot directory, if any directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; You have to take into account that "directory" is used for any non-absolute pathname specified in named.conf, including the "file" clauses for master/slave zones. If you were to change it now then you would break a lot of setups. I believe that the "working directory" and "root config directory" concepts should have been dissociated. > > can find) but perhaps you know some way the directory to write this > file can be specified in named.conf? Maybe to /var/named/var/log ? > > > Also, I'm not sure whether you've actually looked at the default > > named.conf or not, but the two most common files that someone would > > want to write are the dump and statistics files, and there are already > > suitable paths for those files provided, and the bind user can > > actually write to them by default. It would be trivial to expand those > > examples to other things that are of particular interest to you. > > That's what I thought, but my extensive reading hasn't shown me how to > do that for named.run, so I'd appreciate a clue for a better solution. > Best is to have a sepatate configuration directive for the "working directory" versus "root config directory" assumed by the current "directory" statement. Another idea would be to add a final "options { directory "/var/run/named"; }; " statement at the end of the file -- from the BIND sources it appears that there is a callback function which may pickup this final statement in order to make it the current working directory for the named process. Oh, and in the idea that we should keep the default configuration as simple as possible for the average user and for whatever scenario, here is my proposal: directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/run/named/named_dump.db"; statistics-file "/var/run/named/named.stats"; Now the reasons: - the directory statement should remain the same in order not to break existing "file" functionality for DNS zones; - we should use /var/run/named since this is the single common path available for both chrooted and non-chrooted setups; - rather then dispersing the various output files we should standardize for a single common output location I'm not sure what happens when the user toggles tracing / query logging (with rndc) -- where would these files go by default ? My 2cents, Adrian. From dougb at FreeBSD.org Mon Aug 4 18:46:22 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 4 18:46:30 2008 Subject: permissions on /etc/namedb In-Reply-To: <4896C374.803@psg.com> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> <20080804084833.GA35267@svzserv.kemerovo.su> <4896C374.803@psg.com> Message-ID: <48974E7B.5050401@FreeBSD.org> Randy Bush wrote: > my fix to all this has been > /usr/ports/dns/unbound (cache only) > or > /usr/ports/dns/nsd (auth only) > > and the developers/porters are constructive and friendly Oddly enough I think of myself as constructive and friendly. :) However I can't make a default configuration that fits everyone's needs. I can only do what I can to make it safe by default. Of course the two alternatives you listed are good ones, and I encourage my clients to investigate them for their environments even if they continue using BIND since IMO diversity is a good thing, helps improve resilience, etc. Doug -- This .signature sanitized for your protection From dougb at FreeBSD.org Mon Aug 4 18:50:16 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 4 18:50:22 2008 Subject: permissions on /etc/namedb In-Reply-To: <20080804075510.GA28531@svzserv.kemerovo.su> References: <20080803073803.GA10321@grosbein.pp.ru> <4895EB57.2000801@FreeBSD.org> <20080803183346.GA53252@svzserv.kemerovo.su> <4896997D.8060001@FreeBSD.org> <20080804060658.GA19639@svzserv.kemerovo.su> <4896A416.80602@FreeBSD.org> <20080804075510.GA28531@svzserv.kemerovo.su> Message-ID: <48974F65.7050301@FreeBSD.org> Eugene Grosbein wrote: > On Sun, Aug 03, 2008 at 11:39:18PM -0700, Doug Barton wrote: > >>>>>>> I need /etc/namedb to be owned by root:bind and have permissions 01775, Fair enough, I misread that bit. Sorry for the confusion. I will (once again) return to my point that while I do not think what you are proposing is an appropriate default, you have the tools to do what you want to do, so good luck with it. -- This .signature sanitized for your protection From DarkStone at mu.com Mon Aug 4 21:46:26 2008 From: DarkStone at mu.com (DarkStone MuOnline Server) Date: Mon Aug 4 21:46:36 2008 Subject: DarkStone MuOnline Server Challenge you To a Duel. Message-ID: <200808042109.m74L9BR15139@www.377963.com> [votenew.jpg] _________________________________________________________________ [pixel.gif] www.darkstonemu.net [pixel.gif] [pixel.gif] [pixel.gif] [pixel.gif] [muonlinedarkstoneadv256vo4.gif] DarkStone MuOnline DarkStone MU Online is a MMORPG that takes the player, into a fantasy world full of excitement, adventure and monsters. With several ways to train a character, multiple character classes, and a vast continent to explore, GMO is a sure way to a unique adventure. Join thousands of players from all over the world and help defend the Continent of Legend, clearing it from the clenches of Kundun and his forces forever. . With new content and features being introduced regularly, this game is perfect for those looking for an exciting MMO experience. [pixel.gif] [pixel.gif] [pixel.gif] You start off as a Dark Wizard, a Dark Knight, Dark Lord, Magic GLadiator, a Summoner or a Fairy Elf, with accordant strengths and weaknesses. You can save different base characters, a fun feature that allows you to begin play as a wizard, and later, restart and switch to a knight--but not both at the same time. The look of your character changes to reflect any new accoutrements you get, including wings and spells. There's also a coordinate system on display, so it's easier to move around the elaborate MU world. Items can be combined in many different ways, but more game experience gets you better gear. You can even fight other players, but be warned: if you kill too many innocents, you'll be branded a murderer. Server Stats: ON * Experience: 1000x * Drops: 80% * Reset Level: 399 keep stats * Shops: +7 items. (you have to find some shops for the good items.) * Bless Bug On * Register: http://www.darkstonemu.net/DarkStone-Register.html * Download: http://www.darkstonemu.net/DarkStone-Downloads.html Official Game Installer: http://darkstonemu.net/Download/DarkStoneMu.exe In order to play free just enter your [1]Site and download the [2]Client. We encourage you to visit the DarkStone MU Online forums at [3]http://darkstonemu.net/ _________________________________________________________________ *Please do not respond to this e-mail as your reply will not be received. References 1. http://www.darkstonemu.net/DarkStone-Register.html 2. http://www.darkstonemu.net/DarkStone-Downloads.html 3. http://www.craiova-online.ro/rds-mu-server-212/ From dcornejo at gmail.com Mon Aug 4 22:40:57 2008 From: dcornejo at gmail.com (David Cornejo) Date: Mon Aug 4 22:41:03 2008 Subject: bridging wireless station Message-ID: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> hi, i would like to bridge a wireless client to ethernet (in 8-CURRENT) - the last bug in the if_bridge man page says this is a no-no. the question is whether this could be worked around - don't need the highest performance, so maybe netgraph or even a userland daemon would work. i don't have any ability to do anything at the access point end so some of the tunneling protocols are out any thoughts are appreciated, thanks, From sam at freebsd.org Mon Aug 4 22:48:08 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Aug 4 22:48:14 2008 Subject: bridging wireless station In-Reply-To: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> Message-ID: <48978726.3060501@freebsd.org> David Cornejo wrote: > hi, > > i would like to bridge a wireless client to ethernet (in 8-CURRENT) - > the last bug in the if_bridge man page says this is a no-no. > > the question is whether this could be worked around - don't need the > highest performance, so maybe netgraph or even a userland daemon would > work. i don't have any ability to do anything at the access point end > so some of the tunneling protocols are out > > any thoughts are appreciated, > > The man page is out of date; HEAD has WDS support now so you can bridge traffic that's 4-address encapsulated. You might try to be more clear what you're trying to setup. Sam From thompsa at FreeBSD.org Mon Aug 4 22:58:47 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Aug 4 22:58:53 2008 Subject: bridging wireless station In-Reply-To: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> Message-ID: <20080804225840.GC6737@citylink.fud.org.nz> On Mon, Aug 04, 2008 at 12:13:09PM -1000, David Cornejo wrote: > hi, > > i would like to bridge a wireless client to ethernet (in 8-CURRENT) - > the last bug in the if_bridge man page says this is a no-no. The bridge man page needs to be updated as its possible to do this now. > the question is whether this could be worked around - don't need the > highest performance, so maybe netgraph or even a userland daemon would > work. i don't have any ability to do anything at the access point end > so some of the tunneling protocols are out The system supports wdslegacy and dwds modes. lecacy takes a static bssid address to forward the traffic to, this mode can only be encrypted with wep. dwds is a unique feature where the card connects as a standard station (with any crypto, such as wpa), and then is set into wds mode. This isnt hooked into the system scripts at all and needs to be finished off. Have a look at tools/tools/net80211/scripts/setup.wds* and try some scenarios out. Andrew From dougb at FreeBSD.org Mon Aug 4 22:59:17 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 4 22:59:26 2008 Subject: permissions on /etc/namedb In-Reply-To: <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> References: <4896A416.80602@FreeBSD.org> <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> Message-ID: <489789C1.1040509@FreeBSD.org> Adrian Penisoara wrote: > Hi, > > On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith > wrote: > With the notable exception of making standard functions rndc trace and > querylog work, writing to the default file named.run, which named wants > to write in 'the working directory'. You'll have seen my solution to > that, touching named.run in case it doesn't exist then chown'ing it to > bind:wheel in /etc/rc.d/named, which I don't think endangers security. I think that is a reasonable solution for your situation, although I don't think it's appropriate to enable that by default. The default configuration is supposed to be a simple local resolver setup. Users who need more advanced features should be reading the docs. > I've not been able to find another solution, and there's no equivalent > of dump-file and statistics-file for the trace/querylog file (that I Query logging has its own log category, so you would do something like this: logging { channel queries_log { file "/var/log/queries.log"; severity debug; print-time yes; }; category queries { queries_log; }; }; The problem is that if you put that in your named.conf file it will log all queries when you start named. If there is interest I can add that to the default named.conf and add a knob to rc.conf to turn query logging on and off by default, but I'm hesitant to add that much complexity to something that is supposed to be simple but is already too complex. OTOH, one could argue that even for a local resolver there would be a non-trivial number of users who would want to enable logging of queries ... As for the equivalent functionality for the debug aspect of named.run, you're right, there is no equivalent. (FYI, the fact that queries are recorded in named.run when you bump the debug level is a side effect of the fact that queries are logged to the resolver category at debug level 1.) The problem is that the default_debug channel has a special property (only receives input when debug level is > 0) that cannot be reproduced with configuration options, and you cannot redefine the default logging channels. (but see below) > Quoting from a default distributed /etc/namedb/named.conf: > > options { > // Relative to the chroot directory, if any > directory "/etc/namedb"; > pid-file "/var/run/named/pid"; > dump-file "/var/dump/named_dump.db"; > statistics-file "/var/stats/named.stats"; > > You have to take into account that "directory" is used for any > non-absolute pathname specified in named.conf, including the "file" > clauses for master/slave zones. If you were to change it now then you > would break a lot of setups. Agreed. > I believe that the "working directory" and "root config directory" > concepts should have been dissociated. Also agreed. :) I plan to send some feature requests to the bind-users list based on the discussions in this thread. If you're interested in this topic I'd suggest that you follow the discussion on that list. I have an (unreviewed) patch to add a debug-only option at http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to experiment with this. Using that patch I was able to do this: logging { channel our_debug { file "/var/log/named.run"; severity dynamic; print-time yes; debug-only yes; }; category default { default_syslog; our_debug; }; category unmatched { null; }; }; Which duplicates the default logging configuration except that you can now specify the location for the named.run file (or give it another file name, etc.). > Another idea would be to add a final "options { directory > "/var/run/named"; }; " statement at the end of the file -- from the BIND > sources it appears that there is a callback function which may pickup > this final statement in order to make it the current working directory > for the named process. The problem is that when you do a reconfig or a reload named won't be able to see its configuration file. > Oh, and in the idea that we should keep the default configuration as > simple as possible for the average user and for whatever scenario, here > is my proposal: > > dump-file "/var/run/named/named_dump.db"; > statistics-file "/var/run/named/named.stats"; This idea is not without merit, but I actually have them separated for a reason. The reason is sort of an "intermediate" level thing, but if you want to dump the db or the stats more than once and keep more than one version around it's more convenient to do this in a separate directory. Also the assumption is that /var/run is supposed to be cleaned out at each boot, and I wouldn't want to lose those files. > I'm not sure what happens when the user toggles tracing / query > logging (with rndc) -- where would these files go by default ? That depends on how you have syslog configured. If you have no other logging configured and you do 'rndc querylog' to toggle it on it will go to syslog with daemon.info. Unfortunately, FreeBSD's default configuration doesn't log that by default. One could argue that it should, but I really don't want to open that can of worms. If you want to give that a try you could change *.notice in syslog.conf for the /var/log/messages file to *.info, then /etc/rc.d/syslogd restart. (Or uncomment the all.log option, etc.) hth, Doug -- This .signature sanitized for your protection From sam at freebsd.org Tue Aug 5 00:01:36 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Aug 5 00:01:43 2008 Subject: bridging wireless station In-Reply-To: <20080804225840.GC6737@citylink.fud.org.nz> References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> <20080804225840.GC6737@citylink.fud.org.nz> Message-ID: <4897985F.2030903@freebsd.org> Andrew Thompson wrote: > On Mon, Aug 04, 2008 at 12:13:09PM -1000, David Cornejo wrote: > >> hi, >> >> i would like to bridge a wireless client to ethernet (in 8-CURRENT) - >> the last bug in the if_bridge man page says this is a no-no. >> > > The bridge man page needs to be updated as its possible to do this now. > > >> the question is whether this could be worked around - don't need the >> highest performance, so maybe netgraph or even a userland daemon would >> work. i don't have any ability to do anything at the access point end >> so some of the tunneling protocols are out >> > > The system supports wdslegacy and dwds modes. lecacy takes a static > bssid address to forward the traffic to, this mode can only be encrypted > with wep. > > dwds is a unique feature where the card connects as a standard station > (with any crypto, such as wpa), and then is set into wds mode. This > isnt hooked into the system scripts at all and needs to be finished off. > > Have a look at tools/tools/net80211/scripts/setup.wds* and try some > scenarios out. > A nit: dwds probably needs to be integrated with hostapd as there's some work involved that's best in a long-running application and I can't imagine anyone using it w/o some form of security. Having hostapd handle this would also simplify configuration. The integration work is straightforward and would be a good project for someone trying to learn about the wireless facilities. Sam From dcornejo at gmail.com Tue Aug 5 00:17:18 2008 From: dcornejo at gmail.com (David Cornejo) Date: Tue Aug 5 00:17:25 2008 Subject: bridging wireless station In-Reply-To: <48978726.3060501@freebsd.org> References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> <48978726.3060501@freebsd.org> Message-ID: <6b8e8f4f0808041717y1176d69ejc37b170f12349fe6@mail.gmail.com> I have an existing AP that I have no control over (assume it doesn't support WDS) sitting on a clinic LAN. I have a second LAN that I need to bridge to the clinic LAN through a client wireless device. I had done this about a year ago using vtun (via an 'ethernet' tunnel), but then I had some control over the AP. thanks, dave c On Mon, Aug 4, 2008 at 12:48 PM, Sam Leffler wrote: > David Cornejo wrote: >> >> hi, >> >> i would like to bridge a wireless client to ethernet (in 8-CURRENT) - >> the last bug in the if_bridge man page says this is a no-no. >> >> the question is whether this could be worked around - don't need the >> highest performance, so maybe netgraph or even a userland daemon would >> work. i don't have any ability to do anything at the access point end >> so some of the tunneling protocols are out >> >> any thoughts are appreciated, >> >> > > The man page is out of date; HEAD has WDS support now so you can bridge > traffic that's 4-address encapsulated. You might try to be more clear what > you're trying to setup. > > Sam > > From ady at freebsd.ady.ro Tue Aug 5 00:22:27 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Tue Aug 5 00:22:35 2008 Subject: permissions on /etc/namedb In-Reply-To: <489789C1.1040509@FreeBSD.org> References: <4896A416.80602@FreeBSD.org> <78cb3d3f0808040630o7ad311a5r6da8f821d2bfe63a@mail.gmail.com> <489789C1.1040509@FreeBSD.org> Message-ID: <78cb3d3f0808041722qda84514j9f480860152215aa@mail.gmail.com> Hi, On Tue, Aug 5, 2008 at 12:59 AM, Doug Barton wrote: > > Adrian Penisoara wrote: >> >> Quoting from a default distributed /etc/namedb/named.conf: >> >> options { >> // Relative to the chroot directory, if any >> directory "/etc/namedb"; >> pid-file "/var/run/named/pid"; >> dump-file "/var/dump/named_dump.db"; >> statistics-file "/var/stats/named.stats"; >> >> You have to take into account that "directory" is used for any non-absolute pathname specified in named.conf, including the "file" clauses for master/slave zones. If you were to change it now then you would break a lot of setups. > > Agreed. > >> I believe that the "working directory" and "root config directory" concepts should have been dissociated. > > Also agreed. :) I plan to send some feature requests to the bind-users list based on the discussions in this thread. If you're interested in this topic I'd suggest that you follow the discussion on that list. I will try to :). > > I have an (unreviewed) patch to add a debug-only option at http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to experiment with this. Using that patch I was able to do this: > > logging { > channel our_debug { > file "/var/log/named.run"; > severity dynamic; > print-time yes; > debug-only yes; > }; > category default { default_syslog; our_debug; }; > category unmatched { null; }; > }; > > Which duplicates the default logging configuration except that you can now specify the location for the named.run file (or give it another file name, etc.). > >> Another idea would be to add a final "options { directory "/var/run/named"; }; " statement at the end of the file -- from the BIND sources it appears that there is a callback function which may pickup this final statement in order to make it the current working directory for the named process. > > The problem is that when you do a reconfig or a reload named won't be able to see its configuration file. > >> Oh, and in the idea that we should keep the default configuration as simple as possible for the average user and for whatever scenario, here is my proposal: >> >> dump-file "/var/run/named/named_dump.db"; >> statistics-file "/var/run/named/named.stats"; > > This idea is not without merit, but I actually have them separated for a reason. The reason is sort of an "intermediate" level thing, but if you want to dump the db or the stats more than once and keep more than one version around it's more convenient to do this in a separate directory. Also the assumption is that /var/run is supposed to be cleaned out at each boot, and I wouldn't want to lose those files. Yep, you've got a point here. > >> I'm not sure what happens when the user toggles tracing / query logging (with rndc) -- where would these files go by default ? > > That depends on how you have syslog configured. If you have no other logging configured and you do 'rndc querylog' to toggle it on it will go to syslog with daemon.info. Unfortunately, FreeBSD's default configuration doesn't log that by default. One could argue that it should, but I really don't want to open that can of worms. If you want to give that a try you could change *.notice in syslog.conf for the /var/log/messages file to *.info, then /etc/rc.d/syslogd restart. (Or uncomment the all.log option, etc.) Umm, I'd rather add something along the following to /etc/syslog.conf (I usually do it for my nameservers): !named *.* /var/log/named.log And of course, one would accompany this with the following line in /etc/newsyslog.conf: /var/log/named.log 644 7 100 * J Regards, Adrian. From sam at freebsd.org Tue Aug 5 00:24:34 2008 From: sam at freebsd.org (Sam Leffler) Date: Tue Aug 5 00:25:14 2008 Subject: bridging wireless station In-Reply-To: <6b8e8f4f0808041717y1176d69ejc37b170f12349fe6@mail.gmail.com> References: <6b8e8f4f0808041513x2537c723vd575f0760cf53e02@mail.gmail.com> <48978726.3060501@freebsd.org> <6b8e8f4f0808041717y1176d69ejc37b170f12349fe6@mail.gmail.com> Message-ID: <48979DC1.3040402@freebsd.org> Without WDS you'll need to bridge/tunnel at a different layer. Sam David Cornejo wrote: > I have an existing AP that I have no control over (assume it doesn't > support WDS) sitting on a clinic LAN. I have a second LAN that I need > to bridge to the clinic LAN through a client wireless device. I had > done this about a year ago using vtun (via an 'ethernet' tunnel), but > then I had some control over the AP. > > thanks, > dave c > > On Mon, Aug 4, 2008 at 12:48 PM, Sam Leffler wrote: >> David Cornejo wrote: >>> hi, >>> >>> i would like to bridge a wireless client to ethernet (in 8-CURRENT) - >>> the last bug in the if_bridge man page says this is a no-no. >>> >>> the question is whether this could be worked around - don't need the >>> highest performance, so maybe netgraph or even a userland daemon would >>> work. i don't have any ability to do anything at the access point end >>> so some of the tunneling protocols are out >>> >>> any thoughts are appreciated, >>> >>> >> The man page is out of date; HEAD has WDS support now so you can bridge >> traffic that's 4-address encapsulated. You might try to be more clear what >> you're trying to setup. >> >> Sam >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From bilouro at bilouro.com Tue Aug 5 04:21:32 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Tue Aug 5 04:21:45 2008 Subject: [GSoC - tcptest] Weekly Status Report #03 Message-ID: Hi People, I posted the tcptest weekly status report at freebsd wiki. http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_3 Other Links: http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite http://code.google.com/p/tcptest/downloads/list http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro_tcptest/src/scripts/tests -- Victor Hugo Bilouro FreeBSD! From viper at ertelecom.ru Tue Aug 5 08:43:53 2008 From: viper at ertelecom.ru (=?UTF-8?B?0JrQvtGA0LrQvtC00LjQvdC+0LIg0JLQu9Cw0LTQuNC80LjRgA==?=) Date: Tue Aug 5 08:44:01 2008 Subject: arp - strange things In-Reply-To: References: Message-ID: <48980FF1.3090308@ertelecom.ru> I csup my server from Jul 14 to today sources and saw strange issue with arp table. Long description see below. Do you have the same "issue" on your own servers? Partial reverting? [1]http://www.freebsd.org/cgi/cvsweb.cgi /src/sys/netinet/if_ether.c Revision 1.162.2.2 seems fix problem. #if 0 /* -current */ ? ?/* Only call this once */ ?? ? ? ? ? ? ? ? if (firstpa ?? ? ? ? ? ? ? ? ? ? EVENTHANDLER_INVOKE(route_arp_update_event, rt, ?? ? ? ? ? ? ? ? ? ? *)&sin); ? ? ? ? ? ? ? ? } #endif Long description Environment: uname -a FreeBSD monitor 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug? 5 13:15:2 root@monitor:/usr/obj/usr/src/sys/kern Description: arp -an ? (10.100.8.118) at 00:1c:c4:3d:f0:b8 on bce1 [ethernet] ? (10.100.8.118) at (incomplete) on bce1 [ethernet] ............. ? (10.100.10.190) at 00:1a:4b:dd:84:a0 on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ................ ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] [ethernet] [ethernet] route monitor got message of size 296 on Tue Aug? 5 14:08:23 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:? inits: sockaddrs: ?10.100.10.190? bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug? 5 14:09:11 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:? inits: sockaddrs: ?10.100.10.190? bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug? 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:? inits: sockaddrs: ?10.100.10.190? bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug? 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:? inits: sockaddrs: ?10.100.10.190? bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug? 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:? inits: sockaddrs: ?10.100.10.190? bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug? 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks:? inits: sockaddrs: ?10.100.10.190? bce1:0.1e.b.91.15.6 10.100.200.120 -- References 1. 3D"http://www.freebsd.org/cgi/cvs From viper at perm.raid.ru Tue Aug 5 09:23:48 2008 From: viper at perm.raid.ru (Vladimir Korkodinov) Date: Tue Aug 5 09:23:55 2008 Subject: (no subject) Message-ID: <17499.212.33.232.121.1217925622.squirrel@mail.raid.ru> I csup my server from Jul 14 to today sources and saw strange issue with arp table. Long description see below. Do you have the same "issue" on your own servers? Partial reverting http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c Revision 1.162.2.2 seems fix problem. +#if 0 /* -current */ /* Only call this once */ if (firstpass) { sin.sin_addr.s_addr = isaddr.s_addr; EVENTHANDLER_INVOKE(route_arp_update_event, rt, ar_sha(ah), (struct sockaddr *)&sin); } +#endif Long description: Environment: uname -a FreeBSD monitor 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug 5 13:15:24 YEKST 2008 root@monitor:/usr/obj/usr/src/sys/kernel amd64 Description: arp -an ? (10.100.8.118) at 00:1c:c4:3d:f0:b8 on bce1 [ethernet] ? (10.100.8.118) at (incomplete) on bce1 [ethernet] ............. ? (10.100.10.190) at 00:1a:4b:dd:84:a0 on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ................ ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent [ethernet] route monitor got message of size 296 on Tue Aug 5 14:08:23 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:11 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:12 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 got message of size 296 on Tue Aug 5 14:09:17 2008 RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 -- Best regards Vladimir Korkodinov From proks at logos.sky.od.ua Tue Aug 5 16:12:19 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Tue Aug 5 16:12:25 2008 Subject: ipfw nat/natd Message-ID: <20080805191158.F31591@logos.sky.od.ua> I have a problem at the scheme: ( gw ) <-----> ( nat_router ) <-----> ( https ) real.ip0 real.ip1 10.19.90.1 10.19.90.2 If I use ipfw+natd on nat_router then redirect to https server and to nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to nat_router local address is fail. This is bug ? ipfw+nat schema - on nat_router - ipfw rules ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \ redirect_port tcp 10.19.90.2:443 443 ipfw add 500 nat 1 log ip from any to any via vlan2 // nat - iperf -s -p 5000 - on gw - iperf -p 5000 -c real.ip1 tcpdump -np -i vlan2 host real.ip0 18:36:08.170034 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:08.170093 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.170239 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.208523 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:11.208554 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.208712 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.448772 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:14.448802 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.449225 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.689771 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:17.689801 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.689736 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.944763 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:20.944794 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:23.945252 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 Thanks all! From proks at logos.sky.od.ua Tue Aug 5 16:15:27 2008 From: proks at logos.sky.od.ua (Prokofiev S.P.) Date: Tue Aug 5 16:15:45 2008 Subject: ipfw nat/natd Message-ID: <20080805181839.T23842@logos.sky.od.ua> I have a problem at the scheme: ( gw ) <-----> ( nat_router ) <-----> ( https ) real.ip0 real.ip1 10.19.90.1 10.19.90.2 If I use ipfw+natd on nat_router then redirect to https server and to nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to nat_router local address is fail. This is bug ? ipfw+nat schema - on nat_router - ipfw rules ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \ redirect_port tcp 10.19.90.2:443 443 ipfw add 500 nat 1 log ip from any to any via vlan2 // nat - iperf -s -p 5000 - on gw - iperf -p 5000 -c real.ip1 tcpdump -np -i vlan2 host real.ip0 18:36:08.170034 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:08.170093 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.170239 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:11.208523 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:11.208554 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.208712 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:14.448772 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:14.448802 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.449225 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:17.689771 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:17.689801 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.689736 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:20.944763 IP real.ip0.60950 > real.ip1.5000: S 3167071663:3167071663(0) win 65535 18:36:20.944794 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 18:36:23.945252 IP real.ip1.5000 > real.ip0.60950: S 655190881:655190881(0) ack 3167071664 win 65535 Thanks all! From atkin901 at yahoo.com Tue Aug 5 16:15:37 2008 From: atkin901 at yahoo.com (Mark Atkinson) Date: Tue Aug 5 16:15:45 2008 Subject: [GSoC - tcptest] Weekly Status Report #03 References: Message-ID: Victor Hugo Bilouro wrote: > Hi People, > > I posted the tcptest weekly status report at freebsd wiki. > > http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_3 > > Other Links: > http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite > http://code.google.com/p/tcptest/downloads/list > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro_tcptest/src/scripts/tests > Keep up the good work. Your package seems to be missing the psuedoipv4.py file/class however, and it's not in the ports/net/py-pcs port either. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From smithi at nimnet.asn.au Tue Aug 5 17:25:21 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Aug 5 17:25:29 2008 Subject: permissions on /etc/namedb In-Reply-To: <489789C1.1040509@FreeBSD.org> Message-ID: On Mon, 4 Aug 2008, Doug Barton wrote: > Adrian Penisoara wrote: > > On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith > > wrote: > > With the notable exception of making standard functions rndc trace and > > querylog work, writing to the default file named.run, which named wants > > to write in 'the working directory'. You'll have seen my solution to > > that, touching named.run in case it doesn't exist then chown'ing it to > > bind:wheel in /etc/rc.d/named, which I don't think endangers security. > > I think that is a reasonable solution for your situation, although I > don't think it's appropriate to enable that by default. The default > configuration is supposed to be a simple local resolver setup. Users > who need more advanced features should be reading the docs. Over and over :) I've *almost* got my head around the logging section, after initially resisting the idea of using rndc trace being 'advanced'. > > I've not been able to find another solution, and there's no equivalent > > of dump-file and statistics-file for the trace/querylog file (that I > > Query logging has its own log category, so you would do something like > this: > > logging { > channel queries_log { > file "/var/log/queries.log"; > severity debug; print-time yes; > }; > category queries { queries_log; }; > }; > > The problem is that if you put that in your named.conf file it will > log all queries when you start named. If there is interest I can add > that to the default named.conf and add a knob to rc.conf to turn query > logging on and off by default, but I'm hesitant to add that much Even with option 'querylog no' in .conf? Anyhow, manageable with rndc. > complexity to something that is supposed to be simple but is already > too complex. OTOH, one could argue that even for a local resolver > there would be a non-trivial number of users who would want to enable > logging of queries ... I was starting to wonder if I was the only one who ever used it, though only wanting it on when and as required. Same with debug logging; I'm finding it really handy just now, checking a new setup for a handful of auth zones, but wouldn't usually want to know except during 'issues'. > As for the equivalent functionality for the debug aspect of named.run, > you're right, there is no equivalent. (FYI, the fact that queries are > recorded in named.run when you bump the debug level is a side effect > of the fact that queries are logged to the resolver category at debug > level 1.) The problem is that the default_debug channel has a special > property (only receives input when debug level is > 0) that cannot be > reproduced with configuration options, and you cannot redefine the > default logging channels. (but see below) Funny thing is, you can redefine these, modulo the exception below, despite what the ARM says. Late last night, before reading this from you this morning, I'd found http://www.cymru.com/Documents/secure-bind-template.html showing redefining the default_syslog channel, amidst a useful example of using channels and categories - where I find the ARM a wee bit terse - so I thought, why not try: logging { channel default_debug { file "/var/log/named.run"; severity dynamic; print-time yes; print-category yes; // education .. print-severity yes; // ditto }; category default { default_syslog; default_debug; }; }; which works fine - except as you say, it logs, tolerably minimally, even when notrace / debug level is 0. And using that I'm starting to figure out which debug messages come from which categories at what levels, so it's very useful at the moment, though obviously a gross workaround .. Adrian Penisoara wrote: > > Quoting from a default distributed /etc/namedb/named.conf: > > > > options { > > // Relative to the chroot directory, if any > > directory "/etc/namedb"; > > pid-file "/var/run/named/pid"; > > dump-file "/var/dump/named_dump.db"; > > statistics-file "/var/stats/named.stats"; > > > > You have to take into account that "directory" is used for any > > non-absolute pathname specified in named.conf, including the "file" > > clauses for master/slave zones. If you were to change it now then you > > would break a lot of setups. > > Agreed. > > > I believe that the "working directory" and "root config directory" > > concepts should have been dissociated. > > Also agreed. :) I plan to send some feature requests to the > bind-users list based on the discussions in this thread. If you're > interested in this topic I'd suggest that you follow the discussion on > that list. Wish I had the time, maybe next month. If there were a 'logdirectory' option, defaulting to 'directory' as now, that would solve this whole POLA issue for stragglers from bind 4 and others expecting debug and query logging to work as per rndc(8) in an out-of-the-box setup. > I have an (unreviewed) patch to add a debug-only option at > http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to > experiment with this. Using that patch I was able to do this: > > logging { > channel our_debug { > file "/var/log/named.run"; > severity dynamic; > print-time yes; > debug-only yes; > }; > category default { default_syslog; our_debug; }; > category unmatched { null; }; > }; > > Which duplicates the default logging configuration except that you can > now specify the location for the named.run file (or give it another > file name, etc.). So debug-only would give the same functionality as that default_debug special property (log if trace > 0) to other channels as desired, right? > > Another idea would be to add a final "options { directory > > "/var/run/named"; }; " statement at the end of the file -- from the BIND > > sources it appears that there is a callback function which may pickup > > this final statement in order to make it the current working directory > > for the named process. > > The problem is that when you do a reconfig or a reload named won't be > able to see its configuration file. > > > Oh, and in the idea that we should keep the default configuration as > > simple as possible for the average user and for whatever scenario, here > > is my proposal: > > > > dump-file "/var/run/named/named_dump.db"; > > statistics-file "/var/run/named/named.stats"; > > This idea is not without merit, but I actually have them separated for > a reason. The reason is sort of an "intermediate" level thing, but if > you want to dump the db or the stats more than once and keep more than > one version around it's more convenient to do this in a separate > directory. Also the assumption is that /var/run is supposed to be > cleaned out at each boot, and I wouldn't want to lose those files. Well I'm comfortable with the directory setup as is, only excepting the desire expressed here for somewhere standard as supplied that bind can write its other log files to. So far I only know about named.run and named.recursing (which I also tried, because it was there :) > > I'm not sure what happens when the user toggles tracing / query > > logging (with rndc) -- where would these files go by default ? Currently, named tries to open named.run in its 'working directory', ie directory "[/var/named]/etc/namedb" by default, owned by root. Try 'rndc trace' and tail /var/log/messages and you may see "isc_log_open 'named.run' failed: permission denied" ono, at bind 9.3.4-P1 anyway. > That depends on how you have syslog configured. If you have no other > logging configured and you do 'rndc querylog' to toggle it on it will > go to syslog with daemon.info. Unfortunately, FreeBSD's default > configuration doesn't log that by default. One could argue that it > should, but I really don't want to open that can of worms. If you want > to give that a try you could change *.notice in syslog.conf for the > /var/log/messages file to *.info, then /etc/rc.d/syslogd restart. (Or > uncomment the all.log option, etc.) Scary :) Thanks for the detailed explanations, Doug. Much appreciated. cheers, Ian PS sorry about your direct mail bouncing off our ancient mailserver's antispam (mis)config. To be retired any day now, but fixed anyway. From eksffa at freebsdbrasil.com.br Tue Aug 5 19:51:32 2008 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Tue Aug 5 19:51:39 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48970597.3030407@freebsdbrasil.com.br> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> <48970597.3030407@freebsdbrasil.com.br> Message-ID: <4898AF05.5020505@freebsdbrasil.com.br> Patrick Tracanelli escreveu: > Mike Makonnen escreveu: >> Mike Makonnen wrote: >>> Patrick Tracanelli wrote: >>>> >>>> To let you know of my current (real world) tests: >>>> >>>> - Wireless Internet Provider 1: >>>> - 4Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> - Classifying 100Mbit/s of dump over ssh >>>> >>>> Results in: >>>> No latency added, very low CPU usage, no packets dropping. >>>> >>>> - Wireless ISP 2: >>>> - 21 Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> >>>> Results in: >>>> No tcp or udp traffic at all; everything that gets diverted >>>> never comes out of the divert socket, and ipfw-classifyd logs >>>> >>>> Aug 1 12:07:35 ourofino last message repeated 58 times >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella >>>> (rule 1000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh >>>> (rule 50000) >>>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>>> socket: Operation not permitted >>>> Aug 1 12:18:50 ourofino last message repeated 90 times >>> >>> Hmmm... this part means that the call to sendto(2) to write the >>> packet back into network stack failed. This explains why you are not >>> seein g any traffic comming back out of the divert socket, but I >>> don't see why it would suddenly fail with a permission error. Could >>> this be a kernel bug? >>>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue >>>> full >>>> Aug 1 12:19:11 ourofino last message repeated 94 times >>>> >>>> Raised queue len a lot (up to 40960), when the application starts it >>>> uses up to 25% CPU and a second after that, CPU usage gets lower the >>>> 0.1%. >>> >>> This looks like a deadlock. If it weren't able to process packets >>> fast enough the cpu usage should be high even as it's spewing "packet >>> dropped" messages. Can you send me some more information like memory >>> usage and the firewall script you are using? How much of the >>> 21Mbits/s of traffic is P2P? If you reduce the number of protocols >>> you are trying to match against does the behavior change? Using >>> netstat -w1 -I can you tell me how many packets per second >>> we're talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps >>> from the log file seem to show that the daemon is running for approx. >>> 34 sec. before the first "unable to write to write to divert socket" >>> message. Is it passing traffic during this time? Thanks. >>> >>> I've uploaded a newer version. Can you try that also please. It >>> includes: >>> o SIGHUP forces it to re-read its configuration file >>> o rc.d script >>> o minor optimization (calls pthread_cond_signal with the mutex >>> unlocked) >>> o code cleanup >>> >>> Also, for your convenience I have attached a patch against the >>> earlier version that removes a debugging printf that should remove >>> spammage to your log files (the current version has it removed already). >>> >> >> Ooops, a few minutes after I sent this email I found a couple of bugs >> (one major, and one minor). They were in the original tarball as well >> as the newer one I uploaded earlier today. I've uploaded a fixed >> version of the code. Can you try that instead please. >> >> Also, to help track down performance issues I've modified the Makefile >> to build a profiled version of the application so you can use gprof(1) >> to figure out where any problems lie. >> >> Cheers. >> > > On gcc 3.4.6, -Wno-pointer-sign compiler switch is unknown and > therefore compiling fails: > > cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers > -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align > -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wno-pointer-sign -c classifyd.c > cc1: error: unrecognized command line option "-Wno-pointer-sign" > *** Error code 1 > > Stop in /usr/home/setup/ipfw-classifyd. > > If removed, does compile fine. > > On amd64 does not compile: > > cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -pg -g -Wsystem-headers > -Werror -Wall -Wno- > format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer > -arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wcast-align -Wunus > ed-parameter -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wno-pointer > -sign -fPIC -pipe -c classifyd.c > cc1: warnings being treated as errors > classifyd.c: In function 'write_pthread': > classifyd.c:813: warning: format '%d' expects type 'int', but argument 4 > has type 'size_ > t' > *** Error code 1 > > The rules Im running: > > 00001 1379 320702 fwd 192.168.100.11 ip from any to { > 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp0 > 00002 0 0 fwd 192.168.100.11 ip from any to { > 201.91.17.200/29 or dst-ip 189.44.216.168/29 } out via fxp2 > 00003 39137 7760042 fwd 189.52.140.1 ip from 189.52.140.10 to any out > via fxp0 > 00004 34462 10801535 fwd 189.52.140.3 ip from 189.52.140.11 to any out > via fxp0 > 00005 68780 29374414 fwd 189.52.140.1 ip from 189.52.140.18 to any out > via fxp0 > 00006 12154 2003678 fwd 189.52.140.3 ip from 189.52.140.19 to any out > via fxp0 > 00500 4741 770166 divert 7777 tcp from any to any via fxp0 > 00501 172 38599 divert 7777 udp from any to any via fxp0 > 49999 823215 453482966 allow ip from any to any > 65535 0 0 allow ip from any to any > > Memory usage while running classifyd: > > Mem: 67M Active, 27M Inact, 44M Wired, 24K Cache, 111M Buf, 859M Free > Swap: 1024M Total, 1024M Free > > classifyd's CPU usage: > > 5198 root 3 20 0 6132K 5420K kserel 1:14 24.52% > ipfw-classifyd > > System load averga for 5 minutes is 0.2 while not running classifyd and > 0.8 while running. > > Logs with the latest (downloaded a few minutes ago) code: > > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule > 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: fasttrack > (rule 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule > 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule > 50000) > Aug 4 10:15:29 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule 50000) > Aug 4 10:15:36 ourofino ipfw-classifyd: packet dropped: input queue full > Aug 4 10:16:07 ourofino last message repeated 1594 times > Aug 4 10:16:19 ourofino last message repeated 766 times > > I miss the debug lines! ;D > > # netstat -w1 -I fxp0 > input (fxp0) output > packets errs bytes packets errs bytes colls > 535 0 286009 515 0 165965 0 > 416 0 347448 456 0 153585 0 > 444 0 309008 449 0 185087 0 > 493 0 190090 474 0 202637 0 > 547 0 197882 562 0 233751 0 > 409 0 288318 461 0 249421 0 > 434 0 173193 464 0 261512 0 > 437 0 246516 450 0 258908 0 > 458 0 200348 481 0 157800 0 > 423 0 250006 427 0 97723 0 > 367 0 261323 349 0 96405 0 > 592 0 178843 556 0 91032 0 > 450 0 248174 432 0 112650 0 > 390 0 244258 349 0 106532 0 > 442 0 303159 392 0 125664 0 > 407 0 237804 350 0 84367 0 > 460 0 207586 456 0 86633 0 > 364 0 200758 366 0 99798 0 > 313 0 241031 325 0 85746 0 > 463 0 248284 470 0 113385 0 > > With above protocols, wont matter if I run with the default queue len, > with -q 4096 or -q 40960. Its always never enough and I get the "input > queue full" logs. > > However, if I remove add only 1 or 2 protocols (tried bittorrend only > and later, edonkey only), things do work fine, for a few seconds, but than: > > Aug 4 10:22:58 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:24:32 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:28:02 ourofino ipfw-classifyd: unable to write to divert > socket: Invalid argument > Aug 4 10:28:33 ourofino last message repeated 20 times > Aug 4 10:29:03 ourofino last message repeated 18 times > Aug 4 10:29:05 ourofino kernel: pid 5654 (ipfw-classifyd), uid 0: > exited on signal 6 (core dumped) > Aug 4 10:30:06 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 4 10:30:08 ourofino ipfw-classifyd: packet dropped: input queue full > Aug 4 10:30:09 ourofino last message repeated 186 times > Aug 4 10:30:17 ourofino ipfw-classifyd: unable to write to divert > socket: Invalid argument > Aug 4 10:30:27 ourofino last message repeated 2 times > Aug 4 10:32:43 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule > 50000) > Aug 4 10:33:04 ourofino ipfw-classifyd: unable to write to divert > socket: Invalid argument > Aug 4 10:33:22 ourofino last message repeated 11 times > Aug 4 10:33:23 ourofino kernel: pid 5901 (ipfw-classifyd), uid 0: > exited on signal 6 (core dumped) > > I get the " unable to write to divert socket: Invalid argument" > constantly and when classifyd dies (core dump with signal 6) I get the > following debug output: > > Assertion failed: (datalen >= 0), function classify_pthread, file > classifyd.c, line 646. > > What other useful output I can send you? > I tried figuring out myself some extra clues, but still stucked where I began. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From bilouro at bilouro.com Wed Aug 6 01:21:52 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Wed Aug 6 01:22:01 2008 Subject: [GSoC - tcptest] Weekly Status Report #03 In-Reply-To: References: Message-ID: On Tue, Aug 5, 2008 at 1:15 PM, Mark Atkinson wrote: > Victor Hugo Bilouro wrote: > >> Hi People, >> >> I posted the tcptest weekly status report at freebsd wiki. >> >> http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_3 >> >> Other Links: >> http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite >> http://code.google.com/p/tcptest/downloads/list >> > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro_tcptest/src/scripts/tests >> > > Keep up the good work. Your package seems to be missing the psuedoipv4.py > file/class however, and it's not in the ports/net/py-pcs port either. > > -- > Mark Atkinson > atkin901@yahoo.com > (!wired)?(coffee++):(wired); > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Ohh.. tks! The class psuedoipv4 is on ipv4.py only in my sources ( /src/pcs/... ) There are a changed version of pcs inside my sources, so, copy it to ports work folder and then setup.py. To be true, my version have only few changes merged from the latest version of PCS(gnn repository). Unfortunaly we can't work with the latest version of pcs(from gnn repo) because it don't work with its dependencies of ports right now. We choose work on that after gsoc. Best! -- Victor Hugo Bilouro FreeBSD! From netslists at gmail.com Wed Aug 6 05:15:48 2008 From: netslists at gmail.com (Sten Daniel Soersdal) Date: Wed Aug 6 05:15:55 2008 Subject: ng_ppp: question about "bandwidth" parameter. Message-ID: <48992D64.1020502@gmail.com> Is there a reason NG_PPP_MAX_BANDWIDTH is limited to a total of 10 Mbit? If any of the links are faster than 10 Mbit, will i achieve same end result by dividing Bandwidth by say 10? That is, for every 10 Mbit physical link i configure ng_ppp to 1 Mbit? Or could i change the constant to the equivalent of 100 Mbit/s without the risk of breaking anything? The reason i ask is I noticed in ng_ppp.c (1.70.2.3) in function ng_ppp_mp_strategy(..) that ng_ppp also takes into account queued packets and the additional latency that would implicate. -- Sten Daniel Soersdal From mav at FreeBSD.org Wed Aug 6 06:42:54 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Aug 6 06:43:00 2008 Subject: ng_ppp: question about "bandwidth" parameter. In-Reply-To: <48992D64.1020502@gmail.com> References: <48992D64.1020502@gmail.com> Message-ID: <489947EB.4010606@FreeBSD.org> Sten Daniel Soersdal wrote: > Is there a reason NG_PPP_MAX_BANDWIDTH is limited to a total of 10 Mbit? AFAIR the only reason is 32bit integer math overflow protection. Probably it is the time now to think about 64 bits. > If any of the links are faster than 10 Mbit, will i achieve same end > result by dividing Bandwidth by say 10? That is, for every 10 Mbit > physical link i configure ng_ppp to 1 Mbit? > Or could i change the constant to the equivalent of 100 Mbit/s without > the risk of breaking anything? I am not sure. You should first check value ranges in all math operations. > The reason i ask is I noticed in ng_ppp.c (1.70.2.3) in function > ng_ppp_mp_strategy(..) that ng_ppp also takes into account queued > packets and the additional latency that would implicate. Yes. If you divide all speeds on 10 it will break link queue length calculation. So until traffic will be below specified constants it will work more or less correct. Above it node will think that queues are constantly overflowed and link balancing algorithm will become ineffective. -- Alexander Motin From delphij at delphij.net Wed Aug 6 18:47:17 2008 From: delphij at delphij.net (Xin LI) Date: Wed Aug 6 18:47:25 2008 Subject: Routing: local link vs VPN provided route Message-ID: <4899F1AB.8080409@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We have recently working on an OpenVPN scenario and we have found that when there is a locally linked network, the route provided by OpenVPN would not work: - - Local network uses 192.168.1.0/24 network (thus we have a flags 'UC' route) - - Upon connection, the VPN would provide a route to 192.168.1.0/24 through the tun0 device. It seems, however, that the packets would just go to local network. Is it possible to get packets to non-conflicting IP addresses (i.e. only exist in either local network, or remote VPN'ed network) to go through the tun0 device? (Of course it's possible to configure the remote network or local network as 192.168.0.0/24, just curious about this scenario - do we have a switch or something?) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiZ8asACgkQi+vbBBjt66DNHQCgn1aH3X05XnS1jS4Bf+NWotT8 BhkAoJLDo48H8KNGyHauXvoHjeqEEWiJ =ibIF -----END PGP SIGNATURE----- From wmoran at collaborativefusion.com Wed Aug 6 19:00:42 2008 From: wmoran at collaborativefusion.com (Bill Moran) Date: Wed Aug 6 19:00:49 2008 Subject: Routing: local link vs VPN provided route In-Reply-To: <4899F1AB.8080409@delphij.net> References: <4899F1AB.8080409@delphij.net> Message-ID: <20080806145031.9c94326a.wmoran@collaborativefusion.com> In response to Xin LI : > > We have recently working on an OpenVPN scenario and we have found that > when there is a locally linked network, the route provided by OpenVPN > would not work: > > - - Local network uses 192.168.1.0/24 network (thus we have a flags 'UC' > route) > > - - Upon connection, the VPN would provide a route to 192.168.1.0/24 > through the tun0 device. > > It seems, however, that the packets would just go to local network. Is > it possible to get packets to non-conflicting IP addresses (i.e. only > exist in either local network, or remote VPN'ed network) to go through > the tun0 device? Any hack you would do to make this work is going to be unreliable at best. Renumber your network so that routing can work as designed. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From cswiger at mac.com Wed Aug 6 19:31:41 2008 From: cswiger at mac.com (Chuck Swiger) Date: Wed Aug 6 19:31:48 2008 Subject: Routing: local link vs VPN provided route In-Reply-To: <20080806145031.9c94326a.wmoran@collaborativefusion.com> References: <4899F1AB.8080409@delphij.net> <20080806145031.9c94326a.wmoran@collaborativefusion.com> Message-ID: Hi, all-- On Aug 6, 2008, at 11:50 AM, Bill Moran wrote: >> It seems, however, that the packets would just go to local >> network. Is >> it possible to get packets to non-conflicting IP addresses (i.e. only >> exist in either local network, or remote VPN'ed network) to go >> through >> the tun0 device? > > Any hack you would do to make this work is going to be unreliable at > best. > > Renumber your network so that routing can work as designed. Bill's advice is solid, but there are some other alternatives available. You could set up individual host routes (ie, a route with a /32 netmask) which go over tun0 rather than defaulting to your local ethernet link, for the things you want to access remotely. The other alternative is to set up OpenVPN in bridging mode: http://openvpn.net/index.php/documentation/faq.html#bridge1 http://openvpn.net/index.php/documentation/miscellaneous/ethernet-bridging.html This isn't a recommended configuration for many purposes, as it is more efficient to use explicit routing between subnets when you need to cross the VPN link, rather than simply sending everything over that link as in a bridge, but bridging works better with Samba, ZeroConf/ Bonjour, and other things which use network broadcasts to find things on the "local" subnet. Regards, -- -Chuck From info at tecodryer.com Wed Aug 6 21:20:17 2008 From: info at tecodryer.com (TECO DRYER) Date: Wed Aug 6 21:20:23 2008 Subject: Teco Industry is in the business of corn, wheat, paddy, and Message-ID: <20080806212016.31B2D8FC14@mx1.freebsd.org> vegetable dr Sender: "TECO DRYER" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 7 Aug 2008 00:12:23 +0300 Message-ID: <20080806211223463.59F33D6A56552EF2@erkan-e90bf8060> X-Priority: 3 (Normal) Importance: Normal Teco Industry is in the business of corn, wheat, paddy, and vegetable drying machines and the production and marketing of silo & steel construction. Related to the machines that our company produce; Teco Industry has the representatives in Bulgaria, Albania, Ukraine, Tatarstan, Kazakhstan, Russia, Angola and Indonesia. Our partners in these countries are accepted as the leaders in the steel industry. The quality of produced machines is approved by international standards. Teco is guaranteed by CE and ISO 9001-2000 certificates. Teco also contributes to the national economy by creating jobs in designing, project, production, import and export. Teco materializes R&D activities with its professional staff. Quality results are presented to the customers during the production, import and export. Our company takes the leadership of producing and marketing nationally and internationally. For Grain, Oily Seeds, and Pulses: Silos Corn and Soybean Drying Machines Handling Systems like Bucket Elevator, Chain Conveyor and Helix Prop Towers and Catwalks for Handling Systems Unloading Truck Lifts Industrial Foundations, Steel Construction With the expert staff; we take an important target like ‘’Customer Satisfaction and Service Quality’’ and perform service and counseling duties successfully. -------------------------------------------------------------------------------- Contact Us , Teco Dryer Company is ready for a long partnership with you. Sales Engineer Erkan AYMAN eayman@tecodryer.com From linimon at FreeBSD.org Thu Aug 7 17:24:44 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Aug 7 17:24:55 2008 Subject: kern/126339: [ipw] ipw driver drops the connection Message-ID: <200808071724.m77HOip5017618@freefall.freebsd.org> Old Synopsis: ipw driver drops the connection New Synopsis: [ipw] ipw driver drops the connection Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 7 17:24:05 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126339 From scf at FreeBSD.org Thu Aug 7 23:42:33 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Thu Aug 7 23:42:40 2008 Subject: Problems with first device on bridge Message-ID: On a 7-STABLE (built August 7th), I have noticed messages appearing in /var/log/messages: Aug 7 15:07:17 thor kernel: rtfree: 0xc7143a2c has 2 refs Aug 7 15:07:19 thor last message repeated 2 times Aug 7 15:09:28 thor last message repeated 3 times Aug 7 15:11:54 thor last message repeated 9 times This happens if I set up a bridge to have em0 and tap0 such as from: ifconfig bridge0 create ifconfig bridge0 addm em0 ifconfig bridge0 addm tap0 When I start QEMU on tap0, I would immediately lose IPv6 on em0 and eventually IPv4 would go away. I would get a lot more of messages about rtfree with QEMU started. >From experimentation (and some luck), I found that if I reversed the devices on a newly created bridge then the rtfree messages would go away, but I would have problems with tap0. The workaround: create two tap devices tap0 and tap1 and add to bridge0 in the order of tap1, tap0 and em0. On another system, I noticed that a bridge between real NIC's (em1 and sk0) also reports an rtfree message during boot. Any ideas? Sean -- scf@FreeBSD.org From mo0118 at gmail.com Fri Aug 8 01:37:11 2008 From: mo0118 at gmail.com (Jeff Mo) Date: Fri Aug 8 01:37:18 2008 Subject: Question about "kern/125239: [gre] kernel crash when using gre" Message-ID: Hi Sir, I am trying to dive deeper into the stack frames of the following bug: kern/125239: [gre] kernel crash when using greI use FreeBSD 7.0 and already reproduce it, but I am not sure about what the following sentence means: "ifp=Variable "ifp" is not available"? I will be very thankful if anyone can give me some instruction. Regards Jeff ================== (kgdb) f 7 #7 0xc082263b in in_ifinit (ccc. ) at /usr/src/sys/netinet/in.c:817 817 if (rtinitflags(ia)) { (kgdb) info f Stack level 7, frame at 0xd22f3b58: eip = 0xc082263b in in_ifinit (/usr/src/sys/netinet/in.c:817); saved eip 0xc0823607 called by frame at 0xd22f3bb8, caller of frame at 0xd22f3ad4 source language c. Arglist at 0xd22f3b50, args: ifp=Variable "ifp" is not available. From julian at elischer.org Fri Aug 8 02:32:29 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 8 02:32:37 2008 Subject: Question about "kern/125239: [gre] kernel crash when using gre" In-Reply-To: References: Message-ID: <489BB03C.4080803@elischer.org> Jeff Mo wrote: > Hi Sir, > > I am trying to dive deeper into the stack frames of the following bug: > kern/125239: [gre] kernel crash when using greI use FreeBSD 7.0 and already > reproduce it, but I am not sure about what the following sentence means: > "ifp=Variable "ifp" is not available"? > > I will be very thankful if anyone can give me some instruction. > > Regards > Jeff > > ================== > > (kgdb) f 7 > #7 0xc082263b in in_ifinit (ccc. > ) at /usr/src/sys/netinet/in.c:817 > 817 if (rtinitflags(ia)) { > (kgdb) info f > Stack level 7, frame at 0xd22f3b58: > eip = 0xc082263b in in_ifinit (/usr/src/sys/netinet/in.c:817); > saved eip 0xc0823607 > called by frame at 0xd22f3bb8, caller of frame at 0xd22f3ad4 > source language c. > Arglist at 0xd22f3b50, args: ifp=Variable "ifp" is not available. ifp was in a register and is no longer valid at this point. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From Younger.Wang at packetfront.com Fri Aug 8 06:04:57 2008 From: Younger.Wang at packetfront.com (Younger Wang) Date: Fri Aug 8 06:05:08 2008 Subject: (Netgraph problem) Inner tag and outer tag swapped Message-ID: Hi, fxp0 is connected to a trunk port. Frames tagged with VID=201 arrives at fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, with outer tag = 4000, and inner tag = 201. But in fact, it was received with the outer and inner tags reversed. But if I inject the same frame on hub_c4000, the frame is received at hub_QinQ as expected (inner tag = 201, outer tag = 4000). I am really confused. Has anyone seen the same problem? Big thanks. Here is my netgraph setup: ngctl mkpeer fxp0: hub lower physical ngctl name fxp0:lower hub_c4000 ngctl mkpeer hub_c4000: vlan up vlan4000 ngctl name hub_c4000:up vlan_QinQ ngctl mkpeer vlan_QinQ: hub downstream down0 ngctl name vlan_QinQ:downstream hub_QinQ ngctl msg vlan_QinQ: addfilter { vlan=4000 hook="vlan4000" } BR Younger Wang From rfrench at freebsd.org Fri Aug 8 12:49:16 2008 From: rfrench at freebsd.org (Ryan French) Date: Fri Aug 8 12:49:46 2008 Subject: Probem with protosw Message-ID: <200808090032.53611.rfrench@freebsd.org> Hi, I am working on my implementation of MPLS in FreeBSD and I'm having problems with integrating the code I have ported over into the FreeBSD networking stack. The problem I am having at the moment is trying to get my mpls protocol struct to compile. When I try to build the kernel I get a pr_* undeclared here (not in a function) error, for each field of the struct I have declared. I have included the code just in case anyone is able to figure this out. Thanks, Ryan French #include #include #include #include #include #include #include #include #include #include #include #include /* * MPLS protocol family: */ extern struct domain mplsdomain; struct protosw mplssw[] = { { pr_type = 0, pr_domain = &mplsdomain, pr_init = mpls_init, pr_sysctl = mpls_sysctl }, { pr_type = SOCK_DGRAM, pr_domain = &mplsdomain, pr_flags = PR_ATOMIC | PR_ADDR, pr_usrreq = mpls_raw_usrreq, pr_sysctl = mpls_sysctl }, /* raw wildcard */ { pr_type = SOCK_RAW, pr_domain = &mplsdomain, pr_flags = PR_ATOMIC | PR_ADDR, pr_usrreq = mpls_raw_usrreq, pr_sysctl = mpls_sysctl }, }; struct domain mplsdomain = { NETISR_MPLS, "mpls", mpls_init, 0, 0, mplssw, &mplssw[sizeof(mplssw)/sizeof(mplssw[0])], 0, rn_inithead, offsetof(struct sockaddr_mpls, smpls_in_ifindex) << 3, sizeof(struct sockaddr_mpls) }; From gonzo at freebsd.org Fri Aug 8 13:12:04 2008 From: gonzo at freebsd.org (Oleksandr Tymoshenko) Date: Fri Aug 8 13:12:11 2008 Subject: Probem with protosw In-Reply-To: <200808090032.53611.rfrench@freebsd.org> References: <200808090032.53611.rfrench@freebsd.org> Message-ID: <489C42F9.1030207@freebsd.org> Ryan French wrote: > Hi, > > I am working on my implementation of MPLS in FreeBSD and I'm having problems > with integrating the code I have ported over into the FreeBSD networking > stack. The problem I am having at the moment is trying to get my mpls > protocol struct to compile. When I try to build the kernel I get a pr_* > undeclared here (not in a function) error, for each field of the struct I > have declared. I have included the code just in case anyone is able to figure > this out. Syntax is wrong, there are no dots before pr_. Code should look like: struct protosw mplssw[] = { { .pr_type = 0, .pr_domain = &mplsdomain, .pr_init = mpls_init, .pr_sysctl = mpls_sysctl }, { -- gonzo From Younger.Wang at packetfront.com Fri Aug 8 16:27:19 2008 From: Younger.Wang at packetfront.com (Younger Wang) Date: Fri Aug 8 16:27:26 2008 Subject: (Netgraph problem) Inner tag and outer tag swapped In-Reply-To: <489C0DDA.8040606@elischer.org> References: <489C0DDA.8040606@elischer.org> Message-ID: Hi, I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, but in fact it was [ether header][tag 201][tag 4000][payload]. I inserted the hub because I wanted to sniffer in the segment. It should not cause any problem, should it? The system I run is based on vimage_7-20080228.tgz (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan module modified to support changing ethertype. My modification was made for release 7 however. Yes, the difference between vimage source and release 7 could be the cause. I will check it during the weekend. Big thanks! BR Younger Wang -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org] Sent: Friday, August 08, 2008 5:12 PM To: Younger Wang Subject: Re: (Netgraph problem) Inner tag and outer tag swapped Younger Wang wrote: > Hi, > > > > fxp0 is connected to a trunk port. Frames tagged with VID=201 arrives at > fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, > with outer tag = 4000, and inner tag = 201. But in fact, it was received > with the outer and inner tags reversed. is this what you think is on the wire? [ether header][tag 201][tag 4000][payload] > > > > But if I inject the same frame on hub_c4000, the frame is received at > hub_QinQ as expected (inner tag = 201, outer tag = 4000). I am really > confused. Has anyone seen the same problem? Big thanks. > > > > Here is my netgraph setup: > > > > ngctl mkpeer fxp0: hub lower physical > > ngctl name fxp0:lower hub_c4000 looking at your config.. I see: [hub] down0 | downstream [vlan] vlan4000 | up [hub] <--- why do you need this? physical | lower [ether] what version of FreeBSD? some changes were made in vlan handling in the late6/7 timeframe. > > > > ngctl mkpeer hub_c4000: vlan up vlan4000 > > ngctl name hub_c4000:up vlan_QinQ > > > > ngctl mkpeer vlan_QinQ: hub downstream down0 > > ngctl name vlan_QinQ:downstream hub_QinQ > > > > ngctl msg vlan_QinQ: addfilter { vlan=4000 hook="vlan4000" } > > > > BR > > Younger Wang > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From Younger.Wang at packetfront.com Fri Aug 8 16:36:51 2008 From: Younger.Wang at packetfront.com (Younger Wang) Date: Fri Aug 8 16:36:59 2008 Subject: (Netgraph problem) Inner tag and outer tag swapped In-Reply-To: References: <489C0DDA.8040606@elischer.org> Message-ID: I diffed ng_vlan source between release 7 and vimage_7-20080228. They are identical. I will discard my own modification and try original vimage_7-20080228; if it does not still work, I will roll back to release 7 kernel and try again. Thank you so much for the hints. BR Younger Wang -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Younger Wang Sent: Saturday, August 09, 2008 12:29 AM To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: RE: (Netgraph problem) Inner tag and outer tag swapped Hi, I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, but in fact it was [ether header][tag 201][tag 4000][payload]. I inserted the hub because I wanted to sniffer in the segment. It should not cause any problem, should it? The system I run is based on vimage_7-20080228.tgz (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan module modified to support changing ethertype. My modification was made for release 7 however. Yes, the difference between vimage source and release 7 could be the cause. I will check it during the weekend. Big thanks! BR Younger Wang -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org] Sent: Friday, August 08, 2008 5:12 PM To: Younger Wang Subject: Re: (Netgraph problem) Inner tag and outer tag swapped Younger Wang wrote: > Hi, > > > > fxp0 is connected to a trunk port. Frames tagged with VID=201 arrives at > fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, > with outer tag = 4000, and inner tag = 201. But in fact, it was received > with the outer and inner tags reversed. is this what you think is on the wire? [ether header][tag 201][tag 4000][payload] > > > > But if I inject the same frame on hub_c4000, the frame is received at > hub_QinQ as expected (inner tag = 201, outer tag = 4000). I am really > confused. Has anyone seen the same problem? Big thanks. > > > > Here is my netgraph setup: > > > > ngctl mkpeer fxp0: hub lower physical > > ngctl name fxp0:lower hub_c4000 looking at your config.. I see: [hub] down0 | downstream [vlan] vlan4000 | up [hub] <--- why do you need this? physical | lower [ether] what version of FreeBSD? some changes were made in vlan handling in the late6/7 timeframe. > > > > ngctl mkpeer hub_c4000: vlan up vlan4000 > > ngctl name hub_c4000:up vlan_QinQ > > > > ngctl mkpeer vlan_QinQ: hub downstream down0 > > ngctl name vlan_QinQ:downstream hub_QinQ > > > > ngctl msg vlan_QinQ: addfilter { vlan=4000 hook="vlan4000" } > > > > BR > > Younger Wang > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From Younger.Wang at packetfront.com Fri Aug 8 16:58:59 2008 From: Younger.Wang at packetfront.com (Younger Wang) Date: Fri Aug 8 16:59:06 2008 Subject: (Netgraph problem) Inner tag and outer tag swapped In-Reply-To: References: <489C0DDA.8040606@elischer.org> Message-ID: I have rolled back to release 7 kernel. The problem is still there. The problem is seen only when the single tagged frame ingresses from an ether node. I tested it on bge and fxp cards. If the single tagged frame was injected from an eiface interface, there is no problem. BR Younger Wang -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Younger Wang Sent: Saturday, August 09, 2008 12:29 AM To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: RE: (Netgraph problem) Inner tag and outer tag swapped Hi, I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, but in fact it was [ether header][tag 201][tag 4000][payload]. I inserted the hub because I wanted to sniffer in the segment. It should not cause any problem, should it? The system I run is based on vimage_7-20080228.tgz (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan module modified to support changing ethertype. My modification was made for release 7 however. Yes, the difference between vimage source and release 7 could be the cause. I will check it during the weekend. Big thanks! BR Younger Wang -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org] Sent: Friday, August 08, 2008 5:12 PM To: Younger Wang Subject: Re: (Netgraph problem) Inner tag and outer tag swapped Younger Wang wrote: > Hi, > > > > fxp0 is connected to a trunk port. Frames tagged with VID=201 arrives at > fxp0 from a switch trunk port, I expect it will be captured at hub_QinQ, > with outer tag = 4000, and inner tag = 201. But in fact, it was received > with the outer and inner tags reversed. is this what you think is on the wire? [ether header][tag 201][tag 4000][payload] > > > > But if I inject the same frame on hub_c4000, the frame is received at > hub_QinQ as expected (inner tag = 201, outer tag = 4000). I am really > confused. Has anyone seen the same problem? Big thanks. > > > > Here is my netgraph setup: > > > > ngctl mkpeer fxp0: hub lower physical > > ngctl name fxp0:lower hub_c4000 looking at your config.. I see: [hub] down0 | downstream [vlan] vlan4000 | up [hub] <--- why do you need this? physical | lower [ether] what version of FreeBSD? some changes were made in vlan handling in the late6/7 timeframe. > > > > ngctl mkpeer hub_c4000: vlan up vlan4000 > > ngctl name hub_c4000:up vlan_QinQ > > > > ngctl mkpeer vlan_QinQ: hub downstream down0 > > ngctl name vlan_QinQ:downstream hub_QinQ > > > > ngctl msg vlan_QinQ: addfilter { vlan=4000 hook="vlan4000" } > > > > BR > > Younger Wang > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Fri Aug 8 21:23:44 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 8 21:23:51 2008 Subject: (Netgraph problem) Inner tag and outer tag swapped In-Reply-To: References: <489C0DDA.8040606@elischer.org> Message-ID: <489CB95E.5090202@elischer.org> Younger Wang wrote: > Hi, > > I expect to see [Ether header][tag 4000][tag 201][payload] in hub_QinQ, > but in fact it was [ether header][tag 201][tag 4000][payload]. > > I inserted the hub because I wanted to sniffer in the segment. It should > not cause any problem, should it? probably not.. that is what the 'tee' node is for though. > > The system I run is based on vimage_7-20080228.tgz > (http://imunes.tel.fer.hr/virtnet/), on FreeBSD Release 7, with ng_vlan > module modified to support changing ethertype. My modification was made > for release 7 however. Yes, the difference between vimage source and > release 7 could be the cause. I will check it during the weekend. ok that shouldn't make a difference.. on thing is that the vlan header is removed very early (just before the packet is handed to netgraph) and replaced by a packet tag (metadata) is is added back on (at the front) before transmission so that may be related how the headers swap position. it is possible that the vlan node converts the tag back to a header. I'm not sure exactly where it gets added back but it may be worth looking to see if the vlan type does so... > > Big thanks! > > BR > Younger Wang > > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org] > Sent: Friday, August 08, 2008 5:12 PM > To: Younger Wang > Subject: Re: (Netgraph problem) Inner tag and outer tag swapped > > Younger Wang wrote: >> Hi, >> >> >> >> fxp0 is connected to a trunk port. Frames tagged with VID=201 arrives > at >> fxp0 from a switch trunk port, I expect it will be captured at > hub_QinQ, >> with outer tag = 4000, and inner tag = 201. But in fact, it was > received >> with the outer and inner tags reversed. > > is this what you think is on the wire? > > > [ether header][tag 201][tag 4000][payload] > >> >> >> But if I inject the same frame on hub_c4000, the frame is received at >> hub_QinQ as expected (inner tag = 201, outer tag = 4000). I am really >> confused. Has anyone seen the same problem? Big thanks. >> >> >> >> Here is my netgraph setup: >> >> >> >> ngctl mkpeer fxp0: hub lower physical >> >> ngctl name fxp0:lower hub_c4000 > > looking at your config.. I see: > > > [hub] > down0 > | > downstream > [vlan] > vlan4000 > | > up > [hub] <--- why do you need this? > physical > | > lower > [ether] > > > what version of FreeBSD? > some changes were made in vlan handling in the late6/7 timeframe. > > >> >> >> ngctl mkpeer hub_c4000: vlan up vlan4000 >> >> ngctl name hub_c4000:up vlan_QinQ >> >> >> >> ngctl mkpeer vlan_QinQ: hub downstream down0 >> >> ngctl name vlan_QinQ:downstream hub_QinQ >> >> >> >> ngctl msg vlan_QinQ: addfilter { vlan=4000 hook="vlan4000" } >> >> >> >> BR >> >> Younger Wang >> >> >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From ermal.luci at gmail.com Fri Aug 8 23:26:34 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Fri Aug 8 23:26:40 2008 Subject: Application layer classifier for ipfw In-Reply-To: <48945A79.50300@wubethiopia.com> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> Message-ID: <9a542da30808081626y7ce1fe58k483494a6cdbfae60@mail.gmail.com> On Sat, Aug 2, 2008 at 3:00 PM, Mike Makonnen wrote: > Mike Makonnen wrote: >> >> Patrick Tracanelli wrote: >>> >>> To let you know of my current (real world) tests: >>> >>> - Wireless Internet Provider 1: >>> - 4Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> - Classifying 100Mbit/s of dump over ssh >>> >>> Results in: >>> No latency added, very low CPU usage, no packets dropping. >>> >>> - Wireless ISP 2: >>> - 21 Mbit/s of Internet Traffic >>> - Classifying default protocols + soulseek + ssh >>> >>> Results in: >>> No tcp or udp traffic at all; everything that gets diverted never >>> comes out of the divert socket, and ipfw-classifyd logs >>> >>> Aug 1 12:07:35 ourofino last message repeated 58 times >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>> (rule 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule >>> 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule >>> 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule >>> 1000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule >>> 50000) >>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >>> 50000) >>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>> socket: Operation not permitted >>> Aug 1 12:18:50 ourofino last message repeated 90 times >> >> Hmmm... this part means that the call to sendto(2) to write the packet >> back into network stack failed. This explains why you are not seein g any >> traffic comming back out of the divert socket, but I don't see why it would >> suddenly fail with a permission error. Could this be a kernel bug? >>> >>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full >>> Aug 1 12:19:11 ourofino last message repeated 94 times >>> >>> Raised queue len a lot (up to 40960), when the application starts it uses >>> up to 25% CPU and a second after that, CPU usage gets lower the 0.1%. >> >> This looks like a deadlock. If it weren't able to process packets fast >> enough the cpu usage should be high even as it's spewing "packet dropped" >> messages. Can you send me some more information like memory usage and the >> firewall script you are using? How much of the 21Mbits/s of traffic is P2P? >> If you reduce the number of protocols you are trying to match against does >> the behavior change? Using netstat -w1 -I can you tell me how >> many packets per second we're talking about for 4Mbits/s and 21Mbit/s? Also, >> the timestamps from the log file seem to show that the daemon is running for >> approx. 34 sec. before the first "unable to write to write to divert socket" >> message. Is it passing traffic during this time? Thanks. >> >> I've uploaded a newer version. Can you try that also please. It includes: >> o SIGHUP forces it to re-read its configuration file >> o rc.d script >> o minor optimization (calls pthread_cond_signal with the mutex unlocked) >> o code cleanup >> >> Also, for your convenience I have attached a patch against the earlier >> version that removes a debugging printf that should remove spammage to your >> log files (the current version has it removed already). >> > > Ooops, a few minutes after I sent this email I found a couple of bugs (one > major, and one minor). They were in the original tarball as well as the > newer one I uploaded earlier today. I've uploaded a fixed version of the > code. Can you try that instead please. > > Also, to help track down performance issues I've modified the Makefile to > build a profiled version of the application so you can use gprof(1) to > figure out where any problems lie. > Does this sound about right for implementing the GC and implementing syntax as $protocol = dnpipe 20 $protocol2 = dnqueue 30 it has some extra goos for pf(4) and altq(4) $protocol3 = queue $queue name $protocol4 = tag TAGNAME $protocol5 = action block It adds 2 new options -e seconds for seconds before a flow is considered expired and -n #packets proccessed before kicking the GC. --- classifyd_old.c 2008-08-09 00:33:04.000000000 +0000 +++ classifyd.c 2008-08-09 00:33:34.000000000 +0000 @@ -28,13 +28,17 @@ #include #include +#include +#include +#include #include #include #include #include #include #include +#include #include #include @@ -53,6 +57,7 @@ #include #include "hashtable.h" +#include "hashtable_private.h" #include "pathnames.h" #include "protocols.h" @@ -94,6 +99,7 @@ uint32_t if_datalen; /* length in bytes of if_data */ uint16_t if_pktcount; /* number of packets concatenated */ uint16_t if_fwrule; /* ipfw(4) rule associated with flow */ + time_t expire; /* flow expire time */ }; /* @@ -126,7 +132,7 @@ static struct ic_queue outQ; /* divert(4) socket */ -static int dvtS; +static int dvtS = 0; /* config file path */ static const char *conf = IC_CONFIG_PATH; @@ -137,12 +143,25 @@ /* List of protocols available to the system */ struct ic_protocols *fp; +/* Our hashtables */ +struct hashtable *sh = NULL, + *th = NULL, + *uh = NULL; + +/* signaled to kick garbage collector */ +static pthread_cond_t gq_condvar; + +/* number of packets before kicking garbage collector */ +static unsigned int npackets = 250; + +static time_t time_expire = 40; /* 40 seconds */ /* * Forward function declarations. */ void *classify_pthread(void *); void *read_pthread(void *); void *write_pthread(void *); +void *garbage_pthread(void *); static int equalkeys(void *, void *); static unsigned int hashfromkey(void *); static void test_re(void); @@ -155,7 +174,7 @@ { struct sockaddr_in addr; struct sigaction sa; - pthread_t classifytd, readtd, writetd; + pthread_t classifytd, readtd, writetd, garbagectd; const char *errstr; long long num; uint16_t port, qmaxsz; @@ -164,13 +183,27 @@ tflag = 0; port = IC_DPORT; qmaxsz = IC_QMAXSZ; - while ((ch = getopt(argc, argv, "htc:P:p:q:")) != -1) { + while ((ch = getopt(argc, argv, "n:e:htc:P:p:q:")) != -1) { switch(ch) { case 'c': conf = strdup(optarg); if (conf == NULL) err(EX_TEMPFAIL, "config file path"); break; + case 'e': + num = strtonum((const char *)optarg, 1, 400, &errstr); + if (num == 0 && errstr != NULL) { + errx(EX_USAGE, "invalud expire seconds: %s", errstr); + } + time_expire = (time_t)num; + break; + case 'n': + num = strtonum((const char *)optarg, 1, 65535, &errstr); + if (num == 0 && errstr != NULL) { + errx(EX_USAGE, "invalud expire seconds: %s", errstr); + } + npackets = (unsigned int)num; + break; case 'P': protoDir = strdup(optarg); if (protoDir == NULL) @@ -230,6 +263,9 @@ error = pthread_cond_init(&outQ.fq_condvar, NULL); if (error != 0) err(EX_OSERR, "unable to initialize output queue condvar"); + error = pthread_cond_init(&gq_condvar, NULL); + if (error != 0) + err(EX_OSERR, "unable to initialize garbage collector condvar"); /* * Create and bind the divert(4) socket. @@ -276,32 +312,80 @@ if (error == -1) err(EX_OSERR, "unable to set signal handler"); + /* + * There are 3 tables: udp, tcp, and tcp syn. + * The tcp syn table tracks connections for which a + * SYN packet has been sent but no reply has been returned + * yet. Once the SYN ACK reply is detected it is moved to + * the regular tcp connection tracking table. + */ + sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); + if (sh == NULL) { + syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); + error = EX_SOFTWARE; + goto cleanup; + } + th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); + if (th == NULL) { + syslog(LOG_ERR, "unable to create TCP tracking table"); + error = EX_SOFTWARE; + goto cleanup; + } + uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); + if (uh == NULL) { + syslog(LOG_ERR, "unable to create UDP tracking table"); + error = EX_SOFTWARE; + goto cleanup; + } + /* * Create the various threads. */ error = pthread_create(&readtd, NULL, read_pthread, NULL); - if (error != 0) - err(EX_OSERR, "unable to create reader thread"); + if (error != 0) { + syslog(LOG_ERR, "unable to create reader thread"); + error = EX_OSERR; + goto cleanup; + } error = pthread_create(&classifytd, NULL, classify_pthread, NULL); - if (error != 0) - err(EX_OSERR, "unable to create classifier thread"); + if (error != 0) { + syslog(LOG_ERR, "unable to create classifier thread"); + error = EX_OSERR; + goto cleanup; + } error = pthread_create(&writetd, NULL, write_pthread, NULL); - if (error != 0) - err(EX_OSERR, "unable to create writer thread"); - + if (error != 0) { + syslog(LOG_ERR, "unable to create writer thread"); + error = EX_OSERR; + goto cleanup; + } + error = pthread_create(&garbagectd, NULL, garbage_pthread, NULL); + if (error != 0) { + syslog(LOG_ERR, "unable to create garbage collect thread"); + error = EX_OSERR; + goto cleanup; + } /* * Wait for our threads to exit. */ pthread_join(readtd, NULL); pthread_join(classifytd, NULL); pthread_join(writetd, NULL); - + pthread_join(garbagectd, NULL); /* * Cleanup */ - close(dvtS); +cleanup: + if (dvtS > 0) + close(dvtS); + if (sh != NULL) + hashtable_destroy(sh, 1); + if (th != NULL) + hashtable_destroy(th, 1); + if (uh != NULL) + hashtable_destroy(uh, 1); - return (0); + return (error); } void * @@ -310,6 +394,7 @@ struct ic_pkt *pkt; struct ip *ipp; int len; + unsigned int pcktcnt = 0; while (1) { pkt = (struct ic_pkt *)malloc(sizeof(struct ic_pkt)); @@ -353,6 +438,10 @@ STAILQ_INSERT_HEAD(&inQ.fq_pkthead, pkt, fp_link); inQ.fq_size++; pthread_mutex_unlock(&inQ.fq_mtx); + if (++pcktcnt > npackets) { + pcktcnt = 0; + pthread_cond_signal(&gq_condvar); + } pthread_cond_signal(&inQ.fq_condvar); } @@ -420,39 +509,19 @@ struct tcphdr *tcp; struct udphdr *udp; struct ic_pkt *pkt; - struct hashtable *sh, *th, *uh; struct protocol *proto; + struct timeval tv; regmatch_t pmatch; u_char *data, *payload; uint16_t trycount; int datalen, error; - /* - * There are 3 tables: udp, tcp, and tcp syn. - * The tcp syn table tracks connections for which a - * SYN packet has been sent but no reply has been returned - * yet. Once the SYN ACK reply is detected it is moved to - * the regular tcp connection tracking table. - */ - sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); - if (sh == NULL) { - syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); - exit(EX_SOFTWARE); - } - th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); - if (th == NULL) { - syslog(LOG_ERR, "unable to create TCP tracking table"); - exit(EX_SOFTWARE); - } - uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); - if (uh == NULL) { - syslog(LOG_ERR, "unable to create UDP tracking table"); - exit(EX_SOFTWARE); - } - flow = NULL; key = NULL; while(1) { + while(gettimeofday(&tv, NULL) != 0) + ; + pthread_mutex_lock(&inQ.fq_mtx); pkt = STAILQ_LAST(&inQ.fq_pkthead, ic_pkt, fp_link); while (pkt == NULL) { @@ -528,6 +597,8 @@ free(pkt); continue; } + + flow->expire = tv.tv_sec; goto enqueue; /* * Handle session tear-down. @@ -583,8 +654,11 @@ * collecting IC_PKTMAXMATCH packets, just pass it through. */ } else if (flow->if_pktcount >= IC_PKTMAXMATCH && - flow->if_fwrule == 0) + flow->if_fwrule == 0) { + flow->expire = tv.tv_sec; goto enqueue; + } + flow->expire = tv.tv_sec; goto classify; } @@ -630,6 +704,7 @@ free(pkt); continue; } + flow->expire = tv.tv_sec; goto classify; } @@ -688,6 +763,7 @@ flow->if_datalen = datalen; flow->if_pktcount = 1; flow->if_fwrule = 0; + flow->expire = tv.tv_sec; if (hashtable_insert(uh, (void *)key, (void *)flow) == 0) { syslog(LOG_WARNING, "packet dropped: unable to insert into table"); @@ -715,19 +791,26 @@ flow->if_data = data; flow->if_datalen += datalen; flow->if_pktcount++; + flow->expire = tv.tv_sec; /* * If we haven't been able to classify this flow after * collecting IC_PKTMAXMATCH packets, just pass it through. */ } else if (flow->if_pktcount >= IC_PKTMAXMATCH && - flow->if_fwrule == 0) + flow->if_fwrule == 0) { + flow->expire = tv.tv_sec; goto enqueue; + } } else /* Not an TCP or UDP packet. */ goto enqueue; classify: - assert(flow != NULL); + if (flow == NULL) { + syslog(LOG_ERR, "flow is null argghhhhhhh"); + goto enqueue; + } + //assert(flow != NULL); /* * Inform divert(4) what rule to send it to by @@ -823,6 +906,80 @@ return (NULL); } +void * +garbage_pthread(void *arg __unused) +{ + char errbuf[LINE_MAX]; + struct entry *e, *f; + unsigned int i, flows_expired, error; + struct timeval tv; + + while (1) { + flows_expired = 0; + while (gettimeofday(&tv, NULL) != 0) + ; + tv.tv_sec -= time_expire; + + pthread_mutex_lock(&inQ.fq_mtx); + error = pthread_cond_wait(&gq_condvar, &inQ.fq_mtx); + if (error != 0) { + strerror_r(error, errbuf, sizeof(errbuf)); + syslog(EX_OSERR, "unable to wait on garbage collection: %s", + errbuf); + exit(EX_OSERR); + } + + for (i = 0; i < sh->tablelength; i++) { + e = sh->table[i]; + while (e != NULL) { + f = e; e = e->next; + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { + freekey(f->k); + sh->entrycount--; + if (f->v != NULL) + free(f->v); + free(f); + flows_expired++; + } + } + } + for (i = 0; i < th->tablelength; i++) { + e = th->table[i]; + while (e != NULL) { + f = e; e = e->next; + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { + freekey(f->k); + th->entrycount--; + if (f->v != NULL) + free(f->v); + free(f); + flows_expired++; + } + } + } + for (i = 0; i < uh->tablelength; i++) { + e = uh->table[i]; + while (e != NULL) { + f = e; e = e->next; + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { + freekey(f->k); + uh->entrycount--; + if (f->v != NULL) + free(f->v); + free(f); + flows_expired++; + } + } + } + + pthread_mutex_unlock(&inQ.fq_mtx); + + syslog(LOG_WARNING, "expired %u flows", flows_expired); + } + + return (NULL); +} + /* * NOTE: The protocol list (plist) passed as an argument is a global * variable. It is accessed from 3 functions: classify_pthread, @@ -840,12 +997,20 @@ static int read_config(const char *file, struct ic_protocols *plist) { + enum { bufsize = 2048 }; struct protocol *proto; properties props; - const char *errmsg, *name, *value; - int fd; + const char *errmsg, *name; + char *value; + int fd, fdpf; uint16_t rule; + char **ap, *argv[bufsize]; + fdpf = open("/dev/pf", O_RDONLY); + if (fdpf == -1) { + syslog(LOG_ERR, "unable to open /dev/pf"); + return (EX_OSERR); + } fd = open(file, O_RDONLY); if (fd == -1) { syslog(LOG_ERR, "unable to open configuration file"); @@ -863,10 +1028,48 @@ /* Do not match traffic against this pattern */ if (value == NULL) continue; - rule = strtonum(value, 1, 65535, &errmsg); - if (rule == 0) { + for (ap = argv; (*ap = strsep(&value, " \t")) != NULL;) + if (**ap != '\0') + if (++ap >= &argv[bufsize]) + break; + if (!strncmp(argv[0], "queue", strlen("queue"))) { + if (ioctl(fdpf, DIOCGETNAMEDALTQ, &rule)) { + syslog(LOG_WARNING, + "could not get ALTQ translation for" + " queue %s", argv[1]); + continue; + } + if (rule == 0) { + syslog(LOG_WARNING, + "queue %s does not exists!", argv[1]); + continue; + } + } else if (!strncmp(argv[0], "dnqueue", strlen("dnqueue"))) + rule = strtonum(argv[1], 1, 65535, &errmsg); + else if (!strncmp(argv[0], "dnpipe", strlen("dnpipe"))) + rule = strtonum(argv[1], 1, 65535, &errmsg); + else if (!strncmp(argv[0], "tag", strlen("tag"))) { + if (ioctl(fdpf, DIOCGETNAMEDTAG, &rule)) { + syslog(LOG_WARNING, + "could not get tag translation for" + " queue %s", argv[1]); + continue; + } + if (rule == 0) { + syslog(LOG_WARNING, + "tag %s does not exists!", argv[1]); + continue; + } + } else if (!strncmp(argv[0], "action", strlen("action"))) { + if (strncmp(argv[1], "block", strlen("block"))) + rule = PF_DROP; + else if (strncmp(argv[1], "allow", strlen("allow"))) + rule = PF_PASS; + else + continue; + } else { syslog(LOG_WARNING, - "invalid rule number for %s protocol: %s", + "invalid action specified for %s protocol: %s", proto->p_name, errmsg); continue; } @@ -953,10 +1156,14 @@ static void usage(const char *arg0) { - printf("usage: %s [-h] [-c file] [-p port] [-P dir] [-q length]\n", basename(arg0)); + printf("usage: %s [-h] [-c file] [-e seconds] [-n packets] " + "[-p port] [-P dir] [-q length]\n", basename(arg0)); printf("usage: %s -t -P dir\n", basename(arg0)); printf( " -c file : path to configuration file\n" + " -e secs : number of seconds before a flow is expired\n" " -h : this help screen\n" + " -n packets: number of packets before the garbage collector" + " tries to expire flows\n" " -P dir : directory containing protocol patterns\n" " -p port : port number of divert socket\n" " -q length : max length (in packets) of in/out queues\n" -- Ermal From jacoblowens at gmail.com Sat Aug 9 05:17:18 2008 From: jacoblowens at gmail.com (Jacob Owens) Date: Sat Aug 9 05:17:25 2008 Subject: lagg failover not automatic Message-ID: Hello. I've got a old sun V100 which features two gigabit ports (using dc driver). I've been trying to get lagg failover working. on SPARC64 7.0 RELEASE On the box I put the following in /etc/rc.conf: ifconfig_dc0="UP" ifconfig_dc1="UP" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport dc0 laggport dc1 50.40.0.3netmask 255.255.0.0 I even added this to my loader.conf (per the man page) if_lagg_load="YES" I'm not using a smart switch, so no STP. What happens when I unplug the "master" interface, is that the network will stop working. the second I type in 'ifconfig -v' to see what the situation is, there is a small pause, and then the network fails over to the second nic and starts working. So it seems that typing 'ifconfig' somehow wakes the config up... Dmesg does not show the appropriate update (dc0: link state changed to DOWN/dc0: link state changed to UP) until after i type ifconfig either. Here is the before and after outfut of 'ifconfig -v' BEFORE: sunbox# ifconfig -v dc0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 dc1: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 groups: lo lagg0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 media: Ethernet autoselect status: active groups: lagg laggproto failover laggport: dc1 flags=0<> laggport: dc0 flags=5 AFTER: sunbox# ifconfig -v dc0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (none) status: no carrier lagg: laggdev lagg0 dc1: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 media: Ethernet autoselect (100baseTX ) status: active lagg: laggdev lagg0 lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 groups: lo lagg0: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:ba:6c:be:04 inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 media: Ethernet autoselect status: active groups: lagg laggproto failover laggport: dc1 flags=4 laggport: dc0 flags=1 Thanks in advance. any ideas? From thompsa at FreeBSD.org Sat Aug 9 05:57:56 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sat Aug 9 05:58:02 2008 Subject: lagg failover not automatic In-Reply-To: References: Message-ID: <20080809055749.GA95107@citylink.fud.org.nz> On Fri, Aug 08, 2008 at 11:49:27PM -0500, Jacob Owens wrote: > Hello. > > I've got a old sun V100 which features two gigabit ports (using dc driver). > I've been trying to get lagg failover working. on SPARC64 7.0 RELEASE > > On the box I put the following in /etc/rc.conf: > ifconfig_dc0="UP" > ifconfig_dc1="UP" > cloned_interfaces="lagg0" > ifconfig_lagg0="laggproto failover laggport dc0 laggport dc1 50.40.0.3netmask > 255.255.0.0 > > I even added this to my loader.conf (per the man page) > if_lagg_load="YES" > > I'm not using a smart switch, so no STP. > > What happens when I unplug the "master" interface, is that the network will > stop working. the second I type in 'ifconfig -v' to see what the situation > is, there is a small pause, and then the network fails over to the second > nic and starts working. So it seems that typing 'ifconfig' somehow wakes the > config up... Dmesg does not show the appropriate update (dc0: link state > changed to DOWN/dc0: link state changed to UP) until after i type ifconfig > either. Here is the before and after outfut of 'ifconfig -v' lagg (failover/loadbalance) relies on the hardware/driver reporting the link state changes to do failover, its the only way it can tell if the link has gone down. Running ifconfig will cause the hardware media to be polled as it needs the current state for the 'media: ...' line, this will cause the needed linkstate event to happen since it is different to the stored value. This is meant to happen automatically, this is a bug in the dc driver. One thing to note is that LACP mode does not have this problem as heartbeat frames are exchanged with the peer, apart from being slower as its a timeout vs link event. cheers, Andrew From pyunyh at gmail.com Sat Aug 9 08:56:33 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Aug 9 08:56:39 2008 Subject: lagg failover not automatic In-Reply-To: References: Message-ID: <20080809082539.GC42339@cdnetworks.co.kr> On Fri, Aug 08, 2008 at 11:49:27PM -0500, Jacob Owens wrote: > Hello. > > I've got a old sun V100 which features two gigabit ports (using dc driver). > I've been trying to get lagg failover working. on SPARC64 7.0 RELEASE > > On the box I put the following in /etc/rc.conf: > ifconfig_dc0="UP" > ifconfig_dc1="UP" > cloned_interfaces="lagg0" > ifconfig_lagg0="laggproto failover laggport dc0 laggport dc1 50.40.0.3netmask > 255.255.0.0 > > I even added this to my loader.conf (per the man page) > if_lagg_load="YES" > > I'm not using a smart switch, so no STP. > > What happens when I unplug the "master" interface, is that the network will > stop working. the second I type in 'ifconfig -v' to see what the situation > is, there is a small pause, and then the network fails over to the second > nic and starts working. So it seems that typing 'ifconfig' somehow wakes the > config up... Dmesg does not show the appropriate update (dc0: link state > changed to DOWN/dc0: link state changed to UP) until after i type ifconfig > either. Here is the before and after outfut of 'ifconfig -v' > > BEFORE: > sunbox# ifconfig > -v > dc0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect (100baseTX > ) > status: > active > lagg: laggdev > lagg0 > dc1: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect (100baseTX > ) > status: > active > lagg: laggdev > lagg0 > lo0: flags=8049 metric 0 mtu > 16384 > inet 127.0.0.1 netmask > 0xff000000 > groups: > lo > lagg0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 > > media: Ethernet > autoselect > status: > active > groups: > lagg > laggproto > failover > laggport: dc1 > flags=0<> > laggport: dc0 flags=5 > > AFTER: > sunbox# ifconfig > -v > dc0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect > (none) > status: no > carrier > lagg: laggdev > lagg0 > dc1: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > media: Ethernet autoselect (100baseTX > ) > status: > active > lagg: laggdev > lagg0 > lo0: flags=8049 metric 0 mtu > 16384 > inet 127.0.0.1 netmask > 0xff000000 > groups: > lo > lagg0: flags=8843 metric 0 mtu > 1500 > > options=8 > ether > 00:03:ba:6c:be:04 > inet 50.40.0.3 netmask 0xffff0000 broadcast 50.40.255.255 > > media: Ethernet > autoselect > status: > active > groups: > lagg > laggproto > failover > laggport: dc1 > flags=4 > laggport: dc0 flags=1 > > Thanks in advance. any ideas? Would you show me the dmesg output? -- Regards, Pyun YongHyeon From rfrench at freebsd.org Sat Aug 9 10:09:56 2008 From: rfrench at freebsd.org (Ryan French) Date: Sat Aug 9 10:10:02 2008 Subject: Looking for the FreeBSD equivalent of an OpenBSD function Message-ID: <200808092209.55478.rfrench@freebsd.org> Hi all, First of all thank you for all the help with my question yesterday, my problem today is unfortunately not something syntactical like the last one. I am working on moving over code from OpenBSDs implementation ofMPLS to FreeBSD, and I have run up against a function called 'sysctl_ifq' and I was wondering if anyone knew of an equivalent in FreeBSD. The code that calls the function is shown below. Thanks for any help. int mpls_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp, size_t newlen) { if (name[0] >= MPLSCTL_MAXID) return EOPNOTSUPP; /* Almost all sysctl names at this level are terminal. */ if (namelen != 1 && name[0] != MPLSCTL_IFQUEUE) return (ENOTDIR); switch (name[0]) { case MPLSCTL_IFQUEUE: return (sysctl_ifq(name + 1, namelen - 1, oldp, oldlenp, newp, newlen, &mplsintrq)); default: return sysctl_int_arr(mplsctl_vars, name, namelen, oldp, oldlenp, newp, newlen); } } From rwatson at FreeBSD.org Sat Aug 9 11:30:28 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 9 11:30:35 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: Message-ID: On Sun, 3 Aug 2008, Robert Watson wrote: > This is an advance warning that, late next week, I will be merging a fairly > large set of changes to the IPv4 and IPv6 protocols layered over the > inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, > UDP, and raw sockets on both IPv4 and IPv6. I will post a further e-mail > announcement along with patch set and schedule in a day or two once it's > prepared. Patches, which require the MFC of rwlock try-locking, which I did earlier today: http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff These incude the inpcb/inpcbinfo read/write locking changes (although not yet for raw/divert sockets). Any testing, especially with heavy UDP loads, would be much appreciated -- this are fairly complex changes, and also quite a complex MFC. Robert N M Watson Computer Laboratory University of Cambridge > > The thrust of this change is to replace the mutexes protecting the inpcb and > inpcbinfo data structures with read-write locks (rwlocks). These structures > represent, respectively, particular sockets and the global socket lists for > all socket types in IPv4 and IPv6 except for SCTP. When you run netstat, > inpcbinfo is the data structure referencing all connections, and each line in > the nestat output reflects the contents of a specific inpcb. > > In the current stage of this work, the intent is to improve performance for > datagram-related protocols on SMP systems by allowing concurrent acquisition > of both global and connection locks during receive and transmit. This is > possible because, in the common case, no connection or global state is > modified during UDP/raw receive and transmit at the IP layer, so a read lock > is sufficient to prevent data in those structures from unexpectedly changing. > For receive, socket layer state is modified, but this is separately protected > by socket layer locks. On transmit, no state is modified at any layer, so in > principle we will allow fully parallel transmit from multiple threads down to > about the routing and network interface layers, whereas previously they would > bottleneck in UDP. > > The applications targeted by this change are threaded UDP server > applications, such as BIND9, nsd, and UDP-based memcached. Kris Kennaway and > Paul Saab have done fairly extensive testing with the changes and > demonstrated significant performance improvements due to reduced contention > and overhead. Perhaps they can mention some of those numbers in a follow-up > to this post. > > The reason for the heads up is that, while carefully-tested, changes of this > sort do come with risks. We've carefully structured them so as to avoid > breaking the ABIs for netstat, etc, but it's not impossible that some > problems will arise as the changes settle. The goal, however, is to see > these performance improvements in 7.1, and since they've had a bit to shake > out in 8.x and seen some heavy use, I think now is the right time to merge > them. > > In any case, I will send out e-mail in a couple of days with a proposed merge > patch and schedule for merging, and perhaps if you are in a positition where > you might benefit from these improvements, or have interesting UDP or > raw-socket based applications running on 7.x, you could test the candidate > patch before it's merged, reporting any problems. Unless I receive negative > feedback, I will plan on merging the changes late in the week, and keep a > close eye on stable@ for any reports of problems. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From ady at freebsd.ady.ro Sat Aug 9 11:36:27 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sat Aug 9 11:36:34 2008 Subject: Looking for the FreeBSD equivalent of an OpenBSD function In-Reply-To: <200808092209.55478.rfrench@freebsd.org> References: <200808092209.55478.rfrench@freebsd.org> Message-ID: <78cb3d3f0808090436h565dbe9foea6cf8df55c3cf14@mail.gmail.com> Hi, On Sat, Aug 9, 2008 at 12:09 PM, Ryan French wrote: > Hi all, > > First of all thank you for all the help with my question yesterday, my problem > today is unfortunately not something syntactical like the last one. > > I am working on moving over code from OpenBSDs implementation ofMPLS to > FreeBSD, and I have run up against a function called 'sysctl_ifq' and I was > wondering if anyone knew of an equivalent in FreeBSD. The code that calls the > function is shown below. Thanks for any help. You mean the following one: http://fxr.watson.org/fxr/source/net/if.c?v=OPENBSD#L1944 In FreeBSD I think one can extract the values for queue (maximum) length and drops stats from the ifq structure using the _IF_DROP()/_IF_QLEN() macros here: http://fxr.watson.org/fxr/source/net/if_var.h?im=bigexcerpts#L247 I'm not sure whether you might need to use locking primitives to query these values for MP reasons with IF_LOCK()/IF_UNLOCK(). Regards, Adrian. From naddy at mips.inka.de Sat Aug 9 20:47:43 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sat Aug 9 20:47:49 2008 Subject: Rx/tx hardware checksumming statistics? Message-ID: OpenBSD keeps count of the packets that have undergone IPv4 header/ TCP/UDP checksumming in hardware. These statics are available with netstat -s, e.g.: ip: ... 492152 input datagrams checksum-processed by hardware 911338 output datagrams checksum-processed by hardware ... This comes in quite handy to check whether checksum offloading actually works and which protocols are successfully processed this way. On FreeBSD, netstat -s does not provide this information. Are these statistics available in some other way? How would I check whether packets have actually been checksummed in hardware? -- Christian "naddy" Weisgerber naddy@mips.inka.de From pyunyh at gmail.com Mon Aug 11 02:19:17 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Aug 11 02:19:24 2008 Subject: Rx/tx hardware checksumming statistics? In-Reply-To: References: Message-ID: <20080811021703.GC50045@cdnetworks.co.kr> On Sat, Aug 09, 2008 at 08:12:42PM +0000, Christian Weisgerber wrote: > OpenBSD keeps count of the packets that have undergone IPv4 header/ > TCP/UDP checksumming in hardware. These statics are available with > netstat -s, e.g.: > > ip: > ... > 492152 input datagrams checksum-processed by hardware > 911338 output datagrams checksum-processed by hardware > ... > > This comes in quite handy to check whether checksum offloading > actually works and which protocols are successfully processed this > way. > I don't think it indicates whether checksum offloading actually works as OpenBSD blindly set a flag, which was derived from hardware, to indicate hardware performed the checksum computation. You can still have a chance that checksum offloading does not work even if the counter constantly increase over time. In addition, OpenBSD have a no way to disable checksum offloading feature of hardware on the fly so you have to rebuild the driver to disable checksum offloading in case of broken/buggy hardware. > On FreeBSD, netstat -s does not provide this information. Are these > statistics available in some other way? How would I check whether AFAIK there is no such counters in FreeBSD. > packets have actually been checksummed in hardware? > If checksum offloading didn't work you couldn't get a working connection at all. -- Regards, Pyun YongHyeon From onuraslan at gmail.com Mon Aug 11 10:02:11 2008 From: onuraslan at gmail.com (Onur Aslan) Date: Mon Aug 11 10:02:18 2008 Subject: Named Listen IP Message-ID: Hi. I am using named for a ns server. Named listening all ips for my machine. But when i reboot machine, my ppp network connecting after started named. named doesn't listening my ppp network's ip. Do you have a solution? Thanks. From ronan at artful.net Mon Aug 11 10:15:09 2008 From: ronan at artful.net (Ronan Kerambrun) Date: Mon Aug 11 10:15:16 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... Message-ID: <48A009F4.4030901@artful.net> Hi all, I have the same problem, but using Varnish. I dont think it is an application bug because Poul-Henning Kamp (the developer of the application) is also a freebsd kernel developper.. # uname -a FreeBSD cache2 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #0: Thu Jun 19 20:37:34 CEST 2008 root@cache2:/usr/obj/usr/src/sys/GENERIC-ULE amd64 # netstat -n |grep -c CLOSED 1518 # varnishd -V varnishd (varnish-1.1.2) Copyright (c) 2006-2007 Linpro AS / Verdens Gang AS Cheers, ronan From eugen at kuzbass.ru Mon Aug 11 10:25:58 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Aug 11 10:26:05 2008 Subject: Named Listen IP In-Reply-To: References: Message-ID: <20080811102554.GA82579@svzserv.kemerovo.su> On Mon, Aug 11, 2008 at 12:35:08PM +0300, Onur Aslan wrote: > I am using named for a ns server. Named listening all ips for my > machine. But when i reboot machine, my ppp network connecting after > started named. named doesn't listening my ppp network's ip. Do you > have a solution? By default, named runs as nonprivileged user and to the moment ppp brings interface up named has no right to listen it. The only solution I know is to run named as root, so add to /etc/rc.conf: named_uid="root" Eugene Grosbein From bugmaster at FreeBSD.org Mon Aug 11 11:07:01 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:08:19 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200808111107.m7BB70eK047264@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card 98 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/126339 net [ipw] ipw driver drops the connection 60 problems total. From naddy at mips.inka.de Mon Aug 11 12:22:36 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Mon Aug 11 12:22:45 2008 Subject: Rx/tx hardware checksumming statistics? References: <20080811021703.GC50045@cdnetworks.co.kr> Message-ID: Pyun YongHyeon wrote: > I don't think it indicates whether checksum offloading actually > works as OpenBSD blindly set a flag, which was derived from > hardware, to indicate hardware performed the checksum computation. Yes. It counts the instances where the network stack assumes that the hardware successfully verified the checksum. That is an interesting number. OpenBSD's re(4) driver is ported from FreeBSD. Recently, Brad Smith has been merging the tx/rx checksum offload support for the newer chips (RTL8111C etc.) into the OpenBSD driver and I have done some testing for him. Looking at the counters, I have noticed: * IP header rx checksumming is only registered for IP/TCP and IP/UDP packets, but not for other protocols, such as IP/ICMP. * If VLAN tagging is enabled, no rx checksumming is registered at all. I don't have documentation for the Realtek chips, so I don't know if the hardware really cannot perform these operations or if the driver simply fails to take advantage of them. Presumably the same limitations also apply to the FreeBSD driver, but without the counters, how can you tell? -- Christian "naddy" Weisgerber naddy@mips.inka.de From smithi at nimnet.asn.au Mon Aug 11 15:38:57 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Aug 11 15:39:12 2008 Subject: Named Listen IP In-Reply-To: References: Message-ID: <20080812001925.I24964@sola.nimnet.asn.au> On Mon, 11 Aug 2008, Onur Aslan wrote: > I am using named for a ns server. Named listening all ips for my > machine. But when i reboot machine, my ppp network connecting after > started named. named doesn't listening my ppp network's ip. Do you > have a solution? Assuming you have a fixed IP address when ppp comes up, specify that address in named's listen-on list. When ppp has connected, assigned its addresses and set the default route, have ppp run an up-script that runs '/etc/rc.d/named restart'. named will then see the ppp interface and listen on that address as well as any others specified, like localhost. ppp runs its up/down scripts as root; you don't need (or want) to have named running as root. cheers, Ian From pschmehl_lists at tx.rr.com Mon Aug 11 17:40:27 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Mon Aug 11 17:40:34 2008 Subject: Named Listen IP In-Reply-To: <20080812001925.I24964@sola.nimnet.asn.au> References: <20080812001925.I24964@sola.nimnet.asn.au> Message-ID: --On Tuesday, August 12, 2008 01:08:46 +1000 Ian Smith wrote: > On Mon, 11 Aug 2008, Onur Aslan wrote: > > I am using named for a ns server. Named listening all ips for my > > machine. But when i reboot machine, my ppp network connecting after > > started named. named doesn't listening my ppp network's ip. Do you > > have a solution? > > Assuming you have a fixed IP address when ppp comes up, specify that > address in named's listen-on list. When ppp has connected, assigned its > addresses and set the default route, have ppp run an up-script that runs > '/etc/rc.d/named restart'. > > named will then see the ppp interface and listen on that address as well > as any others specified, like localhost. ppp runs its up/down scripts > as root; you don't need (or want) to have named running as root. > Just wondering - couldn't this be fixed by adding the keyword "network" to the REQUIRE portion of the /etc/rc.d/named script? (Right now it contains SERVERS and cleanvar. I'm suggesting adding network.) -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* Check the headers before clicking on Reply. From personal at daemoncore.org Mon Aug 11 20:07:12 2008 From: personal at daemoncore.org (Paul G Webster) Date: Mon Aug 11 20:07:18 2008 Subject: NetGear PCMCIA card (GA518) Message-ID: <1218484244.1750.6.camel@laptop2.daemoncore.org> Good day all, Im trying to get the PCMCIA 100/1000 nic in topic working, someone has managed it before: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-11/0857.html But that patch wont apply cleanly, dmesg reports on card entry (with no patch): re0: port 0xf000-0xf0ff mem 0xfc007000-0xfc0071ff irq 16 at device 0.0 on cardbus0 re0: PHY read failed re0: MII without any phy! device_attach: re0 attach returned 6 Anyone able tend a hand? -- Thank you for your time -- paul g webster From dougb at FreeBSD.org Mon Aug 11 22:06:14 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 11 22:06:20 2008 Subject: Named Listen IP In-Reply-To: References: Message-ID: <48A0B7D3.2090702@FreeBSD.org> Onur Aslan wrote: > Hi. > > I am using named for a ns server. Named listening all ips for my > machine. But when i reboot machine, my ppp network connecting after > started named. Do you mean that the ppp startup script starts running before the named startup script starts running, but doesn't finish connecting until named starts? If so, then the solution that Ian gave you (to add '/etc/rc.d/named restart' to your ppp script) is the right one. Or do you mean that the named startup script runs first, then the ppp startup script runs after it? This shouldn't happen, but if it's happening to you we need to know why. Follow these steps: mkdir testrc cd testrc cp /etc/rc . fetch http://dougbarton.us/rc-debug.diff patch < rc-debug.diff /bin/sh rc If the two "early" runs are different it will show that, in which case there is an even bigger problem. What usually happens is that they are the same and the second one will be deleted. Paste the results of rc.early1 (and 2 if they are different) and rc.late into your response and we'll take it from there. hope this helps, Doug -- This .signature sanitized for your protection From andrew at modulus.org Mon Aug 11 22:34:56 2008 From: andrew at modulus.org (Andrew Snow) Date: Mon Aug 11 22:35:03 2008 Subject: Rx/tx hardware checksumming statistics? In-Reply-To: <20080811021703.GC50045@cdnetworks.co.kr> References: <20080811021703.GC50045@cdnetworks.co.kr> Message-ID: <48A0BE14.6070102@modulus.org> Are there any NIC hardware counters that FreeBSD could be taking advantage of or displaying? From pyunyh at gmail.com Tue Aug 12 02:01:26 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Aug 12 02:01:33 2008 Subject: NetGear PCMCIA card (GA518) In-Reply-To: <1218484244.1750.6.camel@laptop2.daemoncore.org> References: <1218484244.1750.6.camel@laptop2.daemoncore.org> Message-ID: <20080812015905.GC54362@cdnetworks.co.kr> On Mon, Aug 11, 2008 at 08:50:43PM +0100, Paul G Webster wrote: > Good day all, > > Im trying to get the PCMCIA 100/1000 nic in topic working, someone has > managed it before: > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-11/0857.html > > But that patch wont apply cleanly, dmesg reports on card entry (with no > patch): > > re0: port > 0xf000-0xf0ff mem 0xfc007000-0xfc0071ff irq 16 at device 0.0 on cardbus0 > re0: PHY read failed > re0: MII without any phy! > device_attach: re0 attach returned 6 > > Anyone able tend a hand? > It seems that the controller is recognized by re(4) but initialization was not successful. Since your controller is not second generation of RealTek 8168/8111 I think the issue could be related with cardbus driver. imp@ may have more idea what's happening here. > -- Thank you for your time > -- paul g webster -- Regards, Pyun YongHyeon From pyunyh at gmail.com Tue Aug 12 02:31:08 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Aug 12 02:31:20 2008 Subject: Rx/tx hardware checksumming statistics? In-Reply-To: References: <20080811021703.GC50045@cdnetworks.co.kr> Message-ID: <20080812022853.GD54362@cdnetworks.co.kr> On Mon, Aug 11, 2008 at 12:22:33PM +0000, Christian Weisgerber wrote: > Pyun YongHyeon wrote: > > > I don't think it indicates whether checksum offloading actually > > works as OpenBSD blindly set a flag, which was derived from > > hardware, to indicate hardware performed the checksum computation. > > Yes. It counts the instances where the network stack assumes that > the hardware successfully verified the checksum. That is an > interesting number. > > OpenBSD's re(4) driver is ported from FreeBSD. Recently, Brad Smith > has been merging the tx/rx checksum offload support for the newer > chips (RTL8111C etc.) into the OpenBSD driver and I have done some > testing for him. Looking at the counters, I have noticed: > * IP header rx checksumming is only registered for IP/TCP and IP/UDP > packets, but not for other protocols, such as IP/ICMP. Note, the controller can only offload IP, TCP and UDP checksumming. ICMP should be handled by software. > * If VLAN tagging is enabled, no rx checksumming is registered at > all. > > I don't have documentation for the Realtek chips, so I don't know > if the hardware really cannot perform these operations or if the > driver simply fails to take advantage of them. Presumably the same AFAIK all RealTek gigabit controllers can do TSO, checksum offload, and VLAN tag insertion/stripping. Of course there are known hardware bugs for these hardware assistance but it's different question, I think. > limitations also apply to the FreeBSD driver, but without the No, FreeBSD have no such limitation, re(4) takes full advantage of hardware assistance if the controller in question is known to work with the feature. > counters, how can you tell? > I think you can check the output of ifconfig(4). Unlike OpenBSD, you can see 'options' part of output which indicates current active hardware features such as checksum offload, WOL, TSO etc. I have no strong opinions on adding these counters but I guess there are too many hardware assisted counters if we take the route, for example, re(4) can do the following with hardware assistance and each hardware assistance will require separate counters. - TSO(TCP segmentation offload) - VLAN tag insertion - VLAN tag stripping - Tx/Rx IP/TCP/UDP checksum offload > -- > Christian "naddy" Weisgerber naddy@mips.inka.de -- Regards, Pyun YongHyeon From pyunyh at gmail.com Tue Aug 12 02:41:44 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Aug 12 02:41:50 2008 Subject: Rx/tx hardware checksumming statistics? In-Reply-To: <48A0BE14.6070102@modulus.org> References: <20080811021703.GC50045@cdnetworks.co.kr> <48A0BE14.6070102@modulus.org> Message-ID: <20080812023928.GE54362@cdnetworks.co.kr> On Tue, Aug 12, 2008 at 08:32:52AM +1000, Andrew Snow wrote: > > Are there any NIC hardware counters that FreeBSD could be taking > advantage of or displaying? > It depends on device driver. Some drivers access hardware counters maintained by MAC and can display these counters with sysctl(8). In addition these counters are used to update statistics counters in ifnet which can be checked with netstat(1). For example, em(4), age(4), sf(4), bge(4), bce(4) provide sysctl interface. -- Regards, Pyun YongHyeon From remko at FreeBSD.org Tue Aug 12 06:49:17 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Tue Aug 12 06:49:23 2008 Subject: kern/126469: [fxp] [panic] fxp(4) related kernel panic Message-ID: <200808120649.m7C6nHv9064134@freefall.freebsd.org> Synopsis: [fxp] [panic] fxp(4) related kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Aug 12 06:49:16 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=126469 From linimon at FreeBSD.org Tue Aug 12 09:55:31 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Aug 12 09:55:42 2008 Subject: kern/126475: [ath] [panic] ath pcmcia card inevitably panics under FreeBSD-7 STABLE Message-ID: <200808120955.m7C9tVBN004884@freefall.freebsd.org> Synopsis: [ath] [panic] ath pcmcia card inevitably panics under FreeBSD-7 STABLE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Aug 12 09:55:18 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 From mutex at secure-it.ca Tue Aug 12 15:32:14 2008 From: mutex at secure-it.ca (mutex@secure-it.ca) Date: Tue Aug 12 15:32:20 2008 Subject: Named Listen IP In-Reply-To: <48A0B7D3.2090702@FreeBSD.org> References: <48A0B7D3.2090702@FreeBSD.org> Message-ID: <55144.70.80.73.214.1218555105.squirrel@webmail.unixtech.info> Hello, to me, I found that the easiest solution was to use ppp startup script instead of /etc/rc.conf. You should take a look at /etc/ppp/ppp.linkup and /etc/ppp/ip-up files depending on your setup. -- Public --> 4096R/1DA0F13F 2008-06-26 [expires: 2013-06-25] Key fingerprint -- > 2287 2F1F FE62 3975 F181 DDA6 B65F 3B1C 1DA0 F13F uid MuteX mutex@secure-it.ca (secure-it.ca) From naddy at mips.inka.de Tue Aug 12 15:33:18 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue Aug 12 15:33:25 2008 Subject: Rx/tx hardware checksumming statistics? References: <20080811021703.GC50045@cdnetworks.co.kr> <20080812022853.GD54362@cdnetworks.co.kr> Message-ID: Pyun YongHyeon wrote: > > OpenBSD's re(4) driver is ported from FreeBSD. Recently, Brad Smith > > has been merging the tx/rx checksum offload support for the newer > > chips (RTL8111C etc.) into the OpenBSD driver and I have done some > > testing for him. Looking at the counters, I have noticed: > > * IP header rx checksumming is only registered for IP/TCP and IP/UDP > > packets, but not for other protocols, such as IP/ICMP. > > Note, the controller can only offload IP, TCP and UDP checksumming. > ICMP should be handled by software. Yes, but the IP/ICMP packet should still be subject to IP checksumming. What I see with an 8111C (RL_FLAG_DESCV2): * incoming IP/TCP packet => IP checksum processed in hardware => TCP checksum processed in hardware * incoming IP/UDP packet => IP checksum processed in hardware => UDP checksum processed in hardware * incoming IP/ICMP packet => IP checksum _not_ processed in hardware With an old 8169S the latter case is different: * incoming IP/ICMP packet => IP checksum processed in hardware > > limitations also apply to the FreeBSD driver, but without the > > No, FreeBSD have no such limitation, re(4) takes full advantage of > hardware assistance if the controller in question is known to work > with the feature. I cannot find any difference between the respective drivers suggesting that the behavior above would be any different on FreeBSD. There are no relevant differences in the RX checksumming section in re_rxeof(). > > counters, how can you tell? > > I think you can check the output of ifconfig(4). This does not tell you if an individual received packet has been marked CSUM_IP_CHECKED|CSUM_IP_VALID. -- Christian "naddy" Weisgerber naddy@mips.inka.de From naddy at mips.inka.de Tue Aug 12 22:18:40 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue Aug 12 22:18:46 2008 Subject: Rx/tx hardware checksumming statistics? References: <20080811021703.GC50045@cdnetworks.co.kr> Message-ID: Christian Weisgerber wrote: > OpenBSD's re(4) driver is ported from FreeBSD. [...] > * If VLAN tagging is enabled, no rx checksumming is registered at > all. For the record, this is in fact due to a difference in the OpenBSD driver, i.e., it does not apply to FreeBSD. OpenBSD does not enable VLAN tag stripping in hardware. Without this, the chip apparently does not perform any rx checksumming on tagged frames. -- Christian "naddy" Weisgerber naddy@mips.inka.de From pyunyh at gmail.com Wed Aug 13 01:11:57 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Aug 13 01:12:04 2008 Subject: Rx/tx hardware checksumming statistics? In-Reply-To: References: <20080811021703.GC50045@cdnetworks.co.kr> <20080812022853.GD54362@cdnetworks.co.kr> Message-ID: <20080813010944.GB58659@cdnetworks.co.kr> On Tue, Aug 12, 2008 at 03:33:14PM +0000, Christian Weisgerber wrote: > Pyun YongHyeon wrote: > > > > OpenBSD's re(4) driver is ported from FreeBSD. Recently, Brad Smith > > > has been merging the tx/rx checksum offload support for the newer > > > chips (RTL8111C etc.) into the OpenBSD driver and I have done some > > > testing for him. Looking at the counters, I have noticed: > > > * IP header rx checksumming is only registered for IP/TCP and IP/UDP > > > packets, but not for other protocols, such as IP/ICMP. > > > > Note, the controller can only offload IP, TCP and UDP checksumming. > > ICMP should be handled by software. > > Yes, but the IP/ICMP packet should still be subject to IP checksumming. > > What I see with an 8111C (RL_FLAG_DESCV2): > * incoming IP/TCP packet > => IP checksum processed in hardware > => TCP checksum processed in hardware > * incoming IP/UDP packet > => IP checksum processed in hardware > => UDP checksum processed in hardware > * incoming IP/ICMP packet > => IP checksum _not_ processed in hardware > > With an old 8169S the latter case is different: > * incoming IP/ICMP packet > => IP checksum processed in hardware > > > > limitations also apply to the FreeBSD driver, but without the > > > > No, FreeBSD have no such limitation, re(4) takes full advantage of > > hardware assistance if the controller in question is known to work > > with the feature. > > I cannot find any difference between the respective drivers suggesting > that the behavior above would be any different on FreeBSD. There > are no relevant differences in the RX checksumming section in > re_rxeof(). > Aha I see. The second generation of RTL8168/8111/810x controllers use new descriptor format. I don't know why RealTek dropped supporting IP/ICMP checksumming and I couldn't verify that as I have no such hardware. However it seems RealTek added IPv6 checksum offload support for these controllers so the checksum offload oddity for IP/ICMP could be a bug introduced in this newer descriptor format. > > > counters, how can you tell? > > > > I think you can check the output of ifconfig(4). > > This does not tell you if an individual received packet has been > marked CSUM_IP_CHECKED|CSUM_IP_VALID. > That's correct. -- Regards, Pyun YongHyeon From smithi at nimnet.asn.au Wed Aug 13 04:52:19 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Aug 13 04:52:25 2008 Subject: Named Listen IP In-Reply-To: References: <20080812001925.I24964@sola.nimnet.asn.au> Message-ID: <20080813031552.R37370@sola.nimnet.asn.au> On Mon, 11 Aug 2008, Paul Schmehl wrote: > --On Tuesday, August 12, 2008 01:08:46 +1000 Ian Smith > wrote: > > > On Mon, 11 Aug 2008, Onur Aslan wrote: > > > I am using named for a ns server. Named listening all ips for my > > > machine. But when i reboot machine, my ppp network connecting after > > > started named. named doesn't listening my ppp network's ip. Do you > > > have a solution? > > > > Assuming you have a fixed IP address when ppp comes up, specify that > > address in named's listen-on list. When ppp has connected, assigned its > > addresses and set the default route, have ppp run an up-script that runs > > '/etc/rc.d/named restart'. > > > > named will then see the ppp interface and listen on that address as well > > as any others specified, like localhost. ppp runs its up/down scripts > > as root; you don't need (or want) to have named running as root. > > > > Just wondering - couldn't this be fixed by adding the keyword "network" to > the REQUIRE portion of the /etc/rc.d/named script? (Right now it contains > SERVERS and cleanvar. I'm suggesting adding network.) rcorder (for 5.5 and 7.0 anyway) has ppp starting before named alright. However ppp is exec'd and begins connecting but is not waited for - as a rule fortunately, as even ADSL can take a while, and dialup takes a good long while - before proceeding with the boot, including named. I suppose /etc/rc.d/ppp maybe could be hacked to wait around, up to some timeout anyway, or /etc/rc.d/named could be taught to timed-wait on some indication for such specific cases, but some rcorder dependencies seem hardly resolvable in the 'general case' .. I had the same issue with mpd on ADSL recently after a rare reboot; still pondering a tidy solution. cheers, Ian (Paul, sorry but your reply-to clues in the headers only confused me) From brutal_hitman_ at hotmail.com Wed Aug 13 06:29:00 2008 From: brutal_hitman_ at hotmail.com (Ben Wittgen) Date: Wed Aug 13 06:29:07 2008 Subject: (no subject) Message-ID: Hey, I'm new here and an overall FreeBSD newbie. I use pfSense for routing,www.pfsense.org, which uses FreeBSD. I got onto my computer this morning to find my internet had been dropped, no wan or LAN or webGUI, router was still on, so i turned on the monitor that was plugged into the router there were messages being spammed and i could no longer type anything, it completely locked up. it was spamming this:em0: discard frame w/o packet headerem0: discard frame w/o packet headerem0: discard frame w/o packet headerem0: discard frame w/o packet headerre0: discard frame w/o packet headerem0: discard frame w/o packet headerand it was randomly interchanging re0 and em0.im using pfsense 1.2.1-RC1 built on Mon Aug 4 22:05:47 EDT 2008, and the OS version is FreeBSD 7.0. I get this error after about 4-5 days and my wireless goes under heavy load. let me know any more information i need to provide and how to obtain it if it requires logs and i'll be glad to. thanks. _________________________________________________________________ Your PC, mobile phone, and online services work together like never before. http://clk.atdmt.com/MRT/go/108587394/direct/01/ From viper at perm.raid.ru Wed Aug 13 06:34:43 2008 From: viper at perm.raid.ru (Vladimir Korkodinov) Date: Wed Aug 13 06:34:51 2008 Subject: arp - strange things In-Reply-To: <17499.212.33.232.121.1217925622.squirrel@mail.raid.ru> References: <17499.212.33.232.121.1217925622.squirrel@mail.raid.ru> Message-ID: <48912.212.33.232.121.1218609280.squirrel@mail.raid.ru> >From today FreeBSD 7.0-STABLE #7: Wed Aug 13 11:30:49 YEKST 2008 How fix problem? Any suggestion? ? (10.100.8.118) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at 00:1a:4b:dd:84:a0 on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] ? (10.100.10.190) at (incomplete) on bce1 [ethernet] arp -ad 10.100.8.118 (10.100.8.118) deleted delete: cannot locate 10.100.8.118 10.100.10.40 (10.100.10.40) deleted 10.100.10.190 (10.100.10.190) deleted delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 delete: cannot locate 10.100.10.190 uptime 12:33PM up 45 mins arp -an | grep incom | wc -l 245 > I csup my server from Jul 14 to today sources and saw strange issue > with arp table. > Long description see below. > > Do you have the same "issue" on your own servers? > > Partial reverting > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c > Revision 1.162.2.2 seems fix problem. > > +#if 0 /* -current */ /* Only call this once */ > if (firstpass) { > sin.sin_addr.s_addr = isaddr.s_addr; > EVENTHANDLER_INVOKE(route_arp_update_event, rt, > ar_sha(ah), (struct sockaddr *)&sin); > } > +#endif > > Long description: > > Environment: > uname -a > FreeBSD monitor 7.0-STABLE FreeBSD 7.0-STABLE #5: Tue Aug 5 > 13:15:24 YEKST 2008 root@monitor:/usr/obj/usr/src/sys/kernel > amd64 > > Description: > arp -an > ? (10.100.8.118) at 00:1c:c4:3d:f0:b8 on bce1 [ethernet] > ? (10.100.8.118) at (incomplete) on bce1 [ethernet] > ............. > ? (10.100.10.190) at 00:1a:4b:dd:84:a0 on bce1 [ethernet] > ? (10.100.10.190) at (incomplete) on bce1 [ethernet] > ? (10.100.10.190) at (incomplete) on bce1 [ethernet] > ? (10.100.10.190) at (incomplete) on bce1 [ethernet] > ? (10.100.10.190) at (incomplete) on bce1 [ethernet] > ................ > ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent > [ethernet] > ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent > [ethernet] > ? (212.xxx.xxx.xxx) at 00:1e:0b:91:15:08 on bce0 permanent > [ethernet] > > > route monitor > > got message of size 296 on Tue Aug 5 14:08:23 2008 > RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 > > got message of size 296 on Tue Aug 5 14:09:11 2008 > RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 > > got message of size 296 on Tue Aug 5 14:09:12 2008 > RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 > > got message of size 296 on Tue Aug 5 14:09:12 2008 > RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 > > got message of size 296 on Tue Aug 5 14:09:17 2008 > RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 > > got message of size 296 on Tue Aug 5 14:09:17 2008 > RTM_ADD: Add Route: len 296, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 10.100.10.190 bce1:0.1e.b.91.15.6 10.100.200.120 > > -- > Best regards > Vladimir Korkodinov > -- Best regards Vladimir Korkodinov From damien.deville at netasq.com Wed Aug 13 15:20:36 2008 From: damien.deville at netasq.com (Damien Deville) Date: Wed Aug 13 15:20:42 2008 Subject: RELENG_7 crash in if_vlan Message-ID: <48A2FBBD.1000503@netasq.com> Hi, On today's checkout of RELENG_7 it is possible to crash the system using the following commands: ifconfig vlan0 create ifconfig vlan0 -vlandev Crash is located in if_vlan.c in vlan_unconfig_locked() when dereferencing a NULL pointer (ifv->ifv_trunk) to access parent interface using PARENT macro. Damien -- Damien Deville R&D engineer damien.deville@netasq.com http://www.netasq.com NETASQ - We secure IT From jfvogel at gmail.com Wed Aug 13 22:31:43 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Aug 13 22:31:49 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE Message-ID: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> There is a change that has been in the STABLE tree for a few months, but many might have missed it, its an important change to note and possibly for some prepare for with the 7.1 RELEASE. There is a new E1000 network driver, igb, which supports two family of adapters so far: the 82575 and the new 82576. In FreeBSD 7 the support for 82575 was in the em driver, however due to support issues across all the OS's we do drivers for, the decision was made to split the newer drivers off from those before. There are big differences in the register set, and in things like the descriptor format that made this expedient. I made the support for the 82575 available very early in FreeBSD, earlier even than Linux so that certain vendors could have a working driver early. At first I thought to avoid splitting the driver, but support issues are going to make that impractical. So there is a split, its been in HEAD since Febuary, and now 7.1 will release with this change. What this means is that if you have 82575 adapters in a system they are going to change from being 'emX' to being 'igbX', in the RELEASE the install kernel will have both drivers in it, but on an upgrade path, or using a set of scripts that get postinstalled you need to be ready to make this change. How can you tell if you have such a device: Simple, use pciconf, there are only 3 ID's that are effected: 0x10A7, 0x10A9, and 0x10D6. If you have questions feel free to email me. Cheers, Jack Vogel Intel Lan Access Division From paul at gtcomm.net Thu Aug 14 03:11:19 2008 From: paul at gtcomm.net (Paul) Date: Thu Aug 14 03:11:25 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE In-Reply-To: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> Message-ID: <48A3A2DA.8030404@gtcomm.net> Hi Jack. Will the em driver ever support the multiple hardware queues of the 82571 or are we just stuck with the standard em driver? Has there been any significant change in the em driver itself ? I have a feeling that the 82571 should be in the igb driver but for some reason it isn't. I am curious because we have a LOT of 4 port 82571 PCI-E cards and they are not cheap. :] Thanks Paul Jack Vogel wrote: > There is a change that has been in the STABLE tree for a few months, > but many might have missed it, > its an important change to note and possibly for some prepare for with > the 7.1 RELEASE. > > There is a new E1000 network driver, igb, which supports two family of > adapters so far: the > 82575 and the new 82576. In FreeBSD 7 the support for 82575 was in > the em driver, however > due to support issues across all the OS's we do drivers for, the > decision was made to split the > newer drivers off from those before. There are big differences in the > register set, and in things > like the descriptor format that made this expedient. > > I made the support for the 82575 available very early in FreeBSD, > earlier even than Linux so > that certain vendors could have a working driver early. At first I > thought to avoid splitting the > driver, but support issues are going to make that impractical. So > there is a split, its been in > HEAD since Febuary, and now 7.1 will release with this change. > > What this means is that if you have 82575 adapters in a system they > are going to change > from being 'emX' to being 'igbX', in the RELEASE the install kernel > will have both drivers > in it, but on an upgrade path, or using a set of scripts that get > postinstalled you need to > be ready to make this change. > > How can you tell if you have such a device: Simple, use pciconf, there > are only 3 ID's > that are effected: 0x10A7, 0x10A9, and 0x10D6. > > If you have questions feel free to email me. > > Cheers, > > Jack Vogel > Intel Lan Access Division > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From jfvogel at gmail.com Thu Aug 14 04:35:45 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Aug 14 04:35:57 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE In-Reply-To: <48A3A2DA.8030404@gtcomm.net> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> <48A3A2DA.8030404@gtcomm.net> Message-ID: <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> On Wed, Aug 13, 2008 at 8:13 PM, Paul wrote: > Hi Jack. Will the em driver ever support the multiple hardware queues of > the 82571 or are we just stuck with the standard em driver? > Has there been any significant change in the em driver itself ? > I have a feeling that the 82571 should be in the igb driver but for some > reason it isn't. I am curious because we have a LOT of 4 port 82571 PCI-E > cards and they are not cheap. :] Hey Paul, You are right, quad port cards aren't cheap, Intel has sold them even back in a PCI-X based system. And the one you are talking about was released since I have been in this job, so pretty new :) However, they will never support multiple queues, the reason being that in order to do this you need multple MSI vectors, in other words, MSIX. Still, they are very handy, they do support MSI, but just one per interface. Oh, and I debated about where to make the cutoff line on the em/igb split and decided the best thing to do was to follow Linux. The biggest difference between the two drivers is that those in the igb use a different descriptor format, called 'advanced descriptors'. The split does NOT mean that em is now fixed. Quite the contrary, the em driver that was just MFC'd into STABLE has support for what I think is going to be the coolest new consumer adapter out there, called 82574, code name Hartwell, and also for ICH10. Both these two new interfaces have IEEE 1588 Precision Time Protocol support, something that is becoming important for networked multimedia applications. Oh, and Hartwell is the first adapter in the em driver that actually does multiqueue, although in a limited fashion, it does MSIX. This adapter is made at a lower cost point, but it has really nice features. I only wish the new motherboard that I bought had them rather than ICH9 but oh well :) I predict they are going to be selling like hotcakes before the end of year. I will continue to share fixes between the em and igb drivers as they are applicable. I still think a real legacy driver for the oldest adapters would be a good idea, just so they don't get broken by new development, with as many as we support regression testing is already not being done adequately. I just have not had time to think about this yet, it may be coming, it would probably be for everything that was not PCI Express. Hope the info was helpful, I'm always happy to answer questions, Jack From paul at gtcomm.net Thu Aug 14 05:00:15 2008 From: paul at gtcomm.net (Paul) Date: Thu Aug 14 05:00:30 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE In-Reply-To: <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> <48A3A2DA.8030404@gtcomm.net> <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> Message-ID: <48A3BC67.3050905@gtcomm.net> The hardware spec sheet says it does support multi queue but only MSI, so I would suspect it is disabled by default since that would (maybe) cause performance to be less. Would it take advantage of multiple cpus to turn on the multiple queues even without MSIX? (i.e. having more than 1 taskq in freebsd per interface for receives/sends) It should still do per-vector masking so it couldn't be THAT bad with the multi queues enabled but there's probably a good reason why they are disabled by default eh? Would be fun to test it out though :> :> I think even if the driver / bsd split it up into multiple taskq's so it would take advantage of SMP better that it would work, but that might require some modifications outside of the driver level (which I can think of a lot) but I guess i"m hoping for an easier solution so I don't have to go replacing all these 82571EB cards.. They work great, but the cpus are running out.. Having 3 or 4 idle cpus while the other ones are struggling due to network load and dropping packets is aggravating :) Will the 82575/6 cards alleviate that problem or will I still be faced with the same issue (due to os limitations)? I plan on buying the dual port ET controller[82576] (which was supoosed to be shipping last month) but I can't find one anywhere! argh.. Thanks Paul Jack Vogel wrote: > On Wed, Aug 13, 2008 at 8:13 PM, Paul wrote: > >> Hi Jack. Will the em driver ever support the multiple hardware queues of >> the 82571 or are we just stuck with the standard em driver? >> Has there been any significant change in the em driver itself ? >> I have a feeling that the 82571 should be in the igb driver but for some >> reason it isn't. I am curious because we have a LOT of 4 port 82571 PCI-E >> cards and they are not cheap. :] >> > > Hey Paul, > > You are right, quad port cards aren't cheap, Intel has sold them > even back in a > PCI-X based system. And the one you are talking about was released since I > have been in this job, so pretty new :) However, they will never > support multiple > queues, the reason being that in order to do this you need multple MSI vectors, > in other words, MSIX. Still, they are very handy, they do support MSI, but just > one per interface. Oh, and I debated about where to make the cutoff line on the > em/igb split and decided the best thing to do was to follow Linux. The biggest > difference between the two drivers is that those in the igb use a > different descriptor > format, called 'advanced descriptors'. > > The split does NOT mean that em is now fixed. Quite the contrary, > the em driver > that was just MFC'd into STABLE has support for what I think is going to be the > coolest new consumer adapter out there, called 82574, code name Hartwell, and > also for ICH10. Both these two new interfaces have IEEE 1588 Precision Time > Protocol support, something that is becoming important for networked multimedia > applications. Oh, and Hartwell is the first adapter in the em driver > that actually > does multiqueue, although in a limited fashion, it does MSIX. This > adapter is made > at a lower cost point, but it has really nice features. I only wish > the new motherboard > that I bought had them rather than ICH9 but oh well :) I predict they > are going to > be selling like hotcakes before the end of year. > > I will continue to share fixes between the em and igb drivers as they > are applicable. > I still think a real legacy driver for the oldest adapters would be a > good idea, just so > they don't get broken by new development, with as many as we support regression > testing is already not being done adequately. I just have not had time > to think about > this yet, it may be coming, it would probably be for everything that > was not PCI Express. > > Hope the info was helpful, I'm always happy to answer questions, > > Jack > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From jfvogel at gmail.com Thu Aug 14 05:25:05 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Aug 14 05:25:15 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE In-Reply-To: <48A3BC67.3050905@gtcomm.net> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> <48A3A2DA.8030404@gtcomm.net> <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> <48A3BC67.3050905@gtcomm.net> Message-ID: <2a41acea0808132225s6e77175fnf6780b249ed07058@mail.gmail.com> On Wed, Aug 13, 2008 at 10:02 PM, Paul wrote: > The hardware spec sheet says it does support multi queue but only MSI, so I > would suspect it is disabled by default since that would (maybe) cause > performance to be less. > Would it take advantage of multiple cpus to turn on the multiple queues > even without MSIX? (i.e. having more than 1 taskq in freebsd per interface > for receives/sends) > It should still do per-vector masking so it couldn't be THAT bad with the > multi queues enabled but there's probably a good reason why they are > disabled by default eh? Would be > fun to test it out though :> :> > I think even if the driver / bsd split it up into multiple taskq's so it > would take advantage of SMP better that it would work, but that might > require some modifications outside of the ome of his work within a couple weeks. I have also been working on what performance tweaks I havedriver level (which I can think of > a lot) but I guess i"m hoping for an easier solution so > I don't have to go replacing all these 82571EB cards.. They work great, but > the cpus are running out.. Having 3 or 4 idle cpus while the other ones are > struggling due to network load and dropping packets is aggravating :) Will > the 82575/6 cards alleviate that problem or will I still be faced with the > same issue (due to os limitations)? > I plan on buying the dual port ET controller[82576] (which was supoosed to > be shipping last month) but I can't find one anywhere! argh.. The Linux team here implemented multiqueue based on 82571 3 or 4 years ago, they found that without MSIX it just caused more problems than it was worth and they turned it off again until recently. Linux is in a better position right now, Dave Miller has been hacking madly at their stack and they have pretty complete multiqueue support in the stack. One of my friends here at Intel was responsible for a lot of the work and code along the way. I know there's stack work going on, hopefully all drivers will benefit from that as it comes out. Also Kip Macy has been doing some work for a customer that is based on my igb code, he promised to have some patches back to me in a couple weeks, I'm sure it will be good stuff too. I do not know how hard 82576 is to get right now, it has a TON of potential that I have no where near tapped yet. Before the firedrill the last couple of days I had started on updating the ioatdma driver, which we need so that I can put DCA into the igb driver (Direct Cache Access), that should be a big performance enhancer when I can get it done. Jack From paul at gtcomm.net Thu Aug 14 05:43:40 2008 From: paul at gtcomm.net (Paul) Date: Thu Aug 14 05:43:46 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE In-Reply-To: <2a41acea0808132225s6e77175fnf6780b249ed07058@mail.gmail.com> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> <48A3A2DA.8030404@gtcomm.net> <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> <48A3BC67.3050905@gtcomm.net> <2a41acea0808132225s6e77175fnf6780b249ed07058@mail.gmail.com> Message-ID: <48A3C692.3000909@gtcomm.net> Nice.. Now if they would just optimize the IP stack for SMP and the rest of the drivers we may have a piece of equipment and OS that will compete with the hardware vendor routers :) Full BGP, a few million pps(I hope), and filters.. Nothing does that right now short of Juniper M7i or Cisco SUP720-3b/cxl or 72xx, etc.. Of course the first 2 do it way faster but are also very expensive. Linux is backwards on packet forwarding until they get rid of the route cache, it's almost useless in a service provider environment (millions of flows and hundreds of thousands of new flows per second for instance), although it's still the most flexible. Please keep us updated on any interesting changes to the em/igb/ixgb :> I have ordered an 82575 card and will be testing it along with some other CPUs to fire up my routing performance thread again :> :> Paul > The Linux team here implemented multiqueue based on 82571 3 or 4 years ago, > they found that without MSIX it just caused more problems than it was worth > and they turned it off again until recently. > > Linux is in a better position right now, Dave Miller has been hacking madly at > their stack and they have pretty complete multiqueue support in the stack. One > of my friends here at Intel was responsible for a lot of the work and code along > the way. > > I know there's stack work going on, hopefully all drivers will benefit from that > as it comes out. Also Kip Macy has been doing some work for a customer > that is based on my igb code, he promised to have some patches back to me > in a couple weeks, I'm sure it will be good stuff too. > > I do not know how hard 82576 is to get right now, it has a TON of potential > that I have no where near tapped yet. Before the firedrill the last couple of > days I had started on updating the ioatdma driver, which we need so that > I can put DCA into the igb driver (Direct Cache Access), that should be a > big performance enhancer when I can get it done. > > Jack > > From gnn at freebsd.org Thu Aug 14 17:51:59 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Thu Aug 14 17:52:06 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE In-Reply-To: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> Message-ID: Hi Jack, Thanks for this and for the concise pciconf line. We use em (soon to be igb) interfaces extensively at work. Best, George From rfrench at freebsd.org Sat Aug 16 01:56:28 2008 From: rfrench at freebsd.org (Ryan French) Date: Sat Aug 16 01:56:35 2008 Subject: .pru_attach and kernel warnings Message-ID: <200808161356.26891.rfrench@freebsd.org> Hi everyone, I'm having issues with trying to build my kernel at the moment with my MPLS development code included. I'm trying to build a pr_usrreqs struct and with my attach method I am getting the warning 'initialization from incompatible pointer type', but as far as I can see the way I have done it is the same as other protocols. static int mpls_attach(struct socket *so) { int error = 0; if (so->so_snd.sb_hiwat == 0 || so->so_rcv.sb_hiwat == 0) { error = soreserve(so, mpls_raw_sendspace, mpls_raw_recvspace); return error; } else return EOPNOTSUPP; } struct pr_usrreqs mpls_raw_usrreq = { .pru_accept = pru_accept_notsupp, .pru_attach = mpls_attach, .pru_bind = pru_bind_notsupp, .pru_connect = pru_connect_notsupp, .pru_connect2 = pru_connect2_notsupp, .pru_control = mpls_control, .pru_disconnect = pru_disconnect_notsupp, .pru_listen = pru_listen_notsupp, .pru_peeraddr = pru_peeraddr_notsupp, .pru_rcvd = pru_rcvd_notsupp, .pru_rcvoob = pru_rcvoob_notsupp, .pru_send = pru_send_notsupp, .pru_sense = pru_sense_null, .pru_shutdown = pru_shutdown_notsupp, .pru_sockaddr = pru_sockaddr_notsupp, .pru_sosend = pru_sosend_notsupp, .pru_soreceive = pru_soreceive_notsupp, .pru_sopoll = pru_sopoll_notsupp }; Should I ignore this warning or is there a problem with my code that I'm missing? Thanks for any help. From linimon at FreeBSD.org Sat Aug 16 03:07:51 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Aug 16 03:07:58 2008 Subject: kern/126561: [nlm] NLM (rpclockd) RPC UNLOCK failure (stalls Mac OS X Finder, iTunes, etc?) Message-ID: <200808160307.m7G37pUK057819@freefall.freebsd.org> Old Synopsis: NLM (rpclockd) RPC UNLOCK failure (stalls Mac OS X Finder, iTunes, etc?) New Synopsis: [nlm] NLM (rpclockd) RPC UNLOCK failure (stalls Mac OS X Finder, iTunes, etc?) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Aug 16 03:06:30 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126561 From wollman at hergotha.csail.mit.edu Sat Aug 16 05:40:22 2008 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Sat Aug 16 05:40:29 2008 Subject: .pru_attach and kernel warnings In-Reply-To: <200808161356.26891.rfrench@freebsd.org> Message-ID: <200808160511.m7G5BEb1083707@hergotha.csail.mit.edu> In article <200808161356.26891.rfrench@freebsd.org>, rfrench@freebsd.org writes: >static int >mpls_attach(struct socket *so) The prototype for a protocol attach functions is int (*pru_attach)(struct socket *so, int proto, struct thread *td); (see sys/protosw.h). You don't have to use these arguments, but you do have to declare them properly. -GAWollman From gavin at FreeBSD.org Sat Aug 16 12:37:16 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Aug 16 12:37:28 2008 Subject: kern/126564: [ath] doesn't work with my PCI-E X1 wireless network adaptor Message-ID: <200808161237.m7GCbFY3061248@freefall.freebsd.org> Synopsis: [ath] doesn't work with my PCI-E X1 wireless network adaptor State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Sat Aug 16 12:35:46 UTC 2008 State-Changed-Why: To submitter: can you try the updated HAL from http://people.freebsd.org/~sam/ath_hal-20080528.tgz (unpack into /usr/src/sys/contrib/ath) and see if that fixes theings for you? Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Aug 16 12:35:46 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=126564 From mo0118 at gmail.com Sun Aug 17 00:11:11 2008 From: mo0118 at gmail.com (Jeff Mo) Date: Sun Aug 17 00:20:30 2008 Subject: Need Help! In-Reply-To: References: Message-ID: Dear All , After I run the following commands three times, 1 ifconfig gre0 create 2 ifconfig gre0 tunnel 10.101.1.1 10.101.1.2 netmask 255.255.255.255 3 ifconfig gre0 destroy I found something weird: 1. in /var/log/messages , line 907 , there should be TAILQ_REMOVE because of ifconfig gre0 destroy, but nothing happened. 2. when i do the command second time, ia1=0xc2df1600 supposed not be there. 3. Some thing wrong with line 914,915,920,921,931,932,937,938 4. does "ifconfig gre0 destroy" causes TAILQ_REMOVE be called? Please nicely give me some comments. Thanks and Regards Jeff /var/log/messages first time 895 Aug 16 16:30:11 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc2df1600 896 Aug 16 16:30:11 JeffMo kernel: TAILQ_INSERT_TAIL:ia->ia_ifp=0xc27d6c00 897 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00 898 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 899 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00 900 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 901 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00 902 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 903 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00 904 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 905 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600 906 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6c00 907 Aug 16 16:30:11 JeffMo kernel: second time 908 Aug 16 16:30:34 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc3144d00 909 Aug 16 16:30:34 JeffMo kernel: TAILQ_INSERT_TAIL:ia->ia_ifp=0xc27d1c00 910 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00 911 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 912 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00 913 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 914 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc2df1600 915 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0x3e391 916 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00 917 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 918 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00 919 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 920 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600 921 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0x3e391 922 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc3144d00 923 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d1c00 924 Aug 16 16:30:34 JeffMo kernel: third time 925 Aug 16 16:30:57 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc3145800 926 Aug 16 16:30:57 JeffMo kernel: TAILQ_INSERT_TAIL:ia->ia_ifp=0xc2812400 927 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00 928 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 929 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00 930 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 931 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc2df1600 932 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0 933 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00 934 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 935 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00 936 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 937 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600 938 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0 #diff -uw in.c.ori in.c --- in.c.ori 2008-08-16 13:50:54.000000000 +0000 +++ in.c 2008-08-16 16:43:29.000000000 +0000 @@ -320,7 +320,23 @@ ia->ia_broadaddr.sin_family = AF_INET; } ia->ia_ifp = ifp; + //add by jeff:start + printf("TAILQ_INSERT_TAIL:ia=%p\n" , ia); + printf("TAILQ_INSERT_TAIL:ia->ia_ifp=%p\n" , ia->ia_ifp); + struct in_ifaddr *ia1; + TAILQ_FOREACH(ia1, &in_ifaddrhead, ia_link) { + printf("before TAILQ_FOREACH:ia1=%p\n" , ia1); + printf("before TAILQ_FOREACH:ia1->ia_ifp=%p\n" , ia1->ia_ifp); + } + //add by jeff:end TAILQ_INSERT_TAIL(&in_ifaddrhead, ia, ia_link); + //add by jeff:start + TAILQ_FOREACH(ia1, &in_ifaddrhead, ia_link) { + printf("after TAILQ_FOREACH:ia1=%p\n" , ia1); + printf("after TAILQ_FOREACH:ia1->ia_ifp=%p\n" , ia1->ia_ifp); + } + printf("\n"); + //add by jeff:end splx(s); iaIsNew = 1; } @@ -485,6 +501,7 @@ */ s = splnet(); TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); + printf("TAILQ_REMOVE:ia=%p\n" , ia); TAILQ_REMOVE(&in_ifaddrhead, ia, ia_link); if (ia->ia_addr.sin_family == AF_INET) { LIST_REMOVE(ia, ia_hash); @@ -803,8 +820,9 @@ mask = target->ia_sockmask.sin_addr; prefix.s_addr &= mask.s_addr; } - TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + printf("TAILQ_FOREACH:ia=%p\n", ia); + printf("TAILQ_FOREACH:ia->ia_ifp=%p\n", ia->ia_ifp); if (rtinitflags(ia)) { p = ia->ia_addr.sin_addr; @@ -833,6 +851,7 @@ return (0); } } + printf("\n"); /* * No-one seem to have this prefix route, so we try to insert it. */ From spry at anarchy.in.the.ph Sun Aug 17 06:08:42 2008 From: spry at anarchy.in.the.ph (Mars G Miro) Date: Sun Aug 17 06:08:48 2008 Subject: ng_btsocket_rfcomm_receive_uih: Not enough space ... Message-ID: Hi I use a Bluetooth dongle and do an rfcomm_sppd to my 3G phone for my internet needs. It seems that after a few hours of transferring data, prolly hundreds of megabytes , at some point it Aug 17 04:17:34 firefly kernel: ng_btsocket_rfcomm_receive_uih: Not enough space in socket receive queue. Dropping UIH for dlci=2, state=4, flags=0x2, len=505, space=347 Aug 17 04:17:34 firefly kernel: ng_btsocket_rfcomm_receive_uih: Not enough space in socket receive queue. Dropping UIH for dlci=2, state=4, flags=0x2, len=667, space=347 Aug 17 04:17:34 firefly kernel: ng_btsocket_rfcomm_receive_uih: Not enough space in socket receive queue. Dropping UIH for dlci=2, state=4, flags=0x2, len=505, space=29 then chokes my ppp link: Aug 17 04:20:32 firefly ppp[2715]: tun0: Phase: Clearing choked output queue Aug 17 04:22:33 firefly ppp[2715]: tun0: Phase: Clearing choked output queue Aug 17 04:24:34 firefly ppp[2715]: tun0: Phase: Clearing choked output queue Then my ppp link becomes deaf and dumb, I'd have to kill my ppp and restart my script again. Anybody else experiencing this? This is on FreeBSD-7.0R/i386. Thanks. -- cheers mars From freebsd at chrisbuechler.com Sun Aug 17 19:15:20 2008 From: freebsd at chrisbuechler.com (Chris Buechler) Date: Sun Aug 17 19:15:26 2008 Subject: repeatable scp stalls from 7.0 to 7.0 Message-ID: <48A878C6.9000001@chrisbuechler.com> I've been seeing pretty frequent and repeatable scp stalls between two FreeBSD 7.0 servers (7.0-RELEASE-p2 to be exact) on a 100 Mb LAN. They're two HP servers, an Opteron 275 and a dual Xeon 3.4 (don't recall the models but I can get them if it's relevant) using the onboard bge(4) cards. The client side (builder7) SCPs a file to the server side (hosting7) about 20 times a day. The stall happens about 2-4 times a week or so, and has happened ever since we put these two boxes online in their current functions. Initially they were the original 7.0 release, prior to the TCP fix in June. It's behaved the same way both prior to and after that fix. There are no apparent network issues aside from this with either of the boxes. Since we had nothing to go on other than scp sessions going to "stalled" (no relevant logs), I setup a tcpdump on each end filtering on the TCP 22 traffic between these hosts, grabbing 100 bytes of each frame to avoid chewing up too much disk space. When it happened again I split the end out into its own file with editcap, 4.2-4.3 MB each. http://chrisbuechler.com/temp/lastcut-hosting7.pcap - server end, capture taken on host but destination IP is a jail http://chrisbuechler.com/temp/lastcut-builder7.pcap - client end, connection is initiated from the host, no jails involved. The TCP window on the ACKs from server to client start decrementing [1], to the point where it's down to a window of 0. From that point, everything the server (172.29.29.181 ) sends back to the client (172.29.29.170 ) has a window of 0. Restarting the scp makes it work again. It doesn't happen every time, somewhere around 2-3% of the time it does. I don't see any cause for the decrementing window in those captures but maybe I'm missing something. 1 - lastcut-hosting7.pcap frame #21298; lastcut-builder7.pcap #25088 These are both very stock boxes, GENERIC kernels, no significant changes in sysctl or anything else. I'm not sure where to go from here, any assistance in resolving this would be appreciated. cheers, Chris From bugmaster at FreeBSD.org Mon Aug 18 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:08:13 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200808181106.m7IB6rYe079878@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a 102 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/126339 net [ipw] ipw driver drops the connection 60 problems total. From intron at intron.ac Mon Aug 18 13:26:53 2008 From: intron at intron.ac (Intron is my alias on the Internet) Date: Mon Aug 18 13:27:00 2008 Subject: kern/126564: [ath] doesn't work with my PCI-E X1 wireless network adaptor In-Reply-To: <200808161237.m7GCbFY3061248@freefall.freebsd.org> References: <200808161237.m7GCbFY3061248@freefall.freebsd.org> Message-ID: The new HAL works well with my card. Thank you. ------------------------------------------------------------------------ From Beijing, China gavin@FreeBSD.org ??: > Synopsis: [ath] doesn't work with my PCI-E X1 wireless network adaptor > > State-Changed-From-To: open->feedback > State-Changed-By: gavin > State-Changed-When: Sat Aug 16 12:35:46 UTC 2008 > State-Changed-Why: > To submitter: can you try the updated HAL from > http://people.freebsd.org/~sam/ath_hal-20080528.tgz > (unpack into /usr/src/sys/contrib/ath) and see if that fixes > theings for you? > > > Responsible-Changed-From-To: freebsd-i386->freebsd-net > Responsible-Changed-By: gavin > Responsible-Changed-When: Sat Aug 16 12:35:46 UTC 2008 > Responsible-Changed-Why: > Over to maintainers > > http://www.freebsd.org/cgi/query-pr.cgi?pr=126564 From gavin.atkinson at ury.york.ac.uk Mon Aug 18 14:50:07 2008 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Mon Aug 18 14:50:13 2008 Subject: kern/126564: [ath] doesn't work with my PCI-E X1 wireless Message-ID: <200808181450.m7IEo6Xc004164@freefall.freebsd.org> The following reply was made to PR kern/126564; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126564: [ath] doesn't work with my PCI-E X1 wireless Date: Mon, 18 Aug 2008 15:11:58 +0100 (BST) ---------- Forwarded message ---------- Date: Mon, 18 Aug 2008 20:59:33 +0800 From: Intron is my alias on the Internet To: gavin@FreeBSD.org Cc: freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/126564: [ath] doesn't work with my PCI-E X1 wireless network adaptor The new HAL works well with my card. Thank you. ------------------------------------------------------------------------ From Beijing, China From rfrench at freebsd.org Mon Aug 18 21:13:43 2008 From: rfrench at freebsd.org (Ryan French) Date: Mon Aug 18 21:13:55 2008 Subject: Summer of Code is over!! Message-ID: <200808190913.40316.rfrench@freebsd.org> Hi all, As those of you involved in the Google Summer of Code know, today is the last day of coding for the project. However, I still have a lot to do on my implementation of MPLS, and will continue to work on this until it is working. I would like to say thank you to all of those who have helped me over the course of the program in trying to get this project up and running. With that in mind I have submitted the semi-finished code for trying to get sending and receiving of packets working. Unfortunately I have come up against a bit of a brick wall in terms of trying to figure out the exact inner workings of FreeBSD. At the moment, in theory at least, the sending and receiving of packets should work, however I am stuck as to how to integrate my code properly with the kernel. So far I have created a mpls_init which contains a netisr_register function, as well as inserted the appropriate code into the ether_demux function, but it still does not appear to be running the code when an MPLS packet is received. If anyone would like to look at the code and give me any feedback on how to improve it, or any ideas on how to get it working, it would be greatly appreciated, and I understand it is a very big ask of anyone to look through it, so I will thank you in advance for your time. Thank you for being such a great community and helping me get through this summer of code. No doubt you will be hearing from me on the mailing lists as I continue to try and get this project working, and possibly even move onto other projects. -Ryan French From todor.genov at za.verizonbusiness.com Tue Aug 19 00:58:08 2008 From: todor.genov at za.verizonbusiness.com (Todor Genov) Date: Tue Aug 19 00:58:14 2008 Subject: Possible bug - GRE tunnel routing Message-ID: <48AA1A9D.2040607@za.verizonbusiness.com> Hi everyone, I may have found a routing bug relating to GRE tunnels. Could somebody try and replicate this? As per the setup below GRE-encapsulated traffic to 194.31.254.148 should be going out via tun1, but a tcpdump shows the traffic leaving via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 goes out via tun1 as expected. Configuration: FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 tun0 - PPPoE connection to ISP tun1 - vpn connection to office PIX (via vpnc) gre0 - GRE tunnel to machine sitting behind the PIX tun0: flags=8051 metric 0 mtu 1492 inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 Opened by PID 509 tun1: flags=8051 metric 0 mtu 1500 inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 Opened by PID 984 gre0: flags=9051 metric 0 mtu 1476 tunnel inet 194.31.137.70 --> 194.31.154.148 inet 192.168.254.2 --> 192.168.254.1 netmask 0xffffff00 Routing table: Destination Gateway Flags Refs Use Netif Expire default 41.142.82.1 UGS 1 1365 tun0 41.142.82.1 41.142.82.37 UGH 1 0 tun0 192.168.254.1 192.168.254.2 UH 0 3 gre0 194.31.137.64 194.31.137.70 UH 1 0 tun1 194.31.154.148 194.31.137.64 UGS 0 0 tun1 GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed via tun0 [root@fw ~]# tcpdump -ni tun0 proto gre tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, length 64 ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is routed via tun1 [root@fw ~]# tcpdump -ni tun1 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id 10757, seq 14, length 64 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id 10757, seq 14, length 64 However, if I add a /24 route for the GRE endpoint subnet, instead of a /32 to the host: 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 and then bring up the GRE tunnel, everything works as expected and GRE traffic exits via tun1. -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543 -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543 From julian at elischer.org Tue Aug 19 01:50:49 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 19 01:50:56 2008 Subject: Possible bug - GRE tunnel routing In-Reply-To: <48AA1A9D.2040607@za.verizonbusiness.com> References: <48AA1A9D.2040607@za.verizonbusiness.com> Message-ID: <48AA26FD.20305@elischer.org> Todor Genov wrote: > Hi everyone, > > I may have found a routing bug relating to GRE tunnels. Could somebody > try and replicate this? > > As per the setup below GRE-encapsulated traffic to 194.31.254.148 > should be going out via tun1, but a tcpdump shows the traffic leaving > via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 > goes out via tun1 as expected. > > Configuration: > FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 > tun0 - PPPoE connection to ISP > tun1 - vpn connection to office PIX (via vpnc) > gre0 - GRE tunnel to machine sitting behind the PIX > > tun0: flags=8051 metric 0 mtu 1492 > inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 > Opened by PID 509 > tun1: flags=8051 metric 0 mtu 1500 > inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 > Opened by PID 984 Point to point interfaces really don't have netmasks. Otherwise it wouldn't be "Point to Point", it would be "multicast" like ethernet. There is really only one address at this end or the other end. If you want to say that there is a network at the other end then you really need to set a route for it. but it applies equally to all three of these p2p links. so, add a route: route add 92.168.254.0/24 92.168.254.1 > gre0: flags=9051 metric 0 mtu 1476 > tunnel inet 194.31.137.70 --> 194.31.154.148 > inet 192.168.254.2 --> 92.168.254.1 netmask 0xffffff00 > > Routing table: > Destination Gateway Flags Refs Use Netif Expire > default 41.142.82.1 UGS 1 1365 tun0 > 41.142.82.1 41.142.82.37 UGH 1 0 tun0 > 192.168.254.1 192.168.254.2 UH 0 3 gre0 > 194.31.137.64 194.31.137.70 UH 1 0 tun1 > 194.31.154.148 194.31.137.64 UGS 0 0 tun1 > > GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed > via tun0 Why do you think you need -S? routing takes into account only the destination.. > > [root@fw ~]# tcpdump -ni tun0 proto gre > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes > 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP > 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, > length 64 > > > ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is > routed via tun1 > > [root@fw ~]# tcpdump -ni tun1 icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes > 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id > 10757, seq 14, length 64 > 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id > 10757, seq 14, length 64 > > > However, if I add a /24 route for the GRE endpoint subnet, instead of a > /32 to the host: > > 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 > > and then bring up the GRE tunnel, everything works as expected and GRE > traffic exits via tun1. yes.. that is as expected.. > > > From todor.genov at za.verizonbusiness.com Tue Aug 19 08:47:58 2008 From: todor.genov at za.verizonbusiness.com (Todor Genov) Date: Tue Aug 19 08:48:05 2008 Subject: Possible bug - GRE tunnel routing In-Reply-To: <48AA26FD.20305@elischer.org> References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> Message-ID: <48AA88B4.6040606@za.verizonbusiness.com> Hi Julian, Julian Elischer wrote: > Todor Genov wrote: >> Hi everyone, >> >> I may have found a routing bug relating to GRE tunnels. Could somebody >> try and replicate this? >> >> As per the setup below GRE-encapsulated traffic to 194.31.254.148 >> should be going out via tun1, but a tcpdump shows the traffic leaving >> via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 >> goes out via tun1 as expected. >> >> Configuration: >> FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 >> tun0 - PPPoE connection to ISP >> tun1 - vpn connection to office PIX (via vpnc) >> gre0 - GRE tunnel to machine sitting behind the PIX >> >> tun0: flags=8051 metric 0 mtu 1492 >> inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 >> Opened by PID 509 >> tun1: flags=8051 metric 0 mtu 1500 >> inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 >> Opened by PID 984 > > Point to point interfaces really don't have netmasks. > Otherwise it wouldn't be "Point to Point", it would be > "multicast" like ethernet. > > There is really only one address at this end or the other end. > If you want to say that there is a network at the other end > then you really need to set a route for it. > but it applies equally to all three of these p2p links. > > so, add a route: > > route add 92.168.254.0/24 92.168.254.1 The netmask for tun0 is automatically assigned by the ISP, and for tun1 by the VPN server. The one for gre0 is a /30 in the connect scripts - I must have changed it to /24 somewhere along the troubleshooting process - it makes no difference to the end result. The routing table does include routes to the /26 on tun1 and the /24 on gre0. I have left them out as they are not relevant to the problem. The troublesome route is the one to 194.31.154.148/32 Just noticed that the PtP address for tun1 looks incorrect - with that netmask into account .64 is the network address. I'll look into that as a possible cause. > > > >> gre0: flags=9051 metric 0 mtu >> 1476 >> tunnel inet 194.31.137.70 --> 194.31.154.148 >> inet 192.168.254.2 --> 92.168.254.1 netmask 0xffffff00 >> >> Routing table: >> Destination Gateway Flags Refs Use Netif >> Expire >> default 41.142.82.1 UGS 1 1365 tun0 >> 41.142.82.1 41.142.82.37 UGH 1 0 tun0 >> 192.168.254.1 192.168.254.2 UH 0 3 gre0 >> 194.31.137.64 194.31.137.70 UH 1 0 tun1 >> 194.31.154.148 194.31.137.64 UGS 0 0 tun1 >> >> GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed >> via tun0 > > Why do you think you need -S? routing takes into account only the > destination.. > I am using -S just to make sure that the source IP is the gre0 interface - more of a habit than any particular reason. >> >> [root@fw ~]# tcpdump -ni tun0 proto gre >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode >> listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes >> 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP >> 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, >> length 64 >> >> >> ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is >> routed via tun1 >> >> [root@fw ~]# tcpdump -ni tun1 icmp >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode >> listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes >> 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id >> 10757, seq 14, length 64 >> 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id >> 10757, seq 14, length 64 >> >> >> However, if I add a /24 route for the GRE endpoint subnet, instead of a >> /32 to the host: >> >> 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 >> >> and then bring up the GRE tunnel, everything works as expected and GRE >> traffic exits via tun1. > > yes.. that is as expected.. It is also expected that the /32 route over tun1 to the GRE endpoint (196.31.154.148) should suffice. What puzzles me is the fact that GRE traffic to 196.31.154.138 leaves via tun0 and icmp traffic leaves via tun1. > >> >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From ganbold at micom.mng.net Tue Aug 19 09:09:57 2008 From: ganbold at micom.mng.net (Ganbold) Date: Tue Aug 19 09:10:05 2008 Subject: possibly bridge related problem Message-ID: <48AA8624.5010206@micom.mng.net> Hi, I have strange network problem on my laptop. I can't make connection to my desktop(192.168.0.18) from my laptop. However I can ping to other addresses from my laptop. I can't ping and make connection to my laptop from my desktop either. On the laptop I have bridge created at boot time. When I destroy bridge0 I can ping and make connection to my desktop. Is this known problem? If not where should I look for the problem? Or am I doing something wrong? ... devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Tue Aug 19 15:29:26 ULAT 2008 tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms ^C --- 192.168.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes ^C --- 192.168.0.18 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss devil# ifconfig -a bge0: flags=8943 metric 0 mtu 1500 options=98 ether 00:14:22:fb:32:a6 inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 00:14:22:fb:32:a6 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 2000000 member: bge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 20000 tap0: flags=8902 metric 0 mtu 1500 ether 00:bd:4b:1b:00:00 tun0: flags=8051 metric 0 mtu 1500 inet 192.168.10.34 --> 192.168.10.33 netmask 0xffffffff Opened by PID 802 devil# kldstat Id Refs Address Size Name 1 22 0xc0400000 701a64 kernel 2 1 0xc0b02000 5844 if_tap.ko 3 1 0xc0b08000 15524 snd_hda.ko 4 2 0xc0b1e000 52a08 sound.ko 5 2 0xc0b71000 10ebc drm.ko 6 1 0xc0b82000 71c4 i915.ko 7 1 0xc0b8a000 1fe68 kqemu.ko 8 1 0xc0baa000 b8c8 aio.ko 9 1 0xc0bb6000 6b3d0 acpi.ko 10 1 0xc433b000 9000 if_bridge.ko 11 1 0xc4344000 6000 bridgestp.ko 12 2 0xc44c2000 d000 ipfw.ko 13 1 0xc44fb000 4000 ipdivert.ko 14 1 0xc452a000 22000 linux.ko 15 1 0xc45a6000 e000 fuse.ko devil# more /etc/rc.conf cloned_interfaces="bridge0 tap0" firewall_enable="YES" firewall_quiet="NO" firewall_script="/etc/rc.firewall" firewall_type="open" gateway_enable="YES" hostname="devil.micom.mng.net" ifconfig_bge0="DHCP" ifconfig_bridge0="addm bge0 addm tap0 up" inetd_enable="YES" natd_enable="YES" # Enable natd (if firewall_enable == YES). natd_interface="bge0" # Public interface or IPaddress to use. openvpn_enable="YES" openvpn_if="tun" devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 00100 4 200 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 65000 383 33187 allow ip from any to any 65535 0 0 deny ip from any to any devil# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGS 0 205 bge0 127.0.0.1 127.0.0.1 UH 0 2 lo0 192.168.0.0/24 link#1 UC 0 0 bge0 192.168.0.1 00:e0:29:3b:5a:b0 UHLW 2 10 bge0 1099 192.168.10.0/24 192.168.10.33 UGS 0 0 tun0 192.168.10.33 192.168.10.34 UH 1 0 tun0 ... thanks, Ganbold -- Algol-60 surely must be regarded as the most important programming language yet developed. -- T. Cheatham From pluknet at gmail.com Tue Aug 19 09:56:34 2008 From: pluknet at gmail.com (pluknet) Date: Tue Aug 19 09:56:42 2008 Subject: possibly bridge related problem In-Reply-To: <48AA8624.5010206@micom.mng.net> References: <48AA8624.5010206@micom.mng.net> Message-ID: 2008/8/19 Ganbold : > Hi, > > I have strange network problem on my laptop. > I can't make connection to my desktop(192.168.0.18) from my laptop. > However I can ping to other addresses from my laptop. > I can't ping and make connection to my laptop from my desktop either. > > On the laptop I have bridge created at boot time. > When I destroy bridge0 I can ping and make connection to my desktop. > Is this known problem? If not where should I look for the problem? > Or am I doing something wrong? > > ... > devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE > #8: Tue Aug 19 15:29:26 ULAT 2008 > tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 > devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes > 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms > 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms > 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms > ^C > --- 192.168.0.1 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms > > devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes > ^C > --- 192.168.0.18 ping statistics --- > 4 packets transmitted, 0 packets received, 100.0% packet loss > > devil# ifconfig -a bge0: > flags=8943 metric 0 mtu 1500 > options=98 > ether 00:14:22:fb:32:a6 > inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (1000baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 bridge0: > flags=8843 metric 0 mtu 1500 > ether 00:14:22:fb:32:a6 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 2000000 > member: bge0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 20000 > tap0: flags=8902 metric 0 mtu 1500 > ether 00:bd:4b:1b:00:00 > tun0: flags=8051 metric 0 mtu 1500 > inet 192.168.10.34 --> 192.168.10.33 netmask 0xffffffff Opened by PID > 802 > > devil# kldstat Id Refs Address Size Name > 1 22 0xc0400000 701a64 kernel > 2 1 0xc0b02000 5844 if_tap.ko > 3 1 0xc0b08000 15524 snd_hda.ko > 4 2 0xc0b1e000 52a08 sound.ko > 5 2 0xc0b71000 10ebc drm.ko > 6 1 0xc0b82000 71c4 i915.ko > 7 1 0xc0b8a000 1fe68 kqemu.ko > 8 1 0xc0baa000 b8c8 aio.ko > 9 1 0xc0bb6000 6b3d0 acpi.ko > 10 1 0xc433b000 9000 if_bridge.ko > 11 1 0xc4344000 6000 bridgestp.ko > 12 2 0xc44c2000 d000 ipfw.ko > 13 1 0xc44fb000 4000 ipdivert.ko > 14 1 0xc452a000 22000 linux.ko > 15 1 0xc45a6000 e000 fuse.ko > > devil# more /etc/rc.conf > cloned_interfaces="bridge0 tap0" > firewall_enable="YES" > firewall_quiet="NO" > firewall_script="/etc/rc.firewall" > firewall_type="open" > gateway_enable="YES" > hostname="devil.micom.mng.net" > > ifconfig_bge0="DHCP" > ifconfig_bridge0="addm bge0 addm tap0 up" > inetd_enable="YES" > > natd_enable="YES" # Enable natd (if firewall_enable == YES). > natd_interface="bge0" # Public interface or IPaddress to use. > openvpn_enable="YES" > openvpn_if="tun" > > > devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 > 00100 4 200 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 > 65000 383 33187 allow ip from any to any > 65535 0 0 deny ip from any to any > > devil# netstat -rn Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.0.1 UGS 0 205 bge0 > 127.0.0.1 127.0.0.1 UH 0 2 lo0 > 192.168.0.0/24 link#1 UC 0 0 bge0 > 192.168.0.1 00:e0:29:3b:5a:b0 UHLW 2 10 bge0 1099 > 192.168.10.0/24 192.168.10.33 UGS 0 0 tun0 > 192.168.10.33 192.168.10.34 UH 1 0 tun0 > Hi, I guess you got that buggy window in 7-stable between [1] and the fix, that would come [2] in 7-stable in a few days. [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=180364 [2] http://svn.freebsd.org/viewvc/base?view=revision&revision=181824 wbr, pluknet From ganbold at micom.mng.net Tue Aug 19 10:47:19 2008 From: ganbold at micom.mng.net (Ganbold) Date: Tue Aug 19 10:47:26 2008 Subject: possibly bridge related problem In-Reply-To: References: <48AA8624.5010206@micom.mng.net> Message-ID: <48AAA4B4.2060700@micom.mng.net> pluknet wrote: > 2008/8/19 Ganbold : > >> Hi, >> >> I have strange network problem on my laptop. >> I can't make connection to my desktop(192.168.0.18) from my laptop. >> However I can ping to other addresses from my laptop. >> I can't ping and make connection to my laptop from my desktop either. >> >> On the laptop I have bridge created at boot time. >> When I destroy bridge0 I can ping and make connection to my desktop. >> Is this known problem? If not where should I look for the problem? >> Or am I doing something wrong? >> >> ... >> devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE >> #8: Tue Aug 19 15:29:26 ULAT 2008 >> tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 >> devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes >> 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms >> 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms >> 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms >> ^C >> --- 192.168.0.1 ping statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms >> >> devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes >> ^C >> --- 192.168.0.18 ping statistics --- >> 4 packets transmitted, 0 packets received, 100.0% packet loss >> >> devil# ifconfig -a bge0: >> flags=8943 metric 0 mtu 1500 >> options=98 >> ether 00:14:22:fb:32:a6 >> inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255 >> media: Ethernet autoselect (1000baseTX ) >> status: active >> lo0: flags=8049 metric 0 mtu 16384 >> inet 127.0.0.1 netmask 0xff000000 bridge0: >> flags=8843 metric 0 mtu 1500 >> ether 00:14:22:fb:32:a6 >> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >> maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >> member: tap0 flags=143 >> ifmaxaddr 0 port 4 priority 128 path cost 2000000 >> member: bge0 flags=143 >> ifmaxaddr 0 port 1 priority 128 path cost 20000 >> tap0: flags=8902 metric 0 mtu 1500 >> ether 00:bd:4b:1b:00:00 >> tun0: flags=8051 metric 0 mtu 1500 >> inet 192.168.10.34 --> 192.168.10.33 netmask 0xffffffff Opened by PID >> 802 >> >> devil# kldstat Id Refs Address Size Name >> 1 22 0xc0400000 701a64 kernel >> 2 1 0xc0b02000 5844 if_tap.ko >> 3 1 0xc0b08000 15524 snd_hda.ko >> 4 2 0xc0b1e000 52a08 sound.ko >> 5 2 0xc0b71000 10ebc drm.ko >> 6 1 0xc0b82000 71c4 i915.ko >> 7 1 0xc0b8a000 1fe68 kqemu.ko >> 8 1 0xc0baa000 b8c8 aio.ko >> 9 1 0xc0bb6000 6b3d0 acpi.ko >> 10 1 0xc433b000 9000 if_bridge.ko >> 11 1 0xc4344000 6000 bridgestp.ko >> 12 2 0xc44c2000 d000 ipfw.ko >> 13 1 0xc44fb000 4000 ipdivert.ko >> 14 1 0xc452a000 22000 linux.ko >> 15 1 0xc45a6000 e000 fuse.ko >> >> devil# more /etc/rc.conf >> cloned_interfaces="bridge0 tap0" >> firewall_enable="YES" >> firewall_quiet="NO" >> firewall_script="/etc/rc.firewall" >> firewall_type="open" >> gateway_enable="YES" >> hostname="devil.micom.mng.net" >> >> ifconfig_bge0="DHCP" >> ifconfig_bridge0="addm bge0 addm tap0 up" >> inetd_enable="YES" >> >> natd_enable="YES" # Enable natd (if firewall_enable == YES). >> natd_interface="bge0" # Public interface or IPaddress to use. >> openvpn_enable="YES" >> openvpn_if="tun" >> >> >> devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 >> 00100 4 200 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 >> 65000 383 33187 allow ip from any to any >> 65535 0 0 deny ip from any to any >> >> devil# netstat -rn Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 192.168.0.1 UGS 0 205 bge0 >> 127.0.0.1 127.0.0.1 UH 0 2 lo0 >> 192.168.0.0/24 link#1 UC 0 0 bge0 >> 192.168.0.1 00:e0:29:3b:5a:b0 UHLW 2 10 bge0 1099 >> 192.168.10.0/24 192.168.10.33 UGS 0 0 tun0 >> 192.168.10.33 192.168.10.34 UH 1 0 tun0 >> >> > > Hi, > > I guess you got that buggy window in 7-stable between [1] and the fix, > that would come [2] in 7-stable in a few days. > > [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=180364 > [2] http://svn.freebsd.org/viewvc/base?view=revision&revision=181824 > Thanks a lot. After applying the patch it seems it is working OK now :) Ganbold > wbr, > pluknet > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- The Pig, if I am not mistaken, Gives us ham and pork and Bacon. Let others think his heart is big, I think it stupid of the Pig. -- Ogden Nash From smithi at nimnet.asn.au Tue Aug 19 13:12:16 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Aug 19 13:12:23 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <48926C02.6030308@elischer.org> Message-ID: On Thu, 31 Jul 2008, Julian Elischer wrote: > looking int he code I noticed that the following command gave > no error but didn't work.. > > > ipfw add 1000 skipto tablearg ip from any to table(31) Content addressible branching is an elegant and useful idea, thanks for making it work. A simple example in ipfw(8) might promote 'uptake'? > and as I have a use for that, I implemented it.. MFC to 6 possible? likely? I know there's lots of other stuff that hasn't / won't / can't be, but this one looked perhaps stand-alone .. > see attached patch... (hopefully not stripped) > > Of course it is hoped that the rules you are skipping to are nearby > as it iterates through the rules following the skipto to find the > target, Until $someone adds a direct skipto target jump at the virtual machine code level - big recalc hit when adding/deleting rules/sets I suppose - it's still the fastest way to get from a to b, where b > a Speaking of which, should ipfw whinge when asked to skip backwards, which it can't, confirmed on a recent browse re Mike's ipfw-classifyd and a local test months ago. > but.... > if you had a thousand table entries and wanted to sort them into > 20 buckets, it could save you puting them into 20 different > tables and doing 20 table lookups on them. Or even just for quick basic traffic-splitting, bogon lists, whatever .. > here I sort into two categories.. possibly already a win.. > > > julian@trafmon2:cat ipfw-test.sh > #!/bin/sh > ipfw add 100 skipto 10000 ip from any to not 1.1.1.0/24 > ipfw add 1000 skipto tablearg ip from any to "table(31)" > ipfw add 2000 drop ip from any to any > ipfw add 2001 drop ip from any to any > ipfw add 3000 drop ip from any to any > ipfw add 3001 drop ip from any to any > ipfw add 10000 count ip from any to any > ipfw table 31 add 1.1.1.1 2000 > ipfw table 31 add 1.1.1.2 3000 > > julian@trafmon2: ping 1.1.1.1 > [...] (2 packets bounced) > julian@trafmon2: ping 1.1.1.2 > [...] (12 packets bounced) > > julian@trafmon2: ipfw show > 00100 220 19633 skipto 10000 ip from any to not 1.1.1.0/24 > 01000 14 1176 skipto tablearg ip from any to table(31) > 02000 2 168 deny ip from any to any > 02001 0 0 deny ip from any to any > 03000 12 1008 deny ip from any to any > 03001 0 0 deny ip from any to any > 10000 209 18549 count ip from any to any > 65535 1751 153792 allow ip from any to any > > > comments? I like it, FWIW. > + if (tablearg != 0) { > + rulenum = (u_int16_t)tablearg; Should we check that tablearg is < 64K before merrily casting? cheers, Ian From rizzo at iet.unipi.it Tue Aug 19 13:47:03 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Aug 19 13:47:19 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: References: <48926C02.6030308@elischer.org> Message-ID: <20080819133101.GA23276@onelab2.iet.unipi.it> On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > On Thu, 31 Jul 2008, Julian Elischer wrote: ... > > ipfw add 1000 skipto tablearg ip from any to table(31) ... > > see attached patch... (hopefully not stripped) > > > > Of course it is hoped that the rules you are skipping to are nearby > > as it iterates through the rules following the skipto to find the > > target, > > Until $someone adds a direct skipto target jump at the virtual machine > code level - big recalc hit when adding/deleting rules/sets I suppose - > it's still the fastest way to get from a to b, where b > a you mean with tables-based skipto targets ? Because the regular skipto has been a constant-time op forever, even in ipfw1 i believe, invalidating the target cache on a change and recomputing it the fly at the first request. > Speaking of which, should ipfw whinge when asked to skip backwards, > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > and a local test months ago. right... but the error can only be reliably detected in the kernel, as the rule number is not always known when the rule is added. cheers luigi From smithi at nimnet.asn.au Tue Aug 19 18:06:21 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Aug 19 18:06:33 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080819133101.GA23276@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> Message-ID: <20080820031409.V41971@sola.nimnet.asn.au> On Tue, 19 Aug 2008, Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > > On Thu, 31 Jul 2008, Julian Elischer wrote: > ... > > > ipfw add 1000 skipto tablearg ip from any to table(31) > ... > > > see attached patch... (hopefully not stripped) > > > > > > Of course it is hoped that the rules you are skipping to are nearby > > > as it iterates through the rules following the skipto to find the > > > target, > > > > Until $someone adds a direct skipto target jump at the virtual machine > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > it's still the fastest way to get from a to b, where b > a > > you mean with tables-based skipto targets ? Because the regular > skipto has been a constant-time op forever, even in ipfw1 i believe, > invalidating the target cache on a change and recomputing it the > fly at the first request. Thanks; I'd completely missed the caching of skipto targets before, and it's all so well commented too. blushing, but glad for the good news. But yes I was pondering Julian's patch, which has to lookup_next_rule every time, and also Mike's bending of divert reentry rule number in ipfw-classifyd with similar intent, which also has to hunt forward in linear time for its target rule - or am I missing something else here? > > Speaking of which, should ipfw whinge when asked to skip backwards, > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > and a local test months ago. > > right... but the error can only be reliably detected in the kernel, > as the rule number is not always known when the rule is added. Yes I meant at run-time. On second thoughts, it'd be too easy a way to spam syslogd in the general case, but maybe reporting target < current rule for such dynamic forms of skipto might highlight config errors? I should STFU and resume lurking unless I can contribute code, I know. cheers, Ian From julian at elischer.org Tue Aug 19 18:09:27 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 19 18:09:34 2008 Subject: Possible bug - GRE tunnel routing In-Reply-To: <48AA88B4.6040606@za.verizonbusiness.com> References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> Message-ID: <48AB0C5C.8090404@elischer.org> Todor Genov wrote: > Hi Julian, > > Julian Elischer wrote: >> Todor Genov wrote: >>> Hi everyone, >>> >>> I may have found a routing bug relating to GRE tunnels. Could somebody >>> try and replicate this? >>> >>> As per the setup below GRE-encapsulated traffic to 194.31.254.148 >>> should be going out via tun1, but a tcpdump shows the traffic leaving >>> via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 >>> goes out via tun1 as expected. >>> >>> Configuration: >>> FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 >>> tun0 - PPPoE connection to ISP >>> tun1 - vpn connection to office PIX (via vpnc) >>> gre0 - GRE tunnel to machine sitting behind the PIX >>> >>> tun0: flags=8051 metric 0 mtu 1492 >>> inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 >>> Opened by PID 509 >>> tun1: flags=8051 metric 0 mtu 1500 >>> inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 >>> Opened by PID 984 >> Point to point interfaces really don't have netmasks. >> Otherwise it wouldn't be "Point to Point", it would be >> "multicast" like ethernet. >> >> There is really only one address at this end or the other end. >> If you want to say that there is a network at the other end >> then you really need to set a route for it. >> but it applies equally to all three of these p2p links. >> >> so, add a route: >> >> route add 92.168.254.0/24 92.168.254.1 > > The netmask for tun0 is automatically assigned by the ISP, and for tun1 > by the VPN server. The one for gre0 is a /30 in the connect scripts - I > must have changed it to /24 somewhere along the troubleshooting process > - it makes no difference to the end result. let me rephrase that.. p2p links do not support netmasks. That's all p2p links.. ppp, slip, tun, ng, gre, etc. If you what a virtual ethernet interface you may try tap(4) but you will need to have an appropriatly capable piece of software on the other end of the link. A p2p link doesn't take any notice of what you have written as netmask and it doesn't matter what your ISP has given you, or if you type /24 or /22 or /32. The point to point interface only knows about the ONE SINGLE ADDRESS on the other end of the link. If there is a network there, which that address is a part of, then it is up to YOU to add the route that allows packets to get there. > > The routing table does include routes to the /26 on tun1 and the /24 on > gre0. I have left them out as they are not relevant to the problem. The > troublesome route is the one to 194.31.154.148/32 > > Just noticed that the PtP address for tun1 looks incorrect - with that > netmask into account .64 is the network address. I'll look into that as > a possible cause. the netmask should not be taken into account because it is ignored. >> > > > From rizzo at iet.unipi.it Tue Aug 19 18:21:07 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Aug 19 18:21:13 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080820031409.V41971@sola.nimnet.asn.au> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> Message-ID: <20080819182337.GA25703@onelab2.iet.unipi.it> On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: > On Tue, 19 Aug 2008, Luigi Rizzo wrote: > > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: ... > > > Until $someone adds a direct skipto target jump at the virtual machine > > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > > it's still the fastest way to get from a to b, where b > a > > > > you mean with tables-based skipto targets ? Because the regular > > skipto has been a constant-time op forever, even in ipfw1 i believe, > > invalidating the target cache on a change and recomputing it the > > fly at the first request. > > Thanks; I'd completely missed the caching of skipto targets before, and > it's all so well commented too. blushing, but glad for the good news. > > But yes I was pondering Julian's patch, which has to lookup_next_rule > every time, and also Mike's bending of divert reentry rule number in > ipfw-classifyd with similar intent, which also has to hunt forward in > linear time for its target rule - or am I missing something else here? well, you can use a hash table to support that. It shouldn't be so bad to implement, flow tables already use hash tables so one can reuse the same code. > > > Speaking of which, should ipfw whinge when asked to skip backwards, > > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > > and a local test months ago. > > > > right... but the error can only be reliably detected in the kernel, > > as the rule number is not always known when the rule is added. > > Yes I meant at run-time. On second thoughts, it'd be too easy a way to actually you can do it at insertion time, it's just that you cannot do it in userland as other checks before inserting the rule. cheers luigi From julian at elischer.org Tue Aug 19 18:38:05 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 19 18:38:24 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080819182337.GA25703@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> <20080819182337.GA25703@onelab2.iet.unipi.it> Message-ID: <48AB1313.5080405@elischer.org> Luigi Rizzo wrote: > On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: >> On Tue, 19 Aug 2008, Luigi Rizzo wrote: >> > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > ... >> > > Until $someone adds a direct skipto target jump at the virtual machine >> > > code level - big recalc hit when adding/deleting rules/sets I suppose - >> > > it's still the fastest way to get from a to b, where b > a >> > >> > you mean with tables-based skipto targets ? Because the regular >> > skipto has been a constant-time op forever, even in ipfw1 i believe, >> > invalidating the target cache on a change and recomputing it the >> > fly at the first request. >> >> Thanks; I'd completely missed the caching of skipto targets before, and >> it's all so well commented too. blushing, but glad for the good news. >> >> But yes I was pondering Julian's patch, which has to lookup_next_rule >> every time, and also Mike's bending of divert reentry rule number in >> ipfw-classifyd with similar intent, which also has to hunt forward in >> linear time for its target rule - or am I missing something else here? > > well, you can use a hash table to support that. It shouldn't be so bad > to implement, flow tables already use hash tables so one can reuse the same code. one COULD, but I know I use this feature only with a number (20 or less) following rules, each of which is a skipto itself to some further awat location...or a simple drop.. Shall we say we "leave it as an exercise for the reader" ? > >> > > Speaking of which, should ipfw whinge when asked to skip backwards, >> > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd >> > > and a local test months ago. >> > >> > right... but the error can only be reliably detected in the kernel, >> > as the rule number is not always known when the rule is added. >> >> Yes I meant at run-time. On second thoughts, it'd be too easy a way to > > actually you can do it at insertion time, it's just that you cannot > do it in userland as other checks before inserting the rule. > > cheers > luigi From julian at elischer.org Tue Aug 19 18:39:21 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 19 18:39:38 2008 Subject: ipfw add skipto tablearg.... In-Reply-To: <20080819182337.GA25703@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> <20080819182337.GA25703@onelab2.iet.unipi.it> Message-ID: <48AB1360.7060908@elischer.org> Luigi Rizzo wrote: > On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: >> On Tue, 19 Aug 2008, Luigi Rizzo wrote: >> > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > ... >> > > Until $someone adds a direct skipto target jump at the virtual machine >> > > code level - big recalc hit when adding/deleting rules/sets I suppose - >> > > it's still the fastest way to get from a to b, where b > a >> > >> > you mean with tables-based skipto targets ? Because the regular >> > skipto has been a constant-time op forever, even in ipfw1 i believe, >> > invalidating the target cache on a change and recomputing it the >> > fly at the first request. >> >> Thanks; I'd completely missed the caching of skipto targets before, and >> it's all so well commented too. blushing, but glad for the good news. >> >> But yes I was pondering Julian's patch, which has to lookup_next_rule >> every time, and also Mike's bending of divert reentry rule number in >> ipfw-classifyd with similar intent, which also has to hunt forward in >> linear time for its target rule - or am I missing something else here? > > well, you can use a hash table to support that. It shouldn't be so bad > to implement, flow tables already use hash tables so one can reuse the same code. > >> > > Speaking of which, should ipfw whinge when asked to skip backwards, >> > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd >> > > and a local test months ago. >> > >> > right... but the error can only be reliably detected in the kernel, >> > as the rule number is not always known when the rule is added. >> >> Yes I meant at run-time. On second thoughts, it'd be too easy a way to > > actually you can do it at insertion time, it's just that you cannot > do it in userland as other checks before inserting the rule. you can't do it at insertion time if it's a tablearg style skipto.. but such a rule will simply continue at the next rule as if it did not match. > > cheers > luigi From todor.genov at za.verizonbusiness.com Tue Aug 19 20:56:06 2008 From: todor.genov at za.verizonbusiness.com (Todor Genov) Date: Tue Aug 19 20:56:14 2008 Subject: Possible bug - GRE tunnel routing In-Reply-To: <48AB0C5C.8090404@elischer.org> References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> <48AB0C5C.8090404@elischer.org> Message-ID: <48AB3358.4040709@za.verizonbusiness.com> Julian Elischer wrote: > Todor Genov wrote: >> Hi Julian, > let me rephrase that.. > p2p links do not support netmasks. That's all p2p links.. ppp, slip, > tun, ng, gre, etc. > > If you what a virtual ethernet interface you may try tap(4) but you will > need to have an appropriatly capable piece of software on the > other end of the link. > > > A p2p link doesn't take any notice of what you have written as netmask > and it doesn't matter what your ISP has given you, or if you > type /24 or /22 or /32. > > The point to point interface only knows about the ONE SINGLE ADDRESS > on the other end of the link. > If there is a network there, which that address is a part of, then > it is up to YOU to add the route that allows packets to get there. > > This is fully understood and taken into account. For all intended purposes I treat the tunnels as a /30 subnets (despite what ifconfig says) and as per the routing table which I pasted destinations which need to be reached over those tunnels have static routes specified: default 41.142.82.1 UGS 1 1365 tun0 41.142.82.1 41.142.82.37 UGH 1 0 tun0 192.168.254.1 192.168.254.2 UH 0 3 gre0 194.31.137.64 194.31.137.70 UH 1 0 tun1 194.31.154.148 194.31.137.64 UGS 0 0 tun1 ^^^ this is the other end of the GRE tunnel From this routing table alone there is no way that traffic destined to 196.31.154.148 should exit via tun0, but GRE traffic to 194.31.154.148 does. >> >> The routing table does include routes to the /26 on tun1 and the /24 on >> gre0. I have left them out as they are not relevant to the problem. The >> troublesome route is the one to 194.31.154.148/32 >> >> Just noticed that the PtP address for tun1 looks incorrect - with that >> netmask into account .64 is the network address. I'll look into that as >> a possible cause. > > the netmask should not be taken into account because it is ignored. I was referring to static routes, not interface addressing in the above. Those routes also exist in my routing table, even though I omitted them in my original paste 192.168.254.0/24 192.168.254.1 UGS 0 0 gre0 196.31.137.64/26 196.30.157.65 UGS 0 0 tun1 (which i omitted in my original paste). Both those routes are irrelevant as the GRE endpoint is not these subnets - it's merely reachable via tun1 -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543 From julian at elischer.org Tue Aug 19 21:07:52 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 19 21:08:03 2008 Subject: Possible bug - GRE tunnel routing In-Reply-To: <48AB3358.4040709@za.verizonbusiness.com> References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> <48AB0C5C.8090404@elischer.org> <48AB3358.4040709@za.verizonbusiness.com> Message-ID: <48AB362E.2060409@elischer.org> Todor Genov wrote: > Julian Elischer wrote: >> Todor Genov wrote: >>> Hi Julian, >> let me rephrase that.. >> p2p links do not support netmasks. That's all p2p links.. ppp, slip, >> tun, ng, gre, etc. >> >> If you what a virtual ethernet interface you may try tap(4) but you will >> need to have an appropriatly capable piece of software on the >> other end of the link. >> >> >> A p2p link doesn't take any notice of what you have written as netmask >> and it doesn't matter what your ISP has given you, or if you >> type /24 or /22 or /32. >> >> The point to point interface only knows about the ONE SINGLE ADDRESS >> on the other end of the link. >> If there is a network there, which that address is a part of, then >> it is up to YOU to add the route that allows packets to get there. >> >> > > This is fully understood and taken into account. > > For all intended purposes I treat the tunnels as a /30 subnets there you go again... tunnels are NOT SUBNETS OF ANY TYPE the two ends can be in completely different address spaces.. one can be 10.2.2.2 and the other end can be 192.168.2.42 there is NO SUBNETTING on point to point interfaces.. > (despite what ifconfig says) and as per the routing table which I pasted > destinations which need to be reached over those tunnels have static > routes specified: > > default 41.142.82.1 UGS 1 1365 tun0 > 41.142.82.1 41.142.82.37 UGH 1 0 tun0 > 192.168.254.1 192.168.254.2 UH 0 3 gre0 > 194.31.137.64 194.31.137.70 UH 1 0 tun1 > 194.31.154.148 194.31.137.64 UGS 0 0 tun1 > ^^^ this is the other end of the GRE tunnel > > From this routing table alone there is no way that traffic destined to > 196.31.154.148 should exit via tun0, but GRE traffic to 194.31.154.148 does. ^^^^ 196? I've deleted you original mail.. sorry.. Resend me privately the output of ifconfig -a and the FULL netstat -r output.. > > >>> The routing table does include routes to the /26 on tun1 and the /24 on >>> gre0. I have left them out as they are not relevant to the problem. The >>> troublesome route is the one to 194.31.154.148/32 >>> >>> Just noticed that the PtP address for tun1 looks incorrect - with that >>> netmask into account .64 is the network address. I'll look into that as >>> a possible cause. >> the netmask should not be taken into account because it is ignored. > > I was referring to static routes, not interface addressing in the above. so why are you setting netmasks. actually I see a bug, which is that ifconfig -a shows a netmask no matter if it makes sense.. > > Those routes also exist in my routing table, even though I omitted them > in my original paste > > 192.168.254.0/24 192.168.254.1 UGS 0 0 gre0 > 196.31.137.64/26 196.30.157.65 UGS 0 0 tun1 > (which i omitted in my original paste). > > Both those routes are irrelevant as the GRE endpoint is not these > subnets - it's merely reachable via tun1 > > From peo at intersonic.se Tue Aug 19 22:31:16 2008 From: peo at intersonic.se (Per olof Ljungmark) Date: Tue Aug 19 22:31:23 2008 Subject: 7-STABLE lock order reversal Message-ID: <48AB4562.2070203@intersonic.se> (Reposting to -net as suggested by Kris.) 7.0-STABLE #0: Tue Aug 19 20:39:48 CEST 2008 After system update from June 12 sources to Aug 12 I have seen frequent lockups during network operations. Compiled debugging kernel and got the below during boot. Should I open a PR? Suggestions welcome. Thanks. Aug 19 22:12:47 kreutzman kernel: uhid0: on uhub5 Aug 19 22:12:47 kreutzman kernel: lock order reversal: Aug 19 22:12:47 kreutzman kernel: 1st 0xc7077a14 rtentry (rtentry) @ /usr/src/sys/net/route.c:328 Aug 19 22:12:47 kreutzman kernel: 2nd 0xc6eee07c radix node head (radix node head) @ /usr/src/sys/net/route.c:879 Aug 19 22:12:47 kreutzman kernel: KDB: stack backtrace: Aug 19 22:12:47 kreutzman kernel: db_trace_self_wrapper(c0af8084,e71f5a4c,c07a777e,c0afa653,c6eee07c,...) at db_trace_self_wrapper+0x26 Aug 19 22:12:47 kreutzman kernel: kdb_backtrace(c0afa653,c6eee07c,c0afa6b4,c0afa6b4,c0b031c2,...) at kdb_backtrace+0x29 Aug 19 22:12:47 kreutzman kernel: witness_checkorder(c6eee07c,9,c0b031c2,36f,c6c5f2b8,...) at witness_checkorder+0x6de Aug 19 22:12:47 kreutzman kernel: _mtx_lock_flags(c6eee07c,0,c0b031c2,36f,c0af3ca5,...) at _mtx_lock_flags+0xbc Aug 19 22:12:47 kreutzman kernel: rtrequest1_fib(1,e71f5ae8,e71f5b18,0,ce,...) at rtrequest1_fib+0x82 Aug 19 22:12:47 kreutzman kernel: rtredirect_fib(e71f5bb8,e71f5ba8,0,16,e71f5b98,...) at rtredirect_fib+0x13d Aug 19 22:12:47 kreutzman kernel: in_rtredirect(e71f5bb8,e71f5ba8,0,6,e71f5b98,...) at in_rtredirect+0x34 Aug 19 22:12:47 kreutzman kernel: icmp_input(c7081d00,14,80246,c0bf53c0,e71f5c08,...) at icmp_input+0x526 Aug 19 22:12:47 kreutzman kernel: ip_input(c7081d00,14e,800,c6c89400,800,...) at ip_input+0x650 Aug 19 22:12:47 kreutzman kernel: netisr_dispatch(2,c7081d00,10,3,0,...) at netisr_dispatch+0x73 Aug 19 22:12:47 kreutzman kernel: ether_demux(c6c89400,c7081d00,3,0,3,...) at ether_demux+0x1f1 Aug 19 22:12:47 kreutzman kernel: ether_input(c6c89400,c7081d00,c0ac0c3e,c57,c6c89400,...) at ether_input+0x3d9 Aug 19 22:12:47 kreutzman kernel: bge_intr(c6c90000,0,c0af18b8,442,c6b334e8,...) at bge_intr+0x7ca Aug 19 22:12:47 kreutzman kernel: ithread_loop(c6c946d0,e71f5d38,c0af1622,305,c6c97ad0,...) at ithread_loop+0x1c5 Aug 19 22:12:47 kreutzman kernel: fork_exit(c074ce40,c6c946d0,e71f5d38) at fork_exit+0xb8 Aug 19 22:12:47 kreutzman kernel: fork_trampoline() at fork_trampoline+0x8 Aug 19 22:12:47 kreutzman kernel: --- trap 0, eip = 0, esp = 0xe71f5d70, ebp = 0 --- Aug 19 22:12:47 kreutzman kernel: Expensive timeout(9) function: 0xc068b7f0(0xc0c82f00) 0.004460343 s Aug 19 22:12:47 kreutzman savecore: no dumps found From ddg at yan.com.br Wed Aug 20 02:45:25 2008 From: ddg at yan.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Wed Aug 20 02:45:33 2008 Subject: Application layer classifier for ipfw In-Reply-To: <9a542da30808081626y7ce1fe58k483494a6cdbfae60@mail.gmail.com> References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> <9a542da30808081626y7ce1fe58k483494a6cdbfae60@mail.gmail.com> Message-ID: <48AB80BD.0@yan.com.br> Ermal Lu?i escreveu: > On Sat, Aug 2, 2008 at 3:00 PM, Mike Makonnen wrote: > >> Mike Makonnen wrote: >> >>> Patrick Tracanelli wrote: >>> >>>> To let you know of my current (real world) tests: >>>> >>>> - Wireless Internet Provider 1: >>>> - 4Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> - Classifying 100Mbit/s of dump over ssh >>>> >>>> Results in: >>>> No latency added, very low CPU usage, no packets dropping. >>>> >>>> - Wireless ISP 2: >>>> - 21 Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> >>>> Results in: >>>> No tcp or udp traffic at all; everything that gets diverted never >>>> comes out of the divert socket, and ipfw-classifyd logs >>>> >>>> Aug 1 12:07:35 ourofino last message repeated 58 times >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule >>>> 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule >>>> 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule >>>> 1000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule >>>> 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >>>> 50000) >>>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>>> socket: Operation not permitted >>>> Aug 1 12:18:50 ourofino last message repeated 90 times >>>> >>> Hmmm... this part means that the call to sendto(2) to write the packet >>> back into network stack failed. This explains why you are not seein g any >>> traffic comming back out of the divert socket, but I don't see why it would >>> suddenly fail with a permission error. Could this be a kernel bug? >>> >>>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full >>>> Aug 1 12:19:11 ourofino last message repeated 94 times >>>> >>>> Raised queue len a lot (up to 40960), when the application starts it uses >>>> up to 25% CPU and a second after that, CPU usage gets lower the 0.1%. >>>> >>> This looks like a deadlock. If it weren't able to process packets fast >>> enough the cpu usage should be high even as it's spewing "packet dropped" >>> messages. Can you send me some more information like memory usage and the >>> firewall script you are using? How much of the 21Mbits/s of traffic is P2P? >>> If you reduce the number of protocols you are trying to match against does >>> the behavior change? Using netstat -w1 -I can you tell me how >>> many packets per second we're talking about for 4Mbits/s and 21Mbit/s? Also, >>> the timestamps from the log file seem to show that the daemon is running for >>> approx. 34 sec. before the first "unable to write to write to divert socket" >>> message. Is it passing traffic during this time? Thanks. >>> >>> I've uploaded a newer version. Can you try that also please. It includes: >>> o SIGHUP forces it to re-read its configuration file >>> o rc.d script >>> o minor optimization (calls pthread_cond_signal with the mutex unlocked) >>> o code cleanup >>> >>> Also, for your convenience I have attached a patch against the earlier >>> version that removes a debugging printf that should remove spammage to your >>> log files (the current version has it removed already). >>> >>> >> Ooops, a few minutes after I sent this email I found a couple of bugs (one >> major, and one minor). They were in the original tarball as well as the >> newer one I uploaded earlier today. I've uploaded a fixed version of the >> code. Can you try that instead please. >> >> Also, to help track down performance issues I've modified the Makefile to >> build a profiled version of the application so you can use gprof(1) to >> figure out where any problems lie. >> >> > > Does this sound about right for implementing the GC and implementing syntax as > $protocol = dnpipe 20 > $protocol2 = dnqueue 30 > it has some extra goos for pf(4) and altq(4) > $protocol3 = queue $queue name > $protocol4 = tag TAGNAME > $protocol5 = action block > > It adds 2 new options -e seconds for seconds before a flow is > considered expired and -n #packets proccessed before kicking the GC. > > --- classifyd_old.c 2008-08-09 00:33:04.000000000 +0000 > +++ classifyd.c 2008-08-09 00:33:34.000000000 +0000 > @@ -28,13 +28,17 @@ > > #include > #include > +#include > +#include > > +#include > #include > #include > #include > #include > #include > #include > +#include > > #include > #include > @@ -53,6 +57,7 @@ > #include > > #include "hashtable.h" > +#include "hashtable_private.h" > #include "pathnames.h" > #include "protocols.h" > > @@ -94,6 +99,7 @@ > uint32_t if_datalen; /* length in bytes of if_data */ > uint16_t if_pktcount; /* number of packets concatenated */ > uint16_t if_fwrule; /* ipfw(4) rule associated with flow */ > + time_t expire; /* flow expire time */ > }; > > /* > @@ -126,7 +132,7 @@ > static struct ic_queue outQ; > > /* divert(4) socket */ > -static int dvtS; > +static int dvtS = 0; > > /* config file path */ > static const char *conf = IC_CONFIG_PATH; > @@ -137,12 +143,25 @@ > /* List of protocols available to the system */ > struct ic_protocols *fp; > > +/* Our hashtables */ > +struct hashtable *sh = NULL, > + *th = NULL, > + *uh = NULL; > + > +/* signaled to kick garbage collector */ > +static pthread_cond_t gq_condvar; > + > +/* number of packets before kicking garbage collector */ > +static unsigned int npackets = 250; > + > +static time_t time_expire = 40; /* 40 seconds */ > /* > * Forward function declarations. > */ > void *classify_pthread(void *); > void *read_pthread(void *); > void *write_pthread(void *); > +void *garbage_pthread(void *); > static int equalkeys(void *, void *); > static unsigned int hashfromkey(void *); > static void test_re(void); > @@ -155,7 +174,7 @@ > { > struct sockaddr_in addr; > struct sigaction sa; > - pthread_t classifytd, readtd, writetd; > + pthread_t classifytd, readtd, writetd, garbagectd; > const char *errstr; > long long num; > uint16_t port, qmaxsz; > @@ -164,13 +183,27 @@ > tflag = 0; > port = IC_DPORT; > qmaxsz = IC_QMAXSZ; > - while ((ch = getopt(argc, argv, "htc:P:p:q:")) != -1) { > + while ((ch = getopt(argc, argv, "n:e:htc:P:p:q:")) != -1) { > switch(ch) { > case 'c': > conf = strdup(optarg); > if (conf == NULL) > err(EX_TEMPFAIL, "config file path"); > break; > + case 'e': > + num = strtonum((const char *)optarg, 1, 400, &errstr); > + if (num == 0 && errstr != NULL) { > + errx(EX_USAGE, "invalud expire seconds: %s", errstr); > + } > + time_expire = (time_t)num; > + break; > + case 'n': > + num = strtonum((const char *)optarg, 1, > 65535, &errstr); > + if (num == 0 && errstr != NULL) { > + errx(EX_USAGE, "invalud expire > seconds: %s", errstr); > + } > + npackets = (unsigned int)num; > + break; > case 'P': > protoDir = strdup(optarg); > if (protoDir == NULL) > @@ -230,6 +263,9 @@ > error = pthread_cond_init(&outQ.fq_condvar, NULL); > if (error != 0) > err(EX_OSERR, "unable to initialize output queue condvar"); > + error = pthread_cond_init(&gq_condvar, NULL); > + if (error != 0) > + err(EX_OSERR, "unable to initialize garbage collector > condvar"); > > /* > * Create and bind the divert(4) socket. > @@ -276,32 +312,80 @@ > if (error == -1) > err(EX_OSERR, "unable to set signal handler"); > > + /* > + * There are 3 tables: udp, tcp, and tcp syn. > + * The tcp syn table tracks connections for which a > + * SYN packet has been sent but no reply has been returned > + * yet. Once the SYN ACK reply is detected it is moved to > + * the regular tcp connection tracking table. > + */ > + sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > + if (sh == NULL) { > + syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); > + error = EX_SOFTWARE; > + goto cleanup; > + } > + th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > + if (th == NULL) { > + syslog(LOG_ERR, "unable to create TCP tracking table"); > + error = EX_SOFTWARE; > + goto cleanup; > + } > + uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > + if (uh == NULL) { > + syslog(LOG_ERR, "unable to create UDP tracking table"); > + error = EX_SOFTWARE; > + goto cleanup; > + } > + > /* > * Create the various threads. > */ > error = pthread_create(&readtd, NULL, read_pthread, NULL); > - if (error != 0) > - err(EX_OSERR, "unable to create reader thread"); > + if (error != 0) { > + syslog(LOG_ERR, "unable to create reader thread"); > + error = EX_OSERR; > + goto cleanup; > + } > error = pthread_create(&classifytd, NULL, classify_pthread, NULL); > - if (error != 0) > - err(EX_OSERR, "unable to create classifier thread"); > + if (error != 0) { > + syslog(LOG_ERR, "unable to create classifier thread"); > + error = EX_OSERR; > + goto cleanup; > + } > error = pthread_create(&writetd, NULL, write_pthread, NULL); > - if (error != 0) > - err(EX_OSERR, "unable to create writer thread"); > - > + if (error != 0) { > + syslog(LOG_ERR, "unable to create writer thread"); > + error = EX_OSERR; > + goto cleanup; > + } > + error = pthread_create(&garbagectd, NULL, garbage_pthread, NULL); > + if (error != 0) { > + syslog(LOG_ERR, "unable to create garbage collect thread"); > + error = EX_OSERR; > + goto cleanup; > + } > /* > * Wait for our threads to exit. > */ > pthread_join(readtd, NULL); > pthread_join(classifytd, NULL); > pthread_join(writetd, NULL); > - > + pthread_join(garbagectd, NULL); > /* > * Cleanup > */ > - close(dvtS); > +cleanup: > + if (dvtS > 0) > + close(dvtS); > + if (sh != NULL) > + hashtable_destroy(sh, 1); > + if (th != NULL) > + hashtable_destroy(th, 1); > + if (uh != NULL) > + hashtable_destroy(uh, 1); > > - return (0); > + return (error); > } > > void * > @@ -310,6 +394,7 @@ > struct ic_pkt *pkt; > struct ip *ipp; > int len; > + unsigned int pcktcnt = 0; > > while (1) { > pkt = (struct ic_pkt *)malloc(sizeof(struct ic_pkt)); > @@ -353,6 +438,10 @@ > STAILQ_INSERT_HEAD(&inQ.fq_pkthead, pkt, fp_link); > inQ.fq_size++; > pthread_mutex_unlock(&inQ.fq_mtx); > + if (++pcktcnt > npackets) { > + pcktcnt = 0; > + pthread_cond_signal(&gq_condvar); > + } > pthread_cond_signal(&inQ.fq_condvar); > } > > @@ -420,39 +509,19 @@ > struct tcphdr *tcp; > struct udphdr *udp; > struct ic_pkt *pkt; > - struct hashtable *sh, *th, *uh; > struct protocol *proto; > + struct timeval tv; > regmatch_t pmatch; > u_char *data, *payload; > uint16_t trycount; > int datalen, error; > > - /* > - * There are 3 tables: udp, tcp, and tcp syn. > - * The tcp syn table tracks connections for which a > - * SYN packet has been sent but no reply has been returned > - * yet. Once the SYN ACK reply is detected it is moved to > - * the regular tcp connection tracking table. > - */ > - sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > - if (sh == NULL) { > - syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); > - exit(EX_SOFTWARE); > - } > - th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > - if (th == NULL) { > - syslog(LOG_ERR, "unable to create TCP tracking table"); > - exit(EX_SOFTWARE); > - } > - uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > - if (uh == NULL) { > - syslog(LOG_ERR, "unable to create UDP tracking table"); > - exit(EX_SOFTWARE); > - } > - > flow = NULL; > key = NULL; > while(1) { > + while(gettimeofday(&tv, NULL) != 0) > + ; > + > pthread_mutex_lock(&inQ.fq_mtx); > pkt = STAILQ_LAST(&inQ.fq_pkthead, ic_pkt, fp_link); > while (pkt == NULL) { > @@ -528,6 +597,8 @@ > free(pkt); > continue; > } > + > + flow->expire = tv.tv_sec; > goto enqueue; > /* > * Handle session tear-down. > @@ -583,8 +654,11 @@ > * collecting IC_PKTMAXMATCH packets, just pass it through. > */ > } else if (flow->if_pktcount >= IC_PKTMAXMATCH && > - flow->if_fwrule == 0) > + flow->if_fwrule == 0) { > + flow->expire = tv.tv_sec; > goto enqueue; > + } > + flow->expire = tv.tv_sec; > goto classify; > } > > @@ -630,6 +704,7 @@ > free(pkt); > continue; > } > + flow->expire = tv.tv_sec; > goto classify; > } > > @@ -688,6 +763,7 @@ > flow->if_datalen = datalen; > flow->if_pktcount = 1; > flow->if_fwrule = 0; > + flow->expire = tv.tv_sec; > if (hashtable_insert(uh, (void *)key, (void *)flow) == 0) { > syslog(LOG_WARNING, > "packet dropped: unable to insert into table"); > @@ -715,19 +791,26 @@ > flow->if_data = data; > flow->if_datalen += datalen; > flow->if_pktcount++; > + flow->expire = tv.tv_sec; > /* > * If we haven't been able to classify this flow after > * collecting IC_PKTMAXMATCH packets, just pass it through. > */ > } else if (flow->if_pktcount >= IC_PKTMAXMATCH && > - flow->if_fwrule == 0) > + flow->if_fwrule == 0) { > + flow->expire = tv.tv_sec; > goto enqueue; > + } > } else > /* Not an TCP or UDP packet. */ > goto enqueue; > > classify: > - assert(flow != NULL); > + if (flow == NULL) { > + syslog(LOG_ERR, "flow is null argghhhhhhh"); > + goto enqueue; > + } > + //assert(flow != NULL); > > /* > * Inform divert(4) what rule to send it to by > @@ -823,6 +906,80 @@ > return (NULL); > } > > +void * > +garbage_pthread(void *arg __unused) > +{ > + char errbuf[LINE_MAX]; > + struct entry *e, *f; > + unsigned int i, flows_expired, error; > + struct timeval tv; > + > + while (1) { > + flows_expired = 0; > + while (gettimeofday(&tv, NULL) != 0) > + ; > + tv.tv_sec -= time_expire; > + > + pthread_mutex_lock(&inQ.fq_mtx); > + error = pthread_cond_wait(&gq_condvar, &inQ.fq_mtx); > + if (error != 0) { > + strerror_r(error, errbuf, sizeof(errbuf)); > + syslog(EX_OSERR, "unable to wait on garbage > collection: %s", > + errbuf); > + exit(EX_OSERR); > + } > + > + for (i = 0; i < sh->tablelength; i++) { > + e = sh->table[i]; > + while (e != NULL) { > + f = e; e = e->next; > + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { > + freekey(f->k); > + sh->entrycount--; > + if (f->v != NULL) > + free(f->v); > + free(f); > + flows_expired++; > + } > + } > + } > + for (i = 0; i < th->tablelength; i++) { > + e = th->table[i]; > + while (e != NULL) { > + f = e; e = e->next; > + if (((struct ip_flow *)f->v)->expire > < tv.tv_sec) { > + freekey(f->k); > + th->entrycount--; > + if (f->v != NULL) > + free(f->v); > + free(f); > + flows_expired++; > + } > + } > + } > + for (i = 0; i < uh->tablelength; i++) { > + e = uh->table[i]; > + while (e != NULL) { > + f = e; e = e->next; > + if (((struct ip_flow *)f->v)->expire > < tv.tv_sec) { > + freekey(f->k); > + uh->entrycount--; > + if (f->v != NULL) > + free(f->v); > + free(f); > + flows_expired++; > + } > + } > + } > + > + pthread_mutex_unlock(&inQ.fq_mtx); > + > + syslog(LOG_WARNING, "expired %u flows", flows_expired); > + } > + > + return (NULL); > +} > + > /* > * NOTE: The protocol list (plist) passed as an argument is a global > * variable. It is accessed from 3 functions: classify_pthread, > @@ -840,12 +997,20 @@ > static int > read_config(const char *file, struct ic_protocols *plist) > { > + enum { bufsize = 2048 }; > struct protocol *proto; > properties props; > - const char *errmsg, *name, *value; > - int fd; > + const char *errmsg, *name; > + char *value; > + int fd, fdpf; > uint16_t rule; > + char **ap, *argv[bufsize]; > > + fdpf = open("/dev/pf", O_RDONLY); > + if (fdpf == -1) { > + syslog(LOG_ERR, "unable to open /dev/pf"); > + return (EX_OSERR); > + } > fd = open(file, O_RDONLY); > if (fd == -1) { > syslog(LOG_ERR, "unable to open configuration file"); > @@ -863,10 +1028,48 @@ > /* Do not match traffic against this pattern */ > if (value == NULL) > continue; > - rule = strtonum(value, 1, 65535, &errmsg); > - if (rule == 0) { > + for (ap = argv; (*ap = strsep(&value, " \t")) != NULL;) > + if (**ap != '\0') > + if (++ap >= &argv[bufsize]) > + break; > + if (!strncmp(argv[0], "queue", strlen("queue"))) { > + if (ioctl(fdpf, DIOCGETNAMEDALTQ, &rule)) { > + syslog(LOG_WARNING, > + "could not get ALTQ translation for" > + " queue %s", argv[1]); > + continue; > + } > + if (rule == 0) { > + syslog(LOG_WARNING, > + "queue %s does not exists!", argv[1]); > + continue; > + } > + } else if (!strncmp(argv[0], "dnqueue", strlen("dnqueue"))) > + rule = strtonum(argv[1], 1, 65535, &errmsg); > + else if (!strncmp(argv[0], "dnpipe", strlen("dnpipe"))) > + rule = strtonum(argv[1], 1, 65535, &errmsg); > + else if (!strncmp(argv[0], "tag", strlen("tag"))) { > + if (ioctl(fdpf, DIOCGETNAMEDTAG, &rule)) { > + syslog(LOG_WARNING, > + "could not get tag translation for" > + " queue %s", argv[1]); > + continue; > + } > + if (rule == 0) { > + syslog(LOG_WARNING, > + "tag %s does not exists!", argv[1]); > + continue; > + } > + } else if (!strncmp(argv[0], "action", strlen("action"))) { > + if (strncmp(argv[1], "block", strlen("block"))) > + rule = PF_DROP; > + else if (strncmp(argv[1], "allow", strlen("allow"))) > + rule = PF_PASS; > + else > + continue; > + } else { > syslog(LOG_WARNING, > - "invalid rule number for %s protocol: %s", > + "invalid action specified for %s protocol: %s", > proto->p_name, errmsg); > continue; > } > @@ -953,10 +1156,14 @@ > static void > usage(const char *arg0) > { > - printf("usage: %s [-h] [-c file] [-p port] [-P dir] [-q length]\n", > basename(arg0)); > + printf("usage: %s [-h] [-c file] [-e seconds] [-n packets] " > + "[-p port] [-P dir] [-q length]\n", basename(arg0)); > printf("usage: %s -t -P dir\n", basename(arg0)); > printf( " -c file : path to configuration file\n" > + " -e secs : number of seconds before a flow is expired\n" > " -h : this help screen\n" > + " -n packets: number of packets before the garbage collector" > + " tries to expire flows\n" > " -P dir : directory containing protocol patterns\n" > " -p port : port number of divert socket\n" > " -q length : max length (in packets) of in/out queues\n" > > Some progress in solution of presented problems ? -- Daniel From yanefbsd at gmail.com Wed Aug 20 07:11:25 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Wed Aug 20 07:11:32 2008 Subject: Issues (again) with msk driver on 8-CURRENT amd64 Message-ID: <7d6fde3d0808192347y65d1f21egf831dc18e264c510@mail.gmail.com> Hi Pyun! I know it's been a while since I responded, but after reinstalling my system recently I noticed that the issue I mentioned almost a year ago (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) with my Marvell chipset card has once again returned. In the interim I was using x86, and I didn't suffer from any of the issues I have again on x64, and I was using XP x64 but now I've switched over to Vista x64 on my client box. Subsequently, the only thing that's really changed on my system is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). I'm using the 7-RELENG kernel right now (and not really enjoying it, but it works -- yay?), but I'd like to help resolve the issue with msk under CURRENT with x64 and my chipset. Standing by awaiting marching orders with tcpdump, netcat, and pciconf at my side to help debug the issue :). Thanks, -Garrett From yanefbsd at gmail.com Wed Aug 20 07:14:34 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Wed Aug 20 07:14:40 2008 Subject: Issues with msk driver on 8-CURRENT amd64 Message-ID: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> Hi Pyun! I know it's been a while since I responded, but after reinstalling my system recently I noticed that the issue I mentioned almost a year ago (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) with my Marvell chipset card has once again returned. In the interim I was using x86, and I didn't suffer from any of the issues I have again on x64, and I was using XP x64 but now I've switched over to Vista x64 on my client box. Subsequently, the only thing that's really changed on my system is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). I'm using the 7-RELENG kernel right now (and not really enjoying it, but it works -- yay?), but I'd like to help resolve the issue with msk under CURRENT with x64 and my chipset. Standing by awaiting marching orders with tcpdump, netcat, and pciconf at my side to help debug the issue :). Thanks, -Garrett From pyunyh at gmail.com Wed Aug 20 08:30:09 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Aug 20 08:30:15 2008 Subject: Issues with msk driver on 8-CURRENT amd64 In-Reply-To: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> References: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> Message-ID: <20080820080304.GA87443@cdnetworks.co.kr> On Tue, Aug 19, 2008 at 11:45:48PM -0700, Garrett Cooper wrote: > Hi Pyun! > I know it's been a while since I responded, but after > reinstalling my system recently I noticed that the issue I mentioned > almost a year ago > (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) > with my Marvell chipset card has once again returned. In the interim I > was using x86, and I didn't suffer from any of the issues I have again > on x64, and I was using XP x64 but now I've switched over to Vista x64 > on my client box. > Subsequently, the only thing that's really changed on my system > is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). > I'm using the 7-RELENG kernel right now (and not really enjoying > it, but it works -- yay?), but I'd like to help resolve the issue with > msk under CURRENT with x64 and my chipset. > Standing by awaiting marching orders with tcpdump, netcat, and > pciconf at my side to help debug the issue :). Would you please explain your issues with more information? For instance, Can you see a valid link is established by msk(4)? Did both ends agree on established speed/duplex? What speed/duplex was chosen by msk(4)? Forcing speed/duplex have any effects? Turning off checksum offload or TSO have any effects? Did you use back-to-back connection without switch? tcpdump data for a broken connection might be help too. > Thanks, > -Garrett -- Regards, Pyun YongHyeon From slawek.zak at gmail.com Wed Aug 20 11:23:38 2008 From: slawek.zak at gmail.com (Slawek Zak) Date: Wed Aug 20 11:23:45 2008 Subject: Carp renaming cuts the traffic off Message-ID: <787bbe1c0808200357g745166wd5e2de142a7b3d35@mail.gmail.com> Hi, Something weird is going on with renaming of carp interfaces. I use FreeBSD stable updated on August 18. My setup: ifconfig em0 up ifconfig em1 up ifconfig lagg0 create up laggproto failover laggport em0 laggport em1 ifconfig vlan4 create up vlan 4 vlandev lagg0 192.168.0.1/24 ifconfig carp1 create up vhid 1 pass testpass 192.168.0.2/24 I ping 192.168.0.2 (carp IP addres) from external host and get replies - works fine. Now do "ifconfig carp1 name something_else" and watch the magic. I get no traffic back from the carp IP address. Does someone have any clue what's going on and why? Thank you, /S From popofnewslists at gmail.com Wed Aug 20 13:29:18 2008 From: popofnewslists at gmail.com (Popof Popof) Date: Wed Aug 20 13:29:25 2008 Subject: How to make two vlans on one interface working with dhclient Message-ID: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> Hi, I have a FreeBSD 6.0 box andi need to configure it in a way that I must use 2 vlans under one interface and both of them will get an address thanks to dhclient. So in order to make this job I created vlans: ifconfig rl0.100 create ifconfig rl0.2101 create The vlans are created without any problem. But I also want to retrieve an diffrent ip address from a dhcpd server on the two of them. I've made a specific dhclient.conf for each one: interface "rl0.100" { #My options } interface "rl0.2101" { #My options } When I launch dhclient on only one interface (100 or 2101) it's works fine and I get an ip address (class B on vlan 100 and class A on vlan 2101). But if I launch dhclient on the second interface it's make an error: dhclient: Can't bind to dhcp address: Address already in use. Please make sure there is no other dhcp server runing and that there's no entry for dhcp or bootp in /etc/inetd.conf Does someone had an idea about how to fix this problem and having my two vlans working with dhclient? From yanefbsd at gmail.com Wed Aug 20 15:20:20 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Wed Aug 20 15:20:29 2008 Subject: Issues with msk driver on 8-CURRENT amd64 In-Reply-To: <20080820080304.GA87443@cdnetworks.co.kr> References: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> <20080820080304.GA87443@cdnetworks.co.kr> Message-ID: <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com> Comments inline. On Wed, Aug 20, 2008 at 1:03 AM, Pyun YongHyeon wrote: > On Tue, Aug 19, 2008 at 11:45:48PM -0700, Garrett Cooper wrote: > > Hi Pyun! > > I know it's been a while since I responded, but after > > reinstalling my system recently I noticed that the issue I mentioned > > almost a year ago > > (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) > > with my Marvell chipset card has once again returned. In the interim I > > was using x86, and I didn't suffer from any of the issues I have again > > on x64, and I was using XP x64 but now I've switched over to Vista x64 > > on my client box. > > Subsequently, the only thing that's really changed on my system > > is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). > > I'm using the 7-RELENG kernel right now (and not really enjoying > > it, but it works -- yay?), but I'd like to help resolve the issue with > > msk under CURRENT with x64 and my chipset. > > Standing by awaiting marching orders with tcpdump, netcat, and > > pciconf at my side to help debug the issue :). > > Would you please explain your issues with more information? > For instance, > Can you see a valid link is established by msk(4)? Sort of. A link between the endpoints is established, but then it stalls and fails after a "connection reset". > Did both ends agree on established speed/duplex? Yes, they did. > What speed/duplex was chosen by msk(4)? 10/100MBit and GBit duplex, respectively. > Forcing speed/duplex have any effects? Not sure, but using a 100MBit and 1GBit connection yields the same results, whereas before I just claimed it was just gigabit connections. > Turning off checksum offload or TSO have any effects? How do I do that? > Did you use back-to-back connection without switch? I'm connecting via a switch and it works perfectly fine via 7-RELENG with amd64. > tcpdump data for a broken connection might be help too. Ok. More help on trying to setup everything to debug this issue would be helpful. FWIW, the issue might be that the MTU doesn't match for Windows and FreeBSD (I remember reading that somewhere a while back)... unfortunately, my router speaks this MTU (1464?) so connections via msk don't work properly anymore on 8-CURRENT. Thanks, -Garrett From jav at sics.se Wed Aug 20 21:03:48 2008 From: jav at sics.se (Javier Ubillos) Date: Wed Aug 20 21:03:56 2008 Subject: erride default ICMP (and other protocols) default replies. Message-ID: <1219265061.9118.29.camel@dib> Hi freebsd-net. (Sorry for cross posting. This time I think I found the right forum for my question) I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually NAT, but it's a good analogy for this case). I have chosen to use pcaplib to pick up the packets. I have an implementation which picks up the packets, inspects them, rewrites the destination/source ip-addresses and sends them out on the repective interface. The problem I'm facing however is that my interfaces are answering to e.g. icmp-echo (ping) automatically, and I don't know how to turn this behaviour off. What I want to happen is that if A pings C, my router B in between should simply forward the packets w/o any automatic reactions. A --> B --> C So that if e.g. C is down, no echo-reply is sent back (or if C is up, that C is actually sending the echo-reply. Does any one know how to turn off the automatic replies (ICMP and whatever else I haven't forseen yet) or does any one know where I can find out more about the issue? Thank you // Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080820/81401c6c/attachment.pgp From jav at sics.se Wed Aug 20 21:20:28 2008 From: jav at sics.se (Javier Ubillos) Date: Wed Aug 20 21:20:35 2008 Subject: Override default ICMP (and other protocols) default replies. Message-ID: <1219265499.9118.31.camel@dib> Hi freebsd-net. (Sorry for cross posting. This time I think I found the right forum for my question) I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually NAT, but it's a good analogy for this case). I have chosen to use pcaplib to pick up the packets. I have an implementation which picks up the packets, inspects them, rewrites the destination/source ip-addresses and sends them out on the repective interface. The problem I'm facing however is that my interfaces are answering to e.g. icmp-echo (ping) automatically, and I don't know how to turn this behaviour off. What I want to happen is that if A pings C, my router B in between should simply forward the packets w/o any automatic reactions. A --> B --> C So that if e.g. C is down, no echo-reply is sent back (or if C is up, that C is actually sending the echo-reply. Does any one know how to turn off the automatic replies (ICMP and whatever else I haven't forseen yet) or does any one know where I can find out more about the issue? Thank you // Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080820/3e43cc2c/attachment.pgp From scf at FreeBSD.org Wed Aug 20 21:22:53 2008 From: scf at FreeBSD.org (scf@FreeBSD.org) Date: Wed Aug 20 21:23:05 2008 Subject: kern/126695: rtfree messages and network disruption upon use of if_bridge(4) Message-ID: <200808202122.m7KLMraF093622@freefall.freebsd.org> Synopsis: rtfree messages and network disruption upon use of if_bridge(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: scf Responsible-Changed-When: Wed Aug 20 16:21:37 CDT 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126695 From ady at freebsd.ady.ro Wed Aug 20 21:34:42 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Wed Aug 20 21:35:11 2008 Subject: Override default ICMP (and other protocols) default replies. In-Reply-To: <1219265499.9118.31.camel@dib> References: <1219265499.9118.31.camel@dib> Message-ID: Hi, On Wed, 20 Aug 2008, Javier Ubillos wrote: > Hi freebsd-net. > (Sorry for cross posting. This time I think I found the right forum for > my question) > > I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually > NAT, but it's a good analogy for this case). > > I have chosen to use pcaplib to pick up the packets. I have an > implementation which picks up the packets, inspects them, rewrites the > destination/source ip-addresses and sends them out on the repective > interface. Umm, this is going parallel to the real network stack. Why not try to "hijack" the packets fro the kernel to the userland process with a feature like divert in ipfw(8) ? > > The problem I'm facing however is that my interfaces are answering to > e.g. icmp-echo (ping) automatically, and I don't know how to turn this > behaviour off. This is a normal TCP/IP network stack feature in the kernel. You may also find that connecting to one of the open ports on the machine will trigger a similar effect. You need to cut off that packet before entering the upper network application layer in the kernel -- see suggestion above. Regards, Adrian. From freebsd at chrisbuechler.com Thu Aug 21 00:47:25 2008 From: freebsd at chrisbuechler.com (Chris Buechler) Date: Thu Aug 21 00:47:32 2008 Subject: repeatable scp stalls from 7.0 to 7.0 In-Reply-To: <48A878C6.9000001@chrisbuechler.com> References: <48A878C6.9000001@chrisbuechler.com> Message-ID: <48ACBB1C.7080701@chrisbuechler.com> Chris Buechler wrote: > I've been seeing pretty frequent and repeatable scp stalls between two > FreeBSD 7.0 servers (7.0-RELEASE-p2 to be exact) on a 100 Mb LAN. > They're two HP servers, an Opteron 275 and a dual Xeon 3.4 (don't > recall the models but I can get them if it's relevant) using the > onboard bge(4) cards. The client side (builder7) SCPs a file to the > server side (hosting7) about 20 times a day. The stall happens about > 2-4 times a week or so, and has happened ever since we put these two > boxes online in their current functions. Initially they were the > original 7.0 release, prior to the TCP fix in June. It's behaved the > same way both prior to and after that fix. There are no apparent > network issues aside from this with either of the boxes. > > Since we had nothing to go on other than scp sessions going to > "stalled" (no relevant logs), I setup a tcpdump on each end filtering > on the TCP 22 traffic between these hosts, grabbing 100 bytes of each > frame to avoid chewing up too much disk space. When it happened again > I split the end out into its own file with editcap, 4.2-4.3 MB each. > > http://chrisbuechler.com/temp/lastcut-hosting7.pcap - server end, > capture taken on host but destination IP is a jail > http://chrisbuechler.com/temp/lastcut-builder7.pcap - client end, > connection is initiated from the host, no jails involved. > > The TCP window on the ACKs from server to client start decrementing > [1], to the point where it's down to a window of 0. From that point, > everything the server (172.29.29.181) sends back to the client > (172.29.29.170) has a window of 0. Restarting the scp makes it work > again. It doesn't happen every time, somewhere around 2-3% of the time > it does. I don't see any cause for the decrementing window in those > captures but maybe I'm missing something. > > 1 - lastcut-hosting7.pcap frame #21298; lastcut-builder7.pcap #25088 > > These are both very stock boxes, GENERIC kernels, no significant > changes in sysctl or anything else. I'm not sure where to go from > here, any assistance in resolving this would be appreciated. Cut the nasty stuff above that Thunderbird threw in there on the copy/paste, sorry about that. I haven't gotten any replies, thought I would bump this. thanks, Chris From wahjava at gmail.com Thu Aug 21 05:03:34 2008 From: wahjava at gmail.com (=?utf-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksg==?= Ashish Shukla) Date: Thu Aug 21 05:03:41 2008 Subject: rtfree: 0xffffff00030aa4b0 has 2 refs Message-ID: <20080821043828.GA42712@chateau.d.lf> Hi all, I'm getting following message in my dmesg, no. of times continuously. This is the first time, I received this message. rtfree: 0xffffff00030aa4b0 has 2 refs I received this message when I tried to connect to IPv6 internet via Hurricane Electric's tunnel. Following are outputs of some of the commands on my box: ---->8---->8---- % dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p3 #3: Tue Jul 15 10:16:13 IST 2008 root@chateau.d.lf:/usr/obj/usr/src/sys/ULE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100800 Logical CPUs per core: 2 usable memory = 2128392192 (2029 MB) avail memory = 2054033408 (1958 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2d00000f2d device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2d00000f2d device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20e0-0x20e7 mem 0x88100000-0x8817ffff,0x80000000-0x87ffffff,0x88180000-0x8819ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 128M pcm0: mem 0x881a0000-0x881a3fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.2 on pci0 pci2: on pcib2 pcib3: at device 28.3 on pci0 pci3: on pcib3 uhci0: port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x881a4000-0x881a43ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 rl0: port 0x1000-0x10ff mem 0x88009000-0x880090ff irq 21 at device 0.0 on pci4 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:00:21:23:cc:ed rl0: [ITHREAD] pcm1: mem 0x88000000-0x88007fff irq 22 at device 1.0 on pci4 pcm1: pcm1: [ITHREAD] fxp0: port 0x1100-0x113f mem 0x88008000-0x88008fff irq 20 at device 8.0 on pci4 miibus1: on fxp0 inphy0: PHY 1 on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:13:20:b7:55:0a fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20b0-0x20bf irq 18 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] orm0: at iomem 0xcb000-0xcbfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub0 ugen1: on uhub3 Timecounters tick every 1.000 msec acd0: DVDR at ata0-slave UDMA33 ad5: 238475MB at ata2-slave SATA150 ad6: 152627MB at ata3-master SATA150 pcm0: pcm0: SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad5s5 is ext2fs//var/spool/news. GEOM_LABEL: Label for provider ad5s9 is ext2fs/lectures. GEOM_LABEL: Label for provider ad5s10 is ext2fs/archives. GEOM_LABEL: Label for provider ad6s2 is ext2fs//. GEOM_JOURNAL: Journal 499229287: ad6s4a contains data. GEOM_JOURNAL: Journal 499229287: ad6s4a contains journal. GEOM_JOURNAL: Journal ad6s4a clean. GEOM_JOURNAL: Journal 4273413447: ad6s4d contains data. GEOM_JOURNAL: Journal 4273413447: ad6s4d contains journal. GEOM_JOURNAL: Journal ad6s4d clean. GEOM_JOURNAL: Journal 172646561: ad6s4e contains data. GEOM_JOURNAL: Journal 172646561: ad6s4e contains journal. GEOM_JOURNAL: Journal ad6s4e clean. WARNING: Expected rawoffset 0, found 148665509 Trying to mount root from ufs:/dev/ad6s4a.journal plip0: [GIANT-LOCKED] plip0: [ITHREAD] fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 drm0: on vgapci0 info: [drm] AGP at 0x80000000 128MB info: [drm] Initialized i915 1.5.0 20060119 drm0: [ITHREAD] drm0: [ITHREAD] fxp0: link state changed to DOWN fxp0: link state changed to UP WARNING: attempt to net_add_domain(netgraph) after domainfinalize() rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs % ifconfig rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:00:21:23:cc:ed inet6 fe80::200:21ff:fe23:cced%rl0 prefixlen 64 scopeid 0x1 media: Ethernet autoselect (none) status: no carrier fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:13:20:b7:55:0a inet6 fe80::213:20ff:feb7:550a%fxp0 prefixlen 64 scopeid 0x2 inet 172.16.0.2 netmask 0xffffffe0 broadcast 172.16.0.31 inet6 fdxx:xxxx:xxxx::1 prefixlen 48 inet6 2001:470:9130:8000::1 prefixlen 64 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108851 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 ng0: flags=88d1 metric 0 mtu 1492 inet 122.162.237.43 --> 122.160.220.173 netmask 0xffffffff inet6 fe80::200:21ff:fe23:cced%ng0 prefixlen 64 scopeid 0x5 gif0: flags=8051 metric 0 mtu 1280 tunnel inet 122.162.237.43 --> 216.66.80.26 inet6 fe80::200:21ff:fe23:cced%gif0 prefixlen 64 scopeid 0x6 % netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 122.160.220.173 UGS 0 34827 ng0 122.160.220.173 122.162.237.43 UH 1 0 ng0 127.0.0.1 127.0.0.1 UH 0 3337 lo0 172.16.0.0/27 link#2 UC 0 0 fxp0 172.16.0.31 ff:ff:ff:ff:ff:ff UHLWb 1 1 fxp0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2001:470:1f08:3b7::1 UGS gif0 ::1 ::1 UHL lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:470:9130:8000::/64 link#2 UC fxp0 2001:470:9130:8000::1 00:13:20:b7:55:0a UHL lo0 fdcf:xxxx:xxxx::/48 link#2 UC fxp0 fdcf:xxxx:xxxx::1 00:13:20:b7:55:0a UHL lo0 fe80::/10 ::1 UGRS lo0 fe80::%rl0/64 link#1 UC rl0 fe80::200:21ff:fe23:cced%rl0 00:00:21:23:cc:ed UHL lo0 fe80::%fxp0/64 link#2 UC fxp0 fe80::213:20ff:feb7:550a%fxp0 00:13:20:b7:55:0a UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 fe80::%ng0/64 link#5 UC ng0 fe80::200:21ff:fe23:cced%ng0 link#5 UHL lo0 fe80::%gif0/64 link#6 UC gif0 fe80::200:21ff:fe23:cced%gif0 link#6 UHL lo0 ff01:1::/32 link#1 UC rl0 ff01:2::/32 link#2 UC fxp0 ff01:4::/32 ::1 UC lo0 ff01:5::/32 link#5 UC ng0 ff01:6::/32 link#6 UC gif0 ff02::/16 ::1 UGRS lo0 ff02::%rl0/32 link#1 UC rl0 ff02::%fxp0/32 link#2 UC fxp0 ff02::%lo0/32 ::1 UC lo0 ff02::%ng0/32 link#5 UC ng0 ff02::%gif0/32 link#6 UC gif0 % traceroute6 -I -n 2001:4860:0:2001::68 traceroute6 to 2001:4860:0:2001::68 (2001:4860:0:2001::68) from 2001:470:9130:8000::1, 64 hops max, 16 byte packets 1 2001:470:1f08:3b7::1 254.691 ms 255.460 ms 254.047 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * ^C ---->8---->8---- This configuration works fine for me, except for now. The technical support person at the HE's end told their is no problem at HE's end, and it servers are working fine. On googling I found a similar problem[1] reported on freebsd-current last year. And similar to what mentioned in the diff[2] in the followup[3], I found following in my sys/netinet6/in6_gif.c, wondering if it has to do anything with the issue. Please note the calls to the rtfree() function. Shouldn't that call be replaced with RTFREE_LOCKED(). This is just a guess, not sure if that has anything to do with it. 365 if (!rt || rt->rt_ifp != ifp) { 366 #if 0 367 char ip6buf[INET6_ADDRSTRLEN]; 368 log(LOG_WARNING, "%s: packet from %s dropped " 369 "due to ingress filter\n", if_name(GIF2IFP(sc)), 370 ip6_sprintf(ip6buf, &sin6.sin6_addr)); 371 #endif 372 if (rt) 373 rtfree(rt); 374 return 0; 375 } 376 rtfree(rt); 377 } 378 379 return 128 * 2; 380 } Refernces: [1] - http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076401.html [2] - http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070828/1bad9902/rt-0001.bin [3] - http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076494.html Thanks Ashish Shukla -- ?-- ?- ???? ?--- ?- ???- ?- ?--?-? --? -- ?- ?? ?-?? ?-?-?- -?-? --- -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080821/75bfe0b9/attachment.pgp From julian at elischer.org Thu Aug 21 05:20:29 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 21 05:20:36 2008 Subject: m0n0wall/pfsense question. Message-ID: <48ACFB17.9030901@elischer.org> Does anyone know whether the above mentionned bsd systems boot to a ram disk or keep their filesystem on teh flash/disk? From steve at ibctech.ca Thu Aug 21 05:30:19 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Aug 21 05:30:26 2008 Subject: m0n0wall/pfsense question. In-Reply-To: <48ACFB17.9030901@elischer.org> References: <48ACFB17.9030901@elischer.org> Message-ID: <48ACFDC2.10609@ibctech.ca> Julian Elischer wrote: > > Does anyone know whether the above mentionned bsd systems boot to a ram > disk or keep their filesystem on teh flash/disk? Julian, It depends... Its been a while, but any system I've built lately (not related to the aforementioned) are easily dumped from startup->running (then pull the boot medium). I'll find out for you, but if you can provide me with the 'why' factor, it would make research easier and more focused. Steve From linimon at FreeBSD.org Thu Aug 21 09:35:43 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Aug 21 09:35:54 2008 Subject: kern/126688: [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and PAE Message-ID: <200808210935.m7L9ZhMB093324@freefall.freebsd.org> Old Synopsis: 1.4.7 ixgbe driver panic with 4GB and PAE New Synopsis: [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and PAE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 21 09:34:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126688 From yanefbsd at gmail.com Thu Aug 21 09:48:14 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Aug 21 09:48:21 2008 Subject: Issues with msk driver on 8-CURRENT amd64 In-Reply-To: <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com> References: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> <20080820080304.GA87443@cdnetworks.co.kr> <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com> Message-ID: <7d6fde3d0808210248i2a42c88cr378bfc5b998a236c@mail.gmail.com> On Wed, Aug 20, 2008 at 8:20 AM, Garrett Cooper wrote: > Comments inline. > > On Wed, Aug 20, 2008 at 1:03 AM, Pyun YongHyeon wrote: >> On Tue, Aug 19, 2008 at 11:45:48PM -0700, Garrett Cooper wrote: >> > Hi Pyun! >> > I know it's been a while since I responded, but after >> > reinstalling my system recently I noticed that the issue I mentioned >> > almost a year ago >> > (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) >> > with my Marvell chipset card has once again returned. In the interim I >> > was using x86, and I didn't suffer from any of the issues I have again >> > on x64, and I was using XP x64 but now I've switched over to Vista x64 >> > on my client box. >> > Subsequently, the only thing that's really changed on my system >> > is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). >> > I'm using the 7-RELENG kernel right now (and not really enjoying >> > it, but it works -- yay?), but I'd like to help resolve the issue with >> > msk under CURRENT with x64 and my chipset. >> > Standing by awaiting marching orders with tcpdump, netcat, and >> > pciconf at my side to help debug the issue :). >> >> Would you please explain your issues with more information? >> For instance, >> Can you see a valid link is established by msk(4)? > > Sort of. A link between the endpoints is established, but then it > stalls and fails after a "connection reset". > >> Did both ends agree on established speed/duplex? > > Yes, they did. > >> What speed/duplex was chosen by msk(4)? > > 10/100MBit and GBit duplex, respectively. > >> Forcing speed/duplex have any effects? > > Not sure, but using a 100MBit and 1GBit connection yields the same > results, whereas before I just claimed it was just gigabit > connections. > >> Turning off checksum offload or TSO have any effects? > > How do I do that? > >> Did you use back-to-back connection without switch? > > I'm connecting via a switch and it works perfectly fine via 7-RELENG with amd64. > >> tcpdump data for a broken connection might be help too. > > Ok. > > More help on trying to setup everything to debug this issue would be helpful. > > FWIW, the issue might be that the MTU doesn't match for Windows and > FreeBSD (I remember reading that somewhere a while back)... > unfortunately, my router speaks this MTU (1464?) so connections via > msk don't work properly anymore on 8-CURRENT. > > Thanks, > -Garrett I just started tcpdump and I noticed that my FreeBSD box is doing a lot of arp who-has queries (1 host / sec). On a static, private network though this shouldn't be the case, correct? I also setup a simple echo server via python to do my bidding (echo'ing foo) and the messages go through via 7-RELENG's kernel, but I'm seeing a TON of checksum incorrect messages with the 8-CURRENT kernel. Funny though because this issue used to occur with 7-CURRENT last year, which is now 7-RELENG, so someone must have accidentally introduced some kind of regression code into msk(4) or a dependent portion of the kernel, or my compile options are causing this issue. I'm posting my simple echo protocol python script at the bottom of the message, and I'll send you the bzipped format of the tcpdump log privately to avoid spamming net@. Thanks, -Garrett ============= TEST APP =============== #!/usr/bin/env python """ Name: simple_echoer Desc: Simple echo server using a pre-agreed upon port to transmit messages between a client and server. Author: Garrett Cooper [yanegomi {{_AT__spamfree}} gmail {{_DOT__} com] Date: 2008.08.21 Example usage: Case 1 (server): simple_echoer server port_num Case 2 (client): simple_echoer client port_num [hostname|ip] """ import os import socket import sys class simple_echoer: def __init__(self, port): self.port = int(port) def server(self): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((socket.gethostname(), self.port)) s.listen(1) i = 0 while 1: cli_s, __ = s.accept() print "Data received from client socket #", i, cli_s.recv(1500) i = i+1 def client_exit(): sys.exit(0) def client(self, hostname): while 1: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((socket.gethostbyname(hostname), self.port)) s.send("foo") def usage(): print """ Usage: simple_echoer {server|client} port_num [hostname,ip] Note: hostname is only required for the client. """ sys.exit(0) if len(sys.argv) <= 1 or (type != "client" && type != "server"): usage() type = sys.argv[1] if (len(sys.argv) != 4 and type == "client") or len(sys.argv) != 3 and type != "client": usage() se = simple_echoer(sys.argv[2]) if type == "server": se.server() else: se.client(sys.argv[3]) From linimon at FreeBSD.org Thu Aug 21 13:23:44 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Aug 21 13:23:56 2008 Subject: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address Message-ID: <200808211323.m7LDNien043448@freefall.freebsd.org> Old Synopsis: CARP interface renaming makes system no longer respond on the virtual IP address New Synopsis: [carp] CARP interface renaming makes system no longer respond on the virtual IP address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 21 13:23:18 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126714 From sullrich at gmail.com Thu Aug 21 16:56:13 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Thu Aug 21 16:56:20 2008 Subject: m0n0wall/pfsense question. In-Reply-To: <48ACFB17.9030901@elischer.org> References: <48ACFB17.9030901@elischer.org> Message-ID: On 8/21/08, Julian Elischer wrote: > > Does anyone know whether the above mentionned bsd systems boot to a ram > disk or keep their filesystem on teh flash/disk? pfSense keeps the filesystem and m0n0wall runs out of a memory backed system. Hope this helps, Scott From popofnewslists at gmail.com Thu Aug 21 17:36:24 2008 From: popofnewslists at gmail.com (Popof Popof) Date: Thu Aug 21 17:36:31 2008 Subject: How to make two vlans on one interface working with dhclient In-Reply-To: <506570.91627.qm@web46401.mail.sp1.yahoo.com> References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <506570.91627.qm@web46401.mail.sp1.yahoo.com> Message-ID: <9196e72b0808211036j65207771sd384a376601a3a0f@mail.gmail.com> I tried to change the MAC address of rl0.2101 and rl0.100 but this not changed anything. Any other idea ? PS: The exact parameter of ifconfig is lladdr 2008/8/21 Dewayne Geraghty > --- On *Wed, 8/20/08, Popof Popof * wrote: > From: Popof Popof > Subject: How to make two vlans on one interface working with dhclient > To: "FreeBSD Net" > Date: Wednesday, August 20, 2008, 1:13 PM > > Hi, > I have a FreeBSD 6.0 box andi need to configure it in a way that I must use > 2 vlans under one interface and both of them will get an address thanks to > dhclient. > > So in order to make this job I created vlans: > > ifconfig rl0.100 create > ifconfig rl0.2101 create > The vlans are created without any problem. > But I also want to retrieve an diffrent ip address from a dhcpd server on > the two of them. > I've made a specific dhclient.conf for each one: > > interface "rl0.100" { > #My options > } > interface > "rl0.2101" { > #My options > } > > When I launch dhclient on only one interface (100 or 2101) it's works fine > and I get an ip address (class B on vlan 100 and class A on vlan 2101). > But if I launch dhclient on the second interface it's make an error: > > dhclient: Can't bind to dhcp address: Address already in use. Please make > sure there is no other dhcp server runing and that there's no entry for > dhcp > or bootp in /etc/inetd.conf > > Does someone had an idea about how to fix this problem and having my two > vlans working with dhclient? > -------------- > > Popof, > You might need to assign a different MAC address to the interface, try > ifconfig rl0.2101 laddr 00:e0:4c:08:ea:6a > > > > From brooks at freebsd.org Thu Aug 21 18:43:27 2008 From: brooks at freebsd.org (Brooks Davis) Date: Thu Aug 21 18:43:41 2008 Subject: How to make two vlans on one interface working with dhclient In-Reply-To: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> Message-ID: <20080821184404.GA46725@lor.one-eyed-alien.net> On Wed, Aug 20, 2008 at 03:13:00PM +0200, Popof Popof wrote: > Hi, > I have a FreeBSD 6.0 box andi need to configure it in a way that I must use > 2 vlans under one interface and both of them will get an address thanks to > dhclient. > > So in order to make this job I created vlans: > > ifconfig rl0.100 create > ifconfig rl0.2101 create > The vlans are created without any problem. > But I also want to retrieve an diffrent ip address from a dhcpd server on > the two of them. > I've made a specific dhclient.conf for each one: > > interface "rl0.100" { > #My options > } > interface "rl0.2101" { > #My options > } Unless it's absolutly necessicary I don't recommend using dhclient.conf. I don't test it. > When I launch dhclient on only one interface (100 or 2101) it's works fine > and I get an ip address (class B on vlan 100 and class A on vlan 2101). > But if I launch dhclient on the second interface it's make an error: > > dhclient: Can't bind to dhcp address: Address already in use. Please make > sure there is no other dhcp server runing and that there's no entry for dhcp > or bootp in /etc/inetd.conf > > Does someone had an idea about how to fix this problem and having my two > vlans working with dhclient? The current dhclinet scripts don't really support this case. In theory if you removed support for default routes and resolv.conf setting it should probably work, but it's certainly not something I'd expect to work. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080821/681c5fd7/attachment.pgp From julian at elischer.org Thu Aug 21 18:49:54 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 21 18:50:03 2008 Subject: How to make two vlans on one interface working with dhclient In-Reply-To: <20080821184404.GA46725@lor.one-eyed-alien.net> References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <20080821184404.GA46725@lor.one-eyed-alien.net> Message-ID: <48ADB8D0.4040705@elischer.org> Brooks Davis wrote: > On Wed, Aug 20, 2008 at 03:13:00PM +0200, Popof Popof wrote: >> Hi, >> I have a FreeBSD 6.0 box andi need to configure it in a way that I must use >> 2 vlans under one interface and both of them will get an address thanks to >> dhclient. >> >> So in order to make this job I created vlans: >> >> ifconfig rl0.100 create >> ifconfig rl0.2101 create >> The vlans are created without any problem. >> But I also want to retrieve an diffrent ip address from a dhcpd server on >> the two of them. >> I've made a specific dhclient.conf for each one: >> >> interface "rl0.100" { >> #My options >> } >> interface "rl0.2101" { >> #My options >> } > > Unless it's absolutly necessicary I don't recommend using dhclient.conf. I > don't test it. > >> When I launch dhclient on only one interface (100 or 2101) it's works fine >> and I get an ip address (class B on vlan 100 and class A on vlan 2101). >> But if I launch dhclient on the second interface it's make an error: >> >> dhclient: Can't bind to dhcp address: Address already in use. Please make >> sure there is no other dhcp server runing and that there's no entry for dhcp >> or bootp in /etc/inetd.conf >> >> Does someone had an idea about how to fix this problem and having my two >> vlans working with dhclient? > > The current dhclinet scripts don't really support this case. In theory if you > removed support for default routes and resolv.conf setting it should probably > work, but it's certainly not something I'd expect to work. use vimage :-) > > -- Brooks From ccowart at rescomp.berkeley.edu Thu Aug 21 18:53:11 2008 From: ccowart at rescomp.berkeley.edu (Christopher Cowart) Date: Thu Aug 21 18:53:18 2008 Subject: erride default ICMP (and other protocols) default replies. In-Reply-To: <1219265061.9118.29.camel@dib> References: <1219265061.9118.29.camel@dib> Message-ID: <20080821183544.GE25990@hal.rescomp.berkeley.edu> Javier Ubillos wrote: > Hi freebsd-net. > (Sorry for cross posting. This time I think I found the right forum for > my question) > > I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually > NAT, but it's a good analogy for this case). > > I have chosen to use pcaplib to pick up the packets. I have an > implementation which picks up the packets, inspects them, rewrites the > destination/source ip-addresses and sends them out on the repective > interface. > > The problem I'm facing however is that my interfaces are answering to > e.g. icmp-echo (ping) automatically, and I don't know how to turn this > behaviour off. > > What I want to happen is that if A pings C, my router B in between > should simply forward the packets w/o any automatic reactions. > > A --> B --> C > > So that if e.g. C is down, no echo-reply is sent back (or if C is up, > that C is actually sending the echo-reply. > > Does any one know how to turn off the automatic replies (ICMP and > whatever else I haven't forseen yet) or does any one know where I can > find out more about the issue? I'm using ipfw(8), ng_ipfw(4), ng_nat(4), and arp(8) to acheive these results. I have a transparent HTTP proxy via squid that dynamically runs code to setup 1-to-1 NAT rules for users who authenticate to our wireless network. I have a clean 7.0 build, except I patched ng_nat to 7-STABLE to get the functionality of the 'redirectaddr' message. Some relevant code snippets from the system: $onatid and $inatid are deterministic identifiers for numbering the netgraph nodes (they're a function of the public IP assigned). On setup: | ngctl mkpeer ipfw: nat $onatid out | ngctl name ipfw:$onatid $name | ngctl connect ipfw: ${name}: $inatid in | ngctl msg ${name}: setaliasaddr $public_ip | ngctl msg ${name}: redirectaddr '{' \ | "local_addr=$private_ip" \ | "alias_addr=$public_ip" \ | 'description="Static NAT"' \ | '}' | | # Clear any arp entries for this IP that might be in the table, just | # to keep things consistent | arp -d "$public_ip" >/dev/null 2>&1 | | # Use arp(8) to claim this public IP address | arp -s $public_ip $aux_mac pub 2>&1 | nac_log | | ipfw table $private_table add $private_ip $onatid | ipfw table $public_table add $public_ip $inatid On teardown: | arp -d "$public_ip" | ngctl shutdown ipfw:${onatid} | for table in $PRIVATE_TABLES ; do | ipfw -q table $table delete $private_ip $onatid | done | for table in $PUBLIC_TABLES ; do | ipfw -q table $table delete $public_ip $inatid | done This corresponds with the following in ipfw.rules (note by this point in the ruleset, all "management" traffic has been dealt with): | # NAT all traffic coming in from authenticated users | $cmd netgraph tablearg all from "table($TABLE_WIFI_PRIV_AUTH)" to any in | for net in $NAC_PUBLIC_NETS ; do | | # NAT all traffic coming in to authenticated users | $cmd netgraph tablearg all from any to "table($TABLE_WIFI_PUB_AUTH)" \ | in via $(nac_if "$net") | | # We must set interface and direction on these fwd rules. If not, they | # will match traffic from any other hosts on these subnets (including | # the router) and deflect traffic in the wrong direction. | for privnet in $NAC_PRIVATE_NETS ; do | $cmd fwd $(nac_router "$net") ip from $(nac_subnet "$net") to not \ | $(nac_subnet "$net") in via $(nac_if "$privnet") | done | done | $cmd allow all from any to "table($TABLE_WIFI_PRIV_AUTH)" | $cmd allow all from "table($TABLE_WIFI_PUB_AUTH)" to any For each subnet I'm using, I assign an IP to this FreeBSD box so that it knows how to get to the gateway. The published arp entries take care of "claiming" the addresses that are in-use and getting the IP traffic passed up the stack. ipfw intercepts, does the packet-munging, and forwards the results. The hosts behind this box (dubbed an "aux-router" internally) see all IP traffic destined for them -- incoming ICMP or TCP or UDP all gets where it's supposed to go. There is no state across reboots. You may be able to get things working the way you want by *not* using ifconfig to assign address, but instead using this arp(8) trick. You may find the use of ng_nat suits your needs though. Let me know if any of this is unclear. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080821/40072368/attachment.pgp From popofnewslists at gmail.com Thu Aug 21 19:03:55 2008 From: popofnewslists at gmail.com (Popof Popof) Date: Thu Aug 21 19:04:03 2008 Subject: How to make two vlans on one interface working with dhclient In-Reply-To: <48ADB8D0.4040705@elischer.org> References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <20080821184404.GA46725@lor.one-eyed-alien.net> <48ADB8D0.4040705@elischer.org> Message-ID: <9196e72b0808211203j746196fdhc17a221e12e8f065@mail.gmail.com> Here is the output from my ifconfig (I rename rl0.100 and rl0.2101 in vlan0 and vlan1, the RJ45 wire is disconected because i need internet in order to send this message :p ): rl0: flags=8843 mtu 1500 options=8 inet6 fe80::2e0:4dff:fe30:80e1%rl0 prefixlen 64 scopeid 0x1 ether 00:e0:4d:30:80:e1 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=0<> mtu 33208 vlan0: flags=8843 mtu 1500 inet6 fe80::2e0:4dff:fe30:80e1%vlan0 prefixlen 64 scopeid 0x5 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:e0:4d:30:80:a0 media: Ethernet autoselect (none) status: no carrier vlan: 100 parent interface: rl0 vlan1: flags=8843 mtu 1500 inet6 fe80::2e0:4dff:fe30:80e1%vlan1 prefixlen 64 scopeid 0x6 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:e0:4d:30:80:a1 media: Ethernet autoselect (none) status: no carrier vlan: 2101 parent interface: rl0 In order to configure my vlan i follow this guide: http://people.freebsd.org/~arved/vlan/vlan_en.html > Unless it's absolutly necessicary I don't recommend using dhclient.conf. I > don't test it. The problem is that i have to get an ip address from my FAI (i'm trying to bypass my modem, i have an optical connection with an RJ45 instead of RJ11 and I need vlan 100 for internet and 2101 for tv) > The current dhclinet scripts don't really support this case. In theory if you > removed support for default routes and resolv.conf setting it should probably > work, but it's certainly not something I'd expect to work. How do you remove support for default routes and reslov.conf ? I don't understand what do you mean > use vimage :-) If i understand well vimage is used for jail but i need to have those two vlans because my box act like a router and will send data over my switch. From gnn at freebsd.org Thu Aug 21 19:12:03 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Thu Aug 21 19:12:10 2008 Subject: Small patch to multicast code... Message-ID: Hi, Turns out there is a bug in the code that loops back multicast packets. If the underlying device driver supports checksum offloading then the packet that is looped back, when it is transmitted on the wire, is incorrect, due to the fact that the packet is not fully copied. Here is a patch. Comments welcome. Best, George Index: ip_output.c =================================================================== --- ip_output.c (revision 181731) +++ ip_output.c (working copy) @@ -1135,7 +1135,7 @@ register struct ip *ip; struct mbuf *copym; - copym = m_copy(m, 0, M_COPYALL); + copym = m_dup(m, M_DONTWAIT); if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) copym = m_pullup(copym, hlen); if (copym != NULL) { From ed at 80386.nl Thu Aug 21 20:47:39 2008 From: ed at 80386.nl (Ed Schouten) Date: Thu Aug 21 20:47:45 2008 Subject: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) Message-ID: <20080821204736.GR99951@hoeg.nl> Hello everyone, Before I start talking about any technical stuff, I want to mention I'm so far pretty happy with the MPSAFE TTY import. Even though I spent a lot of time close to my mailbox, the amount of troubles caused by the import have remained pretty low (there's only one open bug report, related to ucom(4)), though I'm sure I'll receive lots more the next couple of weeks. Today I thought it would be a good idea to work on my first post-import task, namely designing a hooks interface, which allows other kernel subsystems to inject/capture data. We need such an interface to implement things like snp(4), ppp(4), sl(4), ng_h4(4) and ng_tty(4). As an experiment, I tried to rewrite snp(4), which succeeded (though it needs some polishing before it can hit the tree). There are actually two things I want to discuss in this thread: - Feedback on the current design of the hooks interface. - Figure out which hooks we'll need. We need to know what data is relevant to these line disciplines. === Current design === As I said earlier, I've only got the snp(4) driver working again. A thing I liked about the snp(4) driver, is the way it binds TTY's and snoop instances together. There's this ioctl() called SNPSTTY which is called on a /dev/snp descriptor, which takes a file descriptor as an argument, pointing to the TTY. So right now the API is as follows: | static struct ttyhook myhook = { | .th_a_hook_we_like_1 = mydriver_foo, | .th_a_hook_we_like_2 = mydriver_bar, | ... | }; | | static int | mydriver_ioctl(...) | { | struct tty *tp; | | switch (cmd) { | case MYDRIVER_CONNECT_TO_TTY: | error = ttyhook_register(&tp, td, *(int *)data, | &myhook, softc); | if (error != 0) | return (error); | } | return (ENOTTY); | } The ttyhook_register() routine handles the filedescriptor number to TTY translation safely, so this makes it a lot better than the old programming interface in my opinion. When you want to disconnect the hook, it is often as simple as: | tty_lock(tp); | ttyhook_unregister(tp); /* This releases the lock. */ The hooks are called by the TTY layer with the per-TTY lock held. The consumer can also store 1 pointer inside the TTY structure, which can be obtained by calling ttyhook_softc(). A TTY can only have one associated hook. I think in a lot of cases drivers will just borrow the TTY's lock to lock down some private data as well. === Requirements by the NetGraph folks === So this is actually my question to the people on net@. I suspect the NetGraph bits can be restored again if I add the following hooks to the ttyhook interface: - A hook which gets called each time data arrives on the device (`rint'). When this hook is installed, data will not be delivered to the actual TTY, but diverted to the subsystem in question. - A hook which gets called when the device driver would like to have some data to transmit (`getc'). It just offers a buffer, which can be filled by the subsystem. - A hook which notifies the subsystem of a loss of carrier, device disconnected, etc. A nice thing about the new TTY layer is that we don't need to have any horrible code to convert between mbufs and clists. You can directly copy data from mbufs to the driver's buffers. I'll also document various methods to implement both flow control on input and output. So this is actually what I wanted to tell. I've already got a prototype of the ttyhook interface stored at: http://people.FreeBSD.org/~ed/mpsafetty/ The diffs as of August 21 should just apply on top of SVN. It includes a patched snp(4). Yours, -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080821/bb213ce7/attachment.pgp From rizzo at iet.unipi.it Thu Aug 21 20:51:59 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Aug 21 20:52:06 2008 Subject: Small patch to multicast code... In-Reply-To: References: Message-ID: <20080821203519.GA51534@onelab2.iet.unipi.it> On Thu, Aug 21, 2008 at 03:11:56PM -0400, gnn@freebsd.org wrote: > Hi, > > Turns out there is a bug in the code that loops back multicast > packets. If the underlying device driver supports checksum offloading > then the packet that is looped back, when it is transmitted on the > wire, is incorrect, due to the fact that the packet is not fully > copied. > > Here is a patch. Comments welcome. > > Best, > George > > Index: ip_output.c > =================================================================== > --- ip_output.c (revision 181731) > +++ ip_output.c (working copy) > @@ -1135,7 +1135,7 @@ > register struct ip *ip; > struct mbuf *copym; > > - copym = m_copy(m, 0, M_COPYALL); > + copym = m_dup(m, M_DONTWAIT); > if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) > copym = m_pullup(copym, hlen); > if (copym != NULL) { I am slightly puzzled -- what is exactly the problem, i.e. what part of the packet on the wire is incorrect ? The IP header is within hlen so the m_pullup() should be enough to leave the original content intact. The only thing i can think of is that it's the UDP checksum, residing beyond hlen, which is overwritten somewhere in the call to if_simloop -- in which case perhaps a better fix is to m_pullup() the udp header as well ? (in any case, it is worthwhile to add a comment to explain what should be done -- the code paths using m_*() have become quite fragile with these hw support enhancements that now require selective modifications on previously shared, readonly buffers). cheers luigi From gnn at freebsd.org Thu Aug 21 21:59:51 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Thu Aug 21 21:59:57 2008 Subject: Small patch to multicast code... In-Reply-To: <20080821203519.GA51534@onelab2.iet.unipi.it> References: <20080821203519.GA51534@onelab2.iet.unipi.it> Message-ID: At Thu, 21 Aug 2008 22:35:19 +0200, Luigi Rizzo wrote: > > On Thu, Aug 21, 2008 at 03:11:56PM -0400, gnn@freebsd.org wrote: > > Hi, > > > > Turns out there is a bug in the code that loops back multicast > > packets. If the underlying device driver supports checksum offloading > > then the packet that is looped back, when it is transmitted on the > > wire, is incorrect, due to the fact that the packet is not fully > > copied. > > > > Here is a patch. Comments welcome. > > > > Best, > > George > > > > Index: ip_output.c > > =================================================================== > > --- ip_output.c (revision 181731) > > +++ ip_output.c (working copy) > > @@ -1135,7 +1135,7 @@ > > register struct ip *ip; > > struct mbuf *copym; > > > > - copym = m_copy(m, 0, M_COPYALL); > > + copym = m_dup(m, M_DONTWAIT); > > if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) > > copym = m_pullup(copym, hlen); > > if (copym != NULL) { > > I am slightly puzzled -- what is exactly the problem, i.e. what part > of the packet on the wire is incorrect ? The IP header is within hlen so > the m_pullup() should be enough to leave the original content intact. > > The only thing i can think of is that it's the UDP checksum, > residing beyond hlen, which is overwritten somewhere in the > call to if_simloop -- in which case perhaps a better fix is > to m_pullup() the udp header as well ? It is the checksum that gets trashed, yes. > (in any case, it is worthwhile to add a comment to explain > what should be done -- the code paths using m_*() have become > quite fragile with these hw support enhancements that now > require selective modifications on previously shared, readonly buffers). The m_*() routines actually have reasonable comments, it just seems the wrong one was used here. Best, Gerge From julian at elischer.org Fri Aug 22 01:28:07 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 22 01:28:13 2008 Subject: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) In-Reply-To: <20080821204736.GR99951@hoeg.nl> References: <20080821204736.GR99951@hoeg.nl> Message-ID: <48AE12FC.80304@elischer.org> Ed Schouten wrote: > Hello everyone, > > Before I start talking about any technical stuff, I want to mention I'm > so far pretty happy with the MPSAFE TTY import. Even though I spent a > lot of time close to my mailbox, the amount of troubles caused by the > import have remained pretty low (there's only one open bug report, > related to ucom(4)), though I'm sure I'll receive lots more the next > couple of weeks. > > Today I thought it would be a good idea to work on my first post-import > task, namely designing a hooks interface, which allows other kernel > subsystems to inject/capture data. We need such an interface to > implement things like snp(4), ppp(4), sl(4), ng_h4(4) and ng_tty(4). > > As an experiment, I tried to rewrite snp(4), which succeeded (though it > needs some polishing before it can hit the tree). There are actually two > things I want to discuss in this thread: > > - Feedback on the current design of the hooks interface. > - Figure out which hooks we'll need. We need to know what data is > relevant to these line disciplines. > > === Current design === > > As I said earlier, I've only got the snp(4) driver working again. A > thing I liked about the snp(4) driver, is the way it binds TTY's and > snoop instances together. There's this ioctl() called SNPSTTY which is > called on a /dev/snp descriptor, which takes a file descriptor as an > argument, pointing to the TTY. > > So right now the API is as follows: > > | static struct ttyhook myhook = { > | .th_a_hook_we_like_1 = mydriver_foo, > | .th_a_hook_we_like_2 = mydriver_bar, > | ... > | }; > | > | static int > | mydriver_ioctl(...) > | { > | struct tty *tp; > | > | switch (cmd) { > | case MYDRIVER_CONNECT_TO_TTY: > | error = ttyhook_register(&tp, td, *(int *)data, > | &myhook, softc); > | if (error != 0) > | return (error); > | } > | return (ENOTTY); > | } > > The ttyhook_register() routine handles the filedescriptor number to TTY > translation safely, so this makes it a lot better than the old > programming interface in my opinion. When you want to disconnect the > hook, it is often as simple as: > > | tty_lock(tp); > | ttyhook_unregister(tp); /* This releases the lock. */ > > The hooks are called by the TTY layer with the per-TTY lock held. The > consumer can also store 1 pointer inside the TTY structure, which can be > obtained by calling ttyhook_softc(). A TTY can only have one associated > hook. I think in a lot of cases drivers will just borrow the TTY's lock > to lock down some private data as well. > > === Requirements by the NetGraph folks === > > So this is actually my question to the people on net@. I suspect the > NetGraph bits can be restored again if I add the following hooks to the > ttyhook interface: > > - A hook which gets called each time data arrives on the device > (`rint'). When this hook is installed, data will not be delivered to > the actual TTY, but diverted to the subsystem in question. > > - A hook which gets called when the device driver would like to have > some data to transmit (`getc'). It just offers a buffer, which can be > filled by the subsystem. > > - A hook which notifies the subsystem of a loss of carrier, device > disconnected, etc. > > A nice thing about the new TTY layer is that we don't need to have any > horrible code to convert between mbufs and clists. You can directly copy > data from mbufs to the driver's buffers. I'll also document various > methods to implement both flow control on input and output. > > So this is actually what I wanted to tell. I've already got a prototype > of the ttyhook interface stored at: > > http://people.FreeBSD.org/~ed/mpsafetty/ > > The diffs as of August 21 should just apply on top of SVN. It includes a > patched snp(4). got a p4 pointer? > > Yours, From bms at FreeBSD.org Fri Aug 22 02:46:01 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Aug 22 02:46:07 2008 Subject: Small patch to multicast code... In-Reply-To: References: <20080821203519.GA51534@onelab2.iet.unipi.it> Message-ID: <48AE23FF.9070009@FreeBSD.org> gnn@freebsd.org wrote: >> The only thing i can think of is that it's the UDP checksum, >> residing beyond hlen, which is overwritten somewhere in the >> call to if_simloop -- in which case perhaps a better fix is >> to m_pullup() the udp header as well ? >> > > It is the checksum that gets trashed, yes. > ... > The m_*() routines actually have reasonable comments, it just seems > the wrong one was used here. > Actually, m_copy() has been legacy for some time now -- see comments. I'd be concerned that the change to m_dup() (which makes a full mbuf chain copy) rather than m_copym() (which bumps refcounts) is going to eat into the mbuf clusters on fast links, though it's an easy band-aid for the problem. I agree with Luigi that some of the API contract for mbuf(9) doesn't hold any more now that we have TSO and other offload. cheers BMS From dfilter at FreeBSD.ORG Fri Aug 22 04:10:04 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Aug 22 04:10:10 2008 Subject: kern/114714: commit references a PR Message-ID: <200808220410.m7M4A44d022225@freefall.freebsd.org> The following reply was made to PR kern/114714; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/114714: commit references a PR Date: Fri, 22 Aug 2008 04:04:05 +0000 (UTC) thompsa 2008-08-22 03:55:37 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sbin/ifconfig Makefile ifconfig.8 share/man/man4 gre.4 sys/net if_gre.c if_gre.h Added files: (Branch: RELENG_7) sbin/ifconfig ifgre.c Log: SVN rev 181991 on 2008-08-22 03:55:37Z by thompsa MFC r179894, r181224 Add support for the optional key in the GRE header. PR: kern/114714 Submitted by: Cristian KLEIN Revision Changes Path 1.33.2.1 +1 -0 src/sbin/ifconfig/Makefile 1.142.2.6 +11 -1 src/sbin/ifconfig/ifconfig.8 1.1.2.1 +98 -0 src/sbin/ifconfig/ifgre.c (new) 1.7.2.1 +14 -2 src/share/man/man4/gre.4 1.46.2.5 +44 -3 src/sys/net/if_gre.c 1.13.10.2 +7 -0 src/sys/net/if_gre.h _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From ed at 80386.nl Fri Aug 22 05:17:08 2008 From: ed at 80386.nl (Ed Schouten) Date: Fri Aug 22 05:17:15 2008 Subject: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) In-Reply-To: <48AE12FC.80304@elischer.org> References: <20080821204736.GR99951@hoeg.nl> <48AE12FC.80304@elischer.org> Message-ID: <20080822051707.GU99951@hoeg.nl> * Julian Elischer wrote: > got a p4 pointer? Yes. It's just in //depot/projects/mpsafetty/..., just like where the MPSAFE TTY code used to live. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080822/4ebec8d3/attachment.pgp From julian at elischer.org Fri Aug 22 05:25:00 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 22 05:25:07 2008 Subject: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) In-Reply-To: <20080821204736.GR99951@hoeg.nl> References: <20080821204736.GR99951@hoeg.nl> Message-ID: <48AE4DAA.4080009@elischer.org> Ed Schouten wrote: > Hello everyone, > > Before I start talking about any technical stuff, I want to mention I'm > so far pretty happy with the MPSAFE TTY import. Even though I spent a > lot of time close to my mailbox, the amount of troubles caused by the > import have remained pretty low (there's only one open bug report, > related to ucom(4)), though I'm sure I'll receive lots more the next > couple of weeks. > > Today I thought it would be a good idea to work on my first post-import > task, namely designing a hooks interface, which allows other kernel > subsystems to inject/capture data. We need such an interface to > implement things like snp(4), ppp(4), sl(4), ng_h4(4) and ng_tty(4). > > As an experiment, I tried to rewrite snp(4), which succeeded (though it > needs some polishing before it can hit the tree). There are actually two > things I want to discuss in this thread: > > - Feedback on the current design of the hooks interface. > - Figure out which hooks we'll need. We need to know what data is > relevant to these line disciplines. > > === Current design === > > As I said earlier, I've only got the snp(4) driver working again. A > thing I liked about the snp(4) driver, is the way it binds TTY's and > snoop instances together. There's this ioctl() called SNPSTTY which is > called on a /dev/snp descriptor, which takes a file descriptor as an > argument, pointing to the TTY. > > So right now the API is as follows: > > | static struct ttyhook myhook = { > | .th_a_hook_we_like_1 = mydriver_foo, > | .th_a_hook_we_like_2 = mydriver_bar, > | ... > | }; > | > | static int > | mydriver_ioctl(...) > | { > | struct tty *tp; > | > | switch (cmd) { > | case MYDRIVER_CONNECT_TO_TTY: > | error = ttyhook_register(&tp, td, *(int *)data, > | &myhook, softc); > | if (error != 0) > | return (error); > | } > | return (ENOTTY); > | } > > The ttyhook_register() routine handles the filedescriptor number to TTY > translation safely, so this makes it a lot better than the old > programming interface in my opinion. When you want to disconnect the > hook, it is often as simple as: > > | tty_lock(tp); > | ttyhook_unregister(tp); /* This releases the lock. */ > > The hooks are called by the TTY layer with the per-TTY lock held. The > consumer can also store 1 pointer inside the TTY structure, which can be > obtained by calling ttyhook_softc(). A TTY can only have one associated > hook. I think in a lot of cases drivers will just borrow the TTY's lock > to lock down some private data as well. > > === Requirements by the NetGraph folks === > > So this is actually my question to the people on net@. I suspect the > NetGraph bits can be restored again if I add the following hooks to the > ttyhook interface: > > - A hook which gets called each time data arrives on the device > (`rint'). When this hook is installed, data will not be delivered to > the actual TTY, but diverted to the subsystem in question. yes, though the old interface would only call us once the 'terminator' character was received.. you could make each calling module supply its own "decide if to call yet" function.. so that the heavy calls were not done every time... > > - A hook which gets called when the device driver would like to have > some data to transmit (`getc'). It just offers a buffer, which can be > filled by the subsystem. > yep > - A hook which notifies the subsystem of a loss of carrier, device > disconnected, etc. a nice interface to set the hardware operating parameters (e.g baud, bits) might be nice too but I don't know if we would use it. > > A nice thing about the new TTY layer is that we don't need to have any > horrible code to convert between mbufs and clists. You can directly copy > data from mbufs to the driver's buffers. I'll also document various > methods to implement both flow control on input and output. having done this sort of hting before, the thing you want is th have an interface where you can pass to the tty system, the following things: A pointer to a number of bytes The number of the bytes A function to call when the tty system has finished with the buffer (maybe mfree()) An argument to give to that function. (probably the mbuf) to the tty subsystem, it's a buffer of bytes to the net system it's an mbuf. the 4 arguments could be separately done, or they could be bundled together in a small structure.. your choice. it might be overkill however if ther ewas just one byte to send, so a way to send up to 4 bytes in one simple call might be nice... > > So this is actually what I wanted to tell. I've already got a prototype > of the ttyhook interface stored at: > > http://people.FreeBSD.org/~ed/mpsafetty/ > > The diffs as of August 21 should just apply on top of SVN. It includes a > patched snp(4). > > Yours, From popofnewslists at gmail.com Fri Aug 22 07:14:39 2008 From: popofnewslists at gmail.com (Popof Popof) Date: Fri Aug 22 07:14:50 2008 Subject: How to make two vlans on one interface working with dhclient In-Reply-To: References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <20080821184404.GA46725@lor.one-eyed-alien.net> <48ADB8D0.4040705@elischer.org> <9196e72b0808211203j746196fdhc17a221e12e8f065@mail.gmail.com> Message-ID: <9196e72b0808220014k4b917a08pac2261af88007819@mail.gmail.com> Yes, i applied the modifications at the level of dhclient.conf 2008/8/21 Frank Helbert > Have you tried? > > interface "vlan0" { > #My options > } > interface "vlan1" { > #My options > } > > Thats the way you identify your vlan nics... > > Frank > > On Thu, Aug 21, 2008 at 4:03 PM, Popof Popof > wrote: > > Here is the output from my ifconfig (I rename rl0.100 and rl0.2101 in > vlan0 > > and vlan1, the RJ45 wire is disconected because i need internet in order > to > > send this message :p ): > > > > rl0: flags=8843 mtu 1500 > > options=8 > > inet6 fe80::2e0:4dff:fe30:80e1%rl0 prefixlen 64 scopeid 0x1 > > ether 00:e0:4d:30:80:e1 > > media: Ethernet autoselect (none) > > status: no carrier > > lo0: flags=8049 mtu 16384 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > inet 127.0.0.1 netmask 0xff000000 > > pflog0: flags=0<> mtu 33208 > > vlan0: flags=8843 mtu 1500 > > inet6 fe80::2e0:4dff:fe30:80e1%vlan0 prefixlen 64 scopeid 0x5 > > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > > ether 00:e0:4d:30:80:a0 > > media: Ethernet autoselect (none) > > status: no carrier > > vlan: 100 parent interface: rl0 > > vlan1: flags=8843 mtu 1500 > > inet6 fe80::2e0:4dff:fe30:80e1%vlan1 prefixlen 64 scopeid 0x6 > > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > > ether 00:e0:4d:30:80:a1 > > media: Ethernet autoselect (none) > > status: no carrier > > vlan: 2101 parent interface: rl0 > > > > In order to configure my vlan i follow this guide: > > http://people.freebsd.org/~arved/vlan/vlan_en.html > > > >> Unless it's absolutly necessicary I don't recommend using dhclient.conf. > >> I > >> don't test it. > > > > The problem is that i have to get an ip address from my FAI (i'm trying > to > > bypass my modem, i have an optical connection with an RJ45 instead of > RJ11 > > and I need vlan 100 for internet and 2101 for tv) > > > >> The current dhclinet scripts don't really support this case. In theory > if > >> you > >> removed support for default routes and resolv.conf setting it should > >> probably > >> work, but it's certainly not something I'd expect to work. > > > > How do you remove support for default routes and reslov.conf ? I don't > > understand what do you mean > > > >> use vimage :-) > > > > If i understand well vimage is used for jail but i need to have those two > > vlans because my box act like a router and will send data over my switch. > > > > > From rizzo at iet.unipi.it Fri Aug 22 08:27:47 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Aug 22 08:27:54 2008 Subject: Small patch to multicast code... In-Reply-To: <48AE23FF.9070009@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> Message-ID: <20080822083020.GA57441@onelab2.iet.unipi.it> On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote: > gnn@freebsd.org wrote: > >>The only thing i can think of is that it's the UDP checksum, > >>residing beyond hlen, which is overwritten somewhere in the > >>call to if_simloop -- in which case perhaps a better fix is > >>to m_pullup() the udp header as well ? > >> > > > >It is the checksum that gets trashed, yes. > >... > >The m_*() routines actually have reasonable comments, it just seems > >the wrong one was used here. > > > > Actually, m_copy() has been legacy for some time now -- see comments. The API is undocumented, but in this specific function the reason for using one rather than the other is undocumented. Especially, if you use m_dup() then the call to m_pullup should be unnecessary. That's why I suggested to explain clearly what is wrong in the original code, so even if now we only apply a temporary bandaid (for lack of time, etc.) hopefully later this can be reverted to something more efficient such as pulling up the UDP header as well. cheers luigi From mays at win.net Fri Aug 22 14:48:05 2008 From: mays at win.net (Joseph Mays) Date: Fri Aug 22 14:48:12 2008 Subject: Kernel Panic in SCTP Message-ID: <006e01c90462$339fb320$0a2118d8@engineering01> Hello. We've recently written an extensive software system that uses SCTP as a critical component. We've started to run into an issue where the box kenel panics after throwing an error message from sctp_timer.c that says "Our list is out of order? Out of order list". Can anyone here shed light on what's going on, or give us a clue how to debug this? http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 Joe Mays From citrin at citrin.ru Fri Aug 22 15:45:11 2008 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Fri Aug 22 15:45:18 2008 Subject: bug in unix sockets garbage collector Message-ID: <48AEDC40.6030901@citrin.ru> On servers where used unix sockets, sometimes thread taskq start to eat 100% CPU: http://docs.FreeBSD.org/cgi/mid.cgi?474EFC5C.9060508 Addition info about this problem - when this occurs sysctl net.local.inflight show negative number. % sysctl net.local.inflight net.local.inflight: -3 And this condition become always true: if (local_unp_rights) taskqueue_enqueue(taskqueue_thread, &unp_gc_task); It seems, that unp_rights decremented more often than incremented, or some race exist. -- Anton Yuzhaninov From sam at freebsd.org Fri Aug 22 16:42:52 2008 From: sam at freebsd.org (Sam Leffler) Date: Fri Aug 22 16:42:59 2008 Subject: Small patch to multicast code... In-Reply-To: <20080822083020.GA57441@onelab2.iet.unipi.it> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <20080822083020.GA57441@onelab2.iet.unipi.it> Message-ID: <48AEE8ED.7000301@freebsd.org> Luigi Rizzo wrote: > On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote: > >> gnn@freebsd.org wrote: >> >>>> The only thing i can think of is that it's the UDP checksum, >>>> residing beyond hlen, which is overwritten somewhere in the >>>> call to if_simloop -- in which case perhaps a better fix is >>>> to m_pullup() the udp header as well ? >>>> >>>> >>> It is the checksum that gets trashed, yes. >>> ... >>> The m_*() routines actually have reasonable comments, it just seems >>> the wrong one was used here. >>> >>> >> Actually, m_copy() has been legacy for some time now -- see comments. >> > > The API is undocumented, but in this specific function the reason > for using one rather than the other is undocumented. Especially, > if you use m_dup() then the call to m_pullup should be > unnecessary. > > That's why I suggested to explain clearly what is wrong in the original > code, so even if now we only apply a temporary bandaid (for lack of time, > etc.) hopefully later this can be reverted to something more efficient > such as pulling up the UDP header as well. > > I agree that doing the deep copy is just papering over a bigger problem. Sam From mike at sentex.net Fri Aug 22 17:43:17 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Aug 22 17:43:24 2008 Subject: strange TCP issue on RELENG_7 Message-ID: <200808221719.m7MHJY25090566@lava.sentex.ca> On one of our sendmail boxes that we are running RELENG_7, we have noticed an odd issue triggered or noticed by our monitoring system (bigbrother in this case). The seems to have been happening ever since we installed it, so its not a recent commit issue. Every 5 min, one of our monitoring stations connects to the box on port 25 The connection process is pretty simple. It connects and sends a QUIT and if that works, all is "ok". Here is a normal exchange 17:44:27.966100 IP 192.168.1.2.59586 > 192.168.1.9.25: S 1590561033:1590561033(0) win 65535 17:44:27.966119 IP 192.168.1.9.25 > 192.168.1.2.59586: S 2644498016:2644498016(0) ack 1590561034 win 65535 17:44:27.966649 IP 192.168.1.2.59586 > 192.168.1.9.25: . ack 1 win 8326 17:44:27.966664 IP 192.168.1.2.59586 > 192.168.1.9.25: P 1:12(11) ack 1 win 8326 17:44:27.969087 IP 192.168.1.9.25 > 192.168.1.2.59586: P 1:186(185) ack 12 win 8326 17:44:27.969119 IP 192.168.1.9.25 > 192.168.1.2.59586: F 186:186(0) ack 12 win 8326 17:44:27.969642 IP 192.168.1.2.59586 > 192.168.1.9.25: . ack 187 win 8326 17:44:27.969657 IP 192.168.1.2.59586 > 192.168.1.9.25: F 12:12(0) ack 187 win 8326 17:44:27.969668 IP 192.168.1.9.25 > 192.168.1.2.59586: . ack 13 win 8325 But, perhaps twice a day, or once every 2 days, I will see an RST from the host being monitored for some reason?! It looks like 17:49:27.496803 IP (tos 0x0, ttl 64, id 8521, offset 0, flags [DF], proto TCP (6), length 60) 199.212.134.2.65013 > 199.212.134.9.25: S, cksum 0xabde (correct), 2204170858:2204170858(0) win 65535 17:49:27.496829 IP (tos 0x0, ttl 64, id 42946, offset 0, flags [DF], proto TCP (6), length 60) 199.212.134.9.25 > 199.212.134.2.65013: S, cksum 0xfe09 (correct), 3523370477:3523370477(0) ack 2204170859 win 65535 17:49:27.497260 IP (tos 0x0, ttl 64, id 8522, offset 0, flags [DF], proto TCP (6), length 52) 199.212.134.2.65013 > 199.212.134.9.25: ., cksum 0x0c4c (correct), 1:1(0) ack 1 win 8326 17:49:27.497268 IP (tos 0x0, ttl 64, id 42948, offset 0, flags [DF], proto TCP (6), length 40) 199.212.134.9.25 > 199.212.134.2.65013: R, cksum 0xe62b (correct), 3523370478:3523370478(0) win 0 17:49:27.497270 IP (tos 0x0, ttl 64, id 8523, offset 0, flags [DF], proto TCP (6), length 63) 199.212.134.2.65013 > 199.212.134.9.25: P, cksum 0xb803 (correct), 1:12(11) ack 1 win 8326 17:49:27.497277 IP (tos 0x0, ttl 64, id 42949, offset 0, flags [DF], proto TCP (6), length 40) 199.212.134.9.25 > 199.212.134.2.65013: R, cksum 0xe62b (correct), 3523370478:3523370478(0) win 0 17:49:34.690828 IP (tos 0x0, ttl 64, id 45325, offset 0, flags [DF], proto TCP (6), length 60) 199.212.134.9.65077 > 199.212.134.2.25: S, cksum 0x3e26 (correct), 2116235846:2116235846(0) win 65535 I dont ever see this on RELENG_6, only on RELENG_7. It doesnt seem to be load related as I will see it at various times of the day both busy and quiet and sendmail is not complaining about too many connections which it will when there are. 192.168.1.2 is the monitoring host running bb and 192.168.1.9 is the smtp server being tested. I do have pf on the box, but pf isnt set to send RSTs and I think if there is a state mismatch, it will just drop the packet and not send the RST. I have tried with and without scrub but no obvious difference Rules are simple set skip on lo0 scrub in all block in log on {em0,em1} pass in on {em0,em1} proto {tcp,udp} from pass in on {em0,em1,lo0} proto tcp from any to any port {25,53,587} pass in on {em0,em1,lo0} proto udp from any to any port {53} pass in on {em0,em1} proto icmp from any to any pass out on {em0,em1} proto {icmp,tcp,udp} from any to any -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From gnn at FreeBSD.org Fri Aug 22 17:44:06 2008 From: gnn at FreeBSD.org (gnn@FreeBSD.org) Date: Fri Aug 22 17:44:54 2008 Subject: Small patch to multicast code... In-Reply-To: <48AE23FF.9070009@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> Message-ID: At Fri, 22 Aug 2008 03:27:11 +0100, Bruce M. Simpson wrote: > > gnn@freebsd.org wrote: > >> The only thing i can think of is that it's the UDP checksum, > >> residing beyond hlen, which is overwritten somewhere in the > >> call to if_simloop -- in which case perhaps a better fix is > >> to m_pullup() the udp header as well ? > >> > > > > It is the checksum that gets trashed, yes. > > ... > > The m_*() routines actually have reasonable comments, it just seems > > the wrong one was used here. > > > > Actually, m_copy() has been legacy for some time now -- see comments. > > I'd be concerned that the change to m_dup() (which makes a full mbuf > chain copy) rather than m_copym() (which bumps refcounts) is going to > eat into the mbuf clusters on fast links, though it's an easy band-aid > for the problem. I gather you mean that a fast link on which also we're looping back the packet will be an issue? Since this packet is only going into the simloop() routine. > I agree with Luigi that some of the API contract for mbuf(9) doesn't > hold any more now that we have TSO and other offload. I was actually hoping, as the person who last hacked this code, that you might have a suggestion as to a "right" fix. Best, George From bms at FreeBSD.org Fri Aug 22 18:43:07 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Aug 22 18:43:51 2008 Subject: Small patch to multicast code... In-Reply-To: References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> Message-ID: <48AF08B7.4090804@FreeBSD.org> gnn@FreeBSD.org wrote: > I gather you mean that a fast link on which also we're looping back > the packet will be an issue? Since this packet is only going into the > simloop() routine. > We end up calling if_simloop() from a few "interesting" places, in particular the kernel PIM packet handler. In this particular case we're going to take a full mbuf chain copy every time we send a packet which needs to be looped back to userland. > > I was actually hoping, as the person who last hacked this code, that > you might have a suggestion as to a "right" fix. > It's been a while since I've done any in-depth FreeBSD work other than hacking on the IGMPv3 snap, and my time is largely tied up with other work these days, sadly. It doesn't seem right to my mind that we need to make a full copy of an mbuf chain with m_dup() to workaround this kind of problem. Whilst it may suffice for a band-aid workaround, we may see mbuf pool fragmentation as packet rates go up. However we are now in a "new world order" where mbuf chains may be very tied to the device where they've originated or to where they're going. It isn't clear to me where this kind of intrusion is happening. In the case of ip_mloopback(), somehow we are stomping on a read-only copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine according to the documented uses of mbuf(9), although as Luigi pointed out, most likely we need to look at the upper-layer protocol too, e.g. where UDP checksums are also being offloaded. Some of the code in the IGMPv3 branch actually reworks how loopback happens i.e. the preference is not to loop back wherever possible because of the locking implications. Check the bms_netdev branch history for more info. cheers BMS From bzeeb-lists at lists.zabbadoz.net Fri Aug 22 19:12:39 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Aug 22 19:12:47 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <200808221719.m7MHJY25090566@lava.sentex.ca> References: <200808221719.m7MHJY25090566@lava.sentex.ca> Message-ID: <20080822191146.T66593@maildrop.int.zabbadoz.net> On Fri, 22 Aug 2008, Mike Tancsa wrote: > On one of our sendmail boxes that we are running RELENG_7, we have noticed an > odd issue triggered or noticed by our monitoring system (bigbrother in this > case). The seems to have been happening ever since we installed it, so its > not a recent commit issue. > > Every 5 min, one of our monitoring stations connects to the box on port 25 > > The connection process is pretty simple. It connects and sends a QUIT and if > that works, all is "ok". > > Here is a normal exchange > ... > > > But, perhaps twice a day, or once every 2 days, I will see an RST from the > host being monitored for some reason?! > It looks like > > ... > > I dont ever see this on RELENG_6, only on RELENG_7. It doesnt seem to be load > related as I will see it at various times of the day both busy and quiet and > sendmail is not complaining about too many connections which it will when > there are. > > 192.168.1.2 is the monitoring host running bb and 192.168.1.9 is the smtp > server being tested. I do have pf on the box, but pf isnt set to send RSTs > and I think if there is a state mismatch, it will just drop the packet and > not send the RST. I have tried with and without scrub but no obvious > difference > > Rules are simple > > > set skip on lo0 > scrub in all > > block in log on {em0,em1} > pass in on {em0,em1} proto {tcp,udp} from > pass in on {em0,em1,lo0} proto tcp from any to any port {25,53,587} > pass in on {em0,em1,lo0} proto udp from any to any port {53} > pass in on {em0,em1} proto icmp from any to any > pass out on {em0,em1} proto {icmp,tcp,udp} from any to any can you make sure you have this? http://svn.freebsd.org/changeset/base/181596 -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From mike at sentex.net Fri Aug 22 19:22:42 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Aug 22 19:22:48 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <20080822191146.T66593@maildrop.int.zabbadoz.net> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> Message-ID: <200808221922.m7MJMcUN091064@lava.sentex.ca> At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: >can you make sure you have this? > >http://svn.freebsd.org/changeset/base/181596 Hi, I do. I am running a GENERIC kernel but with inet6 disabled from yesterday 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 and with the patch below as TOE seems to be broken for my workload # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 +++ sys/netinet/tcp_offload.c.disable 2008-08-22 15:16:50.000000000 -0400 @@ -58,6 +58,8 @@ struct rtentry *rt; int error; + return (EINVAL); + /* * Look up the route used for the connection to * determine if it uses an interface capable of I can try changing to ipfw and see if that makes a difference ? But the RST doesnt sound like a pf issue no ? I would have thought it would just blackhole the packet. ---Mike From rizzo at iet.unipi.it Fri Aug 22 19:39:25 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Aug 22 19:39:31 2008 Subject: Small patch to multicast code... In-Reply-To: <48AF08B7.4090804@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> Message-ID: <20080822194200.GC63527@onelab2.iet.unipi.it> On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: > gnn@FreeBSD.org wrote: > >I gather you mean that a fast link on which also we're looping back > >the packet will be an issue? Since this packet is only going into the > >simloop() routine. > > > > We end up calling if_simloop() from a few "interesting" places, in > particular the kernel PIM packet handler. > > In this particular case we're going to take a full mbuf chain copy every > time we send a packet which needs to be looped back to userland. ... > In the case of ip_mloopback(), somehow we are stomping on a read-only > copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine > according to the documented uses of mbuf(9), although as Luigi pointed > out, most likely we need to look at the upper-layer protocol too, e.g. > where UDP checksums are also being offloaded. in fact, george, if you have an easy way to reproduce the error, could you see if reverting your change and instead adding sizeof(struct udphdr) to the length argument in the call to m_pullup() fixes the problem ? cheers luigi From bzeeb-lists at lists.zabbadoz.net Fri Aug 22 20:05:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Aug 22 20:05:15 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <200808221922.m7MJMcUN091064@lava.sentex.ca> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> Message-ID: <20080822195923.X66593@maildrop.int.zabbadoz.net> On Fri, 22 Aug 2008, Mike Tancsa wrote: > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: > >> can you make sure you have this? >> >> http://svn.freebsd.org/changeset/base/181596 > > Hi, > I do. I am running a GENERIC kernel but with inet6 disabled from yesterday > > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 > > and with the patch below as TOE seems to be broken for my workload okay. Does netstat -s -p tcp should any obvious error counters raising? I just try to get the easy things sorted out before anyone starts to debug more TCP... /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From linimon at FreeBSD.org Fri Aug 22 20:05:35 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Aug 22 20:05:50 2008 Subject: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Message-ID: <200808222005.m7MK5ZDP082827@freefall.freebsd.org> Old Synopsis: kernel panic when sending file via ng_ubt New Synopsis: [panic] kernel panic when sending file via ng_ubt(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 22 20:02:51 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126742 From mike at sentex.net Fri Aug 22 20:15:29 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Aug 22 20:15:35 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <20080822195923.X66593@maildrop.int.zabbadoz.net> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <20080822195923.X66593@maildrop.int.zabbadoz.net> Message-ID: <200808222015.m7MKFPp8091270@lava.sentex.ca> At 04:01 PM 8/22/2008, Bjoern A. Zeeb wrote: >On Fri, 22 Aug 2008, Mike Tancsa wrote: > >>At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: >> >>>can you make sure you have this? >>>http://svn.freebsd.org/changeset/base/181596 >> >>Hi, >>I do. I am running a GENERIC kernel but with inet6 disabled from yesterday >> >>7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 >> >>and with the patch below as TOE seems to be broken for my workload > >okay. > >Does netstat -s -p tcp should any obvious error counters raising? > >I just try to get the easy things sorted out before anyone starts >to debug more TCP... Not sure, what is obvious :) This host is part of the primary MX list for a lot of inbound traffic, so there will be all sorts of hosts using all sorts of stacks connecting to it. netstat -ni shows no errors as do the stats from the em driver (below) tcp: 26989994 packets sent 17034559 data packets (84842431 bytes) 101073 data packets (20893246 bytes) retransmitted 4586 data packets unnecessarily retransmitted 2 resends initiated by MTU discovery 6523153 ack-only packets (333850 delayed) 0 URG only packets 0 window probe packets 1016646 window update packets 2314525 control packets 27848527 packets received 15078177 acks (for 78677787 bytes) 830948 duplicate acks 4689 acks for unsent data 11374257 packets (4127132455 bytes) received in-sequence 40287 completely duplicate packets (30901526 bytes) 921 old duplicate packets 352 packets with some dup. data (179712 bytes duped) 225759 out-of-order packets (276463593 bytes) 8 packets (0 bytes) of data after window 0 window probes 710635 window update packets 298525 packets received after close 849 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 5855 discarded due to memory problems 855019 connection requests 1091001 connection accepts 0 bad connection attempts 10943 listen queue overflows 79448 ignored RSTs in the windows 1944666 connections established (including accepts) 2088626 connections closed (including 516007 drops) 840374 connections updated cached RTT on close 842332 connections updated cached RTT variance on close 60049 connections updated cached ssthresh on close 1201 embryonic connections dropped 14026440 segments updated rtt (of 12656642 attempts) 157370 retransmit timeouts 7412 connections dropped by rexmit timeout 1 persist timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 886 keepalive timeouts 13 keepalive probes sent 873 connections dropped by keepalive 110658 correct ACK header predictions 7810293 correct data packet header predictions 1114950 syncache entries added 63212 retransmitted 35592 dupsyn 77 dropped 1091001 completed 0 bucket overflow 0 cache overflow 4908 reset 8260 stale 10943 aborted 0 badack 174 unreach 0 zone failures 1115027 cookies sent 361 cookies received 2843 SACK recovery episodes 2620 segment rexmits in SACK recovery episodes 3722090 byte rexmits in SACK recovery episodes 35491 SACK options (SACK blocks) received 162860 SACK options (SACK blocks) sent 0 SACK scoreboard overflow Aug 22 16:13:28 smtp2 kernel: em0: Excessive collisions = 0 Aug 22 16:13:28 smtp2 kernel: em0: Sequence errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Defer count = 0 Aug 22 16:13:28 smtp2 kernel: em0: Missed Packets = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive No Buffers = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive Length Errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Crc errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Alignment errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Collision/Carrier extension errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: RX overruns = 0 Aug 22 16:13:28 smtp2 kernel: em0: watchdog timeouts = 0 Aug 22 16:13:28 smtp2 kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Aug 22 16:13:28 smtp2 kernel: em0: XON Rcvd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XON Xmtd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XOFF Rcvd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XOFF Xmtd = 0 Aug 22 16:13:28 smtp2 kernel: em0: Good Packets Rcvd = 16920559 Aug 22 16:13:28 smtp2 kernel: em0: Good Packets Xmtd = 16025617 Aug 22 16:13:28 smtp2 kernel: em0: TSO Contexts Xmtd = 0 Aug 22 16:13:28 smtp2 kernel: em0: TSO Contexts Failed = 0 Aug 22 16:13:31 smtp2 kernel: em1: Excessive collisions = 0 Aug 22 16:13:31 smtp2 kernel: em1: Sequence errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Defer count = 0 Aug 22 16:13:31 smtp2 kernel: em1: Missed Packets = 0 Aug 22 16:13:31 smtp2 kernel: em1: Receive No Buffers = 0 Aug 22 16:13:31 smtp2 kernel: em1: Receive Length Errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Receive errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Crc errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Alignment errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Collision/Carrier extension errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: RX overruns = 0 Aug 22 16:13:31 smtp2 kernel: em1: watchdog timeouts = 0 Aug 22 16:13:31 smtp2 kernel: em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Aug 22 16:13:31 smtp2 kernel: em1: XON Rcvd = 0 Aug 22 16:13:31 smtp2 kernel: em1: XON Xmtd = 0 Aug 22 16:13:31 smtp2 kernel: em1: XOFF Rcvd = 0 Aug 22 16:13:31 smtp2 kernel: em1: XOFF Xmtd = 0 Aug 22 16:13:31 smtp2 kernel: em1: Good Packets Rcvd = 13566035 Aug 22 16:13:31 smtp2 kernel: em1: Good Packets Xmtd = 14313612 Aug 22 16:13:31 smtp2 kernel: em1: TSO Contexts Xmtd = 0 Aug 22 16:13:31 smtp2 kernel: em1: TSO Contexts Failed = 0 From gnn at freebsd.org Fri Aug 22 21:34:08 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Fri Aug 22 21:34:14 2008 Subject: Small patch to multicast code... In-Reply-To: <20080822194200.GC63527@onelab2.iet.unipi.it> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <20080822194200.GC63527@onelab2.iet.unipi.it> Message-ID: At Fri, 22 Aug 2008 21:42:00 +0200, Luigi Rizzo wrote: > > On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: > > gnn@FreeBSD.org wrote: > > >I gather you mean that a fast link on which also we're looping back > > >the packet will be an issue? Since this packet is only going into the > > >simloop() routine. > > > > > > > We end up calling if_simloop() from a few "interesting" places, in > > particular the kernel PIM packet handler. > > > > In this particular case we're going to take a full mbuf chain copy every > > time we send a packet which needs to be looped back to userland. > ... > > In the case of ip_mloopback(), somehow we are stomping on a read-only > > copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine > > according to the documented uses of mbuf(9), although as Luigi pointed > > out, most likely we need to look at the upper-layer protocol too, e.g. > > where UDP checksums are also being offloaded. > > in fact, george, if you have an easy way to reproduce the error, > could you see if reverting your change and instead adding > sizeof(struct udphdr) to the length argument in the call to m_pullup() > fixes the problem ? I don't have sample code I can give but it's simple to set up and test. On machine A set up a sender and a listener for the same multicast group/port. On machine B set up a listener. Send from A with the listener on. B should see nothing and its "bad checksums" counter should increase. Turn off listener on A. Send again, B should get the packet. If you listen to the traffic with tcpdump on a 3rd machine you'll see that the checksum is constant, even if the data in the packet, like the ports, is not. Your ethernet cards have to have hardware checksum offloading. I'm using em/igb in 7-STABLE. Best, George From gnn at FreeBSD.org Fri Aug 22 21:40:05 2008 From: gnn at FreeBSD.org (gnn@FreeBSD.org) Date: Fri Aug 22 21:40:11 2008 Subject: Small patch to multicast code... In-Reply-To: <48AF08B7.4090804@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> Message-ID: At Fri, 22 Aug 2008 19:43:03 +0100, Bruce M. Simpson wrote: > > We end up calling if_simloop() from a few "interesting" places, in > particular the kernel PIM packet handler. > > In this particular case we're going to take a full mbuf chain copy every > time we send a packet which needs to be looped back to userland. Right, I know the penalty. > It's been a while since I've done any in-depth FreeBSD work other > than hacking on the IGMPv3 snap, and my time is largely tied up with > other work these days, sadly. > > It doesn't seem right to my mind that we need to make a full copy of > an mbuf chain with m_dup() to workaround this kind of problem. > > Whilst it may suffice for a band-aid workaround, we may see mbuf > pool fragmentation as packet rates go up. > > However we are now in a "new world order" where mbuf chains may be > very tied to the device where they've originated or to where they're > going. It isn't clear to me where this kind of intrusion is > happening. > > In the case of ip_mloopback(), somehow we are stomping on a > read-only copy of an mbuf chain. The use of m_copy() with m_pullup() > there is fine according to the documented uses of mbuf(9), although > as Luigi pointed out, most likely we need to look at the upper-layer > protocol too, e.g. where UDP checksums are also being offloaded. > > Some of the code in the IGMPv3 branch actually reworks how loopback > happens i.e. the preference is not to loop back wherever possible > because of the locking implications. Check the bms_netdev branch > history for more info. Well, what I suspect is the problem are these bits: udp_output(): /* * Set up checksum and output datagram. */ if (udp_cksum) { if (inp->inp_flags & INP_ONESBCAST) faddr.s_addr = INADDR_BROADCAST; ui->ui_sum = in_pseudo(ui->ui_src.s_addr, faddr.s_addr, htons((u_short)len + sizeof(struct udphdr) + IPPROTO_UDP)); m->m_pkthdr.csum_flags = CSUM_UDP; m->m_pkthdr.csum_data = offsetof(struct udphdr, uh_sum); } else ip_mloopback(): copym = m_copy(m, 0, M_COPYALL); if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) copym = m_pullup(copym, hlen); if (copym != NULL) { /* If needed, compute the checksum and mark it as valid. */ if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { in_delayed_cksum(copym); copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; copym->m_pkthdr.csum_flags |= CSUM_DATA_VALID | CSUM_PSEUDO_HDR; copym->m_pkthdr.csum_data = 0xffff; } and: in_delayed_cksum(struct mbuf *m) { struct ip *ip; u_short csum, offset; ip = mtod(m, struct ip *); offset = ip->ip_hl << 2 ; csum = in_cksum_skip(m, ip->ip_len, offset); if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0) csum = 0xffff; offset += m->m_pkthdr.csum_data; /* checksum offset */ Somehow the data that the device needs to do the proper checksum offload is getting trashed here. Now, since it's clear we need a writable packet structure so that we don't trash the original, I'm wondering if the m_pullup() will be sufficient. Best, George From bms at FreeBSD.org Fri Aug 22 21:43:43 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Aug 22 21:43:49 2008 Subject: Small patch to multicast code... In-Reply-To: References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> Message-ID: <48AF330B.4010802@FreeBSD.org> gnn@FreeBSD.org wrote: > Somehow the data that the device needs to do the proper checksum > offload is getting trashed here. Now, since it's clear we need a > writable packet structure so that we don't trash the original, I'm > wondering if the m_pullup() will be sufficient. > If it's serious enough to break UDP checksumming on the wire, perhaps we should just swallow the mbuf allocator heap churn and do the m_dup() for now, but slap in a big comment about why it's there. BMS From gnn at FreeBSD.org Fri Aug 22 22:04:04 2008 From: gnn at FreeBSD.org (gnn@FreeBSD.org) Date: Fri Aug 22 22:04:11 2008 Subject: Small patch to multicast code... In-Reply-To: <48AF330B.4010802@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> Message-ID: At Fri, 22 Aug 2008 22:43:39 +0100, Bruce M. Simpson wrote: > > gnn@FreeBSD.org wrote: > > Somehow the data that the device needs to do the proper checksum > > offload is getting trashed here. Now, since it's clear we need a > > writable packet structure so that we don't trash the original, I'm > > wondering if the m_pullup() will be sufficient. > > > > If it's serious enough to break UDP checksumming on the wire, perhaps we > should just swallow the mbuf allocator heap churn and do the m_dup() for > now, but slap in a big comment about why it's there. I think if none of us finds a better way before early next week that's what I'll do so that this at least works in 7.1. Best, George From freebsd.alex at spamfoodie.com Fri Aug 22 22:30:05 2008 From: freebsd.alex at spamfoodie.com (Alex) Date: Fri Aug 22 22:30:11 2008 Subject: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Message-ID: <200808222230.m7MMU4au095695@freefall.freebsd.org> The following reply was made to PR kern/126742; it has been noted by GNATS. From: Alex To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Date: Fri, 22 Aug 2008 22:27:39 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: 7-STABLE >Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: ok. one last try. i'll simply attach the dmesg output as a file. >How-To-Repeat: >Fix: Patch attached with submission follows: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (2997.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2086535168 (1989 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] uhci0: port 0xe200-0xe21f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe000-0xe01f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe100-0xe11f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf8205000-0xf82053ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcm0: mem 0xf8200000-0xf8203fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 atapci0: port 0xd000-0xd007,0xd100-0xd103,0xd200-0xd207,0xd300-0xd303,0xd400-0xd40f mem 0xf8000000-0xf8001fff irq 19 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xf8204000-0xf82043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 ath0: mem 0xf8100000-0xf810ffff irq 19 at device 1.0 on pci5 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0f:b5:82:07:c8 ath0: mac 7.9 phy 4.5 radio 5.6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f,0xfc00-0xfc0f at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xe700-0xe707,0xe800-0xe803,0xe900-0xe907,0xea00-0xea03,0xeb00-0xeb0f,0xec00-0xec0f irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est0 attach returned 6 p4tcc0: on cpu0 coretemp0: on cpu0 acpi_button0: on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ums0: on uhub1 ums0: 7 buttons and Z dir. ukbd0: on uhub1 kbd0 at ukbd0 Timecounter "TSC" frequency 2997020286 Hz quality 800 Timecounters tick every 1.000 msec ad0: 238474MB at ata0-master SATA300 ad8: 6105MB at ata4-master UDMA33 acd0: DVDR at ata4-slave UDMA33 pcm0: pcm0: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 WARNING: WITNESS option enabled, expect reduced performance. cd0 at ata4 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [344984 x 2048 byte records] Trying to mount root from ufs:/dev/ad8s1a WARNING: / was not properly dismounted Loading configuration files. kernel dumps on /dev/ad0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart From glen.j.barber at gmail.com Sat Aug 23 00:03:56 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Sat Aug 23 00:04:03 2008 Subject: ndis0 no link on 6.3-RELEASE In-Reply-To: <20080316164226.GA658@orion.hexidigital.org> References: <200803132256.01197.glen.j.barber@gmail.com> <20080316164226.GA658@orion.hexidigital.org> Message-ID: <4ad871310808221640r4bb078sb2e303f49863350d@mail.gmail.com> Hi everyone. Sorry to bump such an old post, but I have figured out a 'hack' to get this driver to work, and figured I'd post here, in case it may help someone else. Previously, I said the following, about a Broadcom 4318 chipset on a Dell Inspiron b120: "Upon 'kldunload bcmwl5.ko; kldload bcmwl5.ko', my ndis0 card looses all WPA capabilities." The fix is as follows, as I have been unable to find anything relevant regarding netif, dhclient, wpa_supplicant or ndis: Step 1: Create /etc/rc.local, with '/sbin/kldload /boot/modules/bcmwl5_sys.ko' Step 2: Edit /etc/wpa_supplicant.conf as needed Step 3: Echo 'ifconfig_ndis0="WPA DHCP"' to /etc/rc.conf Outcome: System boots, loading netif, dhclient, and wpa_supplicant. Next, after the other three are running, the rc.local script loads the ndis0 driver. On my system (and surrounding networks) my system tries to authenticate against any available network, but then finally reads wpa_supplicant.conf, and uses my network. As I said, sorry to bump an old thread, but hopefully this will help someone else, regardless of how crude of a hack it is. Regards, -- Glen Barber From adrian at thearle.com.au Sat Aug 23 01:25:06 2008 From: adrian at thearle.com.au (Adrian Thearle) Date: Sat Aug 23 01:25:13 2008 Subject: Wireless and Broadcast packets problem Message-ID: <48AF6293.4000002@thearle.com.au> Hi Guys I am having a problem with my wireless network. The Issue is that clients connected to the wireless LAN cannot _see_ other clients. My understanding of 802.11 was that clients could talk to other clients, except all traffic would go via the access point and that the AP would forward on the packets. This also ensures that encryption works as expected as well as other RF issues. One thing that I can see is going wrong is that clients on the Wireless Lan sending Broadcast packets, but they are not being forwarded by the AP to anyone else... Wireless clients also cannot ping each other (mainly because their ARP requests are not being answered) Below is a simplified system diagram. AdriansPC AlbertAP \|/ --------- 192.168.123/24 ------------ | | |--LAN------bge0-| |---| ral0 (192.168.124/24) |________| |____________|----------tun0--->PPPoE(bge0) Windows FreeBSD Sneaky \|/ --------- | | |---| 192.168.124.2 (Static IP address) |________| ral0 FreeBSD Laptop \|/ --------- | | |---| 192.168.124.150 (DHCP) |________| Windows When running TCPDump on AlbertAP I can see plenty of wireless traffic going around the place. Wireless Clients are able to connect and have their session is encrypted with WPA. This all seems to work, wireless clients are able to browse the net. (Those that can get an IP address anyway, which happens to be the windows machines) *Problem* I have run tcpdump on both AlbertAP and Sneaky and seem some interesting omissions. When I ping Sneaky from Laptop I see on Albert the ARP request come out from Laptop asking for Sneaky's MAC address. AlbertAP> tcpdump -i ral0 10:27:51.979664 arp who-has 192.168.124.2 tell 192.168.124.150 10:27:51.979684 arp who-has 192.168.124.2 tell 192.168.124.150 But on Sneaky I cannot see these packets comming in... All I get is random EAP traffic Sneaky> tcpdump -i ral0 10:30:32.987961 EAP code=2 id=3 length=123 10:30:32.988383 EAP code=1 id=3 length=95 10:30:32.990557 EAP code=2 id=3 length=135 10:30:32.991548 EAP code=1 id=3 length=95 However if a Wired client like AdriansPC tries to ping Laptop then things work. Albert knows the MAC address of the Wireless client to send the ping packet to and so just sends it off. *Problem* The other thing I see alot of is netbios broadcast traffic coming from the Laptop on the wireless. Albert can see all this traffic coming in, but none of it gets forwarded to Sneaky, (nothing about netbios from a tcpdump on sneaky). The same can be said for a particular client doing DHCP/BOOTP. On AlbertAP, I see the request come in and see the response go out (the response goes to 255.255.255.255) but I do not see this on sneaky (I should right, its a broadcast address). Oh and I don't think this client is actually getting a response as I can't do much with it(ie ping). (Its a wireless print server) Interestingly enough DHCP does seem to work to Laptop. I believe that this is because windows is doing DHCP, where as my print server is doing BOOTP. *It does work* Just so you believe me that normal traffic does get around, here is a ping from sneaky to albert. Sneaky> tcpdump -i ral0 10:36:11.243678 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.244634 arp reply 192.168.124.1 is-at 00:1a:ee:00:d5:c0 (oui Unknown) 10:36:11.244693 IP 192.168.124.2 > 192.168.124.1: ICMP echo request, id 18949, seq 0, length 64 10:36:11.251920 IP 192.168.124.1 > 192.168.124.2: ICMP echo reply, id 18949, seq 0, length 64 AlbertAP> tcpdump -i ral0 10:36:11.241001 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.241017 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.241042 arp reply 192.168.124.1 is-at 00:1a:ee:00:d5:c0 (oui Unknown) 10:36:11.248582 IP 192.168.124.2 > 192.168.124.1: ICMP echo request, id 18949, seq 0, length 64 10:36:11.248600 IP 192.168.124.1 > 192.168.124.2: ICMP echo reply, id 18949, seq 0, length 64 *Discussion Point* I find it interesting that sneaky asks for 192.168.124.1's MAC address with an ARP request, but albert got two of them... *System Details* Things are basically setup as detailed in the Handbook, with the wireless LAN on a different Subnet to the wired one. I have also had a go at bridging the two interfaces but ran into trouble so didn't spend long there. I expect I would have the same issues. AlbertAP> uname -a FreeBSD albertAP 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #2: Mon Jul 14 09:00:17 EST 2008 adrian@albertAP:/usr/obj/usr/src/sys/AdriansKernel i386 AlbertAP> ifconfig bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:85:b3:a2:7e inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255 media: Ethernet autoselect (100baseTX ) status: active ral0: flags=8943 metric 0 mtu 2290 ether 00:1a:ee:00:d5:c0 inet 192.168.124.1 netmask 0xffffff00 broadcast 192.168.124.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid Wireless channel 3 (2422 Mhz 11g) bssid 00:1a:ee:00:d5:c0 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 50 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS dtimperiod 1 plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8051 metric 0 mtu 1492 inet 111.111.111.11 --> 222.22.222.222 netmask 0xffffffff (sanatised) Opened by PID 433 ifconfig_ral0="inet 192.168.124.1 ssid Wireless channel 3 mode 11g mediaopt hostap up" hostapd_enable="YES" ipfw Firewall rules ipfw add 007 allow all from any to any via ral0 So is there any chance there is a magic sysctl or ifconfig switch that will make these broadcast packets go to everyone...? or is there another problem? or is this just all the FreeBSD supports at the moment? or am I just dumb... Your help is appreciated Adrian From freebsd.alex at spamfoodie.com Sat Aug 23 02:20:04 2008 From: freebsd.alex at spamfoodie.com (Alex) Date: Sat Aug 23 02:20:12 2008 Subject: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Message-ID: <200808230220.m7N2K4OI017089@freefall.freebsd.org> The following reply was made to PR kern/126742; it has been noted by GNATS. From: Alex To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Date: Sat, 23 Aug 2008 02:13:27 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: 7-STABLE >Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: is there a reason that the problem report database ignores any text if there's a line with a single dot (".") and nothing else in it? i know that in 'mail' that's the way to end your text, but as you can see it's not very useful in the case of this problem report. cheers. >How-To-Repeat: >Fix: From freebsd.alex at spamfoodie.com Sat Aug 23 08:30:05 2008 From: freebsd.alex at spamfoodie.com (Alex) Date: Sat Aug 23 08:30:13 2008 Subject: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Message-ID: <200808230830.m7N8U5aH081332@freefall.freebsd.org> The following reply was made to PR kern/126742; it has been noted by GNATS. From: Alex To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Date: Sat, 23 Aug 2008 08:21:45 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: 7-STABLE >Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: this should work. i simply replaced the lines with a single dot (".") in it with "DOT". --- dmesg begins here --- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (2997.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2086535168 (1989 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] uhci0: port 0xe200-0xe21f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe000-0xe01f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe100-0xe11f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf8205000-0xf82053ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcm0: mem 0xf8200000-0xf8203fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 atapci0: port 0xd000-0xd007,0xd100-0xd103,0xd200-0xd207,0xd300-0xd303,0xd400-0xd40f mem 0xf8000000-0xf8001fff irq 19 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xf8204000-0xf82043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 ath0: mem 0xf8100000-0xf810ffff irq 19 at device 1.0 on pci5 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0f:b5:82:07:c8 ath0: mac 7.9 phy 4.5 radio 5.6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f,0xfc00-0xfc0f at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xe700-0xe707,0xe800-0xe803,0xe900-0xe907,0xea00-0xea03,0xeb00-0xeb0f,0xec00-0xec0f irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est0 attach returned 6 p4tcc0: on cpu0 coretemp0: on cpu0 acpi_button0: on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ums0: on uhub1 ums0: 7 buttons and Z dir. ukbd0: on uhub1 kbd0 at ukbd0 Timecounter "TSC" frequency 2997020286 Hz quality 800 Timecounters tick every 1.000 msec ad0: 238474MB at ata0-master SATA300 ad8: 6105MB at ata4-master UDMA33 acd0: DVDR at ata4-slave UDMA33 pcm0: pcm0: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 WARNING: WITNESS option enabled, expect reduced performance. cd0 at ata4 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [344984 x 2048 byte records] Trying to mount root from ufs:/dev/ad8s1a WARNING: / was not properly dismounted Loading configuration files. kernel dumps on /dev/ad0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart DOT swapon: adding /dev/ad0s1b as swap device Starting file system checks: /dev/ad8s1a: 13332 files, 368195 used, 2657168 free (8032 frags, 331142 blocks, 0.3% fragmentation) /dev/ad0s1a: DEFER FOR BACKGROUND CHECKING Setting hostuuid: 00000000-0000-0000-0000-001a4d4bb4eb. Setting hostid: 0x52f33628. Mounting local file systems: WARNING: /usr was not properly dismounted DOT Setting hostname: moshnroll. kern.sync_on_panic: 0 -> 1 kern.ipc.shmmax: 33554432 -> 67108864 kern.ipc.shmall: 8192 -> 32768 vfs.usermount: 0 -> 1 net.inet.tcp.blackhole: 0 -> 1 kern.ipc.shm_allow_removed: 0 -> 1 /etc/rc: WARNING: Values of network_interfaces other than AUTO are deprecated ath0: flags=8843 metric 0 mtu 1500 ether 00:0f:b5:82:07:c8 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b (DS/11Mbps) status: no carrier ssid cookiebox channel 11 (2462 Mhz 11g) authmode SHARED privacy ON deftxkey 1 wepkey 1:104-bit wepkey 2:104-bit wepkey 3:104-bit wepkey 4:104-bit txpower 31.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 add net default: gateway 192.168.1.1 Additional routing options: ignore ICMP redirect=YES log ICMP redirect=YES DOT Starting devd. WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() discon_compl: - invalid connection handle=42 Starting ums0 moused: DOT Configuring keyboard: keymap keyrate keybell DOT hw.acpi.cpu.cx_lowest: C1 -> C1 Additional IP options: drop SYN+FIN packets=YES DOT Mounting NFS file systems: DOT ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/qt4 /usr/local/lib/wine a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Clearing /tmp. Creating and/or trimming log files: DOT Starting syslogd. Checking for core dump on /dev/ad0s1b... savecore: reboot after panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 Aug 22 17:54:47 moshnroll savecore: reboot after panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 savecore: writing core to vmcore.0 Initial i386 initialization: DOT Additional ABI support: linux DOT Setting date via ntp. Error : hostname nor servname provided, or not known 22 Aug 17:55:46 ntpdate[592]: can't find host rustime01.rus.uni-stuttgart.de 22 Aug 17:55:46 ntpdate[592]: no servers can be used, exiting Starting hcsecd. Starting local daemons: DOT Updating motd DOT Mounting late file systems: DOT Starting powerd. Starting sdpd. Starting smartd. Starting musicpd. Avahi: Failed to create client: Daemon not running Starting fetchmail. fetchmail: no mailservers have been specified. Starting cupsd. Configuring syscons: keymap keyrate keybell cursor font8x16 font8x14 font8x8 blanktime DOT Starting cron. Local package initialization: DOT Starting background file system checks in 60 seconds. Fri Aug 22 17:55:52 CEST 2008 ath0: link state changed to UP --- dmesg ends here --- --- crash begins here --- 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: sblastmbufchk: sb_mb 0xc91a5300 sb_mbtail 0 last 0xc91a5300 packet tree: 0xc91a5300 panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 cpuid = 0 Syncing disks, buffers remaining... 7171 7168 7168 7168 7168 7168 7168 7167 7169 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 Giving up on 7167 buffers Uptime: 2d18h9m43s Physical memory: 2030 MB Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete panic: 5 vncache entries remaining cpuid = 0 Uptime: 2d18h9m47s Physical memory: 2030 MB Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/cd9660.ko...Reading symbols from /boot/kernel/cd9660.ko.symbols...done. done. Loaded symbols for /boot/kernel/cd9660.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from /boot/kernel/pseudofs.ko.symbols...done. done. Loaded symbols for /boot/kernel/pseudofs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/procfs.ko...Reading symbols from /boot/kernel/procfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/procfs.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/ums.ko...Reading symbols from /boot/kernel/ums.ko.symbols...done. done. Loaded symbols for /boot/kernel/ums.ko Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko Reading symbols from /boot/kernel/cam.ko...Reading symbols from /boot/kernel/cam.ko.symbols...done. done. Loaded symbols for /boot/kernel/cam.ko Reading symbols from /boot/kernel/random.ko...Reading symbols from /boot/kernel/random.ko.symbols...done. done. Loaded symbols for /boot/kernel/random.ko Reading symbols from /boot/kernel/wlan_wep.ko...Reading symbols from /boot/kernel/wlan_wep.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_wep.ko Reading symbols from /boot/kernel/wlan_scan_sta.ko...Reading symbols from /boot/kernel/wlan_scan_sta.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_scan_sta.ko Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ubt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_bluetooth.ko Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_hci.ko Reading symbols from /boot/kernel/ng_l2cap.ko...Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_l2cap.ko Reading symbols from /boot/kernel/ng_btsocket.ko...Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_btsocket.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko #0 doadump () at pcpu.h:195 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc04daa4e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc07d73e4 in pfs_vncache_unload () at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs_vncache.c:102 #4 0xc07d6515 in pfs_modevent (mod=0xc54b8280, evt=2, arg=0x0) at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs.c:438 #5 0xc04cd318 in module_shutdown (arg1=0x0, arg2=) at /usr/src/sys/kern/kern_module.c:105 #6 0xc04daaef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:421 #7 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 #8 0xc052d79b in sblastmbufchk (sb=0x0, file=0xc06838ad "/usr/src/sys/kern/uipc_sockbuf.c", line=794) at /usr/src/sys/kern/uipc_sockbuf.c:425 #9 0xc052eed0 in sbcompress (sb=0xc8cb11f0, m=0x0, n=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:794 #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 #11 0xc052f041 in sbappendrecord (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:610 #12 0xc5a2f8fe in ng_btsocket_l2cap_input (context=0x0, pending=1) at /usr/src/sys/modules/netgraph/bluetooth/socket/../../../../netgraph/bluetooth/socket/ng_btsocket_l2cap.c:1458 #13 0xc050cd1b in taskqueue_run (queue=0xc556b500) at /usr/src/sys/kern/subr_taskqueue.c:282 #14 0xc050cf53 in taskqueue_swi_giant_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:336 #15 0xc04be975 in ithread_loop (arg=0xc55d7160) at /usr/src/sys/kern/kern_intr.c:1088 #16 0xc04bc258 in fork_exit (callout=0xc04be7b0 , arg=0xc55d7160, frame=0xe5b12d38) at /usr/src/sys/kern/kern_fork.c:781 #17 0xc06348b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 --- crash ends here --- --- ARUNDEL begins here --- cpu I686_CPU ident ARUNDEL #maxusers 10 makeoptions DEBUG=-g #makeoptions CONF_CFLAGS=-fno-builtin #options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table #options CPU_SUSP_HLT #options CPU_UPGRADE_HW_CACHE #options CPU_FASTER_5X86_FPU options ATA_STATIC_ID #options MSDOSFS #options CD9660 #options USB_DEBUG #options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN #options HZ=100 #options PREEMPTION #options IPI_PREEMPTION options SCHED_4BSD #4BSD scheduler #options SCHED_ULE options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_43TTY #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options COMPAT_FREEBSD5 #Compatible with FreeBSD5 options COMPAT_FREEBSD6 #Compatible with FreeBSD6 options SC_HISTORY_SIZE=1000 #number of history buffer lines #options KDB #Compile with kernel debugger related code #options KDB_TRACE #Print a stack trace of the current thread on the console for a panic. #options KTRACE #ktrace(1) support #options DDB options INVARIANTS options INVARIANT_SUPPORT options SOCKBUF_DEBUG options WITNESS options WITNESS_SKIPSPIN options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV #install a CDEV entry in /dev options UKBD_DFLT_KEYMAP #specify the built-in keymap makeoptions UKBD_DFLT_KEYMAP="german.iso" #options AUTO_EOI_1 #options AUTO_EOI_2 #options ADAPTIVE_GIANT # Giant mutex is adaptive. #options STOP_NMI # Stop CPUS using NMI instead of IPI options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC #devices device eisa device pci device ata device atadisk device atapicd device usb device uhci device ehci device vga device sc device ukbd device ulpt device ath device ath_hal device ath_rate_sample device wlan device cpufreq device coretemp #pseudo devices device loop device ether device pty --- ARUNDEL ends here --- --- ps begins here --- USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 10 78,9 0,0 0 8 ?? RL 5:54pm 12:54,60 [idle: cpu0] root 874 7,1 1,9 311952 39548 v0 S 5:56pm 0:33,92 X :0 -auth /home/arundel/.serverauth.855 (Xorg) arundel 716 0,4 0,3 9288 6460 ?? S 5:55pm 0:27,85 /usr/local/bin/mpd /usr/local/etc/mpd.conf root 30 0,1 0,0 0 8 ?? RL 5:54pm 0:10,86 [irq22: pcm0] root 946 0,0 0,6 14436 12000 ?? Ss 6:01pm 0:02,30 xterm root 0 0,0 0,0 0 0 ?? WLs 5:54pm 0:00,00 [swapper] root 1 0,0 0,0 1888 448 ?? ILs 5:54pm 0:00,01 /sbin/init -- root 2 0,0 0,0 0 8 ?? DL 5:54pm 0:00,17 [g_event] root 3 0,0 0,0 0 8 ?? DL 5:54pm 0:08,86 [g_up] root 4 0,0 0,0 0 8 ?? DL 5:54pm 0:06,24 [g_down] root 5 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [acpi_task_0] root 6 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [acpi_task_1] root 7 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [acpi_task_2] root 8 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [kqueue taskq] root 9 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [xpt_thrd] root 11 0,0 0,0 0 8 ?? WL 5:54pm 0:00,10 [swi1: net] root 12 0,0 0,0 0 8 ?? RL 5:54pm 0:03,43 [swi4: clock] root 13 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi3: vm] root 14 0,0 0,0 0 8 ?? DL 5:54pm 0:00,54 [yarrow] root 15 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi6: Giant taskq] root 16 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi6: task queue] root 17 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi5: +] root 18 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi2: cambio] root 19 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [thread taskq] root 20 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq9: acpi0] root 21 0,0 0,0 0 8 ?? WL 5:54pm 0:00,32 [irq16: nvidia0+] root 22 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb0] root 23 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usbtask-hc] root 24 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usbtask-dr] root 25 0,0 0,0 0 8 ?? WL 5:54pm 0:00,47 [irq21: uhci1] root 26 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb1] root 27 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq18: uhci2 ehci+] root 28 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb2] root 29 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb3] root 31 0,0 0,0 0 8 ?? WL 5:54pm 0:01,68 [irq19: ath0 uhci4*] root 32 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq23: uhci3 ehci1] root 33 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb4] root 34 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb5] root 35 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb6] root 36 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb7] root 37 0,0 0,0 0 8 ?? DL 5:54pm 0:01,27 [ath0 taskq] root 38 0,0 0,0 0 8 ?? WL 5:54pm 0:03,42 [irq14: ata0] root 39 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq15: ata1] root 40 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [pagedaemon] root 41 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [vmdaemon] root 42 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [pagezero] root 43 0,0 0,0 0 8 ?? DL 5:54pm 0:01,57 [bufdaemon] root 44 0,0 0,0 0 8 ?? DL 5:54pm 0:00,38 [syncer] root 45 0,0 0,0 0 8 ?? DL 5:54pm 0:00,02 [vnlru] root 46 0,0 0,0 0 8 ?? DL 5:54pm 0:00,74 [softdepflush] root 47 0,0 0,0 0 8 ?? DL 5:54pm 0:00,16 [schedcpu] root 184 0,0 0,0 1368 796 ?? Is 5:54pm 0:00,00 adjkerntz -i root 401 0,0 0,1 3256 1088 ?? Ss 5:54pm 0:04,47 /usr/sbin/moused -z4 -r 1600 -a 0.2,0.2 -F 6400 -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid root 461 0,0 0,0 1888 544 ?? Is 5:54pm 0:00,00 /sbin/devd root 579 0,0 0,1 3172 1232 ?? Ss 5:54pm 0:00,02 /usr/sbin/syslogd -s root 640 0,0 0,0 3128 1012 ?? Is 5:55pm 0:00,00 /usr/sbin/hcsecd -f /etc/bluetooth/hcsecd.conf root 673 0,0 0,0 3172 1008 ?? Ss 5:55pm 0:00,91 /usr/sbin/powerd nobody 683 0,0 0,1 3116 1148 ?? Is 5:55pm 0:00,00 /usr/sbin/sdpd -c /var/run/sdp -g nobody -u nobody root 699 0,0 0,1 4292 2036 ?? I 5:55pm 0:00,01 /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/etc/smartd.conf arundel 712 0,0 0,2 9288 3928 ?? S 5:55pm 0:00,29 /usr/local/bin/mpd /usr/local/etc/mpd.conf arundel 714 0,0 0,3 9288 5928 ?? S 5:55pm 0:02,50 /usr/local/bin/mpd /usr/local/etc/mpd.conf root 727 0,0 0,1 5868 3012 ?? Ss 5:55pm 0:00,04 sendmail: accepting connections (sendmail) smmsp 733 0,0 0,2 5868 3124 ?? Is 5:55pm 0:00,00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) root 757 0,0 0,2 5340 3400 ?? Is 5:55pm 0:00,02 /usr/local/sbin/cupsd root 782 0,0 0,1 3200 1288 ?? Is 5:55pm 0:00,01 /usr/sbin/cron -s arundel 840 0,0 0,1 6048 2544 ?? Is 5:55pm 0:00,11 /usr/local/bin/fetchmail root 842 0,0 0,1 5776 2484 ?? Is 5:55pm 0:00,25 /usr/local/bin/scmpc --config-file /home/arundel/.scmpcrc root 844 0,0 0,1 4772 1704 ?? Is 5:55pm 0:00,00 /usr/local/bin/obexapp -u arundel -r /var/spool/obex -s -C1 root 884 0,0 0,6 14436 11904 ?? Ss 5:56pm 0:01,46 xterm arundel 908 0,0 0,1 3452 1476 ?? Is 5:59pm 0:00,06 /bin/sh /usr/local/bin/firefox3 arundel 912 0,0 0,1 3452 1512 ?? I 5:59pm 0:00,03 /bin/sh /usr/local/lib/firefox3/run-mozilla.sh /usr/local/lib/firefox3/firefox-bin arundel 917 0,0 3,4 84620 71296 ?? I 5:59pm 0:37,97 /usr/local/lib/firefox3/firefox-bin arundel 919 0,0 0,2 6008 3252 ?? S 5:59pm 0:00,09 /usr/local/libexec/gconfd-2 16 root 971 0,0 0,6 14436 11992 ?? Ss 6:04pm 0:00,41 xterm root 845 0,0 0,1 3612 1624 v0 Is 5:55pm 0:00,12 login [pam] (login) arundel 853 0,0 0,1 4384 2304 v0 I 5:56pm 0:00,08 -bash (bash) arundel 855 0,0 0,1 3452 1476 v0 I+ 5:56pm 0:00,04 /bin/sh /usr/local/bin/startx arundel 873 0,0 0,1 4124 1492 v0 I+ 5:56pm 0:00,01 xinit /home/arundel/.xinitrc -- -auth /home/arundel/.serverauth.855 arundel 879 0,0 0,1 3488 1456 v0 I 5:56pm 0:00,00 sh /home/arundel/.xinitrc arundel 882 0,0 0,5 15352 11076 v0 S 5:56pm 0:01,89 /usr/local/bin/awesome root 846 0,0 0,1 3172 1080 v1 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv1 root 847 0,0 0,1 3172 1080 v2 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv2 root 848 0,0 0,1 3172 1080 v3 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv3 root 849 0,0 0,1 3172 1080 v4 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv4 root 850 0,0 0,1 3172 1080 v5 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv5 root 851 0,0 0,1 3172 1080 v6 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv6 root 852 0,0 0,1 3172 1080 v7 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv7 arundel 886 0,0 0,1 4384 2352 p0 Is 5:56pm 0:00,08 -bash (bash) arundel 906 0,0 0,1 3368 1804 p0 I+ 5:58pm 0:00,10 edit crash arundel 948 0,0 0,1 4384 2348 p1 Ss 6:01pm 0:00,14 -bash (bash) arundel 1110 0,0 0,1 3268 1208 p1 R+ 6:10pm 0:00,02 ps aux arundel 973 0,0 0,1 4384 2348 p2 Is+ 6:04pm 0:00,04 -bash (bash) --- ps ends here --- cheers. >How-To-Repeat: >Fix: From jfmays at launchpad.win.net Sat Aug 23 18:51:27 2008 From: jfmays at launchpad.win.net (Joe Mays) Date: Sat Aug 23 18:51:49 2008 Subject: Fw: Kernel Panic in SCTP Message-ID: <000501c9054d$cb43ab00$441818d8@launchpad02> Just thought I'd put this out there again. Is there anyone who was involved in the SCTP installation on list? > Hello. > > We've recently written an extensive software system that uses SCTP as a > critical component. We've started to run into an issue where the box kenel > panics after throwing an error message from sctp_timer.c that says "Our list > is out of order? Out of order list". Can anyone here shed light on what's > going on, or give us a clue how to debug this? > > http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 Joe Mays From rik at inse.ru Sat Aug 23 21:29:30 2008 From: rik at inse.ru (Roman Kurakin) Date: Sat Aug 23 21:29:38 2008 Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] Message-ID: <48B07DC5.2030203@localhost.inse.ru> Hi, The IPFW_DEFAULT_RULE is also the max allowed rule number. This value should be definitely public, so here is the patch, if there is no objections I'll commit it within a couple of days. After that, I plan to fix a couple of tools that need to know this value. Best regards, rik -------------- next part -------------- Index: ip_fw.h =================================================================== --- ip_fw.h (revision 182080) +++ ip_fw.h (working copy) @@ -29,6 +29,11 @@ #define _IPFW2_H /* + * The default rule number. It is also the max possible rule number. + */ +#define IPFW_DEFAULT_RULE 65535 + +/* * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF * instructions), which specify which fields of the packet Index: ip_fw2.c =================================================================== --- ip_fw2.c (revision 182080) +++ ip_fw2.c (working copy) @@ -122,7 +122,6 @@ static struct callout ipfw_timeout; static uma_zone_t ipfw_dyn_rule_zone; -#define IPFW_DEFAULT_RULE 65535 /* * Data structure to cache our ucred related From rik at inse.ru Sat Aug 23 21:35:41 2008 From: rik at inse.ru (Roman Kurakin) Date: Sat Aug 23 21:35:59 2008 Subject: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private Message-ID: <48B07B32.4040008@localhost.inse.ru> Hi, The IPFW_DEFAULT_RULE is also the max allowed rule number. This value should be definitely public, so here is the patch, if there is no objections I'll commit it within a couple of days. After that, I plan to fix a couple of tools that need to know this value. Best regards, rik -------------- next part -------------- Index: ip_fw.h =================================================================== --- ip_fw.h (revision 182080) +++ ip_fw.h (working copy) @@ -29,6 +29,11 @@ #define _IPFW2_H /* + * The default rule number. It is also the max possible rule number. + */ +#define IPFW_DEFAULT_RULE 65535 + +/* * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF * instructions), which specify which fields of the packet Index: ip_fw2.c =================================================================== --- ip_fw2.c (revision 182080) +++ ip_fw2.c (working copy) @@ -122,7 +122,6 @@ static struct callout ipfw_timeout; static uma_zone_t ipfw_dyn_rule_zone; -#define IPFW_DEFAULT_RULE 65535 /* * Data structure to cache our ucred related From rizzo at iet.unipi.it Sat Aug 23 21:42:17 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Aug 23 21:42:25 2008 Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] In-Reply-To: <48B07DC5.2030203@localhost.inse.ru> References: <48B07DC5.2030203@localhost.inse.ru> Message-ID: <20080823214452.GA75815@onelab2.iet.unipi.it> On Sun, Aug 24, 2008 at 01:14:45AM +0400, Roman Kurakin wrote: > Hi, > > The IPFW_DEFAULT_RULE is also the max allowed rule number. > This value should be definitely public, so here is the patch, if there is > no objections I'll commit it within a couple of days. > After that, I plan to fix a couple of tools that need to know this value. unless the tools you have in mind already include ip_fw.h (in which case the change is harmless and I have no objection), i think it would be better to export the value in a sysctl and let the tools fetch it from there, so they do not need to include the header. cheers luigi From rik at inse.ru Sat Aug 23 22:18:37 2008 From: rik at inse.ru (Roman Kurakin) Date: Sat Aug 23 22:18:44 2008 Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] In-Reply-To: <20080823214452.GA75815@onelab2.iet.unipi.it> References: <48B07DC5.2030203@localhost.inse.ru> <20080823214452.GA75815@onelab2.iet.unipi.it> Message-ID: <48B08946.6030109@localhost.inse.ru> Luigi Rizzo wrote: > On Sun, Aug 24, 2008 at 01:14:45AM +0400, Roman Kurakin wrote: > >> Hi, >> >> The IPFW_DEFAULT_RULE is also the max allowed rule number. >> This value should be definitely public, so here is the patch, if there is >> no objections I'll commit it within a couple of days. >> After that, I plan to fix a couple of tools that need to know this value. >> > > unless the tools you have in mind already include ip_fw.h (in which case > the change is harmless and I have no objection), i think it would be better > to export the value in a sysctl and let the tools fetch it from there, > so they do not need to include the header. > In fact, I am talking about ipfw(8) and natd(8). The first one uses hard-coded value, the last one pass rulenumbers to libalias(3) without a check, libalias(3) flushes rules also without a check. Thus if you erroneously set -punch_fw for natd(8) as 50000:60000 (and not 50000:10000) you will have to get to the remote server to set back all flashed rules at the beginning of the list. Yes, such fix will not save from such stupidities but can decrease the number of them. IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would be better to export this value via sysctl, not compiled in via #include<> for it. The only thing is binary portability, but expecting this from system utility that not just reads smth but also writes is wrong. Anyway, if you aware of some ports, for which this value would be useful sysctl also could be added but we do not have much time before code-freeze. Best regards, rik > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From rizzo at iet.unipi.it Sat Aug 23 23:11:31 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Aug 23 23:11:37 2008 Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] In-Reply-To: <48B08946.6030109@localhost.inse.ru> References: <48B07DC5.2030203@localhost.inse.ru> <20080823214452.GA75815@onelab2.iet.unipi.it> <48B08946.6030109@localhost.inse.ru> Message-ID: <20080823231407.GA76471@onelab2.iet.unipi.it> On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: ... > >unless the tools you have in mind already include ip_fw.h (in which case > >the change is harmless and I have no objection), i think it would be better > >to export the value in a sysctl and let the tools fetch it from there, > >so they do not need to include the header. > > > In fact, I am talking about ipfw(8) and natd(8). The first one uses > hard-coded value, the last one > pass rulenumbers to libalias(3) without a check, libalias(3) flushes ... > IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would > be better to export > this value via sysctl, not compiled in via #include<> for it. The only because ip_fw.h has a lot of stuff in it which in turn is likely to require more headers to build correctly. This is unnecessary bloat at compile time, and also less practical than the sysctl-based approach because it requires a binary update if the value ever changes. Besides, implementing the sysctl does not require to change the headers (thus saving rebuilds of the objects that depend on it), is one line in one file (ip_fw2.c) in the kernel, and one line to call sysctlbyname() in each of the userland program, which you'd need to change anyways; and because both ipfw(8) and natd(8) already use sysctl/sysctlbyname to read/write other similar values from the kernel, you are more consistent with the existing code and don't even need additional headers. At runtime the sysctl is obviously more expensive than reading a hardwired constant, but still a whole lot cheaper than the subsequent action (adding a rule to the firewall) so one won't notice. cheers luigi From rik at inse.ru Sat Aug 23 23:33:24 2008 From: rik at inse.ru (Roman Kurakin) Date: Sat Aug 23 23:33:32 2008 Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] In-Reply-To: <20080823231407.GA76471@onelab2.iet.unipi.it> References: <48B07DC5.2030203@localhost.inse.ru> <20080823214452.GA75815@onelab2.iet.unipi.it> <48B08946.6030109@localhost.inse.ru> <20080823231407.GA76471@onelab2.iet.unipi.it> Message-ID: <48B09ACD.1050600@localhost.inse.ru> Luigi Rizzo wrote: > On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: > ... > >>> unless the tools you have in mind already include ip_fw.h (in which case >>> the change is harmless and I have no objection), i think it would be better >>> to export the value in a sysctl and let the tools fetch it from there, >>> so they do not need to include the header. >>> >>> >> In fact, I am talking about ipfw(8) and natd(8). The first one uses >> hard-coded value, the last one >> pass rulenumbers to libalias(3) without a check, libalias(3) flushes >> > ... > >> IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would >> be better to export >> this value via sysctl, not compiled in via #include<> for it. The only >> > > because ip_fw.h has a lot of stuff in it which in turn is likely > to require more headers to build correctly. This is unnecessary bloat > at compile time, and also less practical than the sysctl-based approach > because it requires a binary update if the value ever changes. > > Besides, implementing the sysctl does not require to change the > headers (thus saving rebuilds of the objects that depend on it), > is one line in one file (ip_fw2.c) in the kernel, and one line to > call sysctlbyname() in each of the userland program, which you'd > need to change anyways; and because both ipfw(8) and natd(8) already > use sysctl/sysctlbyname to read/write other similar values from the > kernel, you are more consistent with the existing code and don't > even need additional headers. > Agreed, but including ip_fw.h for natd.c does not require any additional headers. All that needed looks like already there. If some one point me to other utilities that need to be fixed I'll also a sysctl for them. These two already include enough of netinet includes, so if you not strictly against adding just one more include for natd, I'll prefer not to add a sysctl by right now. rik > At runtime the sysctl is obviously more expensive than reading a > hardwired constant, but still a whole lot cheaper than the subsequent > action (adding a rule to the firewall) so one won't notice. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From max at love2party.net Sat Aug 23 23:49:59 2008 From: max at love2party.net (Max Laier) Date: Sat Aug 23 23:50:07 2008 Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] In-Reply-To: <48B09ACD.1050600@localhost.inse.ru> References: <48B07DC5.2030203@localhost.inse.ru> <20080823231407.GA76471@onelab2.iet.unipi.it> <48B09ACD.1050600@localhost.inse.ru> Message-ID: <200808240149.56698.max@love2party.net> On Sunday 24 August 2008 01:18:37 Roman Kurakin wrote: > Luigi Rizzo wrote: > > On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: > > ... > > > >>> unless the tools you have in mind already include ip_fw.h (in which > >>> case the change is harmless and I have no objection), i think it would > >>> be better to export the value in a sysctl and let the tools fetch it > >>> from there, so they do not need to include the header. > >> > >> In fact, I am talking about ipfw(8) and natd(8). The first one uses > >> hard-coded value, the last one > >> pass rulenumbers to libalias(3) without a check, libalias(3) flushes > > > > ... > > > >> IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would > >> be better to export > >> this value via sysctl, not compiled in via #include<> for it. The only > > > > because ip_fw.h has a lot of stuff in it which in turn is likely > > to require more headers to build correctly. This is unnecessary bloat > > at compile time, and also less practical than the sysctl-based approach > > because it requires a binary update if the value ever changes. > > > > Besides, implementing the sysctl does not require to change the > > headers (thus saving rebuilds of the objects that depend on it), > > is one line in one file (ip_fw2.c) in the kernel, and one line to > > call sysctlbyname() in each of the userland program, which you'd > > need to change anyways; and because both ipfw(8) and natd(8) already > > use sysctl/sysctlbyname to read/write other similar values from the > > kernel, you are more consistent with the existing code and don't > > even need additional headers. > > Agreed, but including ip_fw.h for natd.c does not require any additional > headers. > All that needed looks like already there. > If some one point me to other utilities that need to be fixed I'll also > a sysctl for them. > These two already include enough of netinet includes, so if you not > strictly against adding > just one more include for natd, I'll prefer not to add a sysctl by right > now. There is no guarantee that the kernel or ipfw module you are running was built with the installed ip_fw.h or that IPFW_DEFAULT_RULE wasn't defined differently in the build environment. So a sysctl (or the like) is the *only* correct approach. Please fix it for real and don't just slap band-aid at it. Nice catch, by the way! > rik > > > At runtime the sysctl is obviously more expensive than reading a > > hardwired constant, but still a whole lot cheaper than the subsequent > > action (adding a rule to the firewall) so one won't notice. > > > > cheers > > luigi > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From rik at inse.ru Sun Aug 24 01:38:19 2008 From: rik at inse.ru (Roman Kurakin) Date: Sun Aug 24 01:38:27 2008 Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] In-Reply-To: <200808240149.56698.max@love2party.net> References: <48B07DC5.2030203@localhost.inse.ru> <20080823231407.GA76471@onelab2.iet.unipi.it> <48B09ACD.1050600@localhost.inse.ru> <200808240149.56698.max@love2party.net> Message-ID: <48B0B813.8010606@localhost.inse.ru> Max Laier wrote: > On Sunday 24 August 2008 01:18:37 Roman Kurakin wrote: > >> Luigi Rizzo wrote: >> >>> On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: >>> ... >>> >>> >>>>> unless the tools you have in mind already include ip_fw.h (in which >>>>> case the change is harmless and I have no objection), i think it would >>>>> be better to export the value in a sysctl and let the tools fetch it >>>>> from there, so they do not need to include the header. >>>>> >>>> In fact, I am talking about ipfw(8) and natd(8). The first one uses >>>> hard-coded value, the last one >>>> pass rulenumbers to libalias(3) without a check, libalias(3) flushes >>>> >>> ... >>> >>> >>>> IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would >>>> be better to export >>>> this value via sysctl, not compiled in via #include<> for it. The only >>>> >>> because ip_fw.h has a lot of stuff in it which in turn is likely >>> to require more headers to build correctly. This is unnecessary bloat >>> at compile time, and also less practical than the sysctl-based approach >>> because it requires a binary update if the value ever changes. >>> >>> Besides, implementing the sysctl does not require to change the >>> headers (thus saving rebuilds of the objects that depend on it), >>> is one line in one file (ip_fw2.c) in the kernel, and one line to >>> call sysctlbyname() in each of the userland program, which you'd >>> need to change anyways; and because both ipfw(8) and natd(8) already >>> use sysctl/sysctlbyname to read/write other similar values from the >>> kernel, you are more consistent with the existing code and don't >>> even need additional headers. >>> >> Agreed, but including ip_fw.h for natd.c does not require any additional >> headers. >> All that needed looks like already there. >> If some one point me to other utilities that need to be fixed I'll also >> a sysctl for them. >> These two already include enough of netinet includes, so if you not >> strictly against adding >> just one more include for natd, I'll prefer not to add a sysctl by right >> now. >> > > There is no guarantee that the kernel or ipfw module you are running was built > with the installed ip_fw.h or that IPFW_DEFAULT_RULE wasn't defined > differently in the build environment. So a sysctl (or the like) is the *only* > Very strange situation. In such case we have a very buggy code that could be broken by such cases in many places, cause we can't trust even kernel headers. But if you insist I'll do it via sysctl. > correct approach. Please fix it for real and don't just slap band-aid at it. > Nice catch, by the way! > It is bad luck. I always hit problems than I lack of time setting up smth. All problems where they are not expected I mine ;-) Now time to sleep until I didn't catch other problems :-))) rik >> rik >> >> >>> At runtime the sysctl is obviously more expensive than reading a >>> hardwired constant, but still a whole lot cheaper than the subsequent >>> action (adding a rule to the firewall) so one won't notice. >>> >>> cheers >>> luigi >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From kmacy at freebsd.org Sun Aug 24 02:16:08 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sun Aug 24 02:16:29 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <200808221922.m7MJMcUN091064@lava.sentex.ca> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> Message-ID: <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> Can you help me out a bit with your workload? tcp_offload_connect(...) needs to determine which interface an address corresponds to see if that interface supports TCP offload. The code does the exact same thing as ip_output does except it doesn't have the inpcb locked (which isn't used as part of the route lookup). Julian has worked in this code most recently, maybe he has some idea what is going on. -Kip On Fri, Aug 22, 2008 at 12:22 PM, Mike Tancsa wrote: > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: > >> can you make sure you have this? >> >> http://svn.freebsd.org/changeset/base/181596 > > Hi, > I do. I am running a GENERIC kernel but with inet6 disabled from yesterday > > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 > > and with the patch below as TOE seems to be broken for my workload > > > # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable > --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 > +++ sys/netinet/tcp_offload.c.disable 2008-08-22 15:16:50.000000000 -0400 > @@ -58,6 +58,8 @@ > struct rtentry *rt; > int error; > > + return (EINVAL); > + > /* > * Look up the route used for the connection to > * determine if it uses an interface capable of > > I can try changing to ipfw and see if that makes a difference ? But the RST > doesnt sound like a pf issue no ? I would have thought it would just > blackhole the packet. > > ---Mike > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From mike at sentex.net Sun Aug 24 02:20:16 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun Aug 24 02:20:23 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.co m> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> Message-ID: <200808240220.m7O2KDHA097983@lava.sentex.ca> At 10:16 PM 8/23/2008, Kip Macy wrote: >Can you help me out a bit with your workload? Hi, A lot of incoming tcp connections on em0,em1,lo0 for smtp connections. A lot of inbound and outbound udp connections for local DNS for the box and its neighbours on em0,em1 and a lot of tcp connections for clamav on em1 The problem quickly manifests itself so its pretty easy to see ---Mike From mike at sentex.net Sun Aug 24 03:12:38 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun Aug 24 03:12:45 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.co m> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> Message-ID: <200808240312.m7O3CZS0098145@lava.sentex.ca> At 10:16 PM 8/23/2008, Kip Macy wrote: >Can you help me out a bit with your workload? > >tcp_offload_connect(...) needs to determine which interface an address >corresponds to see if that interface supports TCP offload. The code >does the exact same thing as ip_output does except it doesn't have the >inpcb locked (which isn't used as part of the route lookup). This is the only RELENG_7 box that I have where it routes tcp packets asymmetrically, so that sounds like it might be the portion that is badly interacting. The server has just one default gateway, which is out em0, but clients all over the net will connect to IP addresses aliased on lo0 and to the one IP on em1. But all connections exit out em0 other than connected routes of course. ---Mike >Julian has worked in this code most recently, maybe he has some idea >what is going on. > >-Kip > > >On Fri, Aug 22, 2008 at 12:22 PM, Mike Tancsa wrote: > > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: > > > >> can you make sure you have this? > >> > >> http://svn.freebsd.org/changeset/base/181596 > > > > Hi, > > I do. I am running a GENERIC kernel but with inet6 disabled from yesterday > > > > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 > > > > and with the patch below as TOE seems to be broken for my workload > > > > > > # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable > > --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 > > +++ sys/netinet/tcp_offload.c.disable 2008-08-22 15:16:50.000000000 -0400 > > @@ -58,6 +58,8 @@ > > struct rtentry *rt; > > int error; > > > > + return (EINVAL); > > + > > /* > > * Look up the route used for the connection to > > * determine if it uses an interface capable of > > > > I can try changing to ipfw and see if that makes a difference ? But the RST > > doesnt sound like a pf issue no ? I would have thought it would just > > blackhole the packet. > > > > ---Mike > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From julian at elischer.org Sun Aug 24 05:38:42 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 24 05:38:48 2008 Subject: Fw: Kernel Panic in SCTP In-Reply-To: <000501c9054d$cb43ab00$441818d8@launchpad02> References: <000501c9054d$cb43ab00$441818d8@launchpad02> Message-ID: <48B0F3E0.5080003@elischer.org> Joe Mays wrote: > Just thought I'd put this out there again. Is there anyone who was > involved in the SCTP installation on list? yes, rrs@freebsd.org is but I think he's "away" for a while. > >> Hello. >> >> We've recently written an extensive software system that uses SCTP > as a >> critical component. We've started to run into an issue where the box > kenel >> panics after throwing an error message from sctp_timer.c that says > "Our list >> is out of order? Out of order list". Can anyone here shed light on > what's >> going on, or give us a clue how to debug this? >> >> http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 > > Joe Mays > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Sun Aug 24 05:52:35 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 24 05:52:41 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <200808240312.m7O3CZS0098145@lava.sentex.ca> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> Message-ID: <48B0F722.3050005@elischer.org> Mike Tancsa wrote: > At 10:16 PM 8/23/2008, Kip Macy wrote: >> Can you help me out a bit with your workload? >> >> tcp_offload_connect(...) needs to determine which interface an address >> corresponds to see if that interface supports TCP offload. The code >> does the exact same thing as ip_output does except it doesn't have the >> inpcb locked (which isn't used as part of the route lookup). > > This is the only RELENG_7 box that I have where it routes tcp packets > asymmetrically, so that sounds like it might be the portion that is > badly interacting. The server has just one default gateway, which is out > em0, but clients all over the net will connect to IP addresses aliased > on lo0 and to the one IP on em1. But all connections exit out em0 other > than connected routes of course. > > ---Mike > >> Julian has worked in this code most recently, maybe he has some idea >> what is going on. >> huh? wha? I haven't been following this thread.. what's up? >> -Kip >> >> >> On Fri, Aug 22, 2008 at 12:22 PM, Mike Tancsa wrote: >> > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: >> > >> >> can you make sure you have this? >> >> >> >> http://svn.freebsd.org/changeset/base/181596 >> > >> > Hi, >> > I do. I am running a GENERIC kernel but with inet6 disabled from >> yesterday >> > >> > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 >> > >> > and with the patch below as TOE seems to be broken for my workload >> > >> > >> > # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable >> > --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 >> > +++ sys/netinet/tcp_offload.c.disable 2008-08-22 >> 15:16:50.000000000 -0400 >> > @@ -58,6 +58,8 @@ >> > struct rtentry *rt; >> > int error; >> > >> > + return (EINVAL); >> > + >> > /* >> > * Look up the route used for the connection to >> > * determine if it uses an interface capable of >> > >> > I can try changing to ipfw and see if that makes a difference ? But >> the RST >> > doesnt sound like a pf issue no ? I would have thought it would just >> > blackhole the packet. >> > >> > ---Mike >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From kmacy at freebsd.org Sun Aug 24 05:55:48 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sun Aug 24 05:56:00 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <48B0F722.3050005@elischer.org> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> Message-ID: <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer wrote: > Mike Tancsa wrote: >> >> At 10:16 PM 8/23/2008, Kip Macy wrote: >>> >>> Can you help me out a bit with your workload? >>> >>> tcp_offload_connect(...) needs to determine which interface an address >>> corresponds to see if that interface supports TCP offload. The code >>> does the exact same thing as ip_output does except it doesn't have the >>> inpcb locked (which isn't used as part of the route lookup). >> >> This is the only RELENG_7 box that I have where it routes tcp packets >> asymmetrically, so that sounds like it might be the portion that is badly >> interacting. The server has just one default gateway, which is out em0, but >> clients all over the net will connect to IP addresses aliased on lo0 and to >> the one IP on em1. But all connections exit out em0 other than connected >> routes of course. >> >> ---Mike >> >>> Julian has worked in this code most recently, maybe he has some idea >>> what is going on. >>> > > huh? wha? I haven't been following this thread.. what's up? > Julian - see previous e-mails, the arp cache gets messed up as a result of calling rtalloc in tcp_offload.c - which is done to determine which interface will be used for connection. Any thoughts on why it may end up with dozens of bogus entries? -Kip From julian at elischer.org Sun Aug 24 05:59:11 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 24 05:59:19 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> Message-ID: <48B0F8AD.1090601@elischer.org> Kip Macy wrote: > On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer wrote: >> Mike Tancsa wrote: >>> At 10:16 PM 8/23/2008, Kip Macy wrote: >>>> Can you help me out a bit with your workload? >>>> >>>> tcp_offload_connect(...) needs to determine which interface an address >>>> corresponds to see if that interface supports TCP offload. The code >>>> does the exact same thing as ip_output does except it doesn't have the >>>> inpcb locked (which isn't used as part of the route lookup). >>> This is the only RELENG_7 box that I have where it routes tcp packets >>> asymmetrically, so that sounds like it might be the portion that is badly >>> interacting. The server has just one default gateway, which is out em0, but >>> clients all over the net will connect to IP addresses aliased on lo0 and to >>> the one IP on em1. But all connections exit out em0 other than connected >>> routes of course. >>> >>> ---Mike >>> >>>> Julian has worked in this code most recently, maybe he has some idea >>>> what is going on. >>>> >> huh? wha? I haven't been following this thread.. what's up? >> > Julian - see previous e-mails, the arp cache gets messed up as a > result of calling rtalloc in tcp_offload.c - which is done to > determine which interface will be used for connection. Any thoughts on > why it may end up with dozens of bogus entries? > > -Kip has anyone tried the same scenario on -current? From kmacy at freebsd.org Sun Aug 24 06:05:33 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sun Aug 24 06:05:40 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <48B0F8AD.1090601@elischer.org> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> <48B0F8AD.1090601@elischer.org> Message-ID: <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> Yes, he has the same issue. -Kip On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer wrote: > Kip Macy wrote: >> >> On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer >> wrote: >>> >>> Mike Tancsa wrote: >>>> >>>> At 10:16 PM 8/23/2008, Kip Macy wrote: >>>>> >>>>> Can you help me out a bit with your workload? >>>>> >>>>> tcp_offload_connect(...) needs to determine which interface an address >>>>> corresponds to see if that interface supports TCP offload. The code >>>>> does the exact same thing as ip_output does except it doesn't have the >>>>> inpcb locked (which isn't used as part of the route lookup). >>>> >>>> This is the only RELENG_7 box that I have where it routes tcp packets >>>> asymmetrically, so that sounds like it might be the portion that is >>>> badly >>>> interacting. The server has just one default gateway, which is out em0, >>>> but >>>> clients all over the net will connect to IP addresses aliased on lo0 and >>>> to >>>> the one IP on em1. But all connections exit out em0 other than >>>> connected >>>> routes of course. >>>> >>>> ---Mike >>>> >>>>> Julian has worked in this code most recently, maybe he has some idea >>>>> what is going on. >>>>> >>> huh? wha? I haven't been following this thread.. what's up? >>> >> Julian - see previous e-mails, the arp cache gets messed up as a >> result of calling rtalloc in tcp_offload.c - which is done to >> determine which interface will be used for connection. Any thoughts on >> why it may end up with dozens of bogus entries? >> >> -Kip > > has anyone tried the same scenario on -current? > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From julian at elischer.org Sun Aug 24 06:18:45 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 24 06:18:52 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> <48B0F8AD.1090601@elischer.org> <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> Message-ID: <48B0FD43.2090705@elischer.org> Kip Macy wrote: > Yes, he has the same issue. > -Kip > > > On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer wrote: >> Kip Macy wrote: >>> On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer >>> wrote: >>>> Mike Tancsa wrote: >>>>> At 10:16 PM 8/23/2008, Kip Macy wrote: >>>>>> Can you help me out a bit with your workload? >>>>>> >>>>>> tcp_offload_connect(...) needs to determine which interface an address >>>>>> corresponds to see if that interface supports TCP offload. The code >>>>>> does the exact same thing as ip_output does except it doesn't have the >>>>>> inpcb locked (which isn't used as part of the route lookup). >>>>> This is the only RELENG_7 box that I have where it routes tcp packets >>>>> asymmetrically, so that sounds like it might be the portion that is >>>>> badly >>>>> interacting. The server has just one default gateway, which is out em0, >>>>> but >>>>> clients all over the net will connect to IP addresses aliased on lo0 and >>>>> to >>>>> the one IP on em1. But all connections exit out em0 other than >>>>> connected >>>>> routes of course. >>>>> >>>>> ---Mike >>>>> >>>>>> Julian has worked in this code most recently, maybe he has some idea >>>>>> what is going on. >>>>>> >>>> huh? wha? I haven't been following this thread.. what's up? >>>> >>> Julian - see previous e-mails, the arp cache gets messed up as a >>> result of calling rtalloc in tcp_offload.c - which is done to >>> determine which interface will be used for connection. Any thoughts on >>> why it may end up with dozens of bogus entries? >>> >>> -Kip >> has anyone tried the same scenario on -current? ok so it might be related to the MRT code... I assume he only has one Routing table.. Theoretically it shoudl work the same as before if N==1 but I can imagine a case where it didn't. especially if arp and interffaces are involved.. Mike, can you give me a repro example? >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> From imp at bsdimp.com Sun Aug 24 07:28:31 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Aug 24 07:28:40 2008 Subject: Code review request Message-ID: <20080824.012750.-1186539247.imp@bsdimp.com> I've been shepherding this patch in my p4 tree for a long time. It removes the obsolete support for other systems in if_spppsubr.c. Is there a reason I shouldn't commit this? Warner -------------- next part -------------- Index: if_spppsubr.c =================================================================== --- if_spppsubr.c (revision 182085) +++ if_spppsubr.c (working copy) @@ -23,38 +23,22 @@ #include -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 #include "opt_inet.h" #include "opt_inet6.h" #include "opt_ipx.h" -#endif -#ifdef NetBSD1_3 -# if NetBSD1_3 > 6 -# include "opt_inet.h" -# include "opt_inet6.h" -# include "opt_iso.h" -# endif -#endif - #include #include #include #include #include #include -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 #include -#endif #include #include #include -#if defined (__OpenBSD__) -#include -#else #include -#endif #include #include @@ -65,10 +49,6 @@ #include #include -#if defined (__NetBSD__) || defined (__OpenBSD__) -#include /* XXX for softnet */ -#endif - #include #include @@ -82,11 +62,7 @@ #include #endif -#if defined (__FreeBSD__) || defined (__OpenBSD__) -# include -#else -# include -#endif +#include #ifdef IPX #include @@ -95,12 +71,7 @@ #include -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 -# define IOCTL_CMD_T u_long -#else -# define IOCTL_CMD_T int -#endif - +#define IOCTL_CMD_T u_long #define MAXALIVECNT 3 /* max. alive packets */ /* @@ -261,13 +232,8 @@ void (*scr)(struct sppp *sp); }; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 && __FreeBSD_version < 501113 -#define SPP_FMT "%s%d: " -#define SPP_ARGS(ifp) (ifp)->if_name, (ifp)->if_unit -#else #define SPP_FMT "%s: " #define SPP_ARGS(ifp) (ifp)->if_xname -#endif #define SPPP_LOCK(sp) \ do { \ @@ -1422,11 +1388,7 @@ ++sp->pp_loopcnt; /* Generate new local sequence number */ -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 sp->pp_seq[IDX_LCP] = random(); -#else - sp->pp_seq[IDX_LCP] ^= time.tv_sec ^ time.tv_usec; -#endif break; } sp->pp_loopcnt = 0; @@ -2671,11 +2633,7 @@ if (magic == ~sp->lcp.magic) { if (debug) log(-1, "magic glitch "); -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 sp->lcp.magic = random(); -#else - sp->lcp.magic = time.tv_sec + time.tv_usec; -#endif } else { sp->lcp.magic = magic; if (debug) @@ -2856,11 +2814,7 @@ if (sp->lcp.opts & (1 << LCP_OPT_MAGIC)) { if (! sp->lcp.magic) -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 sp->lcp.magic = random(); -#else - sp->lcp.magic = time.tv_sec + time.tv_usec; -#endif opt[i++] = LCP_OPT_MAGIC; opt[i++] = 6; opt[i++] = sp->lcp.magic >> 24; @@ -4383,15 +4337,7 @@ /* Compute random challenge. */ ch = (u_long *)sp->myauth.challenge; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 read_random(&seed, sizeof seed); -#else - { - struct timeval tv; - microtime(&tv); - seed = tv.tv_sec ^ tv.tv_usec; - } -#endif ch[0] = seed ^ random(); ch[1] = seed ^ random(); ch[2] = seed ^ random(); @@ -4900,17 +4846,7 @@ * aliases don't make any sense on a p2p link anyway. */ si = 0; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = TAILQ_FIRST(&ifp->if_addrlist); - ifa; - ifa = TAILQ_NEXT(ifa, ifa_list)) -#else - for (ifa = ifp->if_addrlist; - ifa; - ifa = ifa->ifa_next) -#endif if (ifa->ifa_addr->sa_family == AF_INET) { si = (struct sockaddr_in *)ifa->ifa_addr; sm = (struct sockaddr_in *)ifa->ifa_netmask; @@ -4949,17 +4885,7 @@ * aliases don't make any sense on a p2p link anyway. */ si = 0; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = TAILQ_FIRST(&ifp->if_addrlist); - ifa; - ifa = TAILQ_NEXT(ifa, ifa_list)) -#else - for (ifa = ifp->if_addrlist; - ifa; - ifa = ifa->ifa_next) -#endif { if (ifa->ifa_addr->sa_family == AF_INET) { @@ -4972,17 +4898,6 @@ if (ifa && si) { int error; -#if defined(__NetBSD__) && __NetBSD_Version__ >= 103080000 - struct sockaddr_in new_sin = *si; - - new_sin.sin_addr.s_addr = htonl(src); - error = in_ifinit(ifp, ifatoia(ifa), &new_sin, 1); - if(debug && error) - { - log(LOG_DEBUG, SPP_FMT "sppp_set_ip_addr: in_ifinit " - " failed, error=%d\n", SPP_ARGS(ifp), error); - } -#else /* delete old route */ error = rtinit(ifa, (int)RTM_DELETE, RTF_HOST); if(debug && error) @@ -5004,7 +4919,6 @@ log(LOG_DEBUG, SPP_FMT "sppp_set_ip_addr: rtinit ADD failed, error=%d", SPP_ARGS(ifp), error); } -#endif } } @@ -5029,17 +4943,7 @@ * aliases don't make any sense on a p2p link anyway. */ si = 0; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = ifp->if_addrlist.tqh_first; - ifa; - ifa = ifa->ifa_list.tqe_next) -#else - for (ifa = ifp->if_addrlist; - ifa; - ifa = ifa->ifa_next) -#endif if (ifa->ifa_addr->sa_family == AF_INET6) { si = (struct sockaddr_in6 *)ifa->ifa_addr; sm = (struct sockaddr_in6 *)ifa->ifa_netmask; @@ -5092,15 +4996,7 @@ */ sin6 = NULL; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = ifp->if_addrlist.tqh_first; - ifa; - ifa = ifa->ifa_list.tqe_next) -#else - for (ifa = ifp->if_addrlist; ifa; ifa = ifa->ifa_next) -#endif { if (ifa->ifa_addr->sa_family == AF_INET6) { From mike at sentex.net Sun Aug 24 11:21:12 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun Aug 24 11:21:19 2008 Subject: strange TCP issue on RELENG_7 In-Reply-To: <48B0FD43.2090705@elischer.org> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> <48B0F8AD.1090601@elischer.org> <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> <48B0FD43.2090705@elischer.org> Message-ID: <200808241121.m7OBL4Pn000366@lava.sentex.ca> At 02:18 AM 8/24/2008, Julian Elischer wrote: >ok so it might be related to the MRT code... > >I assume he only has one Routing table.. Yes, just one routing table >Theoretically it shoudl work the same as before if N==1 >but I can imagine a case where it didn't. >especially if arp and interffaces are involved.. > >Mike, can you give me a repro example? I am not sure how, but it happens on this machine within seconds of all its applications starting up. I am speculating it has to do with the fact the machine has multiple public interfaces as well as IPs aliased to lo0 so that packets will come in em1 destined for em1 and lo0, but will always go out em0 ? The same for the kernel from HEAD shows the same behaviour. The problem started with the tcp offload code http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044468.html has more details ---Mike From bzeeb-lists at lists.zabbadoz.net Sun Aug 24 11:35:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Aug 24 11:35:15 2008 Subject: [CFT/R] IPv4 source address selection Message-ID: <20080824111925.X66593@maildrop.int.zabbadoz.net> Hi, I have a patch, that was inspired by work from Y!, to do porper IPv4 source address selection for unbound sockets (with multi-IP jails). You can temporary find it here: http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff People running my latest jail patches have been ``testing'' this without really knowing the last weeks. In case you wonder why, in the jail case, I loop over the ifa first before simply falling back to the primary jail IP (which is the only jail IP as in HEAD) -- this is because with the upcoming jail patches I have to check if any of possibly lots of IPs match any IP on an interface and only if none matches I have to fall back to the 'primary' jail IP. So the code has been prepared for upcoming changes already. Feel free to test it and report problems or unexpected behavior. Unless someone is going to cry it'll hit HEAD in a few days. /bz PS: in case you review this properly (not only glance at it or test it) let me know so I can punish you in the Reviewed by: line;-) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From rik at inse.ru Sun Aug 24 11:35:38 2008 From: rik at inse.ru (Roman Kurakin) Date: Sun Aug 24 11:35:51 2008 Subject: Code review request In-Reply-To: <20080824.012750.-1186539247.imp@bsdimp.com> References: <20080824.012750.-1186539247.imp@bsdimp.com> Message-ID: <48B14019.80901@localhost.inse.ru> M. Warner Losh wrote: > I've been shepherding this patch in my p4 tree for a long time. It > removes the obsolete support for other systems in if_spppsubr.c. Is > there a reason I shouldn't commit this? > It was there to ease the keeping code in sync with other systems. Please ask Joerg Wunsch before removal. rik > Warner > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From bms at FreeBSD.org Sun Aug 24 11:35:39 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Aug 24 11:35:52 2008 Subject: Code review request In-Reply-To: <20080824.012750.-1186539247.imp@bsdimp.com> References: <20080824.012750.-1186539247.imp@bsdimp.com> Message-ID: <48B14773.9060907@FreeBSD.org> M. Warner Losh wrote: > I've been shepherding this patch in my p4 tree for a long time. It > removes the obsolete support for other systems in if_spppsubr.c. Is > there a reason I shouldn't commit this? > Looks fine to me. From bms at FreeBSD.org Sun Aug 24 13:12:23 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Aug 24 13:12:30 2008 Subject: [CFT/R] IPv4 source address selection In-Reply-To: <20080824111925.X66593@maildrop.int.zabbadoz.net> References: <20080824111925.X66593@maildrop.int.zabbadoz.net> Message-ID: <48B15A6E.5060000@FreeBSD.org> Bjoern A. Zeeb wrote: > Hi, > > I have a patch, that was inspired by work from Y!, to do porper > IPv4 source address selection for unbound sockets (with multi-IP > jails). Hi, This kinda overlaps with some other ideas I'd like to see go in. It looks good and if it's already been tested, it should probably go in anyway as it disentangles the logic and puts it in a separate function. I'm thinking we may wish to use criteria other than interface or jailed socket to select source address. I should point out though that we picked some stuff up from KAME to do source address selection but it's not in the IPv4 stack. cheers BMS From imp at bsdimp.com Sun Aug 24 16:22:55 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Aug 24 16:23:02 2008 Subject: Code review request In-Reply-To: <48B14019.80901@localhost.inse.ru> References: <20080824.012750.-1186539247.imp@bsdimp.com> <48B14019.80901@localhost.inse.ru> Message-ID: <20080824.102144.-705600373.imp@bsdimp.com> In message: <48B14019.80901@localhost.inse.ru> Roman Kurakin writes: : M. Warner Losh wrote: : > I've been shepherding this patch in my p4 tree for a long time. It : > removes the obsolete support for other systems in if_spppsubr.c. Is : > there a reason I shouldn't commit this? : > : It was there to ease the keeping code in sync with other systems. : Please ask Joerg Wunsch before removal. Yea, I knew that history. But there's been a lot of hacking on this file, and the ifdef's are for other systems that were contemporaneous with FreeBSD 3.0, but nothing newer. Plus the FreeBSDisms that are newer haven't been ifdef'd. Warner From imp at bsdimp.com Mon Aug 25 06:26:18 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Aug 25 06:26:30 2008 Subject: Code review Message-ID: <20080825.002316.-1548243307.imp@bsdimp.com> I did this a few years ago when trying to track down a problem with some realtek network chips that I was having problems with at Timing Solutions. I'd like to get this into the tree, since it was helpful then. Comments? Warner -------------- next part -------------- diff -ur src/sys/pci/if_rl.c newcard/src/sys/pci/if_rl.c --- src/sys/pci/if_rl.c 2008-08-23 22:21:15.000000000 -0600 +++ newcard/src/sys/pci/if_rl.c 2008-08-23 22:26:09.000000000 -0600 @@ -1253,18 +1253,120 @@ } static void +rl_twister_update(struct rl_softc *sc) +{ + uint16_t linktest; + static const uint32_t param[4][4] = { + {0xcb39de43, 0xcb39ce43, 0xfb38de03, 0xcb38de43}, + {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83}, + {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83}, + {0xbb39de43, 0xbb39ce43, 0xbb39ce83, 0xbb39ce83} + }; + + /* + * Tune the so-called twister registers of the RTL8139. These + * are used to compensate for impendence mismatches. The + * method for tuning these registes is undocumented and the + * following proceedure is collected from public sources. + */ + switch (sc->rl_twister) + { + case CHK_LINK: + /* + * If we have a sufficent link, then we can proceed in + * the state machine to the next stage. If not, then + * disable further tuning after writing sane defaults. + */ + if (CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_LINK_OK) { + CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_OFF_CMD); + sc->rl_twister = FIND_ROW; + } else { + CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_CMD); + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST); + CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF); + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF); + sc->rl_twister = DONE; + } + break; + case FIND_ROW: + /* + * Read how long it took to see the echo to find the tuning + * row to use. + */ + linktest = CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_STATUS; + if (linktest == RL_CSCFG_ROW3) + sc->rl_twist_row = 3; + else if (linktest == RL_CSCFG_ROW2) + sc->rl_twist_row = 2; + else if (linktest == RL_CSCFG_ROW1) + sc->rl_twist_row = 1; + else + sc->rl_twist_row = 0; + sc->rl_twist_col = 0; + sc->rl_twister = SET_PARAM; + break; + case SET_PARAM: + if (sc->rl_twist_col == 0) + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET); + CSR_WRITE_4(sc, RL_PARA7C, + param[sc->rl_twist_row][sc->rl_twist_col]); + if (++sc->rl_twist_col == 4) { + if (sc->rl_twist_row == 3) + sc->rl_twister = RECHK_LONG; + else + sc->rl_twister = DONE; + } + break; + case RECHK_LONG: + /* + * For long cables, we have to double check to make sure we + * don't mistune. + */ + linktest = CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_STATUS; + if (linktest == RL_CSCFG_ROW3) + sc->rl_twister = DONE; + else { + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_RETUNE); + sc->rl_twister = RETUNE; + } + break; + case RETUNE: + /* Retune for a shorter cable (try column 2) */ + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST); + CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF); + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF); + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET); + sc->rl_twist_row--; + sc->rl_twist_col = 0; + sc->rl_twister = SET_PARAM; + break; + + case DONE: + break; + } + +} + +static void rl_tick(void *xsc) { struct rl_softc *sc = xsc; struct mii_data *mii; + int ticks; RL_LOCK_ASSERT(sc); mii = device_get_softc(sc->rl_miibus); mii_tick(mii); + if (sc->rl_twister != DONE) + rl_twister_update(sc); + if (sc->rl_twister != DONE) + ticks = hz / 10; + else + ticks = hz; rl_watchdog(sc); - callout_reset(&sc->rl_stat_callout, hz, rl_tick, sc); + callout_reset(&sc->rl_stat_callout, ticks, rl_tick, sc); } #ifdef DEVICE_POLLING @@ -1490,6 +1592,13 @@ rl_stop(sc); /* + * Reset twister register tuning state. The twister registers + * and their tuning are undocumented, but are necessary to cope + * with bad links. rl_twister = DONE here will disable this entirely. + */ + sc->rl_twister = CHK_LINK; + + /* * Init our MAC address. Even though the chipset * documentation doesn't mention it, we need to enter "Config * register write enable" mode to modify the ID registers. diff -ur src/sys/pci/if_rlreg.h newcard/src/sys/pci/if_rlreg.h --- src/sys/pci/if_rlreg.h 2008-08-23 22:21:15.000000000 -0600 +++ newcard/src/sys/pci/if_rlreg.h 2008-08-23 22:26:09.000000000 -0600 @@ -309,6 +309,27 @@ #define RL_CMD_RESET 0x0010 /* + * Twister register values. These are completely undocumented and derived + * from public sources. + */ +#define RL_CSCFG_LINK_OK 0x0400 +#define RL_CSCFG_CHANGE 0x0800 +#define RL_CSCFG_STATUS 0xf000 +#define RL_CSCFG_ROW3 0x7000 +#define RL_CSCFG_ROW2 0x3000 +#define RL_CSCFG_ROW1 0x1000 +#define RL_CSCFG_LINK_DOWN_OFF_CMD 0x03c0 +#define RL_CSCFG_LINK_DOWN_CMD 0xf3c0 + +#define RL_NWAYTST_RESET 0 +#define RL_NWAYTST_CBL_TEST 0x20 + +#define RL_PARA78 0x78 +#define RL_PARA78_DEF 0x78fa8388 +#define RL_PARA7C 0x7C +#define RL_PARA7C_DEF 0xcb38de43 +#define RL_PARA7C_RETUNE 0xfb38de03 +/* * EEPROM control register */ #define RL_EE_DATAOUT 0x01 /* Data out */ @@ -801,6 +822,8 @@ bus_addr_t rl_tx_list_addr; }; +enum rl_twist { DONE, CHK_LINK, FIND_ROW, SET_PARAM, RECHK_LONG, RETUNE }; + struct rl_softc { struct ifnet *rl_ifp; /* interface info */ bus_space_handle_t rl_bhandle; /* bus space handle */ @@ -830,6 +853,9 @@ uint32_t rl_rxlenmask; int rl_testmode; int rl_if_flags; + enum rl_twist rl_twister; + int rl_twist_row; + int rl_twist_col; int suspended; /* 0 = normal 1 = suspended */ #ifdef DEVICE_POLLING int rxcycles; @@ -850,6 +876,8 @@ #define RL_FLAG_LINK 0x8000 }; + + #define RL_LOCK(_sc) mtx_lock(&(_sc)->rl_mtx) #define RL_UNLOCK(_sc) mtx_unlock(&(_sc)->rl_mtx) #define RL_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->rl_mtx, MA_OWNED) From dfilter at FreeBSD.ORG Mon Aug 25 09:40:07 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Aug 25 09:40:13 2008 Subject: kern/126561: commit references a PR Message-ID: <200808250940.m7P9e7Gj017643@freefall.freebsd.org> The following reply was made to PR kern/126561; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126561: commit references a PR Date: Mon, 25 Aug 2008 09:30:59 +0000 (UTC) dfr 2008-08-25 09:30:27 UTC FreeBSD src repository Modified files: sys/nlm nlm_prot_server.c Log: SVN rev 182153 on 2008-08-25 09:30:27Z by dfr Add a missing return statement in nlm4_unlock_msg_4_svc which prevented it from returning a reply message in most cases. This in turn caused interoperability problems with Mac OS X clients. PR: 126561 Submitted by: Richard.Conto at gmail.com MFC after: 1 week Revision Changes Path 1.4 +1 -0 src/sys/nlm/nlm_prot_server.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From artis.caune at gmail.com Mon Aug 25 10:10:04 2008 From: artis.caune at gmail.com (Artis Caune) Date: Mon Aug 25 10:10:11 2008 Subject: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address Message-ID: <200808251010.m7PAA4Mk018658@freefall.freebsd.org> The following reply was made to PR kern/126714; it has been noted by GNATS. From: "Artis Caune" To: bug-followup@freebsd.org Cc: slawek.zak@gmail.com Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address Date: Mon, 25 Aug 2008 13:05:55 +0300 Same for me, but when I rename carp interface to original name, everything works. When you change carp0 name to new_name, ifconfig will: - announce that carp0 is gone (departure) - copy new_name to if_xname - announce that new_name has arrived carp check only departure events. When you change name of carp interface, mac address also change: from 00:00:5e:00:01:08 to 70:31:00:00:5e:00 (for me) And because new mac address is no longer CARP mac address, carp_forus() fail, M_PROMISC flag is not cleared and frame is discarded. If you need change names at run time and not in rc.conf, then you should reinitialize carp interface: # ifconfig new_name vhid 1 pass testpass 192.168.0.2/24 or set promisc flag on em0/em1 :) btw, don't change name to "carp" or your box will panic. p.s. if you change name to underlying em0/em1/lagg/vlan interface, you should also reinitialize carp interface or you will see: carp_input: packet received on non-carp interface: bce0 -- regards, Artis Caune <----. CCNA <----|==================== <----' didii FreeBSD From bugmaster at FreeBSD.org Mon Aug 25 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:08:25 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200808251106.m7PB6sjo027828@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126742 net [panic] kernel panic when sending file via ng_ubt(4) 105 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/126339 net [ipw] ipw driver drops the connection o kern/126695 net rtfree messages and network disruption upon use of if_ 61 problems total. From vako2000 at gmail.com Mon Aug 25 11:47:19 2008 From: vako2000 at gmail.com (vako2000) Date: Mon Aug 25 11:47:26 2008 Subject: freebsd-net Message-ID: <61656705.20080825173253@gmail.com> Hello freebsd-net i like freeBSD -- Best regards, vako2000 mailto:vako2000@gmail.com From alexey.pelykh at gmail.com Mon Aug 25 12:40:07 2008 From: alexey.pelykh at gmail.com (Alexey Pelykh) Date: Mon Aug 25 12:40:13 2008 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200808251240.m7PCe6nS040994@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: "Alexey Pelykh" To: bug-followup@FreeBSD.org, skylord@linkline.ru Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Mon, 25 Aug 2008 15:01:09 +0300 Also, DLink 560T. Same problem. NIC freezes on workloads at > 3.0Mbytes/sec dmesg | grep "msk" mskc0: port 0xd800-0xd8ff mem 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1 msk0: on mskc0 miibus0: on msk0 mskc0: [ITHREAD] mskc0: port 0xd800-0xd8ff mem 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1 msk0: on mskc0 miibus0: on msk0 mskc0: [ITHREAD] mskc0: port 0xd800-0xd8ff mem 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1 msk0: on mskc0 miibus0: on msk0 mskc0: [FILTER] msk0: link state changed to UP pciconf -lv mskc0@pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186 rev=0x13 hdr=0x00 vendor = 'D-Link System Inc' device = 'DGE-560T PCIe Gigabit Ethernet Adapter' class = network subclass = ethernet uname -a: FreeBSD taburetka 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #17: Sun Aug 10 01:10:09 EEST 2008 root@taburetka:/usr/obj/usr/src/sys/taburetka_7_0.2008-25-07 i386 From pluknet at gmail.com Mon Aug 25 13:28:38 2008 From: pluknet at gmail.com (pluknet) Date: Mon Aug 25 13:28:45 2008 Subject: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) In-Reply-To: <200808230830.m7N8U5aH081332@freefall.freebsd.org> References: <200808230830.m7N8U5aH081332@freefall.freebsd.org> Message-ID: 2008/8/23 Alex : > this should work. i simply replaced the lines with a single dot (".") in it with "DOT". You have a truncated mail maybe because of '.' treated as a special symbol that means "end of body" in SMTP. > Unread portion of the kernel message buffer: > sblastmbufchk: sb_mb 0xc91a5300 sb_mbtail 0 last 0xc91a5300 > packet tree: > 0xc91a5300 > panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 > cpuid = 0 > Syncing disks, buffers remaining... 7171 7168 7168 7168 7168 7168 7168 7167 7169 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 > Giving up on 7167 buffers > Uptime: 2d18h9m43s > Physical memory: 2030 MB > Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 > Dump complete > panic: 5 vncache entries remaining > cpuid = 0 > Uptime: 2d18h9m47s > Physical memory: 2030 MB > Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 > > #0 doadump () at pcpu.h:195 > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc04daa4e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc07d73e4 in pfs_vncache_unload () at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs_vncache.c:102 > #4 0xc07d6515 in pfs_modevent (mod=0xc54b8280, evt=2, arg=0x0) at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs.c:438 > #5 0xc04cd318 in module_shutdown (arg1=0x0, arg2=) at /usr/src/sys/kern/kern_module.c:105 > #6 0xc04daaef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:421 > #7 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 > #8 0xc052d79b in sblastmbufchk (sb=0x0, file=0xc06838ad "/usr/src/sys/kern/uipc_sockbuf.c", line=794) at /usr/src/sys/kern/uipc_sockbuf.c:425 > #9 0xc052eed0 in sbcompress (sb=0xc8cb11f0, m=0x0, n=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:794 > #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 > #11 0xc052f041 in sbappendrecord (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:610 > #12 0xc5a2f8fe in ng_btsocket_l2cap_input (context=0x0, pending=1) at /usr/src/sys/modules/netgraph/bluetooth/socket/../../../../netgraph/bluetooth/socket/ng_btsocket_l2cap.c:1458 > #13 0xc050cd1b in taskqueue_run (queue=0xc556b500) at /usr/src/sys/kern/subr_taskqueue.c:282 > #14 0xc050cf53 in taskqueue_swi_giant_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:336 > #15 0xc04be975 in ithread_loop (arg=0xc55d7160) at /usr/src/sys/kern/kern_intr.c:1088 > #16 0xc04bc258 in fork_exit (callout=0xc04be7b0 , arg=0xc55d7160, frame=0xe5b12d38) at /usr/src/sys/kern/kern_fork.c:781 > #17 0xc06348b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 > --- crash ends here --- > > --- ARUNDEL begins here --- > cpu I686_CPU > ident ARUNDEL > #maxusers 10 > makeoptions DEBUG=-g > #makeoptions CONF_CFLAGS=-fno-builtin > #options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table > #options CPU_SUSP_HLT > #options CPU_UPGRADE_HW_CACHE > #options CPU_FASTER_5X86_FPU > options ATA_STATIC_ID > > #options MSDOSFS > #options CD9660 > #options USB_DEBUG > #options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN > #options HZ=100 > > #options PREEMPTION > #options IPI_PREEMPTION > > options SCHED_4BSD #4BSD scheduler > #options SCHED_ULE > options INET #InterNETworking > options FFS #Berkeley Fast Filesystem > options SOFTUPDATES #Enable FFS soft updates support > options UFS_DIRHASH #Improve performance on big directories > options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_43TTY #Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_FREEBSD4 #Compatible with FreeBSD4 > options COMPAT_FREEBSD5 #Compatible with FreeBSD5 > options COMPAT_FREEBSD6 #Compatible with FreeBSD6 > > options SC_HISTORY_SIZE=1000 #number of history buffer lines > #options KDB #Compile with kernel debugger related code > #options KDB_TRACE #Print a stack trace of the current thread on the console for a panic. > #options KTRACE #ktrace(1) support > #options DDB > options INVARIANTS > options INVARIANT_SUPPORT > options SOCKBUF_DEBUG > options WITNESS > options WITNESS_SKIPSPIN > options SYSVSHM #SYSV-style shared memory > options SYSVMSG #SYSV-style message queues > options SYSVSEM #SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options KBD_INSTALL_CDEV #install a CDEV entry in /dev > options UKBD_DFLT_KEYMAP #specify the built-in keymap > makeoptions UKBD_DFLT_KEYMAP="german.iso" > #options AUTO_EOI_1 > #options AUTO_EOI_2 > #options ADAPTIVE_GIANT # Giant mutex is adaptive. > #options STOP_NMI # Stop CPUS using NMI instead of IPI > > > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > > #devices > device eisa > device pci > device ata > device atadisk > device atapicd > device usb > device uhci > device ehci > device vga > device sc > device ukbd > device ulpt > device ath > device ath_hal > device ath_rate_sample > device wlan > device cpufreq > device coretemp > > #pseudo devices > device loop > device ether > device pty > --- ARUNDEL ends here --- Looks like it was triggered by the SOCKBUF_DEBUG kernel option. I will try to reproduce it this evening as I'm user of ng_ubt(4). wbr, pluknet From jhay at meraka.org.za Mon Aug 25 19:02:10 2008 From: jhay at meraka.org.za (John Hay) Date: Mon Aug 25 19:02:16 2008 Subject: Small patch to multicast code... In-Reply-To: References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> Message-ID: <20080825190207.GA73478@zibbi.meraka.csir.co.za> On Fri, Aug 22, 2008 at 03:03:30PM -0700, gnn@FreeBSD.org wrote: > At Fri, 22 Aug 2008 22:43:39 +0100, > Bruce M. Simpson wrote: > > > > gnn@FreeBSD.org wrote: > > > Somehow the data that the device needs to do the proper checksum > > > offload is getting trashed here. Now, since it's clear we need a > > > writable packet structure so that we don't trash the original, I'm > > > wondering if the m_pullup() will be sufficient. > > > > > > > If it's serious enough to break UDP checksumming on the wire, perhaps we > > should just swallow the mbuf allocator heap churn and do the m_dup() for > > now, but slap in a big comment about why it's there. > > I think if none of us finds a better way before early next week that's > what I'll do so that this at least works in 7.1. I think we and others have been hitting this problem: kern/119635: [em] Bad UDP packet checksum with em(4) and rxcsum/txcsum enabled http://www.freebsd.org/cgi/query-pr.cgi?pr=119635 I'll try out your patch. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From pluknet at gmail.com Mon Aug 25 19:17:46 2008 From: pluknet at gmail.com (pluknet) Date: Mon Aug 25 19:17:53 2008 Subject: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) In-Reply-To: References: <200808230830.m7N8U5aH081332@freefall.freebsd.org> Message-ID: 2008/8/25 pluknet : > 2008/8/23 Alex : >> this should work. i simply replaced the lines with a single dot (".") in it with "DOT". > > You have a truncated mail maybe because of '.' treated as a special > symbol that means "end of body" in SMTP. > >> Unread portion of the kernel message buffer: >> sblastmbufchk: sb_mb 0xc91a5300 sb_mbtail 0 last 0xc91a5300 >> packet tree: >> 0xc91a5300 >> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 >> cpuid = 0 >> Syncing disks, buffers remaining... 7171 7168 7168 7168 7168 7168 7168 7167 7169 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 >> Giving up on 7167 buffers >> Uptime: 2d18h9m43s >> Physical memory: 2030 MB >> Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 >> Dump complete >> panic: 5 vncache entries remaining >> cpuid = 0 >> Uptime: 2d18h9m47s >> Physical memory: 2030 MB >> Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 >> >> #0 doadump () at pcpu.h:195 >> in pcpu.h >> (kgdb) bt >> #0 doadump () at pcpu.h:195 >> #1 0xc04daa4e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >> #2 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 >> #3 0xc07d73e4 in pfs_vncache_unload () at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs_vncache.c:102 >> #4 0xc07d6515 in pfs_modevent (mod=0xc54b8280, evt=2, arg=0x0) at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs.c:438 >> #5 0xc04cd318 in module_shutdown (arg1=0x0, arg2=) at /usr/src/sys/kern/kern_module.c:105 >> #6 0xc04daaef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:421 >> #7 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 >> #8 0xc052d79b in sblastmbufchk (sb=0x0, file=0xc06838ad "/usr/src/sys/kern/uipc_sockbuf.c", line=794) at /usr/src/sys/kern/uipc_sockbuf.c:425 >> #9 0xc052eed0 in sbcompress (sb=0xc8cb11f0, m=0x0, n=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:794 >> #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 >> #11 0xc052f041 in sbappendrecord (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:610 >> #12 0xc5a2f8fe in ng_btsocket_l2cap_input (context=0x0, pending=1) at /usr/src/sys/modules/netgraph/bluetooth/socket/../../../../netgraph/bluetooth/socket/ng_btsocket_l2cap.c:1458 >> #13 0xc050cd1b in taskqueue_run (queue=0xc556b500) at /usr/src/sys/kern/subr_taskqueue.c:282 >> #14 0xc050cf53 in taskqueue_swi_giant_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:336 >> #15 0xc04be975 in ithread_loop (arg=0xc55d7160) at /usr/src/sys/kern/kern_intr.c:1088 >> #16 0xc04bc258 in fork_exit (callout=0xc04be7b0 , arg=0xc55d7160, frame=0xe5b12d38) at /usr/src/sys/kern/kern_fork.c:781 >> #17 0xc06348b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 >> --- crash ends here --- >> >> --- ARUNDEL begins here --- >> cpu I686_CPU >> ident ARUNDEL >> #maxusers 10 >> makeoptions DEBUG=-g >> #makeoptions CONF_CFLAGS=-fno-builtin >> #options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table >> #options CPU_SUSP_HLT >> #options CPU_UPGRADE_HW_CACHE >> #options CPU_FASTER_5X86_FPU >> options ATA_STATIC_ID >> >> #options MSDOSFS >> #options CD9660 >> #options USB_DEBUG >> #options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN >> #options HZ=100 >> >> #options PREEMPTION >> #options IPI_PREEMPTION >> >> options SCHED_4BSD #4BSD scheduler >> #options SCHED_ULE >> options INET #InterNETworking >> options FFS #Berkeley Fast Filesystem >> options SOFTUPDATES #Enable FFS soft updates support >> options UFS_DIRHASH #Improve performance on big directories >> options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] >> options COMPAT_43TTY #Compatible with BSD 4.3 [KEEP THIS!] >> options COMPAT_FREEBSD4 #Compatible with FreeBSD4 >> options COMPAT_FREEBSD5 #Compatible with FreeBSD5 >> options COMPAT_FREEBSD6 #Compatible with FreeBSD6 >> >> options SC_HISTORY_SIZE=1000 #number of history buffer lines >> #options KDB #Compile with kernel debugger related code >> #options KDB_TRACE #Print a stack trace of the current thread on the console for a panic. >> #options KTRACE #ktrace(1) support >> #options DDB >> options INVARIANTS >> options INVARIANT_SUPPORT >> options SOCKBUF_DEBUG >> options WITNESS >> options WITNESS_SKIPSPIN >> options SYSVSHM #SYSV-style shared memory >> options SYSVMSG #SYSV-style message queues >> options SYSVSEM #SYSV-style semaphores >> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions >> options KBD_INSTALL_CDEV #install a CDEV entry in /dev >> options UKBD_DFLT_KEYMAP #specify the built-in keymap >> makeoptions UKBD_DFLT_KEYMAP="german.iso" >> #options AUTO_EOI_1 >> #options AUTO_EOI_2 >> #options ADAPTIVE_GIANT # Giant mutex is adaptive. >> #options STOP_NMI # Stop CPUS using NMI instead of IPI >> >> >> options SMP # Symmetric MultiProcessor Kernel >> device apic # I/O APIC >> >> >> #devices >> device eisa >> device pci >> device ata >> device atadisk >> device atapicd >> device usb >> device uhci >> device ehci >> device vga >> device sc >> device ukbd >> device ulpt >> device ath >> device ath_hal >> device ath_rate_sample >> device wlan >> device cpufreq >> device coretemp >> >> #pseudo devices >> device loop >> device ether >> device pty >> --- ARUNDEL ends here --- > > Looks like it was triggered by the SOCKBUF_DEBUG kernel option. > I will try to reproduce it this evening as I'm user of ng_ubt(4). > I did some debugging and found some fuzzy code in sbappendrecord_locked(). >> #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 sb->sb_mb and m0 both point to the same address 0xc91a5300. - sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) { struct mbuf *m; SOCKBUF_LOCK_ASSERT(sb); if (m0 == 0) return; m = sb->sb_mb; - m also points to the same address 0xc91a5300 now (as sb->sb_mb and m0 do). - if (m) while (m->m_nextpkt) m = m->m_nextpkt; - Does nothing because m->m_nextpkt is NULL in the first iteration. - sballoc(sb, m0); SBLASTRECORDCHK(sb); SBLINKRECORD(sb, m0); - Does effectively nothing or non-relevant. - if (m) m->m_nextpkt = m0; else sb->sb_mb = m0; - m and m->m_nextpkt both point to the same address 0xc91a5300 now. - m = m0->m_next; - But hey! m0->m_next is NULL. Eventually sbcompress(sb, m, m0) is called with m == NULL and it fails in the SBLASTMBUFCHK check then. wbr, pluknet From jhay at meraka.org.za Mon Aug 25 19:40:40 2008 From: jhay at meraka.org.za (John Hay) Date: Mon Aug 25 19:40:46 2008 Subject: Small patch to multicast code... In-Reply-To: <20080825190207.GA73478@zibbi.meraka.csir.co.za> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> Message-ID: <20080825194038.GA75840@zibbi.meraka.csir.co.za> On Mon, Aug 25, 2008 at 09:02:07PM +0200, John Hay wrote: > On Fri, Aug 22, 2008 at 03:03:30PM -0700, gnn@FreeBSD.org wrote: > > At Fri, 22 Aug 2008 22:43:39 +0100, > > Bruce M. Simpson wrote: > > > > > > gnn@FreeBSD.org wrote: > > > > Somehow the data that the device needs to do the proper checksum > > > > offload is getting trashed here. Now, since it's clear we need a > > > > writable packet structure so that we don't trash the original, I'm > > > > wondering if the m_pullup() will be sufficient. > > > > > > > > > > If it's serious enough to break UDP checksumming on the wire, perhaps we > > > should just swallow the mbuf allocator heap churn and do the m_dup() for > > > now, but slap in a big comment about why it's there. > > > > I think if none of us finds a better way before early next week that's > > what I'll do so that this at least works in 7.1. > > I think we and others have been hitting this problem: > > kern/119635: [em] Bad UDP packet checksum with em(4) and rxcsum/txcsum enabled > http://www.freebsd.org/cgi/query-pr.cgi?pr=119635 > > I'll try out your patch. I have tried it and it does fix my problem. RIP2 over multicast works again. :-) John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From jhb at freebsd.org Mon Aug 25 20:04:44 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 25 20:04:50 2008 Subject: Code review In-Reply-To: <20080825.002316.-1548243307.imp@bsdimp.com> References: <20080825.002316.-1548243307.imp@bsdimp.com> Message-ID: <200808251037.11126.jhb@freebsd.org> On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: > I did this a few years ago when trying to track down a problem with > some realtek network chips that I was having problems with at Timing > Solutions. I'd like to get this into the tree, since it was helpful > then. > > Comments? When you are running a faster tick I think want to only call the mii and watchdog stuff once a second still. I know this will break the tx watchdog for example. Since it's kind of tricky to manage that I think you should just use a separate timer for the twister stuff. -- John Baldwin From imp at bsdimp.com Tue Aug 26 07:25:54 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Aug 26 07:26:13 2008 Subject: Code review In-Reply-To: <200808251037.11126.jhb@freebsd.org> References: <20080825.002316.-1548243307.imp@bsdimp.com> <200808251037.11126.jhb@freebsd.org> Message-ID: <20080826.012357.1973601375.imp@bsdimp.com> In message: <200808251037.11126.jhb@freebsd.org> John Baldwin writes: : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: : > I did this a few years ago when trying to track down a problem with : > some realtek network chips that I was having problems with at Timing : > Solutions. I'd like to get this into the tree, since it was helpful : > then. : > : > Comments? : : When you are running a faster tick I think want to only call the mii and : watchdog stuff once a second still. I know this will break the tx watchdog : for example. Since it's kind of tricky to manage that I think you should : just use a separate timer for the twister stuff. Is this in general, or do you have a specific problem in mind with the rl change? In general, we're not transmitting during this exercise and it happens only once... Is it worth the extra hair? Warner From stefan.lambrev at moneybookers.com Tue Aug 26 08:04:07 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Aug 26 08:04:14 2008 Subject: Small patch to multicast code... In-Reply-To: References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <20080822194200.GC63527@onelab2.iet.unipi.it> Message-ID: <48B3B52A.9080400@moneybookers.com> Greetings, gnn@freebsd.org wrote: > At Fri, 22 Aug 2008 21:42:00 +0200, > Luigi Rizzo wrote: > >> On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: >> >>> gnn@FreeBSD.org wrote: >>> >>>> I gather you mean that a fast link on which also we're looping back >>>> the packet will be an issue? Since this packet is only going into the >>>> simloop() routine. >>>> >>>> >>> We end up calling if_simloop() from a few "interesting" places, in >>> particular the kernel PIM packet handler. >>> >>> In this particular case we're going to take a full mbuf chain copy every >>> time we send a packet which needs to be looped back to userland. >>> >> ... >> >>> In the case of ip_mloopback(), somehow we are stomping on a read-only >>> copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine >>> according to the documented uses of mbuf(9), although as Luigi pointed >>> out, most likely we need to look at the upper-layer protocol too, e.g. >>> where UDP checksums are also being offloaded. >>> >> in fact, george, if you have an easy way to reproduce the error, >> could you see if reverting your change and instead adding >> sizeof(struct udphdr) to the length argument in the call to m_pullup() >> fixes the problem ? >> > > I don't have sample code I can give but it's simple to set up and > test. > > On machine A set up a sender and a listener for the same multicast > group/port. > > On machine B set up a listener. > > Send from A with the listener on. B should see nothing and its "bad > checksums" counter should increase. > > Turn off listener on A. > > Send again, B should get the packet. > Hm this looks very much like the showstopper when trying to use jboss in cluster environment. The nodes are replicating their data using multicast udp. I'll try this patch to see will the cluster work now under FreeBSD. > If you listen to the traffic with tcpdump on a 3rd machine you'll see > that the checksum is constant, even if the data in the packet, like > the ports, is not. > > Your ethernet cards have to have hardware checksum offloading. I'm > using em/igb in 7-STABLE. > em cards and here. Jboss in cluster creates lot of traffic when under pressure, so I wander how this patch will affect performance. > Best, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From onlinesecurity at halifax.co.uk Tue Aug 26 11:28:32 2008 From: onlinesecurity at halifax.co.uk (Halifax Online) Date: Tue Aug 26 11:28:43 2008 Subject: Halifax Online Alert Message-ID: <20080826105834.A861144DB8@www2.ac-rouen.fr> [hx_print.gif] Dear Customer, Due to our MID-YEARLY upgrade, we kindly request you to update your online banking details, do not hesitate to fill all the requested information(s) in the link below and reconfirm your online account details. Note: there is an error in your SECURITY QUESTION and ANSWER in your file with our organisation that need to be updated. Failure to re-confirm your online banking details may leads to temporarily suspension from accessing your account online. [1]https://www.halifax-online.co.uk/_mem_bin/formslogin.asp We use the latest security measures to ensure that your online banking maintaining by our financial institution is well safe and secured according to our banking system Thank you for banking with us. Halifax Online Help Desk Information on protecting yourself from fraud, please review the Security Tips in our Security Center. References 1. http://atp-primrosebordeaux.com/cms/templates/css/www.halifax.co.uk/www.halifax.co.uk/www.halifax.co.uk/_mem_new/_mem_new/index.html From gnn at neville-neil.com Tue Aug 26 14:29:02 2008 From: gnn at neville-neil.com (George V. Neville-Neil) Date: Tue Aug 26 14:29:09 2008 Subject: Small patch to multicast code... In-Reply-To: <20080825194038.GA75840@zibbi.meraka.csir.co.za> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> Message-ID: At Mon, 25 Aug 2008 21:40:38 +0200, John Hay wrote: > > I have tried it and it does fix my problem. RIP2 over multicast works > again. :-) Good to hear. I'm waiting on a bit more feedback but I think I'll be checking this in soon, with a big comment talking about the performance implications etc. Best, George From bzeeb-lists at lists.zabbadoz.net Tue Aug 26 15:12:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Aug 26 15:12:16 2008 Subject: Small patch to multicast code... In-Reply-To: References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> Message-ID: <20080826144130.S66593@maildrop.int.zabbadoz.net> On Tue, 26 Aug 2008, George V. Neville-Neil wrote: Hi, > At Mon, 25 Aug 2008 21:40:38 +0200, > John Hay wrote: >> >> I have tried it and it does fix my problem. RIP2 over multicast works >> again. :-) > > Good to hear. I'm waiting on a bit more feedback but I think I'll be > checking this in soon, with a big comment talking about the > performance implications etc. So wait a second; what was the m_pullup vs. m_dup thing? Has anyone actually tried that? I mean using a sledgehammer if a mitten would be enough is kind of .. uhm. You get it. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From jhb at freebsd.org Tue Aug 26 18:02:53 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Aug 26 18:03:00 2008 Subject: Code review In-Reply-To: <20080826.012357.1973601375.imp@bsdimp.com> References: <20080825.002316.-1548243307.imp@bsdimp.com> <200808251037.11126.jhb@freebsd.org> <20080826.012357.1973601375.imp@bsdimp.com> Message-ID: <200808261033.43091.jhb@freebsd.org> On Tuesday 26 August 2008 03:23:57 am M. Warner Losh wrote: > In message: <200808251037.11126.jhb@freebsd.org> > John Baldwin writes: > : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: > : > I did this a few years ago when trying to track down a problem with > : > some realtek network chips that I was having problems with at Timing > : > Solutions. I'd like to get this into the tree, since it was helpful > : > then. > : > > : > Comments? > : > : When you are running a faster tick I think want to only call the mii and > : watchdog stuff once a second still. I know this will break the tx watchdog > : for example. Since it's kind of tricky to manage that I think you should > : just use a separate timer for the twister stuff. > > Is this in general, or do you have a specific problem in mind with the > rl change? In general, we're not transmitting during this exercise > and it happens only once... Is it worth the extra hair? Worried more about the general case. Is mii_tick() going to be ok with being invoked more often? Also, if you are only doing this during attach or interface up, it might be simpler to have a private timer (shoot, if it's during attach the 'struct callout' can be on the stack) just for this bit. -- John Baldwin From gnn at FreeBSD.org Tue Aug 26 19:43:05 2008 From: gnn at FreeBSD.org (gnn@FreeBSD.org) Date: Tue Aug 26 19:43:11 2008 Subject: Small patch to multicast code... In-Reply-To: <20080826144130.S66593@maildrop.int.zabbadoz.net> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> Message-ID: At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), Bjoern A. Zeeb wrote: > > On Tue, 26 Aug 2008, George V. Neville-Neil wrote: > > Hi, > > > At Mon, 25 Aug 2008 21:40:38 +0200, > > John Hay wrote: > >> > >> I have tried it and it does fix my problem. RIP2 over multicast works > >> again. :-) > > > > Good to hear. I'm waiting on a bit more feedback but I think I'll be > > checking this in soon, with a big comment talking about the > > performance implications etc. > > So wait a second; what was the m_pullup vs. m_dup thing? Has anyone > actually tried that? I mean using a sledgehammer if a mitten would be > enough is kind of .. uhm. You get it. Perhaps I'm confused, I've been off dealing with other issues for a few days, but m_pullup doesn't make a copy of the packet or its fields, only makes sure that it's contiguous in memory. Am I wrong in that? Since the bug is that two pieces of code modify the same data, in ways that interfere, I'm not sure how we can avoid making a copy. It might be nice to limit the copy, but we'd still need two copies, one for the loopback device and one for the real device. Best, George From sam at freebsd.org Wed Aug 27 00:56:15 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Aug 27 00:56:21 2008 Subject: Small patch to multicast code... In-Reply-To: References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> Message-ID: <48B4A62D.3080300@freebsd.org> gnn@freebsd.org wrote: > At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), > Bjoern A. Zeeb wrote: > >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote: >> >> Hi, >> >> >>> At Mon, 25 Aug 2008 21:40:38 +0200, >>> John Hay wrote: >>> >>>> I have tried it and it does fix my problem. RIP2 over multicast works >>>> again. :-) >>>> >>> Good to hear. I'm waiting on a bit more feedback but I think I'll be >>> checking this in soon, with a big comment talking about the >>> performance implications etc. >>> >> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone >> actually tried that? I mean using a sledgehammer if a mitten would be >> enough is kind of .. uhm. You get it. >> > > Perhaps I'm confused, I've been off dealing with other issues for a > few days, but m_pullup doesn't make a copy of the packet or its > fields, only makes sure that it's contiguous in memory. Am I wrong in that? > > Since the bug is that two pieces of code modify the same data, in ways > that interfere, I'm not sure how we can avoid making a copy. It might > be nice to limit the copy, but we'd still need two copies, one for the > loopback device and one for the real device. > > pull the headers up. copy just the headers. no deep copy. Sam From gnn at freebsd.org Wed Aug 27 04:06:01 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Wed Aug 27 04:06:07 2008 Subject: Small patch to multicast code... In-Reply-To: <48B4A62D.3080300@freebsd.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> Message-ID: At Tue, 26 Aug 2008 17:56:13 -0700, Sam Leffler wrote: > > gnn@freebsd.org wrote: > > At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), > > Bjoern A. Zeeb wrote: > > > >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote: > >> > >> Hi, > >> > >> > >>> At Mon, 25 Aug 2008 21:40:38 +0200, > >>> John Hay wrote: > >>> > >>>> I have tried it and it does fix my problem. RIP2 over multicast works > >>>> again. :-) > >>>> > >>> Good to hear. I'm waiting on a bit more feedback but I think I'll be > >>> checking this in soon, with a big comment talking about the > >>> performance implications etc. > >>> > >> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone > >> actually tried that? I mean using a sledgehammer if a mitten would be > >> enough is kind of .. uhm. You get it. > >> > > > > Perhaps I'm confused, I've been off dealing with other issues for a > > few days, but m_pullup doesn't make a copy of the packet or its > > fields, only makes sure that it's contiguous in memory. Am I wrong in that? > > > > Since the bug is that two pieces of code modify the same data, in ways > > that interfere, I'm not sure how we can avoid making a copy. It might > > be nice to limit the copy, but we'd still need two copies, one for the > > loopback device and one for the real device. > > > > > pull the headers up. copy just the headers. no deep copy. > I'm confused, if it's these lines that are screwed up: /* If needed, compute the checksum and mark it as valid. */ if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { in_delayed_cksum(copym); copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; copym->m_pkthdr.csum_flags |= CSUM_DATA_VALID | CSUM_PSEUDO_HDR; copym->m_pkthdr.csum_data = 0xffff; in particular that last line, then how does pulling up the header help? That's not part of the packet, that's the checksum data in the pkthdr itself. Best, George From imp at FreeBSD.org Wed Aug 27 04:52:50 2008 From: imp at FreeBSD.org (imp@FreeBSD.org) Date: Wed Aug 27 04:52:56 2008 Subject: kern/77913: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) Message-ID: <200808270452.m7R4qiSN051927@freefall.freebsd.org> Synopsis: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) State-Changed-From-To: open->patched State-Changed-By: imp State-Changed-When: Tue Aug 26 22:52:32 MDT 2008 State-Changed-Why: Committed to head. http://www.freebsd.org/cgi/query-pr.cgi?pr=77913 From dfilter at FreeBSD.ORG Wed Aug 27 05:00:04 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Aug 27 05:00:20 2008 Subject: kern/77913: commit references a PR Message-ID: <200808270500.m7R504Pv052140@freefall.freebsd.org> The following reply was made to PR kern/77913; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/77913: commit references a PR Date: Wed, 27 Aug 2008 04:53:30 +0000 (UTC) imp 2008-08-27 04:52:27 UTC FreeBSD src repository Modified files: sys/dev/pccard pccarddevs sys/dev/wi if_wi_pccard.c Log: SVN rev 182236 on 2008-08-27 04:52:27Z by imp The APDL-325 is a Wireless LAN pcmcia adapter that sits inside some Billion Access Points. Fix wi(4) to recognise the adapter. PR: 77913 Submitted by: Daan Vreeken [PA4DAN] MFC after: 3 days Revision Changes Path 1.135 +1 -0 src/sys/dev/pccard/pccarddevs 1.62 +1 -0 src/sys/dev/wi/if_wi_pccard.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Wed Aug 27 05:00:07 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Aug 27 05:00:20 2008 Subject: kern/77913: commit references a PR Message-ID: <200808270500.m7R507e6052246@freefall.freebsd.org> The following reply was made to PR kern/77913; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/77913: commit references a PR Date: Wed, 27 Aug 2008 04:56:01 +0000 (UTC) imp 2008-08-27 04:55:37 UTC FreeBSD src repository Modified files: share/man/man4 wi.4 Log: SVN rev 182238 on 2008-08-27 04:55:37Z by imp Add recent ELSA additions to wi(4), plus make sure the list matches the driver for ELSA. PR: 77913 Submitted by: Daan Vreeken MFC after: 3 days Revision Changes Path 1.79 +3 -0 src/share/man/man4/wi.4 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From remko at FreeBSD.org Wed Aug 27 06:32:24 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Wed Aug 27 06:32:35 2008 Subject: kern/126874: [vlan]: Zebra problem if ifconfig vlanX destroy Message-ID: <200808270632.m7R6WNOO067311@freefall.freebsd.org> Old Synopsis: Zebra problem if ifconfig vlanX destroy New Synopsis: [vlan]: Zebra problem if ifconfig vlanX destroy Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Aug 27 06:31:52 UTC 2008 Responsible-Changed-Why: Move to the -net list. http://www.freebsd.org/cgi/query-pr.cgi?pr=126874 From pblok at bsd4all.org Wed Aug 27 11:14:33 2008 From: pblok at bsd4all.org (Peter BLOK) Date: Wed Aug 27 11:27:27 2008 Subject: Signal quality/strength of FreeBSD hostap vs. commercial products Message-ID: Hi, I am trying to build a FreeBSD wireless router for a while and I noticed that the signal strength is always substantial lower compared to common available wireless routers. At first I thought it was due to the wireless card I used, but I have tried several different ones and several different antennas, but it doesn?t come close to common routers. Strangely enough when I started to use an adhoc connection, the signal strength reported was as good as a common router. For clients I have used different cards as well as Windoze and MACOSX. Setting of txpower doesn?t do anything. Any explanations? Peter From linimon at FreeBSD.org Wed Aug 27 11:37:46 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Aug 27 11:37:52 2008 Subject: bin/126822: wpa_supplicant(8): WPA PSK does not work in adhoc mode. Message-ID: <200808271137.m7RBbk7F023175@freefall.freebsd.org> Old Synopsis: wpa_supplicant - WPA PSK does not work in adhoc mode. New Synopsis: wpa_supplicant(8): WPA PSK does not work in adhoc mode. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 27 11:37:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126822 From linimon at FreeBSD.org Wed Aug 27 19:18:17 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Aug 27 19:18:28 2008 Subject: kern/126895: [patch] [ral] Add antenna selection (marked as TBD) Message-ID: <200808271918.m7RJIHlR062780@freefall.freebsd.org> Synopsis: [patch] [ral] Add antenna selection (marked as TBD) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 27 19:17:53 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126895 From dimitry at andric.com Wed Aug 27 21:40:04 2008 From: dimitry at andric.com (Dimitry Andric) Date: Wed Aug 27 21:40:11 2008 Subject: kern/125502: [ral] ifconfig ral0 scan produces no output unless in shared mode Message-ID: <200808272140.m7RLe33F076505@freefall.freebsd.org> The following reply was made to PR kern/125502; it has been noted by GNATS. From: Dimitry Andric To: bug-followup@FreeBSD.org, chelton30@gmail.com Cc: Subject: Re: kern/125502: [ral] ifconfig ral0 scan produces no output unless in shared mode Date: Wed, 27 Aug 2008 23:36:46 +0200 The ral I've got here on RELENG_7 is a mini-PCI card: ral0: mem 0xdfef8000-0xdfefffff irq 18 at device 2.0 on pci2 ral0: MAC/BBP RT2561C, RF RT5225 ral0: Ethernet address: 00:12:0e:61:48:e4 ral0: [ITHREAD] I've got exactly the same as the original submitter: "ifconfig ral0 scan" keeps busy forever, and never returns, if authmode is open. When I set authmode to shared, it scans within a few seconds, usually. When turning on +scan+auth+debug+assoc, I get the following for authmode shared: ral0: scan_next: chan 2g -> 1g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 1 ral0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 6 ral0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 11 ral0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 7 ral0: scan_next: chan 7g -> 13g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 13 ral0: scan_next: chan 13g -> 52a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 52 ral0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 56 ral0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 60 ral0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 64 ral0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 36 ral0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 40 ral0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 44 ral0: ieee80211_start_scan: active scan already in progress ral0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 48 ral0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 2 ral0: received probe_resp from 00:90:4c:60:04:00 rssi 27 [00:90:4c:60:04:00] new probe_resp on chan 2 (bss chan 2) "slackernet" [00:90:4c:60:04:00] caps 0x411 bintval 100 erp 0x0 ral0: ieee80211_add_scan: chan 2g min dwell met (8236357 > 8236355) ral0: received beacon from 00:90:4c:60:04:00 rssi 27 [00:90:4c:60:04:00] new beacon on chan 2 (bss chan 2) "slackernet" [00:90:4c:60:04:00] caps 0x411 bintval 100 erp 0x0 ral0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 3 ral0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 4 ral0: received probe_resp from 00:1b:2f:de:86:1e rssi 17 ral0: received beacon from 00:1b:2f:de:86:1e rssi 17 ral0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 5 ral0: received probe_resp from 00:1b:2f:de:86:1e rssi 15 [00:1b:2f:de:86:1e] new probe_resp on chan 5 (bss chan 5) "pipi" [00:1b:2f:de:86:1e] caps 0x431 bintval 100 erp 0x0 ral0: ieee80211_add_scan: chan 5g min dwell met (8236845 > 8236843) ral0: received beacon from 00:1b:2f:de:86:1e rssi 15 [00:1b:2f:de:86:1e] new beacon on chan 5 (bss chan 5) "pipi" [00:1b:2f:de:86:1e] caps 0x431 bintval 100 erp 0x0 ral0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 8 ral0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 9 ral0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 10 ral0: scan_next: chan 10g -> 12g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 12 ral0: scan_next: chan 12g -> 14g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 14 ral0: scan_next: chan 14g -> 149a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 149 ral0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 153 ral0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 157 ral0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 161 ral0: scan_next: chan 161a -> 100a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 100 ral0: scan_next: chan 100a -> 104a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 104 ral0: scan_next: chan 104a -> 108a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 108 ral0: scan_next: chan 108a -> 112a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 112 ral0: scan_next: chan 112a -> 116a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 116 ral0: scan_next: chan 116a -> 120a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 120 ral0: scan_next: chan 120a -> 124a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 124 ral0: scan_next: chan 124a -> 128a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 128 ral0: scan_next: chan 128a -> 132a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 132 ral0: scan_next: chan 132a -> 136a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 136 ral0: scan_next: chan 136a -> 140a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 140 ral0: macaddr bssid chan rssi rate flag wep essid - 00:90:4c:60:04:00 00:90:4cral0: received beacon from 00:90:4c:60:04:00 rssi 27 [00:90:4c:60:04:00] new beacon on chan 2 (bss chan 2) "slackernet" [00:90:4c:60:04:00] caps 0x411 bintval 100 erp 0x0 :60:04:00 2 30 54M ess wep! "slackernet" - 00:1b:2f:de:86:1e 00:1b:2f:de:86:1e 5 16 54M ess wep! "pipi" ral0: ieee80211_add_scan: chan 2g min dwell met (8241192 > 8240968) ral0: scan_next: done, restart [ticks 8241200, dwell min 20 scanend 2155701896] ...and this in an endless loop, of course. But the ifconfig *does* return. When authmode is open, I get exactly the same messages, but ifconfig doesn't return. The last thing it appears to do, according to ktrace, is to read from a socket: ... 2544 ifconfig CALL __sysctl(0xbfbfe2c0,0x6,0,0xbfbfe2d8,0,0) 2544 ifconfig RET __sysctl 0 2544 ifconfig CALL __sysctl(0xbfbfe2c0,0x6,0x8102000,0xbfbfe2d8,0,0) 2544 ifconfig RET __sysctl 0 2544 ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) 2544 ifconfig RET socket 3 2544 ifconfig CALL socket(PF_ROUTE,SOCK_RAW,0) 2544 ifconfig RET socket 4 2544 ifconfig CALL ioctl(0x3,SIOCS80211,0xbfbfe290) 2544 ifconfig RET ioctl 0 2544 ifconfig CALL read(0x4,0xbfbfda90,0x800) and here it hangs, until interrupted. From rpaulo at FreeBSD.org Thu Aug 28 00:30:32 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Aug 28 00:30:39 2008 Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST Message-ID: <20080828002919.GA54169@alpha.local> Hi, We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of new chips, namely those on the Asus Eee PC, MacBooks and other laptops. If you have an Atheros or Atheros based card, I really wanted you to test it. We were unable to test this in several Atheros chipsets, so if you find a regression, please contact me or Sam Leffler (sam@freebsd.org) ASAP. So, please give it a try :-) Unfortuntely, this will only make 7.1 if the release date slips. So, don't expect this to be MFCed any time soon. Thanks, -- Rui Paulo From slawek.zak at gmail.com Thu Aug 28 11:00:16 2008 From: slawek.zak at gmail.com (Slawek Zak) Date: Thu Aug 28 11:00:23 2008 Subject: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address In-Reply-To: <200808251010.m7PAA4Mk018658@freefall.freebsd.org> References: <200808251010.m7PAA4Mk018658@freefall.freebsd.org> Message-ID: <787bbe1c0808280400r7933f520t97f862eb8232ac49@mail.gmail.com> Hey Artis, Thank you. It really works indeeed :) I haven't thought of such a workaround :) Regards, /S On Mon, Aug 25, 2008 at 12:10 PM, Artis Caune wrote: > The following reply was made to PR kern/126714; it has been noted by GNATS. > > From: "Artis Caune" > To: bug-followup@freebsd.org > Cc: slawek.zak@gmail.com > Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address > Date: Mon, 25 Aug 2008 13:05:55 +0300 > > Same for me, but when I rename carp interface to original name, > everything works. > > > > > When you change carp0 name to new_name, ifconfig will: > - announce that carp0 is gone (departure) > - copy new_name to if_xname > - announce that new_name has arrived > > carp check only departure events. > > When you change name of carp interface, mac address also change: > from 00:00:5e:00:01:08 to 70:31:00:00:5e:00 (for me) > > And because new mac address is no longer CARP mac address, > carp_forus() fail, M_PROMISC flag is not cleared and frame is > discarded. > > > > > If you need change names at run time and not in rc.conf, then you > should reinitialize carp interface: > # ifconfig new_name vhid 1 pass testpass 192.168.0.2/24 > or set promisc flag on em0/em1 :) > > btw, don't change name to "carp" or your box will panic. > > p.s. > if you change name to underlying em0/em1/lagg/vlan interface, you > should also reinitialize carp interface or you will see: > carp_input: packet received on non-carp interface: bce0 > > > > > -- > regards, > Artis Caune > > <----. CCNA > <----|==================== > <----' didii FreeBSD > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From randall at lakerest.net Thu Aug 28 11:39:00 2008 From: randall at lakerest.net (Randy Stewart) Date: Thu Aug 28 11:39:07 2008 Subject: A query regarding SCTP congestion control In-Reply-To: <82bdb5ec0807021137m7819153rbc0631ab6f310d0e@mail.gmail.com> References: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> <48060748.1090807@cisco.com> <82bdb5ec0807021137m7819153rbc0631ab6f310d0e@mail.gmail.com> Message-ID: <0ED8CE06-588C-4A04-BE8D-CCD8DA2C945D@lakerest.net> Remember a lot has changed between the book and now. 1) The initial window is now different 2) labc variable may influence how the cwnd responds are just 2 off the top of my head. You also may want to use a local trace buffer (as I mentioned earlier) since turning KTR on really really skew's things time wise.. its a resource pig. We added the local trace buffer for this very reason. Contact me directly if you need guidance on this. Also you may want to pick up the latest update that I just put up on www.sctp.org It gets the 7.0 stack current to 8.0's code.. .and there have been at least 1 CC fix in the last few months.. R On Jul 2, 2008, at 2:37 PM, sazzadur rahman wrote: > Hello, > I need to get SCTP congestion window data for research purpose. I > collected > cwnd data from SCTP sender running on FreeBSD 7.0 machine by using KTR > kernel log. After that, I tried to plot cwnd vs. time and generated > graph. > But I am unable to explain the graph and it is very different > compared to > the graph as shown in the book "Stream Control Transmission Protocol > (SCTP)", a reference guide by Randall R. Stewart, page 187 and TCP > congestion window. An typical entry from the log looks like: > > 749199232185105 Net:0xc7703000 at cwnd_event (SACK) cwnd:25140 > flight:0 pq:0 > atpc:72 needpc:235 (tsn:0,sendcnt:191,strcnt:191) > > I have used 749199232185105 in x axis as time and cwnd:25140 in y > axis. I > have attached the image file of the graph herewith this mail. > >> From the log, I found that cwnd varies very frequently accross >> time. Does > anyone have any idea regarding this issue? > Please let me know if you have any questions further. > > Thanks in advance. > > Best regards, > Md Sazzadur Rahman > Graduate Student, > School of Computer Science, > University of Oklahoma, > Norman, Oklahoma, USA > > Steps for getting kernel log > > ------------------------------------------ > > 1. Add options: > > options KTR > > options KTR_ENTRIES=65536 > > options KTR_MASK=KTR_SUBSYS > > > 2. Recompile kernel > > config CUSTOM_KERNEL_9_6 > > cd ../compile/ CUSTOM_KERNEL_9_6 > > make cleandepend;make depend; > > make all install > > 3. Tried to enable trace point by: > > Sysctl -w "net.inet.sctp.log_level=0x00000004" > > 4. run SCTP sender. > > 5. pull out data: > > Ktrdump ?q ?t ?o file_name > > Prtcwndlog ?l filename > cwnd.txt > > --------------------------------------------------- > > > > On Wed, Apr 16, 2008 at 9:03 AM, Randall Stewart > wrote: > >> Rahman, Md Sazzadur wrote: >> >>> Hi, I would like to get the values of SCTP congestion control >>> algorithm variables (cwnd, ssthresh, flightsize and pba) from any >>> SCTP based application in runtime for research purpose. Does any API >>> exist in SCTP for that? Do I need to dig the SCTP code in kernel to >>> get the values? >>> >> >> There is a socket option to get the cwnd. >> >> However, I think what you really want is some of the researchish >> tracing stuff that SCTP provides. >> >> You can actually get a real time trace of the cwnd/flight etc via the >> various logging functions. >> >> You basically must compile this as an option.. have to go look >> at the options.. >> >> And then you can either use ktrace (which I don't recommend since >> it turns on to much overhead in the kernel) or you can >> use SCTP_LOCAL_TRACE_BUF >> >> This will put it into a piece of memory only for SCTP and >> not turn on all the other ktrace points. >> >> After you enable the logging in your compile you must turn >> on the logging level.. >> >> SCTP_CWND_LOGGING_ENABLE >> >> woudl be my recommendation. >> >> It gives you a real time up/down growth of the cwnd/flight/rwnd >> >> I think I wrote a "how to" somewhere.. let me go look.. >> >> R >> >> >> >>> I will appreciate any help in this regard. >>> >>> Best Regards, Md Sazzadur Rahman Graduate Student, School of >>> Computer >>> Science, University of Oklahoma, Norman, Oklahoma, USA >>> >>> _______________________________________________ freebsd-net@freebsd.orgmailing >>> list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net To >>> unsubscribe, >>> send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >> >> -- >> Randall Stewart >> NSSTG - Cisco Systems Inc. >> 803-345-0369 803-317-4952 (cell) >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ----- Randall Stewart randall@lakerest.net From gavin at FreeBSD.org Thu Aug 28 16:42:58 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Aug 28 16:43:06 2008 Subject: kern/102344: [ipf] Some packets do not pass through network interface Message-ID: <200808281642.m7SGgvqR011299@freefall.freebsd.org> Synopsis: [ipf] Some packets do not pass through network interface State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Aug 28 16:40:54 UTC 2008 State-Changed-Why: Feedback timeout (1 year today). To submitter: if you do still see this issue and can provide the required information, we can reopen the PR. Responsible-Changed-From-To: freebsd-net->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Aug 28 16:40:54 UTC 2008 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=102344 From gavin at FreeBSD.org Thu Aug 28 17:36:56 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Aug 28 17:37:02 2008 Subject: conf/122858: [nsswitch.conf] nsswitch in 7.0 is f*cked up Message-ID: <200808281736.m7SHatd6017017@freefall.freebsd.org> Synopsis: [nsswitch.conf] nsswitch in 7.0 is f*cked up State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Aug 28 17:33:46 UTC 2008 State-Changed-Why: Feedfback timeout (~3 months). Looks like it was a config error, but without feedback we'll never know. Responsible-Changed-From-To: freebsd-net->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Aug 28 17:33:46 UTC 2008 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=122858 From jacoblowens at gmail.com Fri Aug 29 03:18:30 2008 From: jacoblowens at gmail.com (Jacob Owens) Date: Fri Aug 29 03:18:40 2008 Subject: lagg failover not automatic In-Reply-To: <20080813044809.GD58659@cdnetworks.co.kr> References: <20080809082539.GC42339@cdnetworks.co.kr> <20080812013739.GB54362@cdnetworks.co.kr> <20080813044809.GD58659@cdnetworks.co.kr> Message-ID: To resolve the issue, Pyun first had my patch amphy.c , then the dc driver. The DC patch fixed my issue. Here is what i had to do: 1. save attached patch to /tmp 2. #cd /usr/src 3. #patch -p0 < /tmp/dc.patch 4. rebuild/install kernel and reboot. i used instructions from here: http://www.freebsdmadeeasy.com/tutorials/freebsd/recompiling-the-kernel-in-freebsd.php THANK YOU to Pyun YongHyeon and the freebsd-net group for helping me with this issue!!! Save the text below and save as dc.patch. (The first line is 'index: sys/dev/dc......' ,Last line is ' * When the init.....' Index: sys/dev/dc/if_dc.c =================================================================== --- sys/dev/dc/if_dc.c (revision 181654) +++ sys/dev/dc/if_dc.c (working copy) @@ -2868,6 +2868,12 @@ ifp = sc->dc_ifp; mii = device_get_softc(sc->dc_miibus); + /* + * XXX Can cause autonegotiation failure on certain models + * as DC21143 overdrive mii_ticks. + */ + mii_tick(mii); + if (sc->dc_flags & DC_REDUCED_MII_POLL) { if (sc->dc_flags & DC_21143_NWAY) { r = CSR_READ_4(sc, DC_10BTSTAT); @@ -2881,19 +2887,15 @@ sc->dc_link = 0; mii_mediachg(mii); } - if (sc->dc_link == 0) - mii_tick(mii); } else { r = CSR_READ_4(sc, DC_ISR); if ((r & DC_ISR_RX_STATE) == DC_RXSTATE_WAIT && sc->dc_cdata.dc_tx_cnt == 0) { - mii_tick(mii); if (!(mii->mii_media_status & IFM_ACTIVE)) sc->dc_link = 0; } } - } else - mii_tick(mii); + } /* * When the init routine completes, we expect to be able to send On Tue, Aug 12, 2008 at 11:48 PM, Pyun YongHyeon wrote: > > On Tue, Aug 12, 2008 at 08:49:20AM -0500, Jacob Owens wrote: > > pyun, > > > > Thank you! I am not familiar with patching freebsd. i tried: > > > > # patch < amphy.diff > > > > then it asked me to pick a file.i entered: /sys/dev/mii/amphy.c > > > > then i recompiled my kernel. I don't know if the patch was applied > > correctly. either way, it didn't change anything. > > > > Thanks for testing! I've checked dc(4) and link state checking code > in the driver looks questionable. So I made a patch but I don't > know whether it helps or not. The patch can even break establishing > link so you should be very careful before applying the patch and > should not apply the patch if you have no physical acesss to the > hardware. Would you give it a try? > > Note, I'm not familiar with dc(4) and dc(4) supports too many > variants. It seems that each controller needs different workaround > to overcome its hardware limitation. Link state handling seems to > be one of reason why dc(4) didn't periodically invoke link state > check clock. I would be on vacation from Aug 14 for a week so don't > expect quick reply. > > # You can apply the patch with the following command. > 1. save attached patch to /tmp > 2. #cd /usr/src > 3. #patch -p0 < /tmp/dc.patch > 4. rebuild/install kernel and reboot. > > -- > Regards, > Pyun YongHyeon From jlin2918 at yahoo.com Fri Aug 29 03:46:15 2008 From: jlin2918 at yahoo.com (John Lingate) Date: Fri Aug 29 03:46:22 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 Message-ID: <325689.70498.qm@web58308.mail.re3.yahoo.com> This bug was reported around the release of FreeBSD 7, but does not seem to have made any progress. http://bugzilla.quagga.net/show_bug.cgi?id=420 Is this because the sockopt.c.diff patch is correct, which isn't entirely clear from the following comments, or is there some other solution to this problem?? Thanks! From eugen at kuzbass.ru Fri Aug 29 03:59:02 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Aug 29 03:59:10 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 In-Reply-To: <325689.70498.qm@web58308.mail.re3.yahoo.com> References: <325689.70498.qm@web58308.mail.re3.yahoo.com> Message-ID: <20080829035858.GA83708@svzserv.kemerovo.su> On Thu, Aug 28, 2008 at 08:19:32PM -0700, John Lingate wrote: > This bug was reported around the release of FreeBSD 7, but does not seem to have made any progress. > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > Is this because the sockopt.c.diff patch is correct, which isn't entirely clear from the following comments, or is there some other solution to this problem?? Thanks! You should contact with ports/net/quagga maintainer to push temporary patch into Ports Tree until quagga developers settle with something working. This always was most productive way for us. Eugene Grosbein From julian at elischer.org Fri Aug 29 06:56:13 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 29 06:56:22 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 In-Reply-To: <325689.70498.qm@web58308.mail.re3.yahoo.com> References: <325689.70498.qm@web58308.mail.re3.yahoo.com> Message-ID: <48B79D91.7040303@elischer.org> John Lingate wrote: > This bug was reported around the release of FreeBSD 7, but does not seem to have made any progress. > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > Is this because the sockopt.c.diff patch is correct, which isn't > entirely clear from the following comments, or is there some other > solution to this problem? Thanks! the change in quesiton is in the QUAGGA code not in the BSD code. > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From jlin2918 at yahoo.com Fri Aug 29 10:28:34 2008 From: jlin2918 at yahoo.com (John Lingate) Date: Fri Aug 29 10:28:40 2008 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 Message-ID: <886514.39448.qm@web58301.mail.re3.yahoo.com> --- On Thu, 8/28/08, Julian Elischer wrote: From: Julian Elischer Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 To: jlin2918@yahoo.com Cc: freebsd-net@freebsd.org Date: Thursday, August 28, 2008, 11:56 PM John Lingate wrote: > This bug was reported around the release of FreeBSD 7, but does not seem to have made any progress. > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > Is this because the sockopt.c.diff patch is correct, which isn't > entirely clear from the following comments, or is there some other > solution to this problem? Thanks! the change in quesiton is in the QUAGGA code not in the BSD code. Well, obviously.? However, there are also links to changes that can be made to the BSD code, and apparently this whole issue was precipitated by a change to the BSD kernel interface for multicast. There does not appear to be a consensus as to what the correct fix is, and the patch in question has not been integrated on the Quagga end after 9 months.? As best I can make out, it seems like the sockopt.c.diff patch (for Quagga) might be correct, but then it is not clear why this isn't being included with Quagga. It seemed reasonable to ask for an opinion from people who might understand the code, history, RFC's, and nuances better than I.? That's why I asked about correctness of the patch, or whether another fix was more appropriate.? A patch to the Quagga code isn't necessarily correct just because it's a patch to the Quagga code, just as a patch to FreeBSD isn't necessarily correct just because it's a patch to FreeBSD. From rpaulo at FreeBSD.org Fri Aug 29 10:53:36 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Fri Aug 29 10:53:43 2008 Subject: TCP Anomaly Detector project Message-ID: <20080829105228.GD1468@alpha.local> Hi, Now that tcpad (TCP Anomaly Detector) is, at least, barely usable, I decided to talk about it. First of all, the wiki page http://wiki.freebsd.org/RuiPaulo/TCPAnomaly talks all about the rationale behind it and how it works. For your convenience, I'll post it here too: "tcpad listens for TCP packets on the wire and builds a virtual TCP stack for each TCP endpoint. This means that, for example, if you run tcpad on a gateway, tcpad will monitor every connection between the hosts behind the gateway, the hosts reachable by the gateway (usually the Internet) and the connections to/from the gateway itself. After the initial packets, tcpad has built a virtual TCP stack for each endpoint. [...] Along with this virtual TCP stack, tcpad monitors for abnormalities within the transmitted packets. For further inspection, tcpad keeps every TCP packet in memory and then dumps it into a pcap file. If you suspect a bug in a TCP stack or tcpad itself, you can boot tcpdump(1) or wireshark(1) and see the packet stream for yourself." Now, a warning about it: tcpad is still in pre-beta phase, so if you want to try it out, please be aware that it may crash, may hurt a butterfly or just make your life miserable. In other words, no warranty ;-) If you have great interest in TCP, this is the project you've been looking for to help. ;-) I'm pretty sure that I need a couple more hands to make this project rock solid in the short term, so your help is very appreciated. On the wiki page you should find every information to get you working with tcpad. If you need more help, you can contact me. Thanks for reading. -- Rui Paulo From rizzo at iet.unipi.it Fri Aug 29 16:26:09 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Aug 29 16:26:16 2008 Subject: Small patch to multicast code... In-Reply-To: <48B4A62D.3080300@freebsd.org> References: <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> Message-ID: <20080829162853.GB46693@onelab2.iet.unipi.it> On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote: > gnn@freebsd.org wrote: > >At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), > >Bjoern A. Zeeb wrote: > > > >>On Tue, 26 Aug 2008, George V. Neville-Neil wrote: > >> > >>Hi, > >> > >> > >>>At Mon, 25 Aug 2008 21:40:38 +0200, > >>>John Hay wrote: > >>> > >>>>I have tried it and it does fix my problem. RIP2 over multicast works > >>>>again. :-) > >>>> > >>>Good to hear. I'm waiting on a bit more feedback but I think I'll be > >>>checking this in soon, with a big comment talking about the > >>>performance implications etc. > >>> > >>So wait a second; what was the m_pullup vs. m_dup thing? Has anyone > >>actually tried that? I mean using a sledgehammer if a mitten would be > >>enough is kind of .. uhm. You get it. > >> > > > >Perhaps I'm confused, I've been off dealing with other issues for a > >few days, but m_pullup doesn't make a copy of the packet or its > >fields, only makes sure that it's contiguous in memory. Am I wrong in > >that? > > > >Since the bug is that two pieces of code modify the same data, in ways > >that interfere, I'm not sure how we can avoid making a copy. It might > >be nice to limit the copy, but we'd still need two copies, one for the > >loopback device and one for the real device. > > > > > pull the headers up. copy just the headers. no deep copy. and to be more explicit - the result of m_pullup is that the number of bytes specified as m_pullup argument are in a private piece of memory -- the 'data' region within the mbuf -- so you can freely play with them without trouble. That is why i suggested to just increase the argument to m_pullup by the size of the udp header so one can overwrite the checksum within the mbuf without touching the shared part in the cluster (if any). cheers luigi From sam at freebsd.org Fri Aug 29 16:32:11 2008 From: sam at freebsd.org (Sam Leffler) Date: Fri Aug 29 16:32:17 2008 Subject: Small patch to multicast code... In-Reply-To: <20080829162853.GB46693@onelab2.iet.unipi.it> References: <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> Message-ID: <48B8248A.3060103@freebsd.org> Luigi Rizzo wrote: > On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote: > >> gnn@freebsd.org wrote: >> >>> At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), >>> Bjoern A. Zeeb wrote: >>> >>> >>>> On Tue, 26 Aug 2008, George V. Neville-Neil wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>>> At Mon, 25 Aug 2008 21:40:38 +0200, >>>>> John Hay wrote: >>>>> >>>>> >>>>>> I have tried it and it does fix my problem. RIP2 over multicast works >>>>>> again. :-) >>>>>> >>>>>> >>>>> Good to hear. I'm waiting on a bit more feedback but I think I'll be >>>>> checking this in soon, with a big comment talking about the >>>>> performance implications etc. >>>>> >>>>> >>>> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone >>>> actually tried that? I mean using a sledgehammer if a mitten would be >>>> enough is kind of .. uhm. You get it. >>>> >>>> >>> Perhaps I'm confused, I've been off dealing with other issues for a >>> few days, but m_pullup doesn't make a copy of the packet or its >>> fields, only makes sure that it's contiguous in memory. Am I wrong in >>> that? >>> >>> Since the bug is that two pieces of code modify the same data, in ways >>> that interfere, I'm not sure how we can avoid making a copy. It might >>> be nice to limit the copy, but we'd still need two copies, one for the >>> loopback device and one for the real device. >>> >>> >>> >> pull the headers up. copy just the headers. no deep copy. >> > > and to be more explicit - the result of m_pullup is that > the number of bytes specified as m_pullup argument are in > a private piece of memory -- the 'data' region within the mbuf -- so > you can freely play with them without trouble. > > That is why i suggested to just increase the argument to m_pullup > by the size of the udp header so one can overwrite the checksum > within the mbuf without touching the shared part in the cluster > (if any). > Hmm, never considered the m_pullup guaranteed a private copy (but I see it in the code). The original semantics were just that the data was contiguous. Sam From rizzo at iet.unipi.it Fri Aug 29 16:38:59 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Aug 29 16:39:11 2008 Subject: Small patch to multicast code... In-Reply-To: <48B8248A.3060103@freebsd.org> References: <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> Message-ID: <20080829164145.GA47030@onelab2.iet.unipi.it> On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: > Luigi Rizzo wrote: ... > >and to be more explicit - the result of m_pullup is that > >the number of bytes specified as m_pullup argument are in > >a private piece of memory -- the 'data' region within the mbuf -- so > >you can freely play with them without trouble. > > > >That is why i suggested to just increase the argument to m_pullup > >by the size of the udp header so one can overwrite the checksum > >within the mbuf without touching the shared part in the cluster > >(if any). > > > > Hmm, never considered the m_pullup guaranteed a private copy (but I see > it in the code). The original semantics were just that the data was > contiguous. funny, i thought the guarantee of a writable copy was also part of the original semantics :) cheers luigi From Michael.Tuexen at lurchi.franken.de Fri Aug 29 19:05:07 2008 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Aug 29 19:05:13 2008 Subject: Kernel Panic in SCTP In-Reply-To: <006e01c90462$339fb320$0a2118d8@engineering01> References: <006e01c90462$339fb320$0a2118d8@engineering01> Message-ID: Hi Joe, are you able to provide enough information such that I can reproduce this problem? Best regards Michael On Aug 22, 2008, at 4:20 PM, Joseph Mays wrote: > Hello. > > We've recently written an extensive software system that uses SCTP > as a critical component. We've started to run into an issue where > the box kenel panics after throwing an error message from > sctp_timer.c that says "Our list is out of order? Out of order > list". Can anyone here shed light on what's going on, or give us a > clue how to debug this? > > http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 > > Joe Mays > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From gnn at freebsd.org Fri Aug 29 19:17:30 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Fri Aug 29 19:17:36 2008 Subject: Small patch to multicast code... In-Reply-To: <20080829162853.GB46693@onelab2.iet.unipi.it> References: <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> Message-ID: At Fri, 29 Aug 2008 18:28:53 +0200, Luigi Rizzo wrote: > > and to be more explicit - the result of m_pullup is that > the number of bytes specified as m_pullup argument are in > a private piece of memory -- the 'data' region within the mbuf -- so > you can freely play with them without trouble. > > That is why i suggested to just increase the argument to m_pullup > by the size of the udp header so one can overwrite the checksum > within the mbuf without touching the shared part in the cluster > (if any). I tried various versions of that, but then I noticed that I also had to save out the pkthdr structure as well. Did you come up with a faster workable patch? For now I'm going to commit the patch I sent originally. Best, George From marius at alchemy.franken.de Fri Aug 29 20:55:24 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Fri Aug 29 20:55:30 2008 Subject: lagg failover not automatic In-Reply-To: References: <20080809082539.GC42339@cdnetworks.co.kr> <20080812013739.GB54362@cdnetworks.co.kr> <20080813044809.GD58659@cdnetworks.co.kr> Message-ID: <20080829203537.GA83446@alchemy.franken.de> On Thu, Aug 28, 2008 at 10:18:28PM -0500, Jacob Owens wrote: > To resolve the issue, Pyun first had my patch amphy.c , then the dc driver. > The DC patch fixed my issue. Here is what i had to do: > > 1. save attached patch to /tmp > 2. #cd /usr/src > 3. #patch -p0 < /tmp/dc.patch > 4. rebuild/install kernel and reboot. i used instructions from here: > http://www.freebsdmadeeasy.com/tutorials/freebsd/recompiling-the-kernel-in-freebsd.php > > THANK YOU to Pyun YongHyeon and the freebsd-net group for helping me with > this issue!!! > > Save the text below and save as dc.patch. (The first line is 'index: > sys/dev/dc......' ,Last line is ' * When the init.....' > > Index: sys/dev/dc/if_dc.c > =================================================================== > --- sys/dev/dc/if_dc.c (revision 181654) > +++ sys/dev/dc/if_dc.c (working copy) > @@ -2868,6 +2868,12 @@ > ifp = sc->dc_ifp; > mii = device_get_softc(sc->dc_miibus); > > + /* > + * XXX Can cause autonegotiation failure on certain models > + * as DC21143 overdrive mii_ticks. > + */ > + mii_tick(mii); > + > if (sc->dc_flags & DC_REDUCED_MII_POLL) { > if (sc->dc_flags & DC_21143_NWAY) { > r = CSR_READ_4(sc, DC_10BTSTAT); > @@ -2881,19 +2887,15 @@ > sc->dc_link = 0; > mii_mediachg(mii); > } > - if (sc->dc_link == 0) > - mii_tick(mii); > } else { > r = CSR_READ_4(sc, DC_ISR); > if ((r & DC_ISR_RX_STATE) == DC_RXSTATE_WAIT && > sc->dc_cdata.dc_tx_cnt == 0) { > - mii_tick(mii); > if (!(mii->mii_media_status & IFM_ACTIVE)) > sc->dc_link = 0; > } > } > - } else > - mii_tick(mii); > + } > > /* > * When the init routine completes, we expect to be able to send For the records, a more appropriate fix (the above patch just lets dc(4) bypasse the DC_REDUCED_MII_POLL handling completely) was commited as r182461. Marius From linimon at FreeBSD.org Fri Aug 29 22:12:37 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Aug 29 22:12:48 2008 Subject: kern/126945: [carp] CARP interface destruction with ifconfig destroy causes kernel panic Message-ID: <200808292212.m7TMCbnC020015@freefall.freebsd.org> Old Synopsis: CARP interface destruction with ifconfig destroy causes kernel panic New Synopsis: [carp] CARP interface destruction with ifconfig destroy causes kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 29 22:12:16 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126945 From thompsa at FreeBSD.org Fri Aug 29 23:03:53 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Fri Aug 29 23:03:59 2008 Subject: Small patch to multicast code... In-Reply-To: <20080829164145.GA47030@onelab2.iet.unipi.it> References: <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> <20080829164145.GA47030@onelab2.iet.unipi.it> Message-ID: <20080829223546.GG98483@citylink.fud.org.nz> On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote: > On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: > > Luigi Rizzo wrote: > ... > > >and to be more explicit - the result of m_pullup is that > > >the number of bytes specified as m_pullup argument are in > > >a private piece of memory -- the 'data' region within the mbuf -- so > > >you can freely play with them without trouble. > > > > > >That is why i suggested to just increase the argument to m_pullup > > >by the size of the udp header so one can overwrite the checksum > > >within the mbuf without touching the shared part in the cluster > > >(if any). > > > > > > > Hmm, never considered the m_pullup guaranteed a private copy (but I see > > it in the code). The original semantics were just that the data was > > contiguous. > > funny, i thought the guarantee of a writable copy was also part > of the original semantics :) The bridge code does a deep copy of the packet for each interface it broadcasts on due the firewall code modifying the headers. It sounds like this should just be a copy+pullup instead. Andrew From sam at freebsd.org Sat Aug 30 04:35:16 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Aug 30 04:35:23 2008 Subject: Small patch to multicast code... In-Reply-To: <20080829223546.GG98483@citylink.fud.org.nz> References: <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> <20080829164145.GA47030@onelab2.iet.unipi.it> <20080829223546.GG98483@citylink.fud.org.nz> Message-ID: <48B8CE01.6010604@freebsd.org> Andrew Thompson wrote: > On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote: > >> On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: >> >>> Luigi Rizzo wrote: >>> >> ... >> >>>> and to be more explicit - the result of m_pullup is that >>>> the number of bytes specified as m_pullup argument are in >>>> a private piece of memory -- the 'data' region within the mbuf -- so >>>> you can freely play with them without trouble. >>>> >>>> That is why i suggested to just increase the argument to m_pullup >>>> by the size of the udp header so one can overwrite the checksum >>>> within the mbuf without touching the shared part in the cluster >>>> (if any). >>>> >>>> >>> Hmm, never considered the m_pullup guaranteed a private copy (but I see >>> it in the code). The original semantics were just that the data was >>> contiguous. >>> >> funny, i thought the guarantee of a writable copy was also part >> of the original semantics :) >> > > The bridge code does a deep copy of the packet for each interface it > broadcasts on due the firewall code modifying the headers. It sounds > like this should just be a copy+pullup instead. > > I'd not do that. I think there are paths that assume the deep copy. Right now the network code is very poor honoring read-only-ness of mbuf chains. To get this right we need to do a good audit. I know I hit issues when doing some tricks w/ marking rx buffers read-only to avoid cache flushes. netbsd trys to be more pedantic but still has problems too. Sam From rwatson at FreeBSD.org Sat Aug 30 09:59:31 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 30 09:59:37 2008 Subject: Small patch to multicast code... In-Reply-To: <48B8CE01.6010604@freebsd.org> References: <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> <20080829164145.GA47030@onelab2.iet.unipi.it> <20080829223546.GG98483@citylink.fud.org.nz> <48B8CE01.6010604@freebsd.org> Message-ID: On Fri, 29 Aug 2008, Sam Leffler wrote: >> The bridge code does a deep copy of the packet for each interface it >> broadcasts on due the firewall code modifying the headers. It sounds like >> this should just be a copy+pullup instead. > > I'd not do that. I think there are paths that assume the deep copy. Right > now the network code is very poor honoring read-only-ness of mbuf chains. > To get this right we need to do a good audit. I know I hit issues when > doing some tricks w/ marking rx buffers read-only to avoid cache flushes. > netbsd trys to be more pedantic but still has problems too. This strikes me as an extremely tricky thing to get right as bugs manifest in very subtle ways. The IP output path makes lots of assumptions about being able to continue to write to outgoing headers for the purposes of deferred checksum calculation, NAT, IPSEC, fragmentation, encapsulation, etc. IP multicast loopback is just one of the rare edge cases where, if exercised, we currently deterministically discover this, but presumably there's more to come as parallelism continues to increase. Robert N M Watson Computer Laboratory University of Cambridge From maddog2k at maddog2k.net Sat Aug 30 14:04:27 2008 From: maddog2k at maddog2k.net (Wouter de Jong) Date: Sat Aug 30 14:04:34 2008 Subject: IPv6 on Carp interfaces not supported ? Message-ID: <001c01c90aa9$3b069e10$6ac8a8c0@lan.dejong.biz> Hi, Is IPv6 supported on Carp interfaces on FreeBSD 7.0-RELEASE ? I've spent quite some time to get it working... but I don't succeed...the carp-address will never ping nor route. What do I do ? Basic IPv6 : machine1: sysctl -w net.inet6.ip6.forwarding=1 ifconfig bge0 inet6 2001:a:b:c::2/64 route -n add -inet6 default 2001:a:b:c::fffe machine2: sysctl -w net.inet6.ip6.forwarding=1 ifconfig bge0 inet6 2001:a:b:c::3/64 route -n add -inet6 default 2001:a:b:c::fffe Both addresses are pingable, and when I use either of them on other machines as gateway, they route fine. So now carp : machine1: ifconfig carp1 create ifconfig carp1 vhid 30 pass mekmitasdigoat ifconfig carp1 inet6 2001:a:b:c::1/64 machine2: ifconfig carp1 create ifconfig carp1 vhid 30 advskew 100 pass mekmitasdigoat ifconfig carp1 inet6 2001:a:b:c::1/64 carp goes succesfully to master on one machine, and to backup on another. However..... i can't ping the virtual address 2001:a:b:c::1 from either machine1 or machine2. Nor can other PC's ping it or use it as a gateway. Am i forgetting something ? IPv4 carp works as a charm on these machines.... Regards, Wouter de Jong From marin.bek at gmail.com Sun Aug 31 15:03:27 2008 From: marin.bek at gmail.com (Marin Bek) Date: Sun Aug 31 15:03:34 2008 Subject: 7.0 ipfw nat confusion Message-ID: Hello, I've been using ipfw + natd successfully before, but now have problems using the implemented nat functionality, though I find it a great improvement. Simply NAT-in internal network to external is working flawlessly by just: ipfw nat 1 config if $extern ipfw add 100 nat 1 log ip from any to any But when I add some redirect_port to configuration, it doesn't work. External->internal translation failes (tcpdump unreachable...). Command is accepted, general NAT works fine, but ports are not forwarded. So, I did the following: ipfw nat 1 config if $internal redirect_port tcp 192.168.5.2:5000 5000 redirect_port udp 192.168.5.2:5000 5000 where 192.168.5.X is the internal network, and $internal the NIC connected to this interface. Starting a simple tcp/udp application on one of the internal clients (5.2) on port 5000, and testing it on that computer is successful. But when I attempt to connect to the service via 5.1 (the router internal IP) - no luck. tcpdump-ing gives "192.168.5.1 > 192.168.5.2: ICMP 192.168.5.1 udp port 5000 unreachable" Am I missing something? Should I add some extra rules to the ipfw (it is set to allow_all)? Similar setup worked fine with natd+ipfw. Thanks... From freebsd-net at blacquiere.nl Sun Aug 31 15:07:53 2008 From: freebsd-net at blacquiere.nl (Robert Blacquiere) Date: Sun Aug 31 15:08:01 2008 Subject: Weird tunneling issue Message-ID: <20080831145427.GG4324@shellvm.blacquiere.nl> Hi, I'me having some strange issues with openvpn when a gre tunnel is active. When reverting to gif tunneling the problem does not occur. What happens. I setup a openvpn tunnel to a acces server with a gre tunnel active. Setup of the openvpn tunnel succeeds ant have connection. After a view seconds, between 10 and 60, the openvpn session gets a SIGUSR1 on the client site. Over the gre tunnel is a link to a radius server for authentication of the openvpn clients. When i use a gif tunnel between the server and the radius server, this does not happen. To make it more strange if i have a gre tunnel to some other host active and have the gif tunnel between the access and radius server, the connection (openvpn) is rock stable. gre1: flags=9051 metric 0 mtu 1476 tunnel inet $ip_accessserver --> $ip_radiusserver inet 10.A.A.240 --> 10.A.A.241 netmask 0xffffffff gif1: flags=8051 metric 0 mtu 1280 tunnel inet $ip_accessserver --> $ip_radiusserver inet 10.A.A.102 --> 10.A.A.101 netmask 0xffffffff tap0: flags=8843 metric 0 mtu 1500 ether 00:bd:fa:5f:c6:00 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 Opened by PID 28781 I'me running FreeBSD 7.0-Stable of end jul. on a amd64. Any clues how i could attack this problem or find a solution? Regards Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there!