From ady at freebsd.ady.ro Sun Mar 1 03:01:19 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Mar 1 03:01:26 2009 Subject: crazy network problem -- sleep? In-Reply-To: <49AA352E.5060803@gmail.com> References: <49AA352E.5060803@gmail.com> Message-ID: <78cb3d3f0903010301y5d8bbaf9r4a285653688d74ca@mail.gmail.com> Hi, 2009/3/1 stutiredboy > hi,all: > > recently , we found a problem that , some server which with FreeBSD > 6.2 may stop networking after > days of services, it is so difficulty express this status, e, such as > sleep? i can not ping this server, tracert is also > failure, and other services ,network/server seems to be down... but > while i insert the keyboard/mouse/crt in , > everything is ok, such as a ring to call the system to wake-up... no > errors found in dmesg or /var/log/messages, > such as nothing happened...orz?our unlimit args as follow: > > cputime unlimited > filesize unlimited > datasize 2088152 kbytes > stacksize 65536 kbytes > coredumpsize unlimited > memoryuse unlimited > vmemoryuse unlimited > descriptors 655000 > memorylocked unlimited > maxproc 5547 > sbsize unlimited > > plz give me some suggestion to trace the problem or solve it . thanks a > lot ! > First you need to check whether packets are reaching the system and whether the response packets are leaving it with tcpdump(8) on the appropriate interface. If you see the packets coming but not coming out then you need to check the status of your TCP/IP stack -- e.g. post the output of "netstat -m" and "netstat -s". Also check dmesg output for any errors. If you are using firewall(s) (ipfw/ipfilter/pf) then check the rules and the firewall states status; try temporarily disabling the firewall (ipfw disable firewall / ipf -D / pfctl -d) and check whether your system becomes reachable. Check CPU load, interrupts, packet stats (systat -vmstat / systat -ifstat). Regards, Adrian Penisoara EnterpriseBSD From stutiredboy at gmail.com Sun Mar 1 03:41:06 2009 From: stutiredboy at gmail.com (stutiredboy) Date: Sun Mar 1 03:41:13 2009 Subject: crazy network problem -- sleep? In-Reply-To: <78cb3d3f0903010301y5d8bbaf9r4a285653688d74ca@mail.gmail.com> References: <49AA352E.5060803@gmail.com> <78cb3d3f0903010301y5d8bbaf9r4a285653688d74ca@mail.gmail.com> Message-ID: <49AA744D.8060407@gmail.com> Adrian Penisoara ??: > Hi, > > 2009/3/1 stutiredboy > > > hi,all: > > recently , we found a problem that , some server which with FreeBSD > 6.2 may stop networking after > days of services, it is so difficulty express this status, e, such as > sleep? i can not ping this server, tracert is also > failure, and other services ,network/server seems to be down... but > while i insert the keyboard/mouse/crt in , > everything is ok, such as a ring to call the system to wake-up... no > errors found in dmesg or /var/log/messages, > such as nothing happened...orz?our unlimit args as follow: > > cputime unlimited > filesize unlimited > datasize 2088152 kbytes > stacksize 65536 kbytes > coredumpsize unlimited > memoryuse unlimited > vmemoryuse unlimited > descriptors 655000 > memorylocked unlimited > maxproc 5547 > sbsize unlimited > > plz give me some suggestion to trace the problem or solve it . > thanks a > lot ! > > > First you need to check whether packets are reaching the system and > whether the response packets are leaving it with tcpdump(8) on the > appropriate interface. > > If you see the packets coming but not coming out then you need to > check the status of your TCP/IP stack -- e.g. post the output of > "netstat -m" and "netstat -s". Also check dmesg output for any errors. > > If you are using firewall(s) (ipfw/ipfilter/pf) then check the rules > and the firewall states status; try temporarily disabling the firewall > (ipfw disable firewall / ipf -D / pfctl -d) and check whether your > system becomes reachable. > > Check CPU load, interrupts, packet stats (systat -vmstat / systat > -ifstat). > > Regards, > Adrian Penisoara > EnterpriseBSD hi, thank you for your help, i can only ssh to the system, so while the network is down, i can not login in yes, we have ipfw on , these rules have used a long time, and many other severs do not have this problem, this sistutation happened scarce, in different machine rooms, different isps, different servers, such as hp\dell. while the network usable, the cpu and system load is normal, i have checked dmesg and syslog, nothing special found , where our colleague in machine room insert the keyboard or mouse in ,then the network recover , it is so difficult to catch the ouput of tcpdump or other messages form netstat , the moment you have the keyboard connected , the network recover... thanks very much ! From rizzo at iet.unipi.it Sun Mar 1 07:41:33 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sun Mar 1 07:41:40 2009 Subject: spliting kernel ipfw source ? (also involves sctp) Message-ID: <20090301153010.GA58942@onelab2.iet.unipi.it> Hi, I am planning to split netinet/ip_fw2.c in a number of smaller files to make it more manageable, and while i do this I would also like to move the files related to ipfw2 (namely ip_fw*c) to a better place. Any objection to moving them to sys/netinet/ipfw2 ? Also, I can't help noticing that sys/netinet/ contains 36 files related to sctp -- wouldn't it be the case to move them (perhaps with the exception of the userland headers) to a separate subdirectory ? (I know the same reasoning would apply to tcp, which has 23 files, but the issue here is that there is 25 years of userland code expecting the tcp headers in netinet/ and moving them would be a nightmare for ports...) cheers luigi From ed at 80386.nl Sun Mar 1 08:18:30 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Mar 1 08:18:37 2009 Subject: Making Netgraph compile with LLVM Message-ID: <20090301161827.GR19161@hoeg.nl> Hello all, It turns out Netgraph uses a language construct that is only allowed with GCC, but not with LLVM. According to the specs, LLVM's behaviour is correct. It is not allowed to do this: struct a { struct { int i; char j[]; } b; char k[20]; }; error: variable sized type 'b' must be at end of struct or class Diane Bruce and I thought this patch should solve this issue: http://80386.nl/pub/ng.diff Yes, I know, the solution isn't really elegant, but I think this is the only way to do this safely. Diane and I also compared the output of objdump and they seem to be equivalent, except for some reordering. Objections before I commit this to SVN? -- 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/20090301/8e4a4c55/attachment.pgp From sam at freebsd.org Sun Mar 1 10:15:46 2009 From: sam at freebsd.org (Sam Leffler) Date: Sun Mar 1 10:15:57 2009 Subject: spliting kernel ipfw source ? (also involves sctp) In-Reply-To: <20090301153010.GA58942@onelab2.iet.unipi.it> References: <20090301153010.GA58942@onelab2.iet.unipi.it> Message-ID: <49AAC849.9060105@freebsd.org> Luigi Rizzo wrote: > Hi, > I am planning to split netinet/ip_fw2.c in a number of smaller files > to make it more manageable, and while i do this I would also like > to move the files related to ipfw2 (namely ip_fw*c) to a better place. > Any objection to moving them to sys/netinet/ipfw2 ? > > Also, I can't help noticing that sys/netinet/ contains 36 files > related to sctp -- wouldn't it be the case to move them > (perhaps with the exception of the userland headers) > to a separate subdirectory ? > > (I know the same reasoning would apply to tcp, which has 23 files, > but the issue here is that there is 25 years of userland code expecting > the tcp headers in netinet/ and moving them would be a > nightmare for ports...) > I think sctp belongs in it's own directory. I'd vote for just ipfw; the "2" was an artifact of previous code. Sam From ady at freebsd.ady.ro Sun Mar 1 11:10:13 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Mar 1 11:10:20 2009 Subject: crazy network problem -- sleep? In-Reply-To: <49AA744D.8060407@gmail.com> References: <49AA352E.5060803@gmail.com> <78cb3d3f0903010301y5d8bbaf9r4a285653688d74ca@mail.gmail.com> <49AA744D.8060407@gmail.com> Message-ID: <78cb3d3f0903011110nb13791dk5aa5e1d174c1e063@mail.gmail.com> Hi, 2009/3/1 stutiredboy > Adrian Penisoara ??: > > Hi, > > > > 2009/3/1 stutiredboy > > > > > > hi,all: > > > > recently , we found a problem that , some server which with FreeBSD > > 6.2 may stop networking after > > days of services, it is so difficulty express this status, e, such as > > sleep? i can not ping this server, tracert is also > > failure, and other services ,network/server seems to be down... but > > while i insert the keyboard/mouse/crt in , > > everything is ok, such as a ring to call the system to wake-up... no > > errors found in dmesg or /var/log/messages, > > such as nothing happened...orz?our unlimit args as follow: > > > > cputime unlimited > > filesize unlimited > > datasize 2088152 kbytes > > stacksize 65536 kbytes > > coredumpsize unlimited > > memoryuse unlimited > > vmemoryuse unlimited > > descriptors 655000 > > memorylocked unlimited > > maxproc 5547 > > sbsize unlimited > > > > plz give me some suggestion to trace the problem or solve it . > > thanks a > > lot ! > > > > > > First you need to check whether packets are reaching the system and > > whether the response packets are leaving it with tcpdump(8) on the > > appropriate interface. > > > > If you see the packets coming but not coming out then you need to > > check the status of your TCP/IP stack -- e.g. post the output of > > "netstat -m" and "netstat -s". Also check dmesg output for any errors. > > > > If you are using firewall(s) (ipfw/ipfilter/pf) then check the rules > > and the firewall states status; try temporarily disabling the firewall > > (ipfw disable firewall / ipf -D / pfctl -d) and check whether your > > system becomes reachable. > > > > Check CPU load, interrupts, packet stats (systat -vmstat / systat > > -ifstat). > > > > Regards, > > Adrian Penisoara > > EnterpriseBSD > hi, thank you for your help, i can only ssh to the system, so while the > network is down, i can not login in > > yes, we have ipfw on , these rules have used a long time, and many other > severs do not have this problem, > > this sistutation happened scarce, in different machine rooms, different > isps, different servers, such as hp\dell. > > while the network usable, the cpu and system load is normal, i have > checked dmesg and syslog, nothing > > special found , where our colleague in machine room insert the keyboard > or mouse in ,then the network > > recover , it is so difficult to catch the ouput of tcpdump or other > messages form netstat , the moment you > > have the keyboard connected , the network recover... thanks very much ! You mean that once you plugin a keyboard the machine recovers ? That's weird. What if you leave the keyboard connected all the time ? Try to attach one of the machines which reproduces the problem to a KVM switch (Keyboard/Video/Mouse switcher). If you are able to reproduce again the problem then you might have more chances to catch it. Regards, Adrian. From julian at elischer.org Sun Mar 1 13:40:57 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Mar 1 13:41:03 2009 Subject: spliting kernel ipfw source ? (also involves sctp) In-Reply-To: <20090301153010.GA58942@onelab2.iet.unipi.it> References: <20090301153010.GA58942@onelab2.iet.unipi.it> Message-ID: <49AAFD92.105@elischer.org> Luigi Rizzo wrote: > Hi, > I am planning to split netinet/ip_fw2.c in a number of smaller files > to make it more manageable, and while i do this I would also like > to move the files related to ipfw2 (namely ip_fw*c) to a better place. > Any objection to moving them to sys/netinet/ipfw2 ? > > Also, I can't help noticing that sys/netinet/ contains 36 files > related to sctp -- wouldn't it be the case to move them > (perhaps with the exception of the userland headers) > to a separate subdirectory ? for that matter it would be nice to put ALL teh protocols in their own subdirectories. tcp related files are also multiplying, with things like syncookies etc. > > (I know the same reasoning would apply to tcp, which has 23 files, > but the issue here is that there is 25 years of userland code expecting > the tcp headers in netinet/ and moving them would be a > nightmare for ports...) > > cheers > luigi > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From julian at elischer.org Sun Mar 1 13:45:58 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Mar 1 13:46:05 2009 Subject: Making Netgraph compile with LLVM In-Reply-To: <20090301161827.GR19161@hoeg.nl> References: <20090301161827.GR19161@hoeg.nl> Message-ID: <49AAFF4F.6010400@elischer.org> Ed Schouten wrote: > Hello all, > > It turns out Netgraph uses a language construct that is only allowed > with GCC, but not with LLVM. According to the specs, LLVM's behaviour is > correct. It is not allowed to do this: > > struct a { > struct { > int i; > char j[]; > } b; > char k[20]; > }; > > error: variable sized type 'b' must be at end of struct or class not sure wher eyou are seeing this. the examples you fix don't seem to be nested structs.. what is the outer struct? > > Diane Bruce and I thought this patch should solve this issue: > > http://80386.nl/pub/ng.diff > > Yes, I know, the solution isn't really elegant, but I think this is the > only way to do this safely. Diane and I also compared the output of > objdump and they seem to be equivalent, except for some reordering. > > Objections before I commit this to SVN? > From barney_cordoba at yahoo.com Sun Mar 1 13:57:54 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Sun Mar 1 13:58:01 2009 Subject: rate limiting mail server In-Reply-To: <49A38202.7010506@amplex.net> Message-ID: <407473.34181.qm@web63901.mail.re1.yahoo.com> --- On Tue, 2/24/09, Mark E Doner wrote: > From: Mark E Doner > Subject: rate limiting mail server > To: freebsd-isp@freebsd.org > Date: Tuesday, February 24, 2009, 12:13 AM > Greetings, > I am running a fairly large mail server, FreeBSD, of > course. It is predominantly for residential customers, so > educating the end users to not fall for the scams is never > going to happen. Whenever we have a customer actually hand > over their login credentials, we quickly see a huge flood of > inbound connections from a small handful of IP addresses on > ports 25 and 587, all authenticate as whatever customer fell > for the scam du jour, and of course, load goes through the > roof as I get a few thousand extra junk messages to process > in a matter of minutes. > > Thinking about using PF to rate limit inbound connections, > stuff the hog wild connection rates into a table and drop > them quickly. My question is, I know how to do this, PF > syntax is easy, but has anyone ever tried this? How many new > connections per minute from a single source are acceptable, > and what is blatantly malicious? And, once I have determined > that, how long should I leave the offenders in the > blocklist? > > Any thoughts appreciated, > Mark A better strategy is to identify the spam source and just block it. The way we do it is that we look for unusual domain traffic from a single source and then block the source. I haven't figured out a way to automate it yet but it works very well. You don't really want to rate limit mail spammers. They go on for many hours . BC From ed at 80386.nl Sun Mar 1 14:00:26 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Mar 1 14:00:33 2009 Subject: Making Netgraph compile with LLVM In-Reply-To: <49AAFF4F.6010400@elischer.org> References: <20090301161827.GR19161@hoeg.nl> <49AAFF4F.6010400@elischer.org> Message-ID: <20090301220024.GU19161@hoeg.nl> * Julian Elischer wrote: > Ed Schouten wrote: >> Hello all, >> >> It turns out Netgraph uses a language construct that is only allowed >> with GCC, but not with LLVM. According to the specs, LLVM's behaviour is >> correct. It is not allowed to do this: >> >> struct a { >> struct { >> int i; >> char j[]; >> } b; >> char k[20]; >> }; >> >> error: variable sized type 'b' must be at end of struct or class > > not sure wher eyou are seeing this. > > the examples you fix don't seem to be nested structs.. what is the > outer struct? In the Netgraph code, this isn't done in a single declaration, but there are several structs that (indirectly) nest pppoe_tags. An example is ng_pppoe.c, line 1179: struct { struct pppoe_tag hdr; union uniq data; } __packed uniqtag; It turns out that this is not valid: http://llvm.org/bugs/show_bug.cgi?id=3671 -- 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/20090301/85160b07/attachment.pgp From julian at elischer.org Sun Mar 1 14:10:20 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Mar 1 14:10:38 2009 Subject: Making Netgraph compile with LLVM In-Reply-To: <20090301220024.GU19161@hoeg.nl> References: <20090301161827.GR19161@hoeg.nl> <49AAFF4F.6010400@elischer.org> <20090301220024.GU19161@hoeg.nl> Message-ID: <49AB07CA.4070607@elischer.org> Ed Schouten wrote: > * Julian Elischer wrote: >> Ed Schouten wrote: >>> Hello all, >>> >>> It turns out Netgraph uses a language construct that is only allowed >>> with GCC, but not with LLVM. According to the specs, LLVM's behaviour is >>> correct. It is not allowed to do this: >>> >>> struct a { >>> struct { >>> int i; >>> char j[]; >>> } b; >>> char k[20]; >>> }; >>> >>> error: variable sized type 'b' must be at end of struct or class >> not sure wher eyou are seeing this. >> >> the examples you fix don't seem to be nested structs.. what is the >> outer struct? > > In the Netgraph code, this isn't done in a single declaration, but there > are several structs that (indirectly) nest pppoe_tags. An example is > ng_pppoe.c, line 1179: > > struct { > struct pppoe_tag hdr; > union uniq data; > } __packed uniqtag; > > It turns out that this is not valid: > > http://llvm.org/bugs/show_bug.cgi?id=3671 then the answer is to create a separate structure 'tag header' that can be used in both places. I think.... > From ed at 80386.nl Sun Mar 1 14:15:02 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Mar 1 14:15:08 2009 Subject: Making Netgraph compile with LLVM In-Reply-To: <49AB07CA.4070607@elischer.org> References: <20090301161827.GR19161@hoeg.nl> <49AAFF4F.6010400@elischer.org> <20090301220024.GU19161@hoeg.nl> <49AB07CA.4070607@elischer.org> Message-ID: <20090301221500.GV19161@hoeg.nl> * Julian Elischer wrote: > then the answer is to create a separate structure 'tag header' > that can be used in both places. I think.... I don't know that much about Netgraph. Would you be willing to work on this? I don't use ng_pppoe, so I was only able to validate its correctness by looking at objdump. -- 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/20090301/7e72c98c/attachment.pgp From rpaulo at gmail.com Sun Mar 1 16:44:16 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Sun Mar 1 16:44:30 2009 Subject: spliting kernel ipfw source ? (also involves sctp) In-Reply-To: <49AAFD92.105@elischer.org> References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> Message-ID: <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> On 1 Mar 2009, at 21:26, Julian Elischer wrote: > Luigi Rizzo wrote: >> Hi, >> I am planning to split netinet/ip_fw2.c in a number of smaller files >> to make it more manageable, and while i do this I would also like >> to move the files related to ipfw2 (namely ip_fw*c) to a better >> place. >> Any objection to moving them to sys/netinet/ipfw2 ? >> Also, I can't help noticing that sys/netinet/ contains 36 files >> related to sctp -- wouldn't it be the case to move them >> (perhaps with the exception of the userland headers) >> to a separate subdirectory ? > > for that matter it would be nice to put ALL teh protocols in their > own subdirectories. Yes, that would be the perfect scenario, but I don't think that's doable. SCTP can be moved because it hasn't matured enough to cause a "moving nightmare". I vote for "ipfw" like Sam, BTW. -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090302/0279c871/PGP.pgp From stutiredboy at gmail.com Sun Mar 1 17:14:52 2009 From: stutiredboy at gmail.com (stutiredboy) Date: Sun Mar 1 17:14:59 2009 Subject: crazy network problem -- sleep? In-Reply-To: <78cb3d3f0903011110nb13791dk5aa5e1d174c1e063@mail.gmail.com> References: <49AA352E.5060803@gmail.com> <78cb3d3f0903010301y5d8bbaf9r4a285653688d74ca@mail.gmail.com> <49AA744D.8060407@gmail.com> <78cb3d3f0903011110nb13791dk5aa5e1d174c1e063@mail.gmail.com> Message-ID: <49AB3307.5070900@gmail.com> Adrian Penisoara ??: > Hi, > > 2009/3/1 stutiredboy > > > Adrian Penisoara ??: > > Hi, > > > > 2009/3/1 stutiredboy > > >> > > > > hi,all: > > > > recently , we found a problem that , some server which with FreeBSD > > 6.2 may stop networking after > > days of services, it is so difficulty express this status, e, > such as > > sleep? i can not ping this server, tracert is also > > failure, and other services ,network/server seems to be down... but > > while i insert the keyboard/mouse/crt in , > > everything is ok, such as a ring to call the system to wake-up... no > > errors found in dmesg or /var/log/messages, > > such as nothing happened...orz?our unlimit args as follow: > > > > cputime unlimited > > filesize unlimited > > datasize 2088152 kbytes > > stacksize 65536 kbytes > > coredumpsize unlimited > > memoryuse unlimited > > vmemoryuse unlimited > > descriptors 655000 > > memorylocked unlimited > > maxproc 5547 > > sbsize unlimited > > > > plz give me some suggestion to trace the problem or solve it . > > thanks a > > lot ! > > > > > > First you need to check whether packets are reaching the system and > > whether the response packets are leaving it with tcpdump(8) on the > > appropriate interface. > > > > If you see the packets coming but not coming out then you need to > > check the status of your TCP/IP stack -- e.g. post the output of > > "netstat -m" and "netstat -s". Also check dmesg output for any > errors. > > > > If you are using firewall(s) (ipfw/ipfilter/pf) then check the rules > > and the firewall states status; try temporarily disabling the > firewall > > (ipfw disable firewall / ipf -D / pfctl -d) and check whether your > > system becomes reachable. > > > > Check CPU load, interrupts, packet stats (systat -vmstat / systat > > -ifstat). > > > > Regards, > > Adrian Penisoara > > EnterpriseBSD > hi, thank you for your help, i can only ssh to the system, so > while the > network is down, i can not login in > > yes, we have ipfw on , these rules have used a long time, and many > other > severs do not have this problem, > > this sistutation happened scarce, in different machine rooms, > different > isps, different servers, such as hp\dell. > > while the network usable, the cpu and system load is normal, i have > checked dmesg and syslog, nothing > > special found , where our colleague in machine room insert the > keyboard > or mouse in ,then the network > > recover , it is so difficult to catch the ouput of tcpdump or other > messages form netstat , the moment you > > have the keyboard connected , the network recover... thanks very > much ! > > > You mean that once you plugin a keyboard the machine recovers ? That's > weird. What if you leave the keyboard connected all the time ? > > Try to attach one of the machines which reproduces the problem to a > KVM switch (Keyboard/Video/Mouse switcher). If you are able to > reproduce again the problem then you might have more chances to catch it. > > Regards, > Adrian. > hi, thanks Adrian. yes,it is weird and thanks for your opinion, it's a good a idea , but it is a pity that i do not know which machine will run into this problem again, we have thousands of machines in different machine rooms, i will try this , hope i have the chances to catch the useful info. :-) From perryh at pluto.rain.com Sun Mar 1 18:54:48 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sun Mar 1 18:54:55 2009 Subject: spliting kernel ipfw source ? (also involves sctp) In-Reply-To: <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> Message-ID: <49ab42ca.YZ1mfcCDO0pvdDhv%perryh@pluto.rain.com> Rui Paulo wrote: > On 1 Mar 2009, at 21:26, Julian Elischer wrote: > > Luigi Rizzo wrote: > >> Hi, > >> I am planning to split netinet/ip_fw2.c in a number of smaller > >> files to make it more manageable, and while i do this I would > >> also like to move the files related to ipfw2 (namely ip_fw*c) > >> to a better place. > >> Any objection to moving them to sys/netinet/ipfw2 ? > >> Also, I can't help noticing that sys/netinet/ contains 36 > >> files related to sctp -- wouldn't it be the case to move > >> them (perhaps with the exception of the userland headers) > >> to a separate subdirectory ? > > > > for that matter it would be nice to put ALL teh protocols in > > their own subdirectories. > > Yes, that would be the perfect scenario, but I don't think that's > doable. > > SCTP can be moved because it hasn't matured enough to cause a > "moving nightmare". Perhaps everything can be moved, if hardlinks or symlinks are left in sys/netinet for those parts (mostly .h files, presumably) which have too much legacy to be moved outright. From ady at freebsd.ady.ro Mon Mar 2 00:23:31 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Mon Mar 2 00:23:39 2009 Subject: crazy network problem -- sleep? In-Reply-To: <49AB3307.5070900@gmail.com> References: <49AA352E.5060803@gmail.com> <78cb3d3f0903010301y5d8bbaf9r4a285653688d74ca@mail.gmail.com> <49AA744D.8060407@gmail.com> <78cb3d3f0903011110nb13791dk5aa5e1d174c1e063@mail.gmail.com> <49AB3307.5070900@gmail.com> Message-ID: <78cb3d3f0903020023u98c88fch6dfeaf25db79fc79@mail.gmail.com> Hi, 2009/3/2 stutiredboy [...] > > > > > > You mean that once you plugin a keyboard the machine recovers ? That's > > weird. What if you leave the keyboard connected all the time ? > > > > Try to attach one of the machines which reproduces the problem to a > > KVM switch (Keyboard/Video/Mouse switcher). If you are able to > > reproduce again the problem then you might have more chances to catch it. > > > > Regards, > > Adrian. > > > hi, thanks Adrian. yes,it is weird and thanks for your opinion, it's a > good a idea , but it is a pity that i do not know which machine will run > into this problem again, we have thousands of machines in different > machine rooms, i will try this , hope i have the chances to catch the > useful info. :-) > Please keep in mind hat having a predictable reproduction method for the issue would greatly help resolving the problem, so try to keep tabs on what triggers producing it. Regards, Adrian. From bugmaster at FreeBSD.org Mon Mar 2 03:07:38 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 2 03:11:54 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200903021106.n22B6urR057381@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131310 net [panic] 7.1 panics with mpd netgraph interface changes o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw o kern/130846 net [vge] vge0 not autonegotiating to 1000baseTX full dupl o kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R f kern/130605 net [tcp] Certain hardware produces "Network is unreachabl o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100839 net [txp] txp driver inconsistently stops working when the o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 261 problems total. From jchambers at ucla.edu Mon Mar 2 03:30:07 2009 From: jchambers at ucla.edu (Jason Chambers) Date: Mon Mar 2 03:30:17 2009 Subject: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Message-ID: <200903021130.n22BU5Jr076050@freefall.freebsd.org> The following reply was made to PR kern/130605; it has been noted by GNATS. From: Jason Chambers To: bug-followup@FreeBSD.org, jchambers@ucla.edu Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Date: Mon, 02 Mar 2009 03:26:43 -0800 Hello all. The Nessus problem was finally identified to be caused by incompatible ABI system calls. As for the general "Network is unreachable" error I assume this to be due to the condition described or incorrect implementation of said security tools on FreeBSD. Thanks for the help, this PR can be closed. --Jason From eksffa at freebsdbrasil.com.br Mon Mar 2 05:12:06 2009 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Mon Mar 2 05:12:14 2009 Subject: rate limiting mail server In-Reply-To: <407473.34181.qm@web63901.mail.re1.yahoo.com> References: <407473.34181.qm@web63901.mail.re1.yahoo.com> Message-ID: <49ABD4D0.7070100@freebsdbrasil.com.br> Barney Cordoba escreveu: > > > > --- On Tue, 2/24/09, Mark E Doner wrote: > >> From: Mark E Doner >> Subject: rate limiting mail server >> To: freebsd-isp@freebsd.org >> Date: Tuesday, February 24, 2009, 12:13 AM >> Greetings, >> I am running a fairly large mail server, FreeBSD, of >> course. It is predominantly for residential customers, so >> educating the end users to not fall for the scams is never >> going to happen. Whenever we have a customer actually hand >> over their login credentials, we quickly see a huge flood of >> inbound connections from a small handful of IP addresses on >> ports 25 and 587, all authenticate as whatever customer fell >> for the scam du jour, and of course, load goes through the >> roof as I get a few thousand extra junk messages to process >> in a matter of minutes. >> >> Thinking about using PF to rate limit inbound connections, >> stuff the hog wild connection rates into a table and drop >> them quickly. My question is, I know how to do this, PF >> syntax is easy, but has anyone ever tried this? How many new >> connections per minute from a single source are acceptable, >> and what is blatantly malicious? And, once I have determined >> that, how long should I leave the offenders in the >> blocklist? >> >> Any thoughts appreciated, >> Mark > > A better strategy is to identify the spam source and just block it. The > way we do it is that we look for unusual domain traffic from a single > source and then block the source. I haven't figured out a way to automate > it yet but it works very well. > > You don't really want to rate limit mail spammers. They go on for many hours . > > BC IMHO, what you could potentially do is adding maximum recipients' limit per SMTP session, for your customers (relay access IPs), combining it with tarpiting, while on the firewall side, all you do (my suggestion) is just limiting the simultaneous access per source IP. Remember that you might have NATed customers so limiting per IP dont do it way too limited (2 to 5 simultaneous sessions is probably enough due to your "residential" usage profile). Finally, you didnt mention your MTA. If its Qmail there is a great plugins framework called qmail-spp and it already has a rate control plugin to be used. While qmail-spp is not (yet) available in the Ports Collection I have working patches for qmail-ldap and qmail-spamassassin, which can both be applied from Ports directly (will send-pr(1) to garga@ in the near future...). Those are usually my own approaches to slow down my users' message floods. If you mention your MTA maybe we can be of further assistance. -- 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 gnn at neville-neil.com Mon Mar 2 09:18:35 2009 From: gnn at neville-neil.com (George V. Neville-Neil) Date: Mon Mar 2 09:18:41 2009 Subject: spliting kernel ipfw source ? (also involves sctp) In-Reply-To: <49ab42ca.YZ1mfcCDO0pvdDhv%perryh@pluto.rain.com> References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> <49ab42ca.YZ1mfcCDO0pvdDhv%perryh@pluto.rain.com> Message-ID: At Sun, 01 Mar 2009 18:22:02 -0800, perryh@pluto.rain.com wrote: > > Rui Paulo wrote: > > On 1 Mar 2009, at 21:26, Julian Elischer wrote: > > > Luigi Rizzo wrote: > > >> Hi, > > >> I am planning to split netinet/ip_fw2.c in a number of smaller > > >> files to make it more manageable, and while i do this I would > > >> also like to move the files related to ipfw2 (namely ip_fw*c) > > >> to a better place. > > >> Any objection to moving them to sys/netinet/ipfw2 ? > > >> Also, I can't help noticing that sys/netinet/ contains 36 > > >> files related to sctp -- wouldn't it be the case to move > > >> them (perhaps with the exception of the userland headers) > > >> to a separate subdirectory ? > > > > > > for that matter it would be nice to put ALL teh protocols in > > > their own subdirectories. > > > > Yes, that would be the perfect scenario, but I don't think that's > > doable. > > > > SCTP can be moved because it hasn't matured enough to cause a > > "moving nightmare". > > Perhaps everything can be moved, if hardlinks or symlinks are > left in sys/netinet for those parts (mostly .h files, presumably) > which have too much legacy to be moved outright. I do not believe we want to go down the path of doing links. I do think that moving protocols is OK, and SCTP is a good candidate. I have cc'd the maintainer in case he's not on arch@. As to the original question about ipfw, if it can e done cleanly then yes that's fine. Best, George From rwatson at FreeBSD.org Mon Mar 2 10:30:28 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Mar 2 10:30:35 2009 Subject: spliting kernel ipfw source ? (also involves sctp) In-Reply-To: <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> Message-ID: On Mon, 2 Mar 2009, Rui Paulo wrote: > On 1 Mar 2009, at 21:26, Julian Elischer wrote: > >> Luigi Rizzo wrote: >>> Hi, I am planning to split netinet/ip_fw2.c in a number of smaller files >>> to make it more manageable, and while i do this I would also like to move >>> the files related to ipfw2 (namely ip_fw*c) to a better place. Any >>> objection to moving them to sys/netinet/ipfw2 ? Also, I can't help >>> noticing that sys/netinet/ contains 36 files related to sctp -- wouldn't >>> it be the case to move them (perhaps with the exception of the userland >>> headers) to a separate subdirectory ? >> >> for that matter it would be nice to put ALL teh protocols in their own >> subdirectories. > > Yes, that would be the perfect scenario, but I don't think that's doable. > > SCTP can be moved because it hasn't matured enough to cause a "moving > nightmare". > > I vote for "ipfw" like Sam, BTW. I think massively rearranging things doesn't by us much in terms of beauty, but does give us a lot in terms of hassle, given current assumptions of alignment between the layout of /usr/include and the layout of /usr/src/sys. We'd need to introduce new explicit mappings to install include files in their old locations (which are required by applications), etc. For a change with such a minor benefit, the hassle will be huge. I'm fine with renaming the ipfw .c files and leaving in netinet, but let's not get carried away. Robert N M Watson Computer Laboratory University of Cambridge From rizzo at iet.unipi.it Mon Mar 2 10:57:04 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Mar 2 10:57:28 2009 Subject: spliting kernel ipfw source ? (also involves sctp) In-Reply-To: References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> Message-ID: <20090302190157.GA33704@onelab2.iet.unipi.it> On Mon, Mar 02, 2009 at 06:30:27PM +0000, Robert Watson wrote: .. > >>Luigi Rizzo wrote: > >>>Hi, I am planning to split netinet/ip_fw2.c in a number of smaller files > >>>to make it more manageable, and while i do this I would also like to > >>>move the files related to ipfw2 (namely ip_fw*c) to a better place. Any > >>>objection to moving them to sys/netinet/ipfw2 ? Also, I can't help > >>>noticing that sys/netinet/ contains 36 files related to sctp -- wouldn't > >>>it be the case to move them (perhaps with the exception of the userland > >>>headers) to a separate subdirectory ? ... > I think massively rearranging things doesn't by us much in terms of beauty, > but does give us a lot in terms of hassle, given current assumptions of > alignment between the layout of /usr/include and the layout of > /usr/src/sys. We'd need to introduce new explicit mappings to install > include files in their old locations (which are required by applications), > etc. For a change with such a minor benefit, the hassle will be huge. I'm > fine with renaming the ipfw .c files and leaving in netinet, but let's not > get carried away. I suspect that the mention of symlinks (which is not mine and absolutely not what I want to do) triggered some alarms :) I have very clear the potential nightmare with careless moving of files, so I tried to make it clear that public headers are excluded: as you see i wrote "ip_fw*c" and "exception of the userland headers". To further clarify, my plan is the following: - leave ip_fw.h and ip_dummynet.h in /sys/netinet in case userland code is dependent on their location; - create /sys/netinet/ipfw/ to hold the kernel .c files related to ipfw and possibly dummynet (and also their private headers if any); I am not going to touch other people's stuff, though I repeat that sctp would clearly deserve a cleanup -- i doubt userland needs more than one or possibly two headers (one for the basic stuff, one for the fancy and possibly non-portable stuff). Tcp has similar issues especially for recent additions. More than the number of files in /sys/netinet/, i am worried by the amount of private headers that are exposed to userland for no good reason. In fact, some of them are contain: #ifndef _KERNEL #error "no user-serviceable parts inside" #endif Part of this is for historical reasons, but we should try to move to a better structure. Take e.g. tcp_var.h contains the stats (that some userland program may want to have) but also a ton of internal structures (e.g. those for SACK support) that have appeared very recently and have no reason to be there. cheers luigi From csjp at freebsd.org Mon Mar 2 11:58:48 2009 From: csjp at freebsd.org (Christian Peron) Date: Mon Mar 2 11:58:54 2009 Subject: [heads-up] zero-copy bpf enabled by default In-Reply-To: <20090302194606.GA93824@jnz.sqrt.ca> References: <20090302194606.GA93824@jnz.sqrt.ca> Message-ID: <20090302195845.GA93970@jnz.sqrt.ca> I probably should have mentioned: To disable zero-copy: sysctl net.bpf.zerocopy_enable=0 Also, it is only enabled for processes which use libpcap. On Mon, Mar 02, 2009 at 01:46:06PM -0600, Christian Peron wrote: > This is a heads up that we have flipped the switch to enable > zerocopy bpf by default in head. If there are any issues let > myself or rwatson@ know. > > Cheers! From csjp at freebsd.org Mon Mar 2 12:07:29 2009 From: csjp at freebsd.org (Christian Peron) Date: Mon Mar 2 12:07:46 2009 Subject: [heads-up] zero-copy bpf enabled by default Message-ID: <20090302194606.GA93824@jnz.sqrt.ca> This is a heads up that we have flipped the switch to enable zerocopy bpf by default in head. If there are any issues let myself or rwatson@ know. Cheers! From linimon at FreeBSD.org Tue Mar 3 06:07:23 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Mar 3 06:07:35 2009 Subject: kern/132277: [crypto] [ipsec] poor performance using cryptodevice for IPSEC Message-ID: <200903031407.n23E7LPj017411@freefall.freebsd.org> Old Synopsis: poor performance using criptodevice for IPSEC New Synopsis: [crypto] [ipsec] poor performance using cryptodevice for IPSEC Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 3 14:06:44 UTC 2009 Responsible-Changed-Why: Over to -net on the theory that the problem might be there. http://www.freebsd.org/cgi/query-pr.cgi?pr=132277 From gavin at FreeBSD.org Tue Mar 3 08:12:36 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue Mar 3 08:14:24 2009 Subject: kern/132285: [carp] alias gives incorrect hash in dmesg Message-ID: <200903031612.n23GCZVM014326@freefall.freebsd.org> Old Synopsis: CARP alias gives incorrect hash in dmesg New Synopsis: [carp] alias gives incorrect hash in dmesg Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Tue Mar 3 16:11:56 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=132285 From lapo at lapo.it Tue Mar 3 09:51:38 2009 From: lapo at lapo.it (Lapo Luchini) Date: Tue Mar 3 09:51:46 2009 Subject: using 6to4 on two different IPv4 addresses (alias on stf0 or stf1?) Message-ID: I'm renumbering a server of mine in order to ease migration and am setting most its services to listen to both the "old" and the "new" IPv4 address. I have a little more problems with the 6to4-serviced IPv6 address: adding an alias to stf0 doesn't seem to work, probably because the internal sanity checks use only the first address and don't know about the alias I added (thus this could probably be solved closing kern/123858 but I didn't yet try that); I then tried (unsuccesfully) to have two different 6to4 interfaces, which should IMHO work: % sudo ifconfig stf1 create ifconfig: SIOCIFCREATE: Invalid argument I guess the kernel is hardwired to support only one stf interface? BTW: that server is a 6-STABLE. "man stf" states: Each stf interface is created at runtime using interface cloning. This is most easily done with the ifconfig(8) create command or using the cloned_interfaces variable in rc.conf(5). -- Lapo Luchini - http://lapo.it/ From shawn at tandac.com Tue Mar 3 16:42:22 2009 From: shawn at tandac.com (Shawn Everett) Date: Tue Mar 3 16:42:29 2009 Subject: Force certain websites to use certain connections Message-ID: <1354.206.108.16.89.1236127341.squirrel@alder.hosix.com> Hi All, I've set up a load balanced FreeBSD router using outbound load balancing as configured here: http://www.openbsd.org/faq/pf/pools.html#outgoing There are one or two sites that this is causing problems with. Can anyone suggest a rule that would force certain websites to go through certain interfaces/connections? Shawn From bms at incunabulum.net Tue Mar 3 18:06:20 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 3 18:06:26 2009 Subject: HEADS UP: IGMPv3/SSM: alpha code drop. Message-ID: <49ADDDCE.5000203@incunabulum.net> Hi all, I am making patches available against 8-CURRENT to do IGMPv3 and Source Specific Multicast in the IP stack: http://people.freebsd.org/~bms/stage/igmpv3/ At the moment, the patches are extracted from Perforce, so may need some rejigging of patch's -p option. I would hope to post step-by-step instructions as time permits, however, others are welcome to join in and contribute how-tos like this. This is considered alpha quality code at the moment. It has seen some testing in a QEMU environment. Things which are known not to be tested, although believed correct, include response to a Group-Source query, and backwards compatibility mode for IGMPv1/v2 multicast routers. Whilst there have been similar efforts from KAME and others, it wasn't possible to incorporate them in FreeBSD due to divergence in SMP implementation. Most of the work involved in this project was to do with fine grained locking, and layering the state machines in such a way that the locks could be untangled and taken in the right order. The code is also believed to do the right thing with respect to VIMAGE. From an architectural standpoint, the most important wide-ranging change that this makes to the IPv4 stack in FreeBSD, is the change which takes the IN_MULTI_LOCK() out of the ip_output() and ip_input() paths. Filtering of inbound multicast traffic is pushed up to the transport protocol layers (RAW, and UDP; SCTP and TCP drop multicast traffic.) The rationale is that if you are running an up-to-date multicast capable network, IGMPv3 will ensure that you only receive the traffic your hosts requested anyway, and bottom half IP has no business taking socket-layer locks. The other win for IGMPv3 from a user standpoint is the retransmission of the control traffic. Whilst multicasting over lossy and wireless networks has issues of its own, retransmissions of the control traffic insulate the routers and endpoints somewhat from such loss. Also, IGMPv3 plays nicer with switched networks and smart switches -- it's easier for switches to snoop IGMPv3, as only one multicast group address is now used for IGMPv3 control plane traffic -- and it is easier for administrators to spot what's going on, as they need only sniff one group address. From the kernel point of view, one major assumption made by this code is that kernel consumers will never request source-specific memberships. If this functionality is required, it's easy enough to add it, as 'struct in_mfilter' is used to represent the SSM filter sets using RB-trees as a disjoint-set data structure. in_addmulti() and in_delmulti() are implemented as compatibility shims only to the new KPIs. Currently the carp(4) code relies on them. I'll be pushing some of the userland changes in shortly. My intention would be to merge this to HEAD sometime within the next week or so, this is long overdue, and needs to go in, as it brings us up to date with Windows and Linux on the implementation. Unfortunately, whilst I have an automated regression testing suite in existence for the on-the-wire IGMPv3 protocol behaviour, I can't run it in simulation due to a strange issue where getty doesn't seem to work on QEMU's emulated uart interface. Any help to debug that would be greatly appreciated. This work is being funded by a 3rd party, and is the culmination of a long development cycle. Feedback is very welcome. thanks, BMS From bms at incunabulum.net Tue Mar 3 19:51:24 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 3 19:51:36 2009 Subject: HEADS UP: IGMPv3/SSM: alpha code drop. In-Reply-To: <49ADDDCE.5000203@incunabulum.net> References: <49ADDDCE.5000203@incunabulum.net> Message-ID: <49ADFAB7.1040408@incunabulum.net> Bruce Simpson wrote: > > From an architectural standpoint, the most important wide-ranging > change that this makes to the IPv4 stack in FreeBSD, is the change > which takes the IN_MULTI_LOCK() out of the ip_output() and ip_input() > paths. Filtering of inbound multicast traffic is pushed up to the > transport protocol layers (RAW, and UDP; SCTP and TCP drop multicast > traffic.) The first part of this particular change has now been merged to HEAD. All other non-invasive changes have been merged to HEAD; the diff set for IGMPv3 has now been minimized. This SHOULD increase multicast send performance when loopback is explicitly disabled, and is one half of the changes needed to the bottom half of IPv4 to make it possible to designate in_multi_mtx as a non-recursive mutex. Please let me know if there are any problems. thanks, BMS From Alexander at Leidinger.net Wed Mar 4 02:10:45 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Mar 4 02:10:51 2009 Subject: HEADS UP: IGMPv3/SSM: alpha code drop. In-Reply-To: <49ADDDCE.5000203@incunabulum.net> References: <49ADDDCE.5000203@incunabulum.net> Message-ID: <20090304105525.90665tgxalwo19ss@webmail.leidinger.net> Quoting Bruce Simpson (from Wed, 04 Mar 2009 01:47:58 +0000): > Hi all, > > I am making patches available against 8-CURRENT to do IGMPv3 and > Source Specific Multicast in the IP stack: > http://people.freebsd.org/~bms/stage/igmpv3/ Is this supposed to make multicast work in a jail? In the past I tried some simple tests (e.g. mtest(8)), but I wasn't able to receive anything in a jail (this test was triggered by the fact, that some avahi-tools from the avahi port didn't showed an expected result). Bye, Alexander. -- Memory fault -- core...uh...um...core... Oh dammit, I forget! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From marii.vasile at gmail.com Wed Mar 4 02:20:04 2009 From: marii.vasile at gmail.com (Vasile Marii) Date: Wed Mar 4 02:20:11 2009 Subject: kern/132277: [crypto] [ipsec] poor performance using cryptodevice for IPSEC Message-ID: <200903041020.n24AK4cY060551@freefall.freebsd.org> The following reply was made to PR kern/132277; it has been noted by GNATS. From: "Vasile Marii" To: , Cc: Subject: Re: kern/132277: [crypto] [ipsec] poor performance using cryptodevice for IPSEC Date: Wed, 4 Mar 2009 11:41:47 +0200 This is a multipart message in MIME format. ------=_NextPart_000_0001_01C99CBE.34A8B240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://forum.pfsense.org/index.php/topic,14581.msg77206.html#msg77206 ------=_NextPart_000_0001_01C99CBE.34A8B240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://forum.pfsense.org/index.php/topic,14581.msg77206= .html#msg77206

------=_NextPart_000_0001_01C99CBE.34A8B240-- From bms at incunabulum.net Wed Mar 4 03:49:07 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Mar 4 03:49:19 2009 Subject: HEADS UP: IGMPv3/SSM: alpha code drop. In-Reply-To: <20090304105525.90665tgxalwo19ss@webmail.leidinger.net> References: <49ADDDCE.5000203@incunabulum.net> <20090304105525.90665tgxalwo19ss@webmail.leidinger.net> Message-ID: <49AE6AAF.5090905@incunabulum.net> Alexander Leidinger wrote: > ... > Is this supposed to make multicast work in a jail? In the past I tried > some simple tests (e.g. mtest(8)), but I wasn't able to receive > anything in a jail (this test was triggered by the fact, that some > avahi-tools from the avahi port didn't showed an expected result). Not really, no, I have just been making my best guess here. I would hope bz would join in once it's checked in -- as I understand it, jails are a difficult case for multicast (and broadcast) sockets because of how they change how address lookup works. Other than that I have done no testing with jails. I believe the code will continue to work as-is, however others are welcome to test and contribute once it's in. thanks, BMS From Alexander at Leidinger.net Wed Mar 4 04:27:37 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Mar 4 04:27:48 2009 Subject: HEADS UP: IGMPv3/SSM: alpha code drop. In-Reply-To: <49AE6AAF.5090905@incunabulum.net> References: <49ADDDCE.5000203@incunabulum.net> <20090304105525.90665tgxalwo19ss@webmail.leidinger.net> <49AE6AAF.5090905@incunabulum.net> Message-ID: <20090304132722.11537bwxtk2oys8w@webmail.leidinger.net> Quoting Bruce Simpson (from Wed, 04 Mar 2009 11:49:03 +0000): > Alexander Leidinger wrote: >> ... >> Is this supposed to make multicast work in a jail? In the past I >> tried some simple tests (e.g. mtest(8)), but I wasn't able to >> receive anything in a jail (this test was triggered by the fact, >> that some avahi-tools from the avahi port didn't showed an expected >> result). > > Not really, no, I have just been making my best guess here. I would > hope bz would join in once it's checked in -- as I understand it, > jails are a difficult case for multicast (and broadcast) sockets > because of how they change how address lookup works. Other than that > I have done no testing with jails. > > I believe the code will continue to work as-is, however others are > welcome to test and contribute once it's in. Thanks for the info. I hope the vimage stuff will change this situation regardless of the fact if someone jumps in and makes the current stuff work or not. Bye, Alexander. -- For every action, there is an equal and opposite criticism. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From dhorn2000 at gmail.com Wed Mar 4 11:26:29 2009 From: dhorn2000 at gmail.com (David Horn) Date: Wed Mar 4 11:26:36 2009 Subject: Proposal: Rework ipv6 rtsol initialization in rc.d Message-ID: <25ff90d60903041057k2e8a469ej43734effd30fd3ff@mail.gmail.com> Proposal: Rework ipv6 rtsol initialization in rc.d Why: on multihomed or transient (e.g. laptops) connections, ipv6 autoconfiguration can be slow, causing ipv6 initialization delays while waiting for unsolicited router advertisements What: add devd.conf entries, create /etc/rc.d/rtsol script (ala dhclient script), modify network.subr, update man 5 rtsol Discussion point: There is a comment in network.subr, and in man 5 rtsol about multihomed connections not being appropriate for rtsol I read through RFC 2461 and 2462, and while it does list multihomed issues in appendix A of RFC 2461, it does not have any "MUST NOT" or "SHOULD NOT" language around router solicitations with respect to multihomed ipv6 systems. (Someone, please correct me if I am wrong here, or if there is some other RFC that applies) The multihomed issue is more around IPv6 autoconfiguration in general, not specific to soliciting for a router. Since FreeBSD already allows for IPv6 autoconfiguration on multihomed ipv6 systems (just without calling rtsol on multiple interfaces), I would think that this is really a non-issue for rtsol. Comments ? Please let me know if I am way off base here. I will gladly submit a patch for review if no one has any objections to multihomed ipv6 rtsol. --Thanks! ---_Dave Horn Non quia difficilia sunt non audemus, sed quia non audemus, difficilia sunt. From linimon at FreeBSD.org Wed Mar 4 17:43:57 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 4 17:44:02 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' Message-ID: <200903050143.n251htES060465@freefall.freebsd.org> Synopsis: [ndis] wpa_supplicant(8) returns 'no space on device' State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Thu Mar 5 01:43:20 UTC 2009 State-Changed-Why: To submitter: did the suggestion from Paul B. Mahol fix this problem? http://www.freebsd.org/cgi/query-pr.cgi?pr=130820 From linimon at lonesome.com Wed Mar 4 17:50:03 2009 From: linimon at lonesome.com (Mark Linimon) Date: Wed Mar 4 17:50:10 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' Message-ID: <200903050150.n251o3gk060665@freefall.freebsd.org> The following reply was made to PR kern/130820; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' Date: Wed, 4 Mar 2009 19:44:31 -0600 ----- Forwarded message from "Paul B. Mahol" ----- From: "Paul B. Mahol" To: linimon@freebsd.org Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' Yet another invalid bug report. OP should use -Dndis and not -Dbsd -- Paul ----- End forwarded message ----- From feh at fehcom.de Thu Mar 5 00:13:25 2009 From: feh at fehcom.de (Erwin Hoffmann) Date: Thu Mar 5 00:13:40 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' In-Reply-To: <200903050143.n251htES060465@freefall.freebsd.org> References: <200903050143.n251htES060465@freefall.freebsd.org> Message-ID: <55CF3225C5C074DD9DCB1564@[192.168.192.108]> Hi thanks for following my bug-report: --On Donnerstag, 5. M?rz 2009 01:43 +0000 linimon@FreeBSD.org wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=130820 From: "Paul B. Mahol" To: linimon@freebsd.org Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' Yet another invalid bug report. OP should use -Dndis and not -Dbsd -- I did not reply to the comment, because of it's obvious stupidness: If you go thru the code source for the wpasuplicant (what I did trying to fix the bug), you can see that (at least that's true for FreeBSD 6.3) the wpasupplicant *only* supports the BSD driver for wlan cards and no other. That is ok, if the documentation clearly would mention that. However, it is completely misleading (and shows the ignorance on that subject by Paul) even pretending FreeBSD's wpasuplicant can be used with the driver option. In fact, FreeBSD's wpasupplicant implementation is at best half baked. It turned out, that one has to consider at least two different ndis drivers: 1. The generic one, which works for unencrypted and WEP connections (using the chipset's internal de/encryption facilities). 2. A specific ndis driver different from (1.) used to talk to the wlan adapter while encryption and authentication is done by wpasupplicant. Since (2.) is missing, wpasupplicant tries to use the build-in BSD driver, which of course fails with the error message mentioned in my bug report. In order to follow up this subject, I would recommend to change the category of the bug into something like 'documentation bug' straighten up the docs and close it. I'm inclined to set up a wpa reference page with a detailed description of this issue and perhaps include some additional patches (wpasupplicant latest version for FreeBSD and others). However, currently I'm busy with other projects; so it is likely that this will we postponed after the summer term. Further, it would be great (and maybe I ask one of my students) to get the ndis driver working for FreeBSD. But again: This will not happen until the winter term. regards. --eh. From ivoras at freebsd.org Thu Mar 5 03:30:54 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Mar 5 03:31:01 2009 Subject: IPFW and IPv6 TCP timeout problem Message-ID: Hi, It appears that IPFW drops dynamic (state-keeping) rules for idle IPv6 TCP connections after a short (60 seconds by default) timeout. This of course creates problems for services like SSH and NFS. I've contacted Luigi Rizzo about it but he cannot help with the IPv6 part of the ipfw. His guess is that the part that should send keepalive ACK packets like ipfw does for IPv4 is broken or nonexistent for IPv6. Any takers? Should I file a PR? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090305/382031aa/signature.pgp From joost at jodocus.org Thu Mar 5 05:21:05 2009 From: joost at jodocus.org (Joost Bekkers) Date: Thu Mar 5 05:21:11 2009 Subject: IPFW and IPv6 TCP timeout problem In-Reply-To: References: Message-ID: <29230.62.12.14.25.1236258269.squirrel@jodocus.org> On Thu, March 5, 2009 12:30, Ivan Voras wrote: > Hi, > > It appears that IPFW drops dynamic (state-keeping) rules for idle IPv6 > TCP connections after a short (60 seconds by default) timeout. This of > course creates problems for services like SSH and NFS. I've contacted > Luigi Rizzo about it but he cannot help with the IPv6 part of the ipfw. > His guess is that the part that should send keepalive ACK packets like > ipfw does for IPv4 is broken or nonexistent for IPv6. > > Any takers? Should I file a PR? > > You might want to check if kern/117234 is relevant here. I've got a feeling this is the problem you're seeing. The PR includes a patch, it just needs somebody to commit it. good luck. Joost. From steve at ibctech.ca Thu Mar 5 09:35:39 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Mar 5 09:35:46 2009 Subject: HP Procurve, FreeBSD and LACP Message-ID: <49B00D5F.80304@ibctech.ca> Hi everyone, I'm attempting to configure a lagg interface between a FreeBSD box and an HP Procurve 2848, but can't seem to get it right. The lagg interface consists of an re and an age device, both connected to the switch at 1000/full. FreeBSD claims that lagg is up, but only one of the physical interfaces is set to 'ACTIVE'. The switch is 208.70.104.2/25, and the lagg interface is 208.70.104.110/25. I can ping the FreeBSD box from the switch (and vice-versa), but traffic traversing the switch to the FBSD box fails. When I ping from FBSD to another host connected to the switch, I see ARP who-has and replies travelling in both directions, on both devices in question. However, any Layer-3 (ICMP) doesn't cross the switch. The switch claims things are ok: # sh lacp PORT LACP TRUNK PORT LACP LACP NUMB ENABLED GROUP STATUS PARTNER STATUS ---- ------- ------- ------- ------- ------- 11 Active Trk1 Up Yes Success 12 Active Trk1 Up Yes Success # sh mac MAC Address Located on Port ------------- --------------- 001a70-14563d Trk1 001d60-0d7b63 Trk1 # sh arp IP Address MAC Address Type Port --------------- ----------------- ------- ---- 208.70.104.110 001a70-14563d dynamic Trk1 # sh trunk Port | Name Type | Group Type ---- + -------------------------------- --------- + ----- ----- 11 | amanda.eagle.ca (LACP link #1) 11 | Trk1 LACP 12 | amanda.eagle.ca (LACP link #2) 12 | Trk1 LACP # sh run vlan 10 name "cat10" untagged 1-10,13-22,29-44,Trk1 ip address 208.70.104.2 255.255.255.128 exit I know that the host's setup is ok, as I can connect the lagg interface directly into a second FreeBSD box with lagg, and things just work. Is this a case where I am doing something wrong, or do I just need to replace the HP with a Cisco? ;) Steve From onemda at gmail.com Thu Mar 5 10:30:00 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Mar 5 10:30:06 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' In-Reply-To: <55CF3225C5C074DD9DCB1564@192.168.192.108> References: <200903050143.n251htES060465@freefall.freebsd.org> <55CF3225C5C074DD9DCB1564@192.168.192.108> Message-ID: <3a142e750903051029h37839d28l5e07ead6b616c73b@mail.gmail.com> On 3/5/09, Erwin Hoffmann wrote: > Hi > > thanks for following my bug-report: > > --On Donnerstag, 5. Maerz 2009 01:43 +0000 linimon@FreeBSD.org wrote: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=130820 > > From: "Paul B. Mahol" > To: linimon@freebsd.org > Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org > Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on > device' > > Yet another invalid bug report. > OP should use -Dndis and not -Dbsd > > -- > > I did not reply to the comment, because of it's obvious stupidness: > > If you go thru the code source for the wpasuplicant (what I did trying to > fix the bug), you can see that (at least that's true for FreeBSD 6.3) the > wpasupplicant *only* supports the BSD driver for wlan cards and no other. > > That is ok, if the documentation clearly would mention that. > > However, it is completely misleading (and shows the ignorance on that > subject by Paul) even pretending FreeBSD's wpasuplicant can be used with > the driver option. > > In fact, FreeBSD's wpasupplicant implementation is at best half baked. > It turned out, that one has to consider at least two different ndis drivers: > > 1. The generic one, which works for unencrypted and WEP connections (using > the chipset's internal de/encryption facilities). > 2. A specific ndis driver different from (1.) used to talk to the wlan > adapter while encryption and authentication is done by wpasupplicant. > > Since (2.) is missing, wpasupplicant tries to use the build-in BSD driver, > which of course fails with the error message mentioned in my bug report. > > In order to follow up this subject, I would recommend to change the > category of the bug into something like 'documentation bug' straighten up > the docs and close it. > > I'm inclined to set up a wpa reference page with a detailed description of > this issue and perhaps include some additional patches (wpasupplicant > latest version for FreeBSD and others). However, currently I'm busy with > other projects; so it is likely that this will we postponed after the > summer term. > > Further, it would be great (and maybe I ask one of my students) to get the > ndis driver working for FreeBSD. But again: This will not happen until the > winter term. Patches are always welcome but note that mayor development is going in 8.0 CURRENT and there ndisulator + wpa_supplicant work for me. wpa_supplicant on 6.3 RELEASE does support ndis driver interface, I come up to that conclusion looking in cvs but I can not be sure because I never used wpa_supplicant with 6.3 RELEASE http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/wpa/wpa_supplicant/?only_with_tag=RELENG_6_3_0_RELEASE -- Paul From linimon at FreeBSD.org Thu Mar 5 12:23:28 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Mar 5 12:23:37 2009 Subject: kern/132342: [ndis] [patch] incorrect number used in for loop; fix TXPMGT reporting Message-ID: <200903052023.n25KNRB6049721@freefall.freebsd.org> Old Synopsis: incorrect number used in for loop; fix TXPMGT reporting New Synopsis: [ndis] [patch] incorrect number used in for loop; fix TXPMGT reporting Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 5 20:23:01 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132342 From "ingonline." at ingvysyabank.com Thu Mar 5 19:27:37 2009 From: "ingonline." at ingvysyabank.com (ING Vysya Bank) Date: Thu Mar 5 19:27:44 2009 Subject: ING Update Message-ID: <20090306032310.AAC149C1B2@mailadmin.rpsnet.cz> [1][banklogo.gif] [mibanklogo2.gif] Dear Customer We are currently running a system update and maintenance. However, we have encountered some error on some [2]mi-b@nk account. For this reason, we require all our customers to login to their [3]mi-b@ank account and confirm their account status. If your account is in order, please disregard further instructions. If an error is being encountered in your account, please be advised to login to your [4]mi-b@ank account and update your data correctly. Errors will be immediately corrected in effect. Please click on the link below to proceed; [5]https://online.ingvysyabank.com/ Thanks for your co-operattion. Sincerely, Online Banking Customer Service © 2008.ING Vysya Bank Limited. All rights reserved References 1. http://www.ingvysyabank.com/index.aspx 2. mailto:mi-b@nk 3. mailto:mi-b@ank 4. mailto:mi-B@ank 5. http://www.qdealers.com/Auto-Dealer-Website-Design/FancyZoom%201.1/internetbanking.htm From siraj.sailor at ymail.com Fri Mar 6 00:07:38 2009 From: siraj.sailor at ymail.com (Sailor Siraj) Date: Fri Mar 6 04:11:28 2009 Subject: implementation of mDNS Message-ID: <41055.21272.qm@web43407.mail.sp1.yahoo.com> Hello everyone, I , Sailor Siraj - a computer science student from India, am quite interested to implement mDNS in FreeBSD as my gsoc project. I have done quite study in this field. Before submiting my project idea I needed to confirm if there is any previous or ongoing work being done on this field. Thanking all and waiting for a reply.. Sailor Siraj From bms at incunabulum.net Fri Mar 6 06:02:28 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Mar 6 06:02:34 2009 Subject: implementation of mDNS In-Reply-To: <41055.21272.qm@web43407.mail.sp1.yahoo.com> References: <41055.21272.qm@web43407.mail.sp1.yahoo.com> Message-ID: <49B12CF0.8050500@incunabulum.net> Sailor Siraj wrote: > Hello everyone, > > I , Sailor Siraj - a computer science student from India, am quite interested to implement mDNS in FreeBSD as my gsoc project. I have done quite study in this field. Before submiting my project idea I needed to confirm if there is any previous or ongoing work being done on this field. > I'm afraid that project's already been sponsored, and somework has taken place, although it hasn't made its way into FreeBSD for the moment. You might want to contact Fredrik Lindberg as he was the student who worked on the BSD-licensed mDNS stack. thanks, BMS From linimon at FreeBSD.org Fri Mar 6 08:11:14 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Mar 6 08:11:26 2009 Subject: kern/132354: [nat] Getting some packages to ipnat(8) causes crash Message-ID: <200903061611.n26GBCOf049160@freefall.freebsd.org> Old Synopsis: Getting some packages to the ipnat causes crash New Synopsis: [nat] Getting some packages to ipnat(8) causes crash Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 6 16:10:27 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132354 From dougb at FreeBSD.org Fri Mar 6 15:47:10 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Mar 6 15:47:16 2009 Subject: Proposal: Rework ipv6 rtsol initialization in rc.d In-Reply-To: <25ff90d60903041057k2e8a469ej43734effd30fd3ff@mail.gmail.com> References: <25ff90d60903041057k2e8a469ej43734effd30fd3ff@mail.gmail.com> Message-ID: <49B1AF12.2010302@FreeBSD.org> David Horn wrote: > Proposal: Rework ipv6 rtsol initialization in rc.d > Why: on multihomed or transient (e.g. laptops) connections, ipv6 > autoconfiguration can be slow, causing ipv6 initialization delays > while waiting for unsolicited router advertisements I don't quite understand this problem statement. Can you flesh it out a bit? > What: add devd.conf entries, create /etc/rc.d/rtsol script (ala > dhclient script), modify network.subr, update man 5 rtsol This sounds like a significant change so I would like to see a thorough justification for it before it goes in, and it will need thorough testing to make sure that there are no regressions. > Discussion point: There is a comment in network.subr, and in man 5 > rtsol about multihomed connections not being appropriate for rtsol > > I read through RFC 2461 and 2462, and while it does list multihomed > issues in appendix A of RFC 2461, it does not have any "MUST NOT" or > "SHOULD NOT" language around router solicitations with respect to > multihomed ipv6 systems. (Someone, please correct me if I am wrong > here, or if there is some other RFC that applies) The multihomed > issue is more around IPv6 autoconfiguration in general, not specific > to soliciting for a router. Since FreeBSD already allows for IPv6 > autoconfiguration on multihomed ipv6 systems (just without calling > rtsol on multiple interfaces), I would think that this is really a > non-issue for rtsol. My main concern would be making sure that the routing issues (particularly default routes for the various interfaces) don't end up with regressions. In general I agree with the concern that RA isn't really designed for use in a multihomed environment. That said, there aren't really any good multihome solutions in any case, so as long as this doesn't break anything I'm not opposed to giving it a go. hth, Doug -- This .signature sanitized for your protection From dhorn2000 at gmail.com Sat Mar 7 07:15:29 2009 From: dhorn2000 at gmail.com (David Horn) Date: Sat Mar 7 07:15:35 2009 Subject: Proposal: Rework ipv6 rtsol initialization in rc.d In-Reply-To: <49B1AF12.2010302@FreeBSD.org> References: <25ff90d60903041057k2e8a469ej43734effd30fd3ff@mail.gmail.com> <49B1AF12.2010302@FreeBSD.org> Message-ID: <25ff90d60903070715h72f00241v6e20c44e1769453@mail.gmail.com> On Fri, Mar 6, 2009 at 6:17 PM, Doug Barton wrote: > David Horn wrote: >> Proposal: ? Rework ipv6 rtsol initialization in rc.d > >> Why: ?on multihomed or transient (e.g. laptops) connections, ipv6 >> autoconfiguration can be slow, causing ipv6 initialization delays >> while waiting for unsolicited router advertisements > > I don't quite understand this problem statement. Can you flesh it out > a bit? > Apologies, I was a bit too brief. Here is a better set of descriptions for the two issues: - (1) Slow ipv6 initialization after link state changes - (2) Multihomed ipv6 rtsol initialization at boot Issue (1) IPv6 can be slow to initialize if link changes state in a single interface environment, and is not UP during boot. Example (1) Boot laptop, but no net interface UP during boot. (e.g. wifi out of range, Ethernet cable unplugged, etc.) and ipv6_enable rcvar is "YES". When link state does go UP, IPv4 initializes immediately due to dhclient being called from devd (in either 802.11 or Ethernet situations) e.g. /etc/devd.conf relevant lines: media-type "ethernet"; action "/etc/rc.d/dhclient start $subsystem"; media-type "802.11"; action "/etc/rc.d/dhclient start $subsystem"; IPv6 RA may be received either immediately (if you are lucky), or after upto a 10 minute wait depending on timing. The leaves the link in an indeterminate state for a random (0 seconds to 600 seconds) period of time for IPv6 connectivity. The solution is clearly spelled out in RFC 2461 (6.3.7): 6.3.7. Sending Router Solicitations When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Router Advertisement to locate default routers or learn prefixes. To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. - The host attaches to a link for the first time. - The host re-attaches to a link after being detached for some time. Proposal (1) - Try to get IPv6 initialization timing to ~ parity with IPv4 initialization by calling rtsol at same or similar times as dhclient is being called. - Create /etc/rc.d/rtsol script that checks for disabled ipv6, and other rc.conf vars then calls /sbin/rtsol e.g. ipv6_enabled rcvar and ipv6_network_interfaces rcvar, rtsol_flags - Add devd.conf action lines for new /etc/rc.d/rtsol script for both Ethernet and 802.11 types - I *think* devd.conf entries are preferable to running rtsold in the background having it watch for link-up events. - This also applies to situations like roaming wi-fi, and devd should do nicely here, and should allow seemlessly moving from one ipv6 prefix to another (in the case where one 802.11 AP is on one /64 prefix, and a different 802.11 AP may be on another /64 prefix) =================================================================== Issue (2): In a multihomed network interface environment, rtsol will only be called on the first interface in the list during boot sequence due to a perception that there *may* be problems. See network.subr in network6_interface_setup(), specifically "rtsol $1" and comments rather than "rtsol $rtsol_interfaces" Example (2): Laptop has both Ethernet and WiFi network interfaces, and appropriate rc.conf entries to make them both attempt to start at boot, and ipv6_enable rcvar is "YES". In my case, this would be bfe0 and iwn0 (realy wlan0 in -current, as iwn0 can not be used). Ethernet cable is disconnected, but wifi does succeed in connecting. ifconfig -l returns bfe0 in the list before wlan0, so rtsol is called on the non-connected interface, but never called on wlan0. dhclient is called on wlan0 properly however, so ipv4 initializes quickly, and ipv6 can take some time (0 - 600 seconds). Proposal (2): Investigate in what cases it would be acceptable and prudent to initialize all potential ipv6 interface (e.g. $rtsol_interfaces). /sbin/rtsol already works properly if called with multiple interfaces. >> What: add devd.conf entries, create /etc/rc.d/rtsol script (ala >> dhclient script), modify network.subr, update man 5 rtsol > > This sounds like a significant change so I would like to see a > thorough justification for it before it goes in, and it will need > thorough testing to make sure that there are no regressions. > I absolutely agree. This will need to be thoroughly tested. >> Discussion point: ?There is a comment in network.subr, and in man 5 >> rtsol about multihomed connections not being appropriate for rtsol >> >> I read through RFC 2461 and 2462, and while it does list multihomed >> issues in appendix A of RFC 2461, it does not have any "MUST NOT" or >> "SHOULD NOT" language around router solicitations with respect to >> multihomed ipv6 systems. ?(Someone, please correct me if I am wrong >> here, or if there is some other RFC that applies) ?The multihomed >> issue is more around IPv6 autoconfiguration in general, not specific >> to soliciting for a router. ?Since FreeBSD already allows for IPv6 >> autoconfiguration on multihomed ipv6 systems (just without calling >> rtsol on multiple interfaces), I would think that this is really a >> non-issue for rtsol. > > My main concern would be making sure that the routing issues > (particularly default routes for the various interfaces) don't end up > with regressions. In general I agree with the concern that RA isn't > really designed for use in a multihomed environment. That said, there > aren't really any good multihome solutions in any case, so as long as > this doesn't break anything I'm not opposed to giving it a go. > > I need to do some more investigation, but from what I can tell FreeBSD already works in multihomed IPv6 RA environment, there is just the issue of waiting for an RA, or soliciting via rtsol. I also need to look at this on 7.1-STABLE just to make sure that some of the things I am seeing are not -CURRENT specific. -Thanks in advance. -_Dave > hth, > > Doug From bettina at apoteelia.net Sat Mar 7 10:36:19 2009 From: bettina at apoteelia.net (Bettina Schmidtberger) Date: Sat Mar 7 10:36:34 2009 Subject: Der versprochene Geheimtipp Message-ID: <21e0a27848ad0c3f7923bfc3c9001c68@localhost.localdomain> Hi Du! Wie ich es Dir versprochen habe, wollte ich Dir ja noch die Adresse sagen wo wir die Dinger bestellt haben. Gibt ja viele Seiten wo man echt nur ?bers Ohr gehauen wird. Aber bei der Adresse bekommen wir immer nur Originalware und das innheralb k?rzester Zeit zugeschickt. Mit dem Zoll hatten wir da auch nie Probleme, da der Versand direkt aus Europa erfolgt. Klasse oder? Also hier nun die Adresse: http://www.apoteelia.net Viel Spass w?nsch ich Dir und das es gut funktioniert! Gru?, Deine Bettina . . - . . . . . . . . . . : . Gib Acht! Man hatte dir eingeredet, du h?ttest es schwer, dein Leben sei verpfuscht, das Leben sei eine Schuld, sei schlecht, ohne Sinn, ohne Wert; man wollte dich ducken, dich in die gro?e Armee der Leidenden schmuggeln, du solltest bemitleidenswert werden und bemitleiden: und du glaubtest ihnen ? wie ungern! ? und wieder nicht ? wie gern! Denn du bist stark, aber warst krank ? wo? wie? was wei? ich. Und deine Sehnsucht war, herauszukommen aus allen diesen m?den Verneinungen, diesen t?richten Formeln, die im Nein ihr Ja haben, diesen t?nenden Wissenschaften, diesen Worten ?. Deswegen sprangst du von Buch zu Buch, spieltest mit ihren Formeln und lie?est sie wieder fallen, die Neins und Wenns, um selber eine zu finden, aber ein Ja! sollte sie klingen ? denn du wolltest leben! Aber nicht wie der P?bel lebt ? einen Grund, ein Ziel, eine Lebensformel suchtest du. Nun, hier ist sie: Wei?t du: das Himmelsweinglas, das du ausschl?rfen wolltest ? ? nun niete dir die Formel: Die Welt schaffst du. Du vergeistigst das Chaos zur Welt; das Andere, das Noch-nicht-Du, das alte Ding an sich, ist nur das, was von dir noch nicht geschaffen, vermenschlicht, noch nicht dein Eigentum geworden ist. ? Du schaffst die Welt: nun lebe, lebe! ? Die kleine blaue Blume l?utete so froh und stark ? warum soll ich ihr nicht glauben? Und dann bin ich baden gegangen ? ? ? und habe stundenlang im Grase gelegen; und w?hrend die wei?en Wolken durch den Himmel segelten und der Flu? geruhig durch Schilfduft und Ried und schwatzendes Vogelvolk hinstr?mte, habe ich das Ding an sich, den Intellekt und den Willen verlacht und mir ein Ich-wei?-nicht-was? gew?nscht. Gegen Abend entstiegen Schw?rme von Eintagsfliegen dem Flu?, an den Gr?sern, Halmen und Pfosten kletterten sie hoch und warfen aus der H?lle sich in die Luft zum kurzen Hochzeitsleben. Die Luft war wei? ?ber den Wassern von den auf und nieder tanzenden Massen ? und die sinkende Sonne in dem H?henrauch, den der Nordwind gebracht hatte, rot wie ein Rubin: das h?tte mich fast bezwungen, da? ich schon begann, die stundenkurze Existenz der Imago zu beklagen und daran sentimentale Folgerungen zu kn?pfen ? aber da h?rte ich den Enzian l?uten und ich lachte: Das Tier freut sich jahrelang seines R?uberlebens, und dieser Liebesflug ist sein taumelnder H?hepunkt. Es lebe das Leben und seine ewige Br?cke: Venus genetrix! Vor acht Tagen h?tte ich ihr geflucht und geklagt: Was ist das Leben? So ist das Leben: es flie?t dahin wie Wellenschaum, kommt u From fjo-lists at ogris.de Sun Mar 8 00:41:42 2009 From: fjo-lists at ogris.de (Felix J. Ogris) Date: Sun Mar 8 00:41:50 2009 Subject: CARP IP level load balancing In-Reply-To: Message-ID: On 1/20/09 3:30 PM, "Alexey Ivanov" wrote: > Is there any plans to port IP level LB from OpenBSD, and, if yes, will it be > ported to 7x and 6x? Feel free to port http://ogris.de/carp/carp_aa.patch to 7.x. Felix From patfbsd at davenulle.org Sun Mar 8 13:00:17 2009 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sun Mar 8 13:00:23 2009 Subject: misc/132277: poor performance using criptodevice for IPSEC Message-ID: <200903082000.n28K0B5B042748@freefall.freebsd.org> The following reply was made to PR kern/132277; it has been noted by GNATS. From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: bug-followup@FreeBSD.org Cc: Vasile Marii Subject: Re: misc/132277: poor performance using criptodevice for IPSEC Date: Sun, 8 Mar 2009 20:56:01 +0100 Le Tue, 3 Mar 2009 07:42:44 GMT, Vasile Marii : Hi, > Does anybody have any better results on glxsb or via?(i mean a netperf > test between two machines) or there is a hack or a setting in the > kernel or somewhere else? I've made some tests on IPsec with glxsb and the performances are very bad (around 14 Mbits). I think the problem is that glxsb handles only one request at a time. When it is busy, it blocks the Open Crypto Framework with ERESTART and it unblocks the OCF when the previous request is completed. Then the OCF has to wake up and to resubmit the request. It looks like this performs very badly when using it with IPsec. If glxsb processes the requests synchronously it performs quite better, around 50 Mbits. I will look for glxsb. From dfilter at FreeBSD.ORG Sun Mar 8 19:40:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sun Mar 8 19:40:10 2009 Subject: kern/132342: commit references a PR Message-ID: <200903090240.n292e4Ov062176@freefall.freebsd.org> The following reply was made to PR kern/132342; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132342: commit references a PR Date: Mon, 9 Mar 2009 02:38:02 +0000 (UTC) Author: sam Date: Mon Mar 9 02:37:52 2009 New Revision: 189550 URL: http://svn.freebsd.org/changeset/base/189550 Log: Fix TXPMGT handling: o correct dBm<->mW conversion logic o set net80211 TXPMGT capability only if driver reports it is capable PR: kern/132342 Submitted by: "Paul B. Mahol" Modified: head/sys/dev/if_ndis/if_ndis.c Modified: head/sys/dev/if_ndis/if_ndis.c ============================================================================== --- head/sys/dev/if_ndis/if_ndis.c Mon Mar 9 02:34:02 2009 (r189549) +++ head/sys/dev/if_ndis/if_ndis.c Mon Mar 9 02:37:52 2009 (r189550) @@ -102,7 +102,7 @@ SYSCTL_INT(_hw_ndisusb, OID_AUTO, halt, "Halt NDIS USB driver when it's attached"); /* 0 - 30 dBm to mW conversion table */ -const uint16_t dBm2mW[] = { +static const uint16_t dBm2mW[] = { 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 4, 4, 4, 5, 6, 6, 7, 8, 9, 10, 11, 13, 14, 16, 18, 20, 22, 25, 28, @@ -749,7 +749,7 @@ ndis_attach(dev) ic->ic_ifp = ifp; ic->ic_opmode = IEEE80211_M_STA; ic->ic_phytype = IEEE80211_T_DS; - ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS | IEEE80211_C_TXPMGT; + ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS; setbit(ic->ic_modecaps, IEEE80211_MODE_AUTO); len = 0; r = ndis_get_info(sc, OID_802_11_NETWORK_TYPES_SUPPORTED, @@ -928,6 +928,11 @@ got_crypto: r = ndis_get_info(sc, OID_802_11_POWER_MODE, &arg, &i); if (r == 0) ic->ic_caps |= IEEE80211_C_PMGT; + + r = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &i); + if (r == 0) + ic->ic_caps |= IEEE80211_C_TXPMGT; + bcopy(eaddr, &ic->ic_myaddr, sizeof(eaddr)); ieee80211_ifattach(ic); ic->ic_raw_xmit = ndis_raw_xmit; @@ -2325,9 +2330,10 @@ ndis_setstate_80211(sc) ndis_set_info(sc, OID_802_11_POWER_MODE, &arg, &len); /* Set TX power */ - if (ic->ic_txpowlimit < sizeof(dBm2mW)) { - len = sizeof(arg); + if ((ic->ic_caps & IEEE80211_C_TXPMGT) && + ic->ic_txpowlimit < (sizeof(dBm2mW) / sizeof(dBm2mW[0]))) { arg = dBm2mW[ic->ic_txpowlimit]; + len = sizeof(arg); ndis_set_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len); } @@ -2798,11 +2804,10 @@ ndis_getstate_80211(sc) } /* Get TX power */ - len = sizeof(arg); - rval = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len); - - if (!rval) { - for (i = 0; i < sizeof(dBm2mW); i++) + if (ic->ic_caps & IEEE80211_C_TXPMGT) { + len = sizeof(arg); + ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len); + for (i = 0; i < (sizeof(dBm2mW) / sizeof(dBm2mW[0])); i++) if (dBm2mW[i] >= arg) break; ic->ic_txpowlimit = i; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From yongari at FreeBSD.org Mon Mar 9 00:14:30 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Mon Mar 9 00:14:37 2009 Subject: kern/130846: [vge] vge0 not autonegotiating to 1000baseTX full duplex in 7.1 Message-ID: <200903090714.n297EUiE034558@freefall.freebsd.org> Synopsis: [vge] vge0 not autonegotiating to 1000baseTX full duplex in 7.1 Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Mar 9 07:13:48 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=130846 From kaushalshriyan at gmail.com Mon Mar 9 05:53:38 2009 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Mon Mar 9 09:01:35 2009 Subject: IP Route cache Message-ID: <6b16fb4c0903090527q3279daewcba65ec40882aa76@mail.gmail.com> Hi is there a way to enable IP Route Cache in FreeBSD ?. I am using FreeBSD as Firewall in my setup. Thanks and Regards Kaushal From bugmaster at FreeBSD.org Mon Mar 9 10:15:12 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 9 10:16:51 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200903091715.n29HF92K045326@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132342 net [ndis] [patch] incorrect number used in for loop; fix o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131310 net [panic] 7.1 panics with mpd netgraph interface changes o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R f kern/130605 net [tcp] Certain hardware produces "Network is unreachabl o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100839 net [txp] txp driver inconsistently stops working when the o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 264 problems total. From bms at incunabulum.net Mon Mar 9 10:58:05 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Mar 9 10:58:13 2009 Subject: HEADS UP: IGMPv3/SSM committed to IPv4 stack. Message-ID: <49B558A2.2050101@incunabulum.net> Hi all, Support for IGMPv3 and Source-Specific Multicast has now been committed to FreeBSD-CURRENT. At this point, the code is believed to be in a 'late beta' state suitable for more widespread testing. There may be some issues with recorded-source processing. Folk running multicast-enabled networks are encouraged to try the code and report any issues. Basic protocol verification has been performed manually using bleeding edge PCS from Mercurial: http://pcs.sourceforge.net/ If there are any issues, please contact me via email in the first instance. This work has been generously funded by a third party. thanks, BMS From richard at tector.org.uk Tue Mar 10 08:30:05 2009 From: richard at tector.org.uk (Richard Tector) Date: Tue Mar 10 08:30:11 2009 Subject: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock Message-ID: <200903101530.n2AFU3ud007640@freefall.freebsd.org> The following reply was made to PR kern/129846; it has been noted by GNATS. From: Richard Tector To: bug-followup@FreeBSD.org, koie@suri.co.jp Cc: Subject: Re: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock Date: Tue, 10 Mar 2009 15:25:42 +0000 This is a cryptographically signed message in MIME format. --------------ms070406050304010702070107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just a me too on 7.1-STABLE amd64 (as of 2009-03-05 at least). Note this does not happen with a 7.1-RELEASE kernel, so I'm assuming it's not userland. Regards, Richard --------------ms070406050304010702070107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHMDCC A5QwggL9oAMCAQICAQYwDQYJKoZIhvcNAQEEBQAwgYExCzAJBgNVBAYTAlVLMRYwFAYDVQQI Ew1TdGFmZm9yZHNoaXJlMQ4wDAYDVQQHEwVLZWVsZTEZMBcGA1UEChMQVGhlIEtlZWxlIENl bnRyZTEvMC0GA1UEAxMmVGhlIEtlZWxlIENlbnRyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkw HhcNMDYwOTI5MTQxNzE1WhcNMTAwOTI5MTQxNzE1WjCBhDELMAkGA1UEBhMCVUsxFjAUBgNV BAgTDVN0YWZmb3Jkc2hpcmUxEjAQBgNVBAcTCU5ld2Nhc3RsZTEKMAgGA1UEChMBIDEXMBUG A1UEAxMOUmljaGFyZCBUZWN0b3IxJDAiBgkqhkiG9w0BCQEWFXJpY2hhcmRAdGVjdG9yLm9y Zy51azCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqadxU4apjUusNPQIUTvEbH0DMoYD 0S1e8A/06cibkDaJfz7iLWqMTXhYbkq3FM7Ujjxx2Jw0JHUKo2uhrqjR0SjFhTzW1KvmhPCO MAfYht/NYjWCZzGcR3YdfNiWwBsWgCNxK3MonO8avT5CXT/NweMtZrDHhX2VquxD8v3/TlMC AwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJh dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBRzml/pUyA2Fw1CX1b2sikniz6NhzCBtgYDVR0j BIGuMIGrgBSNCaM0QC1N5Hiyb/MPAVd/ouQEEqGBh6SBhDCBgTELMAkGA1UEBhMCVUsxFjAU BgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2Vl bGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhv cml0eYIJAJZYbH4e6XXnMA0GCSqGSIb3DQEBBAUAA4GBAHObxzoGANKR90eLQMS6q/yfcJMu pHLoZT/UajG8cFdxzGxXNhuQhmYAfzUOqaJL/fMBznnNoRC7IHS+iCWCI2v2Rp9cDkoFw0m1 lvp5boNpYMPGPGNfemedVGzY4vDxI4o6bBCut47KGr3+wNA/+oHtHmCBQ6WdP/WEDjsSnmeM MIIDlDCCAv2gAwIBAgIBBjANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCVUsxFjAUBgNV BAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2VlbGUg Q2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhvcml0 eTAeFw0wNjA5MjkxNDE3MTVaFw0xMDA5MjkxNDE3MTVaMIGEMQswCQYDVQQGEwJVSzEWMBQG A1UECBMNU3RhZmZvcmRzaGlyZTESMBAGA1UEBxMJTmV3Y2FzdGxlMQowCAYDVQQKEwEgMRcw FQYDVQQDEw5SaWNoYXJkIFRlY3RvcjEkMCIGCSqGSIb3DQEJARYVcmljaGFyZEB0ZWN0b3Iu b3JnLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpp3FThqmNS6w09AhRO8RsfQMy hgPRLV7wD/TpyJuQNol/PuItaoxNeFhuSrcUztSOPHHYnDQkdQqja6GuqNHRKMWFPNbUq+aE 8I4wB9iG381iNYJnMZxHdh182JbAGxaAI3Ercyic7xq9PkJdP83B4y1msMeFfZWq7EPy/f9O UwIDAQABo4IBFTCCAREwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5l cmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHOaX+lTIDYXDUJfVvayKSeLPo2HMIG2BgNV HSMEga4wgauAFI0JozRALU3keLJv8w8BV3+i5AQSoYGHpIGEMIGBMQswCQYDVQQGEwJVSzEW MBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUxGTAXBgNVBAoTEFRoZSBL ZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUgQ2VydGlmaWNhdGUgQXV0 aG9yaXR5ggkAllhsfh7pdecwDQYJKoZIhvcNAQEEBQADgYEAc5vHOgYA0pH3R4tAxLqr/J9w ky6kcuhlP9RqMbxwV3HMbFc2G5CGZgB/NQ6pokv98wHOec2hELsgdL6IJYIja/ZGn1wOSgXD SbWW+nlug2lgw8Y8Y196Z51UbNji8PEjijpsEK63jsoavf7A0D/6ge0eYIFDpZ0/9YQOOxKe Z4wxggMbMIIDFwIBATCBhzCBgTELMAkGA1UEBhMCVUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hp cmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQD EyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhvcml0eQIBBjAJBgUrDgMCGgUA oIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMTAx NTI1NDJaMCMGCSqGSIb3DQEJBDEWBBTJYQ3hrFto8zT3gMiVH9oG2swxnDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBmAYJKwYBBAGCNxAEMYGKMIGHMIGBMQswCQYDVQQGEwJV SzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUxGTAXBgNVBAoTEFRo ZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgEGMIGaBgsqhkiG9w0BCRACCzGBiqCBhzCBgTELMAkGA1UEBhMCVUsxFjAU BgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2Vl bGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhv cml0eQIBBjANBgkqhkiG9w0BAQEFAASBgFypCanQMLA0VnZMvXy5/XhDQIH9v8TzcXZa4qUg Rkc4jSe8JixgcP8WP+Hkwx5hweS1AgWFg07lk/cLwIXSSKKuv9RjtKgYKZF7q06KutaVlTz4 7bhlrATb9zmKmnGqtK+SNJ5myeKEARVBO5DsuiWW9d+F9yy7U+rDdaifiNJCAAAAAAAA --------------ms070406050304010702070107-- From jchambers at ucla.edu Tue Mar 10 16:05:59 2009 From: jchambers at ucla.edu (Jason Chambers) Date: Tue Mar 10 16:06:06 2009 Subject: [this can be closed] ---> kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools In-Reply-To: <200903021130.n22BU5Jr076050@freefall.freebsd.org> References: <200903021130.n22BU5Jr076050@freefall.freebsd.org> Message-ID: <49B6F24B.5020004@ucla.edu> FYI again. --Jason Jason Chambers wrote: > The following reply was made to PR kern/130605; it has been noted by GNATS. > > From: Jason Chambers > To: bug-followup@FreeBSD.org, jchambers@ucla.edu > Cc: > Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" > errors for scanning tools > Date: Mon, 02 Mar 2009 03:26:43 -0800 > > Hello all. > > The Nessus problem was finally identified to be caused by incompatible > ABI system calls. > > As for the general "Network is unreachable" error I assume this to be > due to the condition described or incorrect implementation of said > security tools on FreeBSD. > > Thanks for the help, this PR can be closed. > > --Jason > > _______________________________________________ > 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 gavin at FreeBSD.org Wed Mar 11 08:12:12 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Mar 11 08:12:18 2009 Subject: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Message-ID: <200903111512.n2BFCB8r091372@freefall.freebsd.org> Synopsis: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Wed Mar 11 15:09:08 UTC 2009 State-Changed-Why: Close, submitter is happy that this has been resolved (see also 132518) http://www.freebsd.org/cgi/query-pr.cgi?pr=130605 From rwatson at FreeBSD.org Wed Mar 11 13:50:39 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Wed Mar 11 13:50:45 2009 Subject: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock Message-ID: <200903112050.n2BKocsF022677@freefall.freebsd.org> Synopsis: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: rwatson Responsible-Changed-When: Wed Mar 11 20:50:01 UTC 2009 Responsible-Changed-Why: Grab ownership. http://www.freebsd.org/cgi/query-pr.cgi?pr=129846 From rwatson at FreeBSD.org Wed Mar 11 13:53:32 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Mar 11 13:53:42 2009 Subject: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock In-Reply-To: <200903101530.n2AFU3ud007640@freefall.freebsd.org> References: <200903101530.n2AFU3ud007640@freefall.freebsd.org> Message-ID: On Tue, 10 Mar 2009, Richard Tector wrote: > Just a me too on 7.1-STABLE amd64 (as of 2009-03-05 at least). Note this > does not happen with a 7.1-RELEASE kernel, so I'm assuming it's not > userland. This problem is believed fixed as of r189531, committed 8 March -- could you try updating and see if that helps? A more complete description of the problem can be found here: http://www.freebsd.org/cgi/query-pr.cgi?pr=132222 Robert N M Watson Computer Laboratory University of Cambridge From bms at incunabulum.net Wed Mar 11 16:49:37 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Mar 11 16:49:44 2009 Subject: HEADS UP: multicast forwarding ipv4/ipv6 split and fine grained locking patch Message-ID: <49B84E08.3020107@incunabulum.net> Hi all, If you look at this URL: http://people.freebsd.org/~bms/stage/mrouting/ ...I have two patches which considerably clean up IPv4 multicast forwarding. Summary of changes: The ip_mroute.ko module is also split into two, and the dependencies between IPv4 and IPv6 are untangled. BSD constructs are now used for the data structures in MROUTING, and some but not all style(9) bugs fixed. Fine grained locking is added. The MFC and VIF tables are exported from the live kernel via sysctl, which allows netstat with MROUTING to be built without libkvm support. I'd like to hear from folk who are able to give these patches more in-depth testing before I go ahead and commit them. thanks! BMS From yongari at FreeBSD.org Wed Mar 11 19:41:02 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Wed Mar 11 19:41:09 2009 Subject: kern/100839: [txp] txp driver inconsistently stops working when the interface is brought down and back up Message-ID: <200903120241.n2C2f2IJ074894@freefall.freebsd.org> Synopsis: [txp] txp driver inconsistently stops working when the interface is brought down and back up State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Thu Mar 12 02:39:48 UTC 2009 State-Changed-Why: I've committed overhauled txp(4) to HEAD. Now txp(4) always start from known state by downloading firmware in interface up time so it may have fixed your issue. Would you give it a try on your box? Download the following files and it should build without problems on 7.1-RELEASE/7-stable/CURRENT. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/txp/3c990img.h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/txp/if_txp.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/txp/if_txpreg.h Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Mar 12 02:39:48 UTC 2009 Responsible-Changed-Why: I've committed overhauled txp(4). Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=100839 From linimon at FreeBSD.org Wed Mar 11 23:24:30 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 11 23:24:37 2009 Subject: kern/132554: [ipfilter] There is no ippool start script/ipfilter magic to load them Message-ID: <200903120624.n2C6OS65070124@freefall.freebsd.org> Old Synopsis: There is no ippool start script/ipfilter magic to load them New Synopsis: [ipfilter] There is no ippool start script/ipfilter magic to load them Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 12 06:23:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132554 From richardtector at thekeelecentre.com Thu Mar 12 08:06:25 2009 From: richardtector at thekeelecentre.com (Richard Tector) Date: Thu Mar 12 08:06:41 2009 Subject: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock In-Reply-To: References: <200903101530.n2AFU3ud007640@freefall.freebsd.org> Message-ID: <49B92090.40406@thekeelecentre.com> Robert Watson wrote: > On Tue, 10 Mar 2009, Richard Tector wrote: > >> Just a me too on 7.1-STABLE amd64 (as of 2009-03-05 at least). Note >> this does not happen with a 7.1-RELEASE kernel, so I'm assuming it's >> not userland. > > This problem is believed fixed as of r189531, committed 8 March -- could > you try updating and see if that helps? A more complete description of > the problem can be found here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=132222 > Been running for just over 14 hours now with the new kernel and no problems observed. I think can you close this PR now, thanks. Regards, Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2709 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090312/42fd9913/smime.bin From ivoras at freebsd.org Thu Mar 12 08:21:58 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Mar 12 08:22:04 2009 Subject: IPFW and IPv6 TCP timeout problem In-Reply-To: <29230.62.12.14.25.1236258269.squirrel@jodocus.org> References: <29230.62.12.14.25.1236258269.squirrel@jodocus.org> Message-ID: <49B92870.1090600@freebsd.org> Joost Bekkers wrote: > On Thu, March 5, 2009 12:30, Ivan Voras wrote: >> Hi, >> >> It appears that IPFW drops dynamic (state-keeping) rules for idle IPv6 >> TCP connections after a short (60 seconds by default) timeout. This of >> course creates problems for services like SSH and NFS. I've contacted >> Luigi Rizzo about it but he cannot help with the IPv6 part of the ipfw. >> His guess is that the part that should send keepalive ACK packets like >> ipfw does for IPv4 is broken or nonexistent for IPv6. >> >> Any takers? Should I file a PR? >> >> > > You might want to check if kern/117234 is relevant here. I've got a > feeling this is the problem you're seeing. > > The PR includes a patch, it just needs somebody to commit it. I'm running a patched kernel now and it doesn't fix the issue - the dynamic rules continue to disappear after the timeout like before. Maybe the patch solves something else? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090312/af91aa65/signature.pgp From stb at lassitu.de Thu Mar 12 08:30:32 2009 From: stb at lassitu.de (Stefan Bethke) Date: Thu Mar 12 08:30:39 2009 Subject: Multi-homing, jails, and source address selection Message-ID: I'm having some trouble configuring a dual-homed jail host, running - current from about 4 weeks ago. My machine has one external interface em0 connected to an /27 IPv4 network. Additionally, I have a VPN interface tun0 provided by an OpenVPN instance with a private /18 range. I'd like my jails to be dual-homed, with a public and a VPN address each. Processes in the jail should pick the appropriate source address depending on the destination address, so that the source address for a connection going to a VPN address will be the jails' VPN address, and all other connections will use the jails' public IP. I have a couple of questions that I can't seem to find answers to: How do I get the VPN addresses configured? tun0 won't accept them (since ptp interfaces require a destination address). If I use lo0, I seem to have source address selection issues. I've experimented with various setups, but haven't found one that would work just right. In the example below, if I ping from foo to a VPN address, the source address is foo's public IP. If I run ping with -S10.0.63.3, the source address still is 192.0.2.3. Is there any documentation on how source addresses are selected? I thought I remembered that on unbound sockets the destination route would be used to pick the first address of the outgoing interface as the source address; the same address would be picked on connecting a socket. I'm currently running with this configuration in rc.conf: cloned_interfaces="tun0" ifconfig_em0="192.0.2.2/27" ifconfig_tun0="10.0.63.1 10.0.63.255" defaultrouter="192.0.2.1" inetd_flags="-wW -a 192.0.2.2" static_routes="openvpn" route_openvpn="10.0.0.0/18 10.0.63.255" jail_enable="YES" jail_set_hostname_allow="NO" jail_sysvipc_allow="YES" jail_devfs_enable="YES" jail_mount_enable="YES" jail_list="foo bar baz" jail_foo_rootdir="/jail/foo.example.com" jail_foo_hostname="foo.example.com" jail_foo_ip="em0|192.0.2.3,lo0|10.0.63.3" Any suggestions? -- Stefan Bethke Fon +49 151 14070811 From joost at jodocus.org Thu Mar 12 09:50:56 2009 From: joost at jodocus.org (Joost Bekkers) Date: Thu Mar 12 09:51:03 2009 Subject: IPFW and IPv6 TCP timeout problem In-Reply-To: <49B92870.1090600@freebsd.org> References: <29230.62.12.14.25.1236258269.squirrel@jodocus.org> <49B92870.1090600@freebsd.org> Message-ID: <2498.192.168.100.227.1236876651.squirrel@jodocus.org> On Thu, March 12, 2009 16:21, Ivan Voras wrote: > Joost Bekkers wrote: >> On Thu, March 5, 2009 12:30, Ivan Voras wrote: >>> Hi, >>> >>> It appears that IPFW drops dynamic (state-keeping) rules for idle IPv6 >>> TCP connections after a short (60 seconds by default) timeout. This of >>> course creates problems for services like SSH and NFS. I've contacted >>> Luigi Rizzo about it but he cannot help with the IPv6 part of the ipfw. >>> His guess is that the part that should send keepalive ACK packets like >>> ipfw does for IPv4 is broken or nonexistent for IPv6. >>> >>> Any takers? Should I file a PR? >>> >>> >> >> You might want to check if kern/117234 is relevant here. I've got a >> feeling this is the problem you're seeing. >> >> The PR includes a patch, it just needs somebody to commit it. > > I'm running a patched kernel now and it doesn't fix the issue - the > dynamic rules continue to disappear after the timeout like before. > > Maybe the patch solves something else? The patch solves a problem where dyn-rules for idle connections are dropped after net.inet.ip.fw.dyn_ack_lifetime because the keep-alive packets aren't being send. Sounds suspiciously the same to me... You did use the later patch in the pr and not max's, right? The first patch in the pr sends keep-alives to the wrong port. I'm assuming the timer does get reset whenever the connection is in use, so if there is a response to a keep-alive that packet reaches check-state. Can you do a tcpdump to see if keep-alives are being sent. They should appear in the last 20 seconds of the dyn-rule timer. Joost. From barney_cordoba at yahoo.com Thu Mar 12 15:12:11 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu Mar 12 15:12:18 2009 Subject: CARP IP level load balancing In-Reply-To: Message-ID: <278464.35012.qm@web63907.mail.re1.yahoo.com> --- On Sun, 3/8/09, Felix J. Ogris wrote: > From: Felix J. Ogris > Subject: Re: CARP IP level load balancing > To: freebsd-net@freebsd.org > Date: Sunday, March 8, 2009, 4:24 AM > On 1/20/09 3:30 PM, "Alexey Ivanov" > wrote: > > > Is there any plans to port IP level LB from OpenBSD, > and, if yes, will it be > > ported to 7x and 6x? > > Feel free to port http://ogris.de/carp/carp_aa.patch to > 7.x. > > Felix > Is there some difference from LAGG? Barney From scf at FreeBSD.org Thu Mar 12 18:54:37 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Thu Mar 12 18:54:44 2009 Subject: tap(4) SIOCSIFMTU patch Message-ID: Here is a patch[1] that will allow the MTU to be set higher than 1500 on a tap(4) interface. I ran into the need to do this when I had em0 set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for QEMU. A bridge interface will not allow interfaces with different MTU's to be added to it. Since I have touched little inside the kernel, I thought it best if others take a look at it first. Sean 1. http://people.freebsd.org/~scf/if_tap-SIOCSIFMTU.patch -- scf@FreeBSD.org From pluknet at gmail.com Thu Mar 12 23:06:24 2009 From: pluknet at gmail.com (pluknet) Date: Thu Mar 12 23:06:31 2009 Subject: CARP IP level load balancing In-Reply-To: <278464.35012.qm@web63907.mail.re1.yahoo.com> References: <278464.35012.qm@web63907.mail.re1.yahoo.com> Message-ID: 2009/3/13 Barney Cordoba : > > > > > --- On Sun, 3/8/09, Felix J. Ogris wrote: > >> From: Felix J. Ogris >> Subject: Re: CARP IP level load balancing >> To: freebsd-net@freebsd.org >> Date: Sunday, March 8, 2009, 4:24 AM >> On 1/20/09 3:30 PM, "Alexey Ivanov" >> wrote: >> >> > Is there any plans to port IP level LB from OpenBSD, >> and, if yes, will it be >> > ported to 7x and 6x? >> >> Feel free to port http://ogris.de/carp/carp_aa.patch to >> 7.x. >> >> Felix >> > > Is there some difference from LAGG? > > Barney > Difference in what we count as "the point of refuse". -- wbr, pluknet From vova at parallels.com Fri Mar 13 02:26:43 2009 From: vova at parallels.com (Vladimir Grebenschikov) Date: Fri Mar 13 02:26:51 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() Message-ID: <1236934375.2583.6.camel@localhost> Hi Recent 8-CURRENT Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05f7251 stack pointer = 0x28:0xc4a8db8c frame pointer = 0x28:0xc4a8dc24 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock) ... #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0478399 in db_fncall (dummy1=0, dummy2=0, dummy3=-1065953936, dummy4=0xc4a8d930 "p??,\004") at /usr/src/sys/ddb/db_command.c:548 #2 0xc0478791 in db_command (last_cmdp=0xc075709c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04788ea in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc047a72d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc05798a4 in kdb_trap (type=12, code=0, tf=0xc4a8db4c) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc06bb70f in trap_fatal (frame=0xc4a8db4c, eva=20) at /usr/src/sys/i386/i386/trap.c:917 #7 0xc06bb9b0 in trap_pfault (frame=0xc4a8db4c, usermode=0, eva=20) at /usr/src/sys/i386/i386/trap.c:839 #8 0xc06bc312 in trap (frame=0xc4a8db4c) at /usr/src/sys/i386/i386/trap.c:521 #9 0xc06a331b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc05f7251 in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:1817 #11 0xc0598e29 in pffasttimo (arg=0x0) at /usr/src/sys/kern/uipc_domain.c:498 #12 0xc0562cbc in softclock (arg=0xc076ddc0) at /usr/src/sys/kern/kern_timeout.c:411 #13 0xc053021b in intr_event_execute_handlers (p=0xc4c61a90, ie=0xc4c9c200) at /usr/src/sys/kern/kern_intr.c:1134 #14 0xc05315ca in ithread_loop (arg=0xc4c472f0) at /usr/src/sys/kern/kern_intr.c:1147 ---Type to continue, or q to quit--- #15 0xc052db70 in fork_exit (callout=0xc0531560 , arg=0xc4c472f0, frame=0xc4a8dd38) at /usr/src/sys/kern/kern_fork.c:821 #16 0xc06a3390 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) fr 10 #10 0xc05f7251 in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:1817 1817 if (inm->inm_timer == 0) { (kgdb) This happens when I've configured IP-TV on DSL rounter, and though TV should go to another port (ethernet) FreeBSD kernel now crashes while try to get connected through WiFi. If I try to connect through wired port to same broadcast domain - everything in ok. Wireless card: ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: AR5413 mac 10.3 RF5424 phy 6.1 key_mgmt=WPA-PSK with wpa_supplicant crash is 100% reproducible -- Vladimir B. Grebenschikov Project Manager, Automation Parallels Inc. vova@parallels.com From rpaulo at freebsd.org Fri Mar 13 02:36:59 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Fri Mar 13 02:37:06 2009 Subject: tap(4) SIOCSIFMTU patch In-Reply-To: References: Message-ID: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> On 13 Mar 2009, at 01:54, Sean C. Farley wrote: > Here is a patch[1] that will allow the MTU to be set higher than > 1500 on a tap(4) interface. I ran into the need to do this when I > had em0 set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for > QEMU. A bridge interface will not allow interfaces with different > MTU's to be added to it. > > Since I have touched little inside the kernel, I thought it best if > others take a look at it first. > > Sean > 1. http://people.freebsd.org/~scf/if_tap-SIOCSIFMTU.patch This looks ok. I'm assuming bridge now works for you. Regards -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090313/69d323f5/PGP.pgp From vova at fbsd.ru Fri Mar 13 02:41:03 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Mar 13 02:41:16 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() Message-ID: <1236937253.2282.0.camel@localhost> Hi Recent 8-CURRENT Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05f7251 stack pointer = 0x28:0xc4a8db8c frame pointer = 0x28:0xc4a8dc24 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock) ... #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0478399 in db_fncall (dummy1=0, dummy2=0, dummy3=-1065953936, dummy4=0xc4a8d930 "p??,\004") at /usr/src/sys/ddb/db_command.c:548 #2 0xc0478791 in db_command (last_cmdp=0xc075709c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04788ea in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc047a72d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc05798a4 in kdb_trap (type=12, code=0, tf=0xc4a8db4c) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc06bb70f in trap_fatal (frame=0xc4a8db4c, eva=20) at /usr/src/sys/i386/i386/trap.c:917 #7 0xc06bb9b0 in trap_pfault (frame=0xc4a8db4c, usermode=0, eva=20) at /usr/src/sys/i386/i386/trap.c:839 #8 0xc06bc312 in trap (frame=0xc4a8db4c) at /usr/src/sys/i386/i386/trap.c:521 #9 0xc06a331b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc05f7251 in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:1817 #11 0xc0598e29 in pffasttimo (arg=0x0) at /usr/src/sys/kern/uipc_domain.c:498 #12 0xc0562cbc in softclock (arg=0xc076ddc0) at /usr/src/sys/kern/kern_timeout.c:411 #13 0xc053021b in intr_event_execute_handlers (p=0xc4c61a90, ie=0xc4c9c200) at /usr/src/sys/kern/kern_intr.c:1134 #14 0xc05315ca in ithread_loop (arg=0xc4c472f0) at /usr/src/sys/kern/kern_intr.c:1147 ---Type to continue, or q to quit--- #15 0xc052db70 in fork_exit (callout=0xc0531560 , arg=0xc4c472f0, frame=0xc4a8dd38) at /usr/src/sys/kern/kern_fork.c:821 #16 0xc06a3390 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) fr 10 #10 0xc05f7251 in igmp_fasttimo () at /usr/src/sys/netinet/igmp.c:1817 1817 if (inm->inm_timer == 0) { (kgdb) This happens when I've configured IP-TV on DSL rounter, and though TV should go to another port (ethernet) FreeBSD kernel now crashes while try to get connected through WiFi. If I try to connect through wired port to same broadcast domain - everything in ok. Wireless card: ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: AR5413 mac 10.3 RF5424 phy 6.1 key_mgmt=WPA-PSK with wpa_supplicant crash is 100% reproducible With older kernel (4 mar 2009) everything working as expected. -- Vladimir B. Grebenschikov Project Manager, Automation Parallels Inc. vova@parallels.com -- Vladimir B. Grebenschikov vova@fbsd.ru From rwatson at FreeBSD.org Fri Mar 13 04:35:14 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Mar 13 04:35:20 2009 Subject: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock In-Reply-To: <49B92090.40406@thekeelecentre.com> References: <200903101530.n2AFU3ud007640@freefall.freebsd.org> <49B92090.40406@thekeelecentre.com> Message-ID: On Thu, 12 Mar 2009, Richard Tector wrote: > Robert Watson wrote: >> On Tue, 10 Mar 2009, Richard Tector wrote: >> >>> Just a me too on 7.1-STABLE amd64 (as of 2009-03-05 at least). Note this >>> does not happen with a 7.1-RELEASE kernel, so I'm assuming it's not >>> userland. >> >> This problem is believed fixed as of r189531, committed 8 March -- could >> you try updating and see if that helps? A more complete description of the >> problem can be found here: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=132222 > > Been running for just over 14 hours now with the new kernel and no problems > observed. I think can you close this PR now, thanks. Thanks for the feedback -- let me know if you see the problem recur. Robert N M Watson Computer Laboratory University of Cambridge From scf at FreeBSD.org Fri Mar 13 07:22:55 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Fri Mar 13 07:24:20 2009 Subject: tap(4) SIOCSIFMTU patch In-Reply-To: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> References: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> Message-ID: On Fri, 13 Mar 2009, Rui Paulo wrote: > On 13 Mar 2009, at 01:54, Sean C. Farley wrote: > >> Here is a patch[1] that will allow the MTU to be set higher than 1500 >> on a tap(4) interface. I ran into the need to do this when I had em0 >> set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for QEMU. A >> bridge interface will not allow interfaces with different MTU's to be >> added to it. >> >> Since I have touched little inside the kernel, I thought it best if >> others take a look at it first. >> >> Sean >> 1. http://people.freebsd.org/~scf/if_tap-SIOCSIFMTU.patch > > This looks ok. I'm assuming bridge now works for you. Thank you for reviewing it. Yes, this fixes my issue with bridging a tap device to an interface with an MTU higher than 1500. I will probably commit this patch this weekend. Sean -- scf@FreeBSD.org From healer at rpi.edu Fri Mar 13 09:50:04 2009 From: healer at rpi.edu (Robert Healey) Date: Fri Mar 13 09:50:11 2009 Subject: kern/122252: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) Message-ID: <200903131650.n2DGo4B7087891@freefall.freebsd.org> The following reply was made to PR kern/122252; it has been noted by GNATS. From: Robert Healey To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/122252: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) Date: Fri, 13 Mar 2009 11:33:41 -0400 I am having a similar issue to this bug, only I get a hard lock instead of a reboot. I have a Supermicro H8SSL-i2 board with Opteron 1000 series chip and Serverworks chipset. When I have hw.bg.allow_asf enabled, the last output I get is the kernel printing the mac address for the TAP interface I initialize for later use with OpenVPN. bge0 has the IPMI card connected to it, bge1 has 2 802.1q interfaces attached to it. Thank you for your time. Bob Healey pciconf -lv: pisces# pciconf -lv pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0x00361166 rev=0x00 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'HT1000 PCI/PCI-X bridge' class = bridge subclass = PCI-PCI hostb0@pci0:0:2:0: class=0x060000 card=0x02011166 chip=0x02051166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'HT1000 Legacy South Bridge' class = bridge subclass = HOST-PCI atapci1@pci0:0:2:1: class=0x01018a card=0x02141166 chip=0x02141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'HT1000 Legacy IDE controller' class = mass storage subclass = ATA isab0@pci0:0:2:2: class=0x060100 card=0x02301166 chip=0x02341166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'HT1000 LPC Bridge' class = bridge subclass = PCI-ISA ohci0@pci0:0:3:0: class=0x0c0310 card=0x02231166 chip=0x02231166 rev=0x01 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = '0x0223 USB controller' class = serial bus subclass = USB ohci1@pci0:0:3:1: class=0x0c0310 card=0x02231166 chip=0x02231166 rev=0x01 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = '0x0223 USB controller' class = serial bus subclass = USB ehci0@pci0:0:3:2: class=0x0c0320 card=0x02231166 chip=0x02231166 rev=0x01 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = '0x0223 USB controller' class = serial bus subclass = USB vgapci0@pci0:0:5:0: class=0x030000 card=0x515e1002 chip=0x515e1002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon ES1000 Radeon ES1000' class = display subclass = VGA hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI pcib2@pci0:1:13:0: class=0x060400 card=0x00000000 chip=0x01041166 rev=0xb2 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'HT1000 PCI/PCI-X bridge' class = bridge subclass = PCI-PCI atapci0@pci0:1:14:0: class=0x010405 card=0x024a1166 chip=0x024a1166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5785 (HT1000) SATA Native SATA Mode' class = mass storage subclass = RAID bge0@pci0:2:3:0: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class = network subclass = ethernet bge1@pci0:2:3:1: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class = network subclass = ethernet dmesg.boot: pisces# cat /var/run/dmesg.boot Copyright (c) 1992-2009 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.1-RELEASE-p3 #1: Wed Mar 4 00:37:19 EST 2009 root@pisces.phys.rpi.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual-Core AMD Opteron(tm) Processor 1210 (1795.51-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f32 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 usable memory = 1060282368 (1011 MB) avail memory = 1021526016 (974 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 540, 20 (4) failed acpi0: reservation of 500, 20 (4) failed acpi0: reservation of 560, 20 (4) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 bge0: mem 0xff490000-0xff49ffff irq 24 at device 3.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:30:48:5e:6e:06 bge0: [ITHREAD] bge1: mem 0xff480000-0xff48ffff irq 25 at device 3.1 on pci2 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:30:48:5e:6e:07 bge1: [ITHREAD] atapci0: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb41f mem 0xff5fe000-0xff5fffff irq 11 at device 14.0 on pci1 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 2.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] isab0: at device 2.2 on pci0 isa0: on isab0 ohci0: port 0xe800-0xe8ff mem 0xff6eb000-0xff6ebfff irq 10 at device 3.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: port 0xd800-0xd8ff mem 0xff6ea000-0xff6eafff irq 10 at device 3.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: port 0xd400-0xd4ff mem 0xff6e9000-0xff6e9fff irq 10 at device 3.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: <(0x1166) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2 uhub2: 4 ports with 4 removable, self powered vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf7ffffff,0xff6f0000-0xff6fffff irq 19 at device 5.0 on pci0 k8temp0: on hostb4 acpi_button0: on acpi0 acpi_button1: on acpi0 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 Generic PS/2 mouse, device ID 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 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] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcdfff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 ad4: 238475MB at ata2-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted tap0: Ethernet address: 00:bd:6e:ad:02:00 bge1: link state changed to UP vlan0: link state changed to UP vlan1: link state changed to UP bge0: link state changed to UP Limiting icmp unreach response from 228 to 200 packets/sec -- Bob Healey Systems Administrator Physics Department, RPI healer@rpi.edu From bms at incunabulum.net Fri Mar 13 16:17:51 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Mar 13 16:17:58 2009 Subject: tap(4) SIOCSIFMTU patch In-Reply-To: References: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> Message-ID: <49BAE99B.2030508@incunabulum.net> Sean C. Farley wrote: > > Yes, this fixes my issue with bridging a tap device to an interface > with an MTU higher than 1500. > I will probably commit this patch this weekend. I can't think of any reason why not, other than you might want to ensure that tap's MTU is bounded within reasonable limits, 'cause yoi don't want to exhaust the jumbo cluster pool if say mtu is more than 9000. I think ifconfig already performs such a check but you might want to double check. cheers BMS From bms at incunabulum.net Fri Mar 13 16:22:11 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Mar 13 16:22:23 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <1236937253.2282.0.camel@localhost> References: <1236937253.2282.0.camel@localhost> Message-ID: <49BAEA9F.8020302@incunabulum.net> Thanks for this report. Sam has reported wihat I believe is the same issue. I haven't had a chance to look at this yet, I'm absolutely exhausted from working on some other stuff that had to happen right away. From scf at FreeBSD.org Fri Mar 13 16:53:59 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Fri Mar 13 16:54:05 2009 Subject: tap(4) SIOCSIFMTU patch In-Reply-To: <49BAE99B.2030508@incunabulum.net> References: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> <49BAE99B.2030508@incunabulum.net> Message-ID: On Fri, 13 Mar 2009, Bruce Simpson wrote: > Sean C. Farley wrote: >> >> Yes, this fixes my issue with bridging a tap device to an interface >> with an MTU higher than 1500. I will probably commit this patch this >> weekend. > > I can't think of any reason why not, other than you might want to > ensure that tap's MTU is bounded within reasonable limits, 'cause yoi > don't want to exhaust the jumbo cluster pool if say mtu is more than > 9000. I was letting ifhwioctl() perform the MTU limit check. It insures: IF_MINMTU <= ifr->ifr_mtu <= IF_MAXMTU I admitted to being new. See! :) Exhausting the jumbo cluster pool refers to kern.ipc.nmbjumbo[p|9|16], yes? em(4) has an upper limit of 16114 for MTU. I could limit the MTU to TAPMRU (16384) which is the limit for a write to the driver anyway. > I think ifconfig already performs such a check but you might want to double > check. I noticed that ifconfig can report JUMBO_MTU, but few drivers actually flag it. Should I set this for tap? Sean -- scf@FreeBSD.org From bms at incunabulum.net Fri Mar 13 18:06:28 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Mar 13 18:06:33 2009 Subject: tap(4) SIOCSIFMTU patch In-Reply-To: References: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> <49BAE99B.2030508@incunabulum.net> Message-ID: <49BB030F.5010201@incunabulum.net> Sean C. Farley wrote: > ... > Exhausting the jumbo cluster pool refers to kern.ipc.nmbjumbo[p|9|16], > yes? em(4) has an upper limit of 16114 for MTU. I could limit the > MTU to TAPMRU (16384) which is the limit for a write to the driver > anyway. Just waiting for my VFS cache to spool up after a fresh boot with the KScope goggles on... Sounds realistic. I seem to recall that whilst IPv6 will allow for truly massive datagrams, the KAME implementation didn't support up to the full size. I can't believe that's going to be a real issue, though. Even lo(4) won't bump its MTU up to 128KB unless told to (LARGE_LOMTU def). It's hardcoded for lo(4). In this case it probably isn't anyting to worry about -- it's pilot error, for now, if the MTU is set too high on an ifnet. You just need to keep an eye out for it, because tap(4) relies utterly on m_uiotombuf() on the U->K path, and it will try to allocate jumbo clusters upfront first thing. > >> I think ifconfig already performs such a check but you might want to >> double check. > > I noticed that ifconfig can report JUMBO_MTU, but few drivers actually > flag it. Should I set this for tap? I don't think it's going to be a problem. lo(4) just passes the MTU down to the ifnet struct as your patch does. Go ahead and commit! And thanks! cheers, BMS From bms at incunabulum.net Fri Mar 13 18:49:56 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Mar 13 18:50:08 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BAEA9F.8020302@incunabulum.net> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> Message-ID: <49BB0D3E.2020306@incunabulum.net> All I have in the kit box is what appears to be a Belkin branded Ralink cardbus card. I think it's a Ralikn 25xx. I have a PCI-Cardbus bridge, so I'm going to leave a NanoBSD image of SVN HEAD to cook in the background whilst I sort out my humanity... From patfbsd at davenulle.org Sat Mar 14 05:10:03 2009 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sat Mar 14 05:10:10 2009 Subject: misc/132277: poor performance using criptodevice for IPSEC Message-ID: <200903141210.n2ECA3TH019354@freefall.freebsd.org> The following reply was made to PR kern/132277; it has been noted by GNATS. From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: bug-followup@FreeBSD.org Cc: Vasile Marii Subject: Re: misc/132277: poor performance using criptodevice for IPSEC Date: Sat, 14 Mar 2009 13:05:52 +0100 Le Sun, 8 Mar 2009 20:00:11 GMT, Patrick Lamaizière : > I've made some tests on IPsec with glxsb and the performances are > very bad (around 14 Mbits). > > I think the problem is that glxsb handles only one request at a time. > When it is busy, it blocks the Open Crypto Framework with ERESTART > and it unblocks the OCF when the previous request is completed. Then > the OCF has to wake up and to resubmit the request. It looks like > this performs very badly when using it with IPsec. > > If glxsb processes the requests synchronously it performs quite > better, around 50 Mbits. I've filled a PR with a patch for glxb(4): kern/132622 Regards. From linimon at FreeBSD.org Sat Mar 14 08:33:41 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Mar 14 08:33:48 2009 Subject: kern/132625: [iwn] iwn drivers don't support setting country Message-ID: <200903141533.n2EFXeqK093608@freefall.freebsd.org> Old Synopsis: iwn drivers don't support setting country New Synopsis: [iwn] iwn drivers don't support setting country Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 14 15:33:13 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132625 From bzeeb-lists at lists.zabbadoz.net Sat Mar 14 11:05:10 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Mar 14 11:05:17 2009 Subject: Multi-homing, jails, and source address selection In-Reply-To: References: Message-ID: <20090314174526.E96785@maildrop.int.zabbadoz.net> On Thu, 12 Mar 2009, Stefan Bethke wrote: Hi, > I'm having some trouble configuring a dual-homed jail host, running -current > from about 4 weeks ago. > > My machine has one external interface em0 connected to an /27 IPv4 network. > Additionally, I have a VPN interface tun0 provided by an OpenVPN instance > with a private /18 range. > > I'd like my jails to be dual-homed, with a public and a VPN address each. > Processes in the jail should pick the appropriate source address depending on > the destination address, so that the source address for a connection going to > a VPN address will be the jails' VPN address, and all other connections will > use the jails' public IP. > > I have a couple of questions that I can't seem to find answers to: > > How do I get the VPN addresses configured? tun0 won't accept them (since ptp > interfaces require a destination address). If I use lo0, I seem to have > source address selection issues. I've experimented with various setups, but > haven't found one that would work just right. In the example below, if I > ping from foo to a VPN address, the source address is foo's public IP. If I > run ping with -S10.0.63.3, the source address still is 192.0.2.3. > > Is there any documentation on how source addresses are selected? I thought I > remembered that on unbound sockets the destination route would be used to > pick the first address of the outgoing interface as the source address; the > same address would be picked on connecting a socket. > > I'm currently running with this configuration in rc.conf: > > cloned_interfaces="tun0" > ifconfig_em0="192.0.2.2/27" > ifconfig_tun0="10.0.63.1 10.0.63.255" > > defaultrouter="192.0.2.1" > inetd_flags="-wW -a 192.0.2.2" > static_routes="openvpn" > route_openvpn="10.0.0.0/18 10.0.63.255" > > jail_enable="YES" > jail_set_hostname_allow="NO" > jail_sysvipc_allow="YES" > jail_devfs_enable="YES" > jail_mount_enable="YES" > > jail_list="foo bar baz" > jail_foo_rootdir="/jail/foo.example.com" > jail_foo_hostname="foo.example.com" > jail_foo_ip="em0|192.0.2.3,lo0|10.0.63.3" > > > Any suggestions? sys/netinet/in_pcb.c:in_pcbladdr() is your friend - http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L546 This is the case you are running into: http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L628 /* * If the outgoing interface on the route found is not * a loopback interface, use the address from that interface. * In case of jails do those three steps: * 1. check if the interface address belongs to the jail. If so use it. * 2. check if we have any address on the outgoing interface * belonging to this jail. If so use it. * 3. as a last resort return the 'default' jail address. */ so you are hitting "3." . I am not sure but I'd assume ifconfig tun0 10.0.63.3 10.0.63.255 alias would work, just not with the logic to create the IPs upon jail start (and we will not accept patches to handle that;). I'd also suggest to use telnet instead of ping to run tests as ping imho has some private magic. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From stb at lassitu.de Sat Mar 14 13:22:06 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sat Mar 14 13:22:14 2009 Subject: Multi-homing, jails, and source address selection In-Reply-To: <20090314174526.E96785@maildrop.int.zabbadoz.net> References: <20090314174526.E96785@maildrop.int.zabbadoz.net> Message-ID: Am 14.03.2009 um 19:01 schrieb Bjoern A. Zeeb: > On Thu, 12 Mar 2009, Stefan Bethke wrote: > >> I'm having some trouble configuring a dual-homed jail host, running >> -current from about 4 weeks ago. >> ... >> Is there any documentation on how source addresses are selected? I >> thought I remembered that on unbound sockets the destination route >> would be used to pick the first address of the outgoing interface >> as the source address; the same address would be picked on >> connecting a socket. > > sys/netinet/in_pcb.c:in_pcbladdr() is your friend - > http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L546 > > This is the case you are running into: > http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L628 > /* > * If the outgoing interface on the route found is not > * a loopback interface, use the address from that interface. > * In case of jails do those three steps: > * 1. check if the interface address belongs to the jail. If so use it. > * 2. check if we have any address on the outgoing interface > * belonging to this jail. If so use it. > * 3. as a last resort return the 'default' jail address. > */ > > so you are hitting "3." . > > I am not sure but I'd assume > ifconfig tun0 10.0.63.3 10.0.63.255 alias > would work, just not with the logic to create the IPs upon jail start > (and we will not accept patches to handle that;). This is what I figured is happening. For the time being, I've gone back to single-homed; I'm using pf binat rules to map public ips to the vpn ones for the jails. Not perfect, but works for most cases. (The only really missing option is to bind a service in the jail to VPN address only, so it's only accessible over the VPN, but I can enforce that through pf or hosts.allow.) Assigning aliases to tun0 appears to work too, but you need a distinct destination address for each alias. Annoying. Since I'm using "topology subnet" in OpenVPN, a point-to-point interface is conceptually slightly off; a broadcast interface would fit much nicer. This would also allow the standard rc.d/jail script to do it's magic, if the necessary tun seetings could be applied through ifconfig. Is there a specific reason this setting can only be done through an ioctl on the dev node, instead of thorugh ifconfig? (Specifically TUNSIFMODE.) Additionally, this open the way to run OpenVPN inside a jail, since all ifconfig and route setup would be done prior to OpenVPN starting up. (tun also down the interface if the dev node is closed, but I have a feeling that could be mediated somewhat easily as well.) Thanks, Stefan -- Stefan Bethke Fon +49 151 14070811 From sam at freebsd.org Sat Mar 14 14:06:48 2009 From: sam at freebsd.org (Sam Leffler) Date: Sat Mar 14 14:07:00 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BB0D3E.2020306@incunabulum.net> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> Message-ID: <49BC1C66.7030400@freebsd.org> This patches avoids the crash. Not sure how ifma_protospec is supposed to be handled so I'm not committing it. Sam -------------- next part -------------- Index: in.c =================================================================== --- in.c (revision 189750) +++ in.c (working copy) @@ -1040,7 +1040,8 @@ */ IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { - if (ifma->ifma_addr->sa_family != AF_INET) + if (ifma->ifma_addr->sa_family != AF_INET || + ifma->ifma_protospec == NULL) continue; inm = (struct in_multi *)ifma->ifma_protospec; LIST_INSERT_HEAD(&purgeinms, inm, inm_link); Index: igmp.c =================================================================== --- igmp.c (revision 189750) +++ igmp.c (working copy) @@ -623,7 +623,8 @@ if (igi->igi_version == IGMP_VERSION_3) { IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { - if (ifma->ifma_addr->sa_family != AF_INET) + if (ifma->ifma_addr->sa_family != AF_INET || + ifma->ifma_protospec == NULL) continue; inm = (struct in_multi *)ifma->ifma_protospec; if (inm->inm_state == IGMP_LEAVING_MEMBER) { From julian at elischer.org Sat Mar 14 14:35:16 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Mar 14 14:35:23 2009 Subject: Multi-homing, jails, and source address selection In-Reply-To: References: <20090314174526.E96785@maildrop.int.zabbadoz.net> Message-ID: <49BC2317.3050009@elischer.org> Stefan Bethke wrote: > Am 14.03.2009 um 19:01 schrieb Bjoern A. Zeeb: > >> On Thu, 12 Mar 2009, Stefan Bethke wrote: >> >>> I'm having some trouble configuring a dual-homed jail host, running >>> -current from about 4 weeks ago. >>> ... >>> Is there any documentation on how source addresses are selected? I >>> thought I remembered that on unbound sockets the destination route >>> would be used to pick the first address of the outgoing interface as >>> the source address; the same address would be picked on connecting a >>> socket. >> >> sys/netinet/in_pcb.c:in_pcbladdr() is your friend - >> http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L546 >> >> This is the case you are running into: >> http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L628 >> /* >> * If the outgoing interface on the route found is not >> * a loopback interface, use the address from that interface. >> * In case of jails do those three steps: >> * 1. check if the interface address belongs to the jail. If so use it. >> * 2. check if we have any address on the outgoing interface >> * belonging to this jail. If so use it. >> * 3. as a last resort return the 'default' jail address. >> */ >> >> so you are hitting "3." . >> >> I am not sure but I'd assume >> ifconfig tun0 10.0.63.3 10.0.63.255 alias >> would work, just not with the logic to create the IPs upon jail start >> (and we will not accept patches to handle that;). > > This is what I figured is happening. > > For the time being, I've gone back to single-homed; I'm using pf binat > rules to map public ips to the vpn ones for the jails. Not perfect, but > works for most cases. (The only really missing option is to bind a > service in the jail to VPN address only, so it's only accessible over > the VPN, but I can enforce that through pf or hosts.allow.) > > Assigning aliases to tun0 appears to work too, but you need a distinct > destination address for each alias. Annoying. > > Since I'm using "topology subnet" in OpenVPN, a point-to-point interface > is conceptually slightly off; a broadcast interface would fit much > nicer. This would also allow the standard rc.d/jail script to do it's > magic, if the necessary tun seetings could be applied through ifconfig. > Is there a specific reason this setting can only be done through an > ioctl on the dev node, instead of thorugh ifconfig? (Specifically > TUNSIFMODE.) > > Additionally, this open the way to run OpenVPN inside a jail, since all > ifconfig and route setup would be done prior to OpenVPN starting up. > (tun also down the interface if the dev node is closed, but I have a > feeling that could be mediated somewhat easily as well.) One of the things you can do is assign different routing tabels to each jail. This means that tho can control which interface it will select as the outgoing interface. setfib -{0-15} jail (jail args) > > > Thanks, > Stefan > From bms at incunabulum.net Sat Mar 14 16:28:56 2009 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat Mar 14 16:29:08 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BC1C66.7030400@freebsd.org> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> Message-ID: <49BC3DB5.2070807@incunabulum.net> Sam, Sam Leffler wrote: > This patches avoids the crash. Not sure how ifma_protospec is > supposed to be handled so I'm not committing it. Thanks for this. I have a test machine ready to be prepped but it's missing a CF card (I have none) so need to pick one up from a friend. I have a pci-cardbus adapter + a ral(4) CardBus card, but no CardBus ath(4) -- I imagine this ain't specific to ath(4) so that should be fine. I'll try to look at this Sun/Mon, I have a -CURRENT image built for the 1U box now that just needs bootstrapping (it has a CF slot). thanks, BMS From rwatson at FreeBSD.org Sun Mar 15 03:04:30 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Mar 15 03:04:43 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed (was: Re: Wiki page for non-MPSAFE network stack de-orbit scheduling) In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: On Mon, 16 Feb 2009, Robert Watson wrote: > 16 February 2009 HEADS UP to lists (this e-mail) > 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x Slightly delayed while USB NDIS was sorted out, I will be moving ahead with disabling the build of all IFF_NEEDSGIANT drivers in HEAD later today. > 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x And this date is probably going to remain about the same. Anyone who is interested is welcome to step in and update/fix drivers on the removal path at any time, and drivers can also be restored later easily if drivers are updated outside the tree as well. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From stb at lassitu.de Sun Mar 15 05:48:42 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sun Mar 15 05:48:49 2009 Subject: Multi-homing, jails, and source address selection In-Reply-To: <49BC2317.3050009@elischer.org> References: <20090314174526.E96785@maildrop.int.zabbadoz.net> <49BC2317.3050009@elischer.org> Message-ID: <68726DB3-DAC2-4ABB-A1DC-A018992B8EC6@lassitu.de> Am 14.03.2009 um 22:35 schrieb Julian Elischer: > Stefan Bethke wrote: >> Am 14.03.2009 um 19:01 schrieb Bjoern A. Zeeb: >>> On Thu, 12 Mar 2009, Stefan Bethke wrote: >>> >>>> I'm having some trouble configuring a dual-homed jail host, >>>> running -current from about 4 weeks ago. >>>> ... >>>> Is there any documentation on how source addresses are selected? >>>> I thought I remembered that on unbound sockets the destination >>>> route would be used to pick the first address of the outgoing >>>> interface as the source address; the same address would be picked >>>> on connecting a socket. >>> >>> sys/netinet/in_pcb.c:in_pcbladdr() is your friend - >>> http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L546 >>> >>> This is the case you are running into: >>> http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L628 >>> /* >>> * If the outgoing interface on the route found is not >>> * a loopback interface, use the address from that interface. >>> * In case of jails do those three steps: >>> * 1. check if the interface address belongs to the jail. If so use >>> it. >>> * 2. check if we have any address on the outgoing interface >>> * belonging to this jail. If so use it. >>> * 3. as a last resort return the 'default' jail address. >>> */ >>> >>> so you are hitting "3." . >>> >>> I am not sure but I'd assume >>> ifconfig tun0 10.0.63.3 10.0.63.255 alias >>> would work, just not with the logic to create the IPs upon jail >>> start >>> (and we will not accept patches to handle that;). >> This is what I figured is happening. >> For the time being, I've gone back to single-homed; I'm using pf >> binat rules to map public ips to the vpn ones for the jails. Not >> perfect, but works for most cases. (The only really missing option >> is to bind a service in the jail to VPN address only, so it's only >> accessible over the VPN, but I can enforce that through pf or >> hosts.allow.) >> Assigning aliases to tun0 appears to work too, but you need a >> distinct destination address for each alias. Annoying. >> Since I'm using "topology subnet" in OpenVPN, a point-to-point >> interface is conceptually slightly off; a broadcast interface would >> fit much nicer. This would also allow the standard rc.d/jail >> script to do it's magic, if the necessary tun seetings could be >> applied through ifconfig. Is there a specific reason this setting >> can only be done through an ioctl on the dev node, instead of >> thorugh ifconfig? (Specifically TUNSIFMODE.) >> Additionally, this open the way to run OpenVPN inside a jail, since >> all ifconfig and route setup would be done prior to OpenVPN >> starting up. (tun also down the interface if the dev node is >> closed, but I have a feeling that could be mediated somewhat easily >> as well.) > > One of the things you can do is assign different routing tabels to > each jail. This means that tho can control which interface it will > select as the outgoing interface. > > setfib -{0-15} jail (jail args) I hope to investigate the VIMAGE work soon, but how exactly would that help me with multihoming jails? As it turns out, my issue is with source address selection mostly, and the way point-to-point interfaces work; the routing table doesn't really come into play? Stefan -- Stefan Bethke Fon +49 151 14070811 From rwatson at FreeBSD.org Sun Mar 15 07:27:30 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Mar 15 07:27:35 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed (was: Re: Wiki page for non-MPSAFE network stack de-orbit scheduling) In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: On Sun, 15 Mar 2009, Robert Watson wrote: > On Mon, 16 Feb 2009, Robert Watson wrote: > >> 16 February 2009 HEADS UP to lists (this e-mail) >> 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x > > Slightly delayed while USB NDIS was sorted out, I will be moving ahead with > disabling the build of all IFF_NEEDSGIANT drivers in HEAD later today. This patch is now committed; while I've done build testing (etc) there's always a chance of problems -- please drop me an e-mail if I missed something. Robert N M Watson Computer Laboratory University of Cambridge > >> 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x > > And this date is probably going to remain about the same. > > Anyone who is interested is welcome to step in and update/fix drivers on the > removal path at any time, and drivers can also be restored later easily if > drivers are updated outside the tree as well. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 rwatson at FreeBSD.org Sun Mar 15 08:54:20 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Mar 15 08:54:26 2009 Subject: HEADS UP: if_ar, if_sr, *old* USB stack network driver users In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: On Sun, 15 Mar 2009, Robert Watson wrote: >>> 16 February 2009 HEADS UP to lists (this e-mail) >>> 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers >>> in 8.x >> >> Slightly delayed while USB NDIS was sorted out, I will be moving ahead with >> disabling the build of all IFF_NEEDSGIANT drivers in HEAD later today. > > This patch is now committed; while I've done build testing (etc) there's > always a chance of problems -- please drop me an e-mail if I missed > something. Just to be clear -- if you are a user of: if_ar if_sr Or one of the USB network interface drivers from the old USB stack (not the new USB2 stack), then you will now find your device drivers are not part of the build. USB users should use the new USB stack if they need network interface drivers; if_ar and if_sr drivers will need to modify the device drivers to be MPSAFE and then submit patches. Robert N M Watson Computer Laboratory University of Cambridge From julian at elischer.org Sun Mar 15 10:14:54 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Mar 15 10:15:03 2009 Subject: Multi-homing, jails, and source address selection In-Reply-To: <68726DB3-DAC2-4ABB-A1DC-A018992B8EC6@lassitu.de> References: <20090314174526.E96785@maildrop.int.zabbadoz.net> <49BC2317.3050009@elischer.org> <68726DB3-DAC2-4ABB-A1DC-A018992B8EC6@lassitu.de> Message-ID: <49BD3791.9060007@elischer.org> Stefan Bethke wrote: >> setfib -{0-15} jail (jail args) > > I hope to investigate the VIMAGE work soon, this has nothing to do with vimage. it's teh multiple routing table support I'm talking about. For example different tables with different default routes. > but how exactly would that > help me with multihoming jails? > As it turns out, my issue is with source address selection mostly, The routing table selects your source address so it has everything to do with it. If youhave several addressesin your jail, (with teh new code) then which is selected for a particular session depends on the routing table. It is the address of the local end of the interface that you will use to get to the destination. > and the way point-to-point interfaces > work; the routing table doesn't really come into play? What makes you say that?? No IP packet is sent without consulting the routing table. if you can control which table is used you can control the source address. > > Stefan > From julian at elischer.org Sun Mar 15 10:22:20 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Mar 15 10:22:32 2009 Subject: HEADS UP: if_ar, if_sr, *old* USB stack network driver users In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: <49BD394F.8060002@elischer.org> Robert Watson wrote: > > On Sun, 15 Mar 2009, Robert Watson wrote: > >>>> 16 February 2009 HEADS UP to lists (this e-mail) >>>> 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x >>> >>> Slightly delayed while USB NDIS was sorted out, I will be moving >>> ahead with disabling the build of all IFF_NEEDSGIANT drivers in HEAD >>> later today. >> >> This patch is now committed; while I've done build testing (etc) >> there's always a chance of problems -- please drop me an e-mail if I >> missed something. > > Just to be clear -- if you are a user of: > > if_ar > if_sr these are drivers for synch io cards. they have netgraph interfaces as well as 'old style' interfaces. I think John Hay was the last person seen with these cards. > > Or one of the USB network interface drivers from the old USB stack (not > the new USB2 stack), then you will now find your device drivers are not > part of the build. USB users should use the new USB stack if they need > network interface drivers; if_ar and if_sr drivers will need to modify > the device drivers to be MPSAFE and then submit patches. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 linimon at FreeBSD.org Sun Mar 15 15:00:10 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Mar 15 15:00:24 2009 Subject: kern/132672: [ndis] [panic] ndis with rt2860.sys causes kernel panic in CURRENT-amd64 Message-ID: <200903152200.n2FM09fM084596@freefall.freebsd.org> Old Synopsis: ndis with rt2860.sys causes kernel panic in CURRENT-amd64 New Synopsis: [ndis] [panic] ndis with rt2860.sys causes kernel panic in CURRENT-amd64 Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 15 21:59:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132672 From lothlorien at pvu.msk.ru Sun Mar 15 15:20:03 2009 From: lothlorien at pvu.msk.ru (Gennady Kudryashoff) Date: Sun Mar 15 15:20:09 2009 Subject: amd64/132672: ndis with rt2860.sys causes kernel panic in CURRENT-amd64 Message-ID: <200903152220.n2FMK2I1010490@freefall.freebsd.org> The following reply was made to PR kern/132672; it has been noted by GNATS. From: Gennady Kudryashoff To: Scot Hetzel Cc: freebsd-gnats-submit@freebsd.org Subject: Re[2]: amd64/132672: ndis with rt2860.sys causes kernel panic in CURRENT-amd64 Date: Mon, 16 Mar 2009 00:15:32 +0300 Hello Scot, Sunday, March 15, 2009, 10:53:45 PM, you wrote: >> === [cut here] === >> no match for ZwWriteFile >> no match for ZwCreateFile >> no match for ZwReadFile >> SH> This is the cause of your kernel panic. This Windows NDIS Driver SH> wants 3 functions that are not currently implemented in the FreeBSD SH> NDIS Driver. I'm afraid it isn't. :( If it was right there is no need to write a PR. There is no panic in i386 version of 8-CURRENT (and 7-STABLE) with i386 drivers from the same archive when I make an attempt to kldload it, however, strings >> no match for ZwWriteFile >> no match for ZwCreateFile >> no match for ZwReadFile are present in console output and driver works (I can attach module). SH> You'll need to either look for an older Windows NDIS Driver, or SH> attempt to implement these missing functions. Unfortunately, I'm not a programmer :( From the other side, porting new features of ral driver from OpenBSD side (with rt2860 support) will be more promising here. -- Best regards, Gennady Passport & Visa Dept of Moscow Police / Ïàñïîðòíî-âèçîâîå óïðàâëåíèå ÃÓÂÄ ã. Ìîñêâû From marii.vasile at gmail.com Mon Mar 16 02:30:06 2009 From: marii.vasile at gmail.com (Vasile Marii) Date: Mon Mar 16 02:30:13 2009 Subject: kern/132277: [crypto] [ipsec] poor performance using cryptodevice for IPSEC Message-ID: <200903160930.n2G9U67j012112@freefall.freebsd.org> The following reply was made to PR kern/132277; it has been noted by GNATS. From: Vasile Marii To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132277: [crypto] [ipsec] poor performance using cryptodevice for IPSEC Date: Mon, 16 Mar 2009 11:26:46 +0200 Thanks Patrick. Anyway, that patch solves the problem for glxsb but let's admit that there is still a problem with the OCF interface or OCF itself because on linux geode performs much better: around 90 Mbps. I must insist that there is a problem with the OCF or something because it's not ok to get half a speed on a 100Mbps NIC only because interaction with IP stack(as i think) or interface with OCF is not ok. -- Vasile Marii From bugmaster at FreeBSD.org Mon Mar 16 04:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 16 04:08:46 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200903161106.n2GB6xWu043328@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132342 net [ndis] [patch] incorrect number used in for loop; fix o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131310 net [panic] 7.1 panics with mpd netgraph interface changes o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 264 problems total. From sepron at gmail.com Mon Mar 16 08:41:01 2009 From: sepron at gmail.com (Sergey Pronin) Date: Mon Mar 16 08:41:06 2009 Subject: Synopsis: process swi1: net, taskq em0 and dummynet gives 100% CPU usage Message-ID: Synopsis: process swi1: net, taskq em0 and dummynet gives 100% CPU usage Related to http://lists.freebsd.org/pipermail/freebsd-net/2009-February/021120.html Not depending on the conditions (no heavy load, not a lot of traffic passing through, not a lot of ng nodes) server stops to work properly. A: 1) swi1:net gives me 100% CPU usage. 2) server is not responding to icmp echo requests 3) ssh of course not working 4) mpd has an "ngsock" state at the top 5) rebooting the server helps. B: 1) taskq: em0 gives me 100% CPU usage. 2) I have watchdog timeout in my /var/log/messages 3) server is not responding to icmp echo requests 4) ssh of course not working 5) mpd has an "ngsock" state at the top 6) rebooting the server helps. 7) swi1:net is 0% C: 1) dummynet process gives 100% CPU usage. 2) server is not responding to icmp echo requests 3) ssh of course not working 4) mpd has an "ngsock" state at the top 5) rebooting the server helps. I have few servers: INTEL S3200SH with Q8200 or E8600 NICs: 82566DM-2 or 82571EB (em driver) OSes: FreeBSD 7.0-RELEASE-p10, FreeBSD 7.0-RELEASE-p9, FreeBSD 6.4-RELEASE-p3 Soft: mpd 4.4.1, ipfw with dummynet shaping, pf (nat only) PPPoE I'm using only em0 card with about 550 vlans 2000 ng nodes created About 500-700 simultaneous PPPoE sessions in a rush hour. kernel: device bpf # Berkeley packet filter device pf options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=1000 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET options DEVICE_POLLING options HZ=2000 options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_IFACE options NETGRAPH_SOCKET options NETGRAPH_PPP options NETGRAPH_TCPMSS options NETGRAPH_TEE options NETGRAPH_VJC options NETGRAPH_PPPOE On some servers i have netgraph as modules and polling option commented out. sysctl.conf: net.inet.ip.intr_queue_maxlen=1000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fw.one_pass=1 net.inet.ip.fastforwarding=1 net.isr.direct=0 #net.inet.ip.portrange.randomized=0 net.inet.tcp.syncookies=1 kern.ipc.maxsockbuf=1048576 net.graph.maxdgram=524288 net.graph.recvspace=524288 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 dev.em.0.rx_int_delay=160 dev.em.0.rx_abs_int_delay=160 dev.em.0.tx_int_delay=160 dev.em.0.tx_abs_int_delay=160 dev.em.0.rx_processing_limit=200 loader.conf: autoboot_delay="2" kern.ipc.maxpipekva=10000000 net.graph.maxalloc=2048 hw.em.rxd="512" hw.em.txd="1024" About 30 ipfw rules and 2 rules for shaping: 00300 pipe tablearg ip from any to table(4) out via ng* 00301 pipe tablearg ip from table(5) to any in via ng* I have tested different network cards with different chipsets. With and without lagg0. I had the same problems with Freebsd 7.1-RELEASE-p1/p2. I tried to start servers without em tuning in loader.conf and sysctl.conf. Server uptime differs from one week to two month. I have two another servers with the same hardware, but without using dummynet, netgraph and mpd. There is only quagga + bgp, same chipsets, FreeBSD 7.0-RELEAS-p10. No problems at all. IMHO: problem is somewhere in netgraph. Something is causing an infinite loop. Any ideas? From steve at ibctech.ca Mon Mar 16 09:55:57 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon Mar 16 09:56:03 2009 Subject: uRPF Message-ID: <49BE8494.6030305@ibctech.ca> Hi everyone, I've implemented RTBH within our network, but I have one small issue. I've got one FreeBSD/Quagga edge router that has an interface which contains a default route out. Although this will change in the next while, at this time, it is preventing me from doing reverse path check, thereby breaking source-based black-holing. It appears to me that IPFW's verrevpath (and it's kin) do not provide the ability to perform the RPF check and allow default. Have there been any advancements in this regard? Am I missing something, or is there another approach to allowing default with reverse path? Regards, Steve From cokane at FreeBSD.org Mon Mar 16 13:10:17 2009 From: cokane at FreeBSD.org (Coleman Kane) Date: Mon Mar 16 13:10:24 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BC1C66.7030400@freebsd.org> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> Message-ID: <1237233210.84180.20.camel@localhost> The crash that I am seeing (using if_ndis) occurs in igmp_fasttimo... This patch doesn't fix that, I'll get more info as soon as I can. On Sat, 2009-03-14 at 14:06 -0700, Sam Leffler wrote: > This patches avoids the crash. Not sure how ifma_protospec is supposed > to be handled so I'm not committing it. > > Sam > > plain text document attachment (mcast.patch) > Index: in.c > =================================================================== > --- in.c (revision 189750) > +++ in.c (working copy) > @@ -1040,7 +1040,8 @@ > */ > IF_ADDR_LOCK(ifp); > TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { > - if (ifma->ifma_addr->sa_family != AF_INET) > + if (ifma->ifma_addr->sa_family != AF_INET || > + ifma->ifma_protospec == NULL) > continue; > inm = (struct in_multi *)ifma->ifma_protospec; > LIST_INSERT_HEAD(&purgeinms, inm, inm_link); > Index: igmp.c > =================================================================== > --- igmp.c (revision 189750) > +++ igmp.c (working copy) > @@ -623,7 +623,8 @@ > if (igi->igi_version == IGMP_VERSION_3) { > IF_ADDR_LOCK(ifp); > TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { > - if (ifma->ifma_addr->sa_family != AF_INET) > + if (ifma->ifma_addr->sa_family != AF_INET || > + ifma->ifma_protospec == NULL) > continue; > inm = (struct in_multi *)ifma->ifma_protospec; > if (inm->inm_state == IGMP_LEAVING_MEMBER) { > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090316/6536e464/attachment.pgp From sam at freebsd.org Mon Mar 16 13:14:12 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Mar 16 13:14:19 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <1237233210.84180.20.camel@localhost> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> <1237233210.84180.20.camel@localhost> Message-ID: <49BEB312.7060105@freebsd.org> It is the same issue but the root cause is unclear. There is much code that does assumes ifma_protospec might be NULL and checks for it. In my case (creating a wlan ifnet and then destroying it on eject) the patch below is sufficient. I don't care to dig right now to understand how this stuff is supposed to work; it should be clear from comments etc but the code is lacking. Sam Coleman Kane wrote: > The crash that I am seeing (using if_ndis) occurs in igmp_fasttimo... > This patch doesn't fix that, I'll get more info as soon as I can. > > On Sat, 2009-03-14 at 14:06 -0700, Sam Leffler wrote: > >> This patches avoids the crash. Not sure how ifma_protospec is supposed >> to be handled so I'm not committing it. >> >> Sam >> >> plain text document attachment (mcast.patch) >> Index: in.c >> =================================================================== >> --- in.c (revision 189750) >> +++ in.c (working copy) >> @@ -1040,7 +1040,8 @@ >> */ >> IF_ADDR_LOCK(ifp); >> TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { >> - if (ifma->ifma_addr->sa_family != AF_INET) >> + if (ifma->ifma_addr->sa_family != AF_INET || >> + ifma->ifma_protospec == NULL) >> continue; >> inm = (struct in_multi *)ifma->ifma_protospec; >> LIST_INSERT_HEAD(&purgeinms, inm, inm_link); >> Index: igmp.c >> =================================================================== >> --- igmp.c (revision 189750) >> +++ igmp.c (working copy) >> @@ -623,7 +623,8 @@ >> if (igi->igi_version == IGMP_VERSION_3) { >> IF_ADDR_LOCK(ifp); >> TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { >> - if (ifma->ifma_addr->sa_family != AF_INET) >> + if (ifma->ifma_addr->sa_family != AF_INET || >> + ifma->ifma_protospec == NULL) >> continue; >> inm = (struct in_multi *)ifma->ifma_protospec; >> if (inm->inm_state == IGMP_LEAVING_MEMBER) { >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> From linimon at FreeBSD.org Mon Mar 16 17:34:35 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Mar 16 17:34:46 2009 Subject: kern/132705: [tcp_wrappers] [patch] libwrap - infinite loop if hosts.allow line > 2k Message-ID: <200903170034.n2H0YYRl095183@freefall.freebsd.org> Old Synopsis: libwrap - infinite loop if hosts.allow line > 2k New Synopsis: [tcp_wrappers] [patch] libwrap - infinite loop if hosts.allow line > 2k Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 17 00:34:17 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132705 From linimon at FreeBSD.org Mon Mar 16 19:34:00 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Mar 16 19:34:07 2009 Subject: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface Message-ID: <200903170233.n2H2Xxox049414@freefall.freebsd.org> Old Synopsis: Panic when creating vlan's on lagg interface New Synopsis: [lagg] [panic] Panic when creating vlan's on lagg interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 17 02:33:42 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132715 From bms at incunabulum.net Tue Mar 17 00:44:47 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 00:44:54 2009 Subject: ae(4) Wake-on-Lan MFC Message-ID: <49BF54EB.3070800@incunabulum.net> Hi, I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did. However, WOL support is now there, and it looks like the change can just go in: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7&tr1=1.1&r2=1.3%3AHEAD&tr2=1.3 I am tied up looking at other stuff at the moment, it would be nice to merge the change, but low priority for me right now. BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD branches since the SVN change, does anyone know an easier way? thanks BMS From julian at elischer.org Tue Mar 17 00:53:42 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Mar 17 00:53:49 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <49BF54EB.3070800@incunabulum.net> References: <49BF54EB.3070800@incunabulum.net> Message-ID: <49BF570A.6000904@elischer.org> Bruce Simpson wrote: > Hi, > > I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did. > > However, WOL support is now there, and it looks like the change can just > go in: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7&tr1=1.1&r2=1.3%3AHEAD&tr2=1.3 > > > I am tied up looking at other stuff at the moment, it would be nice to > merge the change, but low priority for me right now. > > BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD > branches since the SVN change, > does anyone know an easier way? that's basically what I do.. > > thanks > BMS > _______________________________________________ > 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 incunabulum.net Tue Mar 17 01:13:02 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 01:13:08 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BEB312.7060105@freebsd.org> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> <1237233210.84180.20.camel@localhost> <49BEB312.7060105@freebsd.org> Message-ID: <49BF5B8A.4040108@incunabulum.net> Sam Leffler wrote: > It is the same issue but the root cause is unclear. There is much > code that does assumes ifma_protospec might be NULL and checks for > it. In my case (creating a wlan ifnet and then destroying it on > eject) the patch below is sufficient. I don't care to dig right now > to understand how this stuff is supposed to work; it should be clear > from comments etc but the code is lacking. > This is just to say I've tried to reproduce the 802.11 related panics, however have hit a brick wall because the PCI-CardBus bridge does not seem to detect anything in its slot. (1U Itox Expanding Dragon industrial PC w/a SiteCom branded Ricoh RL475 cardbus card). I tried unloading if_fxp with IGMPv3 active on the ifnet, and didn't see any panic, I'm assuming this is OK for the time being. Qing Li volunteered to test IGMPv3 out for any VLAN related issues -- I understand it stacks ifnets in a similar way to that of 802.11 -- however I have had no feedback from him since last week. So I'm waiting for a HEAD build to a USB2 stick to finish, so I can try testing nondestructively on my laptop, where I know for sure that the PCI-CardBus bridge slot works, and I can detach an 802.11 card on the fly. Re ifma_protospec: Yes, there are tricks in the ifnet/in layer which set it to NULL and look for it to be NULL. I ended up doing it this way mainly because adding reference counting to ifnet would have simply been too much work, and it's really a ball that needs to be kicked around at a dev summit. However time presses on and it's better to get SOMETHING out there. Most likely the IGMPv3 changes are hitting this in the 802.11 case somehow, I don't have a complete picture of how/why/what's going on, and have been relying on feedback from others so far. cheers BMS From linimon at FreeBSD.org Tue Mar 17 01:21:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Mar 17 01:21:27 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903170821.n2H8LKcL033469@freefall.freebsd.org> Old Synopsis: Wifi ath0 associates fine with AP, but DHCP or IP does not work New Synopsis: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 17 08:21:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132722 From bms at incunabulum.net Tue Mar 17 01:31:42 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 01:31:49 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <200903170821.n2H8LKcL033469@freefall.freebsd.org> References: <200903170821.n2H8LKcL033469@freefall.freebsd.org> Message-ID: <49BF5FEA.6030302@incunabulum.net> Hi, Can you please try cvsupping RELENG_7 sources to after this date: %%% Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 %%% The Atheros open source HAL from HEAD was MFC'd and this may or may not fix your problem. thanks, BMS From bms at incunabulum.net Tue Mar 17 01:40:05 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 01:40:12 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903170840.n2H8e4ki053210@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce Simpson To: freebsd-gnats-submit@freebsd.org Cc: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org, Matthias Apitz , Sam Leffler Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 08:31:38 +0000 Hi, Can you please try cvsupping RELENG_7 sources to after this date: %%% Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 %%% The Atheros open source HAL from HEAD was MFC'd and this may or may not fix your problem. thanks, BMS From guru at unixarea.de Tue Mar 17 02:00:13 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Mar 17 02:00:20 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903170900.n2H90C9Y077742@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz To: bug-followup@FreeBSD.org, guru@unixarea.de Cc: Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 09:42:43 +0100 I forgot to mention that I've applied this patch from Sam to my RELENG_7 kernel: http://article.gmane.org/gmane.os.freebsd.stable/60383/match=cft+ath+hal+src I think, updating to Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 as suggested will not change anything, or I'm wrong? matthias From bms at incunabulum.net Tue Mar 17 02:16:12 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 02:16:18 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <200903170900.n2H90C9Y077742@freefall.freebsd.org> References: <200903170900.n2H90C9Y077742@freefall.freebsd.org> Message-ID: <49BF6A59.6090801@incunabulum.net> Hi, One crucial piece of info missing is exactly which Atheros part you are using, can you please attach this to the PR? you can get this from pciconf -lv and look for the ath0, also please post your boot time dmesg / or when you insert the part. thanks. Matthias Apitz wrote: > The following reply was made to PR kern/132722; it has been noted by GNATS. > > From: Matthias Apitz > To: bug-followup@FreeBSD.org, guru@unixarea.de > Cc: > Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work > Date: Tue, 17 Mar 2009 09:42:43 +0100 > > I forgot to mention that I've applied this patch from Sam to my RELENG_7 > kernel: > > http://article.gmane.org/gmane.os.freebsd.stable/60383/match=cft+ath+hal+src > > I think, updating to > > Date: Thu Mar 12 03:09:11 2009 > New Revision: 189720 > URL: http://svn.freebsd.org/changeset/base/189720 > > as suggested will not change anything, or I'm wrong? > I didn't make many changes apart from fixups in a few files for the diff, so if you're running with the updated HAL, then in theory an svn update/cvsup should make no change. Of course the only way to be sure is to look under the hood. I didn't see any issues with the backported HAL, and I don't really know enough about ath(4) to suggest any workarounds at this point other than reversing your application of the patch, and cvsupping to before the date the patch was MFCed, can we be absolutely sure that the regression you observe happens with the new HAL? Sam would know more, but of course one of the reasons I've taken this on is because a project I'm involved with needs working ath(4) on pci-e in 7.x, I don't know about chip specific problems at this point in time, so I'm just as in the dark as you are! thanks, BMS From srikanthhcu05 at gmail.com Tue Mar 17 02:18:24 2009 From: srikanthhcu05 at gmail.com (srikanth jampala) Date: Tue Mar 17 02:18:31 2009 Subject: SA add notification to externa module Message-ID: Hi all This is my first posting. I want the notifications about the SA (security association) add/delete events, from the kernel to my externel kernel module. How can I do this... ? Thanks in advance for ur suggestions. Sriknath From vanhu at FreeBSD.org Tue Mar 17 02:29:04 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Tue Mar 17 02:29:11 2009 Subject: SA add notification to externa module In-Reply-To: References: Message-ID: <20090317092933.GA72942@zeninc.net> On Tue, Mar 17, 2009 at 02:23:13PM +0530, srikanth jampala wrote: > Hi all Hi. > This is my first posting. > > I want the notifications about the SA (security association) add/delete > events, > from the kernel to my externel kernel module. > > How can I do this... ? Such events are notified to all PFKey registered sockets. Usually, those notifications are sent to userland, but I guess you could start searching from there (see key_sendup_mbuf(x, y, KEY_SENDUP_REGISTERED) in netipsec/keysock.c). Yvan. From bms at incunabulum.net Tue Mar 17 03:39:36 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 03:39:43 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090317103650.GA6156@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> Message-ID: <49BF7DE4.4010804@incunabulum.net> Matthias Apitz wrote: > as requested the output of dmesg(1) and the ath0 related part of > 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. > with the AP in my office (WPA) and in my home (WEP); > Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. cheers BMS From guru at unixarea.de Tue Mar 17 03:40:07 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Mar 17 03:40:13 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903171040.n2HAe6Zf009431@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz To: bug-followup@FreeBSD.org Cc: freebsd-net@FreeBSD.org, Bruce Simpson Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:36:51 +0100 as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Copyright (c) 1992-2009 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.1-STABLE #1: Tue Mar 10 11:42:48 CET 2009 guru@rebelion.Sisis.de:/usr/src/sys/i386/compile/REBELION Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 900MHz (900.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff AMD Features=0x100000 real memory = 1064828928 (1015 MB) avail memory = 1028284416 (980 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f700000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xec00-0xec07 mem 0xf7f00000-0xf7f7ffff,0xd0000000-0xdfffffff,0xf7ec0000-0xf7efffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf7f80000-0xf7ffffff at device 2.1 on pci0 hdac0: mem 0xf7eb8000-0xf7ebbfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090131_0127 hdac0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 18 at device 28.2 on pci0 pci1: on pcib2 ath0: mem 0xfbff0000-0xfbffffff irq 18 at device 0.0 on pci1 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:15:af:b2:ae:e6 ath0: mac 14.2 phy 7.0 radio 10.2 uhci0: port 0xe400-0xe41f 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 0xe480-0xe49f 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 0xe800-0xe81f 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 0xe880-0xe89f 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 0xf7eb7c00-0xf7eb7fff 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 umass0: on uhub4 pcib3: at device 30.0 on pci0 pci4: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_asus0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 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 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] 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 Timecounter "TSC" frequency 900097206 Hz quality 800 Timecounters tick every 10.000 msec ad2: FAILURE - SET_MULTI status=51 error=4 ad2: 3847MB at ata1-master UDMA66 ad3: FAILURE - SET_MULTI status=51 error=4 ad3: 15391MB at ata1-slave UDMA66 hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad2s1a ath0: link state changed to UP ath0@pci0:1:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet matthias From bms at incunabulum.net Tue Mar 17 03:40:10 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 03:40:25 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903171040.n2HAe9w4009479@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce Simpson To: Matthias Apitz Cc: bug-followup@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 10:39:32 +0000 Matthias Apitz wrote: > as requested the output of dmesg(1) and the ath0 related part of > 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. > with the AP in my office (WPA) and in my home (WEP); > Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. cheers BMS From guru at unixarea.de Tue Mar 17 03:49:02 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Mar 17 03:49:16 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49BF7DE4.4010804@incunabulum.net> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> Message-ID: <20090317104548.GB6182@rebelion.Sisis.de> El d?a Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson escribi?: > Matthias Apitz wrote: > >as requested the output of dmesg(1) and the ath0 related part of > >'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. > >with the AP in my office (WPA) and in my home (WEP); > > > > Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. > I tested OK with the 701. Sam said that there may be models of ath(4) > requiring further changes > to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From guru at unixarea.de Tue Mar 17 03:49:03 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Mar 17 03:49:17 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <20090317103650.GA6156@rebelion.Sisis.de> as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Copyright (c) 1992-2009 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.1-STABLE #1: Tue Mar 10 11:42:48 CET 2009 guru@rebelion.Sisis.de:/usr/src/sys/i386/compile/REBELION Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 900MHz (900.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff AMD Features=0x100000 real memory = 1064828928 (1015 MB) avail memory = 1028284416 (980 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f700000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xec00-0xec07 mem 0xf7f00000-0xf7f7ffff,0xd0000000-0xdfffffff,0xf7ec0000-0xf7efffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf7f80000-0xf7ffffff at device 2.1 on pci0 hdac0: mem 0xf7eb8000-0xf7ebbfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090131_0127 hdac0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 18 at device 28.2 on pci0 pci1: on pcib2 ath0: mem 0xfbff0000-0xfbffffff irq 18 at device 0.0 on pci1 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:15:af:b2:ae:e6 ath0: mac 14.2 phy 7.0 radio 10.2 uhci0: port 0xe400-0xe41f 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 0xe480-0xe49f 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 0xe800-0xe81f 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 0xe880-0xe89f 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 0xf7eb7c00-0xf7eb7fff 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 umass0: on uhub4 pcib3: at device 30.0 on pci0 pci4: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_asus0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 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 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] 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 Timecounter "TSC" frequency 900097206 Hz quality 800 Timecounters tick every 10.000 msec ad2: FAILURE - SET_MULTI status=51 error=4 ad2: 3847MB at ata1-master UDMA66 ad3: FAILURE - SET_MULTI status=51 error=4 ad3: 15391MB at ata1-slave UDMA66 hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad2s1a ath0: link state changed to UP ath0@pci0:1:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet matthias From guru at unixarea.de Tue Mar 17 03:50:06 2009 From: guru at unixarea.de (Matthias Apitz) Date: Tue Mar 17 03:50:13 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903171050.n2HAo5qW021806@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz To: Bruce Simpson Cc: Matthias Apitz , freebsd-net@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:45:48 +0100 El día Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson escribió: > Matthias Apitz wrote: > >as requested the output of dmesg(1) and the ath0 related part of > >'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. > >with the AP in my office (WPA) and in my home (WEP); > > > > Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. > I tested OK with the 701. Sam said that there may be models of ath(4) > requiring further changes > to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From cokane at FreeBSD.org Tue Mar 17 06:06:50 2009 From: cokane at FreeBSD.org (Coleman Kane) Date: Tue Mar 17 06:07:02 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BF5B8A.4040108@incunabulum.net> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> <1237233210.84180.20.camel@localhost> <49BEB312.7060105@freebsd.org> <49BF5B8A.4040108@incunabulum.net> Message-ID: <1237295117.1844.6.camel@localhost> On Tue, 2009-03-17 at 08:12 +0000, Bruce Simpson wrote: > Sam Leffler wrote: > > It is the same issue but the root cause is unclear. There is much > > code that does assumes ifma_protospec might be NULL and checks for > > it. In my case (creating a wlan ifnet and then destroying it on > > eject) the patch below is sufficient. I don't care to dig right now > > to understand how this stuff is supposed to work; it should be clear > > from comments etc but the code is lacking. > > > > This is just to say I've tried to reproduce the 802.11 related > panics, however have hit a brick wall because the PCI-CardBus bridge > does not seem to detect anything in its slot. (1U Itox Expanding Dragon > industrial PC w/a SiteCom branded Ricoh RL475 cardbus card). I tried > unloading if_fxp with IGMPv3 active on the ifnet, and didn't see any > panic, I'm assuming this is OK for the time being. > > Qing Li volunteered to test IGMPv3 out for any VLAN related issues > -- I understand it stacks ifnets in a similar way to that of 802.11 -- > however I have had no feedback from him since last week. > So I'm waiting for a HEAD build to a USB2 stick to finish, so I can > try testing nondestructively on my laptop, where I know for sure that > the PCI-CardBus bridge slot works, and I can detach an 802.11 card on > the fly. > > Re ifma_protospec: Yes, there are tricks in the ifnet/in layer which > set it to NULL and look for it to be NULL. I ended up doing it this way > mainly because adding reference counting to ifnet would have simply been > too much work, and it's really a ball that needs to be kicked around at > a dev summit. However time presses on and it's better to get SOMETHING > out there. > Most likely the IGMPv3 changes are hitting this in the 802.11 case > somehow, I don't have a complete picture of how/why/what's going on, and > have been relying on feedback from others so far. > > cheers > BMS > Today I played with it a bit. I've been unable to produce the crash on my wired (if_bge) interface, however it happens regularly on my wireless (ndis0/wlan0) interface. I was unable to get a core dump for other reasons. However, on my system I do not get the crash if I turn off avahi_daemon (set avahi_daemon_enable="NO" in /etc/rc.conf). I tried booting to single user, ran dhclient on wlan0 (after setting it up properly), and then proceeded to boot the system multi-user. As soon as avahi went live, the kernel panicked, as above. If you are looking for a reliable test case, this might be it for you, but I think you need a wlan interface to test it with: * Install net/avahi from ports * Set avahi_daemon_enable="YES" in rc.conf * Configure VAP params for wlan0 card in rc.conf * Log in and run "dhclient wlan0" to trigger the panic -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090317/4bfc7dc7/attachment.pgp From bms at incunabulum.net Tue Mar 17 06:41:58 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 06:42:05 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <1237295117.1844.6.camel@localhost> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> <1237233210.84180.20.camel@localhost> <49BEB312.7060105@freebsd.org> <49BF5B8A.4040108@incunabulum.net> <1237295117.1844.6.camel@localhost> Message-ID: <49BFA8A2.5080807@incunabulum.net> Coleman Kane wrote: > If you are looking for a reliable test case, this might be it for you, > but I think you need a wlan interface to test it with: > * Install net/avahi from ports > * Set avahi_daemon_enable="YES" in rc.conf > * Configure VAP params for wlan0 card in rc.conf > * Log in and run "dhclient wlan0" to trigger the panic > > Actually I was able to panic the kernel right away with the 802.11 code, just by joining a multicast group with mtest(8) on the wlan interface. i.e. # mtest j 224.0.0.2 192.168.x.x -> boom I believe I've found the symptom, but the root cause I don't fully understand. Sam indicated that the VAP code is using ifma's in some nested way between the ifnets which comprise the VAP's member interfaces. A workaround is pending.... cheers BMS From bms at incunabulum.net Tue Mar 17 07:43:38 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Mar 17 07:43:44 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BFA8A2.5080807@incunabulum.net> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> <1237233210.84180.20.camel@localhost> <49BEB312.7060105@freebsd.org> <49BF5B8A.4040108@incunabulum.net> <1237295117.1844.6.camel@localhost> <49BFA8A2.5080807@incunabulum.net> Message-ID: <49BFB713.9030309@incunabulum.net> A suitably kludgy fix for this issue has now been committed to HEAD. From scf at FreeBSD.org Tue Mar 17 09:55:35 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Mar 17 09:55:42 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090317104548.GB6182@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> Message-ID: On Tue, 17 Mar 2009, Matthias Apitz wrote: > El d?a Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson escribi?: > >> Matthias Apitz wrote: >>> as requested the output of dmesg(1) and the ath0 related part of >>> 'pciconf -lv'; pls note also that the Wifi works fine in general, >>> i.e. with the AP in my office (WPA) and in my home (WEP); >>> >> >> Is this an ASUS Eee PC? If so, which model is it? It looks like a >> 901. > > It is an Asus EeePC 900, not the 901. > >> I tested OK with the 701. Sam said that there may be models of ath(4) >> requiring further changes to be back-ported from -CURRENT, this could >> well be one of them. > > as I said the Wifi works in all places, but not with this special AP > (while a Nokia cellphone can associate and DHCP without problems); > > let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. Sean -- scf@FreeBSD.org From scf at FreeBSD.org Tue Mar 17 10:00:17 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Mar 17 10:00:24 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903171700.n2HH0FkP097929@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: "Sean C. Farley" To: Matthias Apitz Cc: Bruce Simpson , freebsd-net@FreeBSD.org, Matthias Apitz , bug-followup@FreeBSD.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:55:32 -0500 (CDT) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --56599777-302749604-1237308518=:51892 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 17 Mar 2009, Matthias Apitz wrote: > El día Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson escribió: > >> Matthias Apitz wrote: >>> as requested the output of dmesg(1) and the ath0 related part of >>> 'pciconf -lv'; pls note also that the Wifi works fine in general, >>> i.e. with the AP in my office (WPA) and in my home (WEP); >>> >> >> Is this an ASUS Eee PC? If so, which model is it? It looks like a >> 901. > > It is an Asus EeePC 900, not the 901. > >> I tested OK with the 701. Sam said that there may be models of ath(4) >> requiring further changes to be back-ported from -CURRENT, this could >> well be one of them. > > as I said the Wifi works in all places, but not with this special AP > (while a Nokia cellphone can associate and DHCP without problems); > > let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. Sean -- scf@FreeBSD.org --56599777-302749604-1237308518=:51892-- From sam at freebsd.org Tue Mar 17 11:56:26 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Mar 17 11:56:33 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> Message-ID: <49BFF258.4020207@freebsd.org> Sean C. Farley wrote: > On Tue, 17 Mar 2009, Matthias Apitz wrote: > >> El d?a Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson >> escribi?: >> >>> Matthias Apitz wrote: >>>> as requested the output of dmesg(1) and the ath0 related part of >>>> 'pciconf -lv'; pls note also that the Wifi works fine in general, >>>> i.e. with the AP in my office (WPA) and in my home (WEP); >>>> >>> >>> Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. >> >> It is an Asus EeePC 900, not the 901. >> >>> I tested OK with the 701. Sam said that there may be models of >>> ath(4) requiring further changes to be back-ported from -CURRENT, >>> this could well be one of them. >> >> as I said the Wifi works in all places, but not with this special AP >> (while a Nokia cellphone can associate and DHCP without problems); >> >> let me know if you need more info; > > Is the AP made by Aruba Networks? > > On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of > wpa_supplicant for it to associate correctly. With v0.5.10, I could > see DHCP requests from my laptop but no responses. This is the patch > I am using currently: > http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch > > Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. Sam From sam at freebsd.org Tue Mar 17 12:02:44 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Mar 17 12:02:50 2009 Subject: IGMP+WiFi panic on recent kernel - in igmp_fasttimo() In-Reply-To: <49BFA8A2.5080807@incunabulum.net> References: <1236937253.2282.0.camel@localhost> <49BAEA9F.8020302@incunabulum.net> <49BB0D3E.2020306@incunabulum.net> <49BC1C66.7030400@freebsd.org> <1237233210.84180.20.camel@localhost> <49BEB312.7060105@freebsd.org> <49BF5B8A.4040108@incunabulum.net> <1237295117.1844.6.camel@localhost> <49BFA8A2.5080807@incunabulum.net> Message-ID: <49BFF3D2.4030407@freebsd.org> Bruce Simpson wrote: > Coleman Kane wrote: >> If you are looking for a reliable test case, this might be it for you, >> but I think you need a wlan interface to test it with: >> * Install net/avahi from ports >> * Set avahi_daemon_enable="YES" in rc.conf >> * Configure VAP params for wlan0 card in rc.conf >> * Log in and run "dhclient wlan0" to trigger the panic >> >> > > Actually I was able to panic the kernel right away with the 802.11 > code, just > by joining a multicast group with mtest(8) on the wlan interface. > > i.e. > > # mtest > j 224.0.0.2 192.168.x.x > -> boom > > I believe I've found the symptom, but the root cause I don't fully > understand. > Sam indicated that the VAP code is using ifma's in some nested way > between > the ifnets which comprise the VAP's member interfaces. > > A workaround is pending.... > net80211 uses the public api's to push mcast addresses from the vap's to the parent ifnet. It does not directly frob any internal data structures except to workaround the ioctl-based callback out of the mcast code when adding an address. Look at ieee80211_ioctl_updatemulti for details. Sam From sam at freebsd.org Tue Mar 17 12:20:05 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Mar 17 12:20:11 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903171920.n2HJK4uZ078916@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Sam Leffler To: "Sean C. Farley" Cc: Matthias Apitz , Matthias Apitz , freebsd-net@freebsd.org, Bruce Simpson , bug-followup@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:56:24 -0700 Sean C. Farley wrote: > On Tue, 17 Mar 2009, Matthias Apitz wrote: > >> El día Tuesday, March 17, 2009 a las 10:39:32AM +0000, Bruce Simpson >> escribió: >> >>> Matthias Apitz wrote: >>>> as requested the output of dmesg(1) and the ath0 related part of >>>> 'pciconf -lv'; pls note also that the Wifi works fine in general, >>>> i.e. with the AP in my office (WPA) and in my home (WEP); >>>> >>> >>> Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. >> >> It is an Asus EeePC 900, not the 901. >> >>> I tested OK with the 701. Sam said that there may be models of >>> ath(4) requiring further changes to be back-ported from -CURRENT, >>> this could well be one of them. >> >> as I said the Wifi works in all places, but not with this special AP >> (while a Nokia cellphone can associate and DHCP without problems); >> >> let me know if you need more info; > > Is the AP made by Aruba Networks? > > On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of > wpa_supplicant for it to associate correctly. With v0.5.10, I could > see DHCP requests from my laptop but no responses. This is the patch > I am using currently: > http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch > > Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. Sam From dhorn2000 at gmail.com Tue Mar 17 14:27:58 2009 From: dhorn2000 at gmail.com (David Horn) Date: Tue Mar 17 14:28:05 2009 Subject: Dynamic loading of network kernel modules? Message-ID: <25ff90d60903171427y4032d11es516d7b757fc3b8e0@mail.gmail.com> I made a minor change to ifconfig to try kldloading the interface name specified on the create wlandev XXXX (ifconfig already tries for normal invocations, just needed to try with the wlandev interface) /usr/src/sbin/ifconfig/ifieee80211.c --- ifieee80211.c.original 2009-03-17 16:53:29.000000000 -0400 +++ ifieee80211.c 2009-03-17 16:53:43.000000000 -0400 @@ -4673,6 +4673,7 @@ memcmp(params.icp_bssid, zerobssid, sizeof(zerobssid)) == 0) errx(1, "no bssid specified for WDS (use wlanbssid)"); ifr->ifr_data = (caddr_t) ¶ms; + ifmaybeload(params.icp_parent); if (ioctl(s, SIOCIFCREATE2, ifr) < 0) err(1, "SIOCIFCREATE2"); } This works nicely, however at startup, I still do not get the interface up, or the kernel module loaded, so a second patch is needed. At issue is the list_net_interfaces() function in /etc/rc.d/network.subr, which assumes that the greatest possible list of interfaces is that which 'ifconfig -l' can give us. Unfortunately, this puts us in a bit of a chicken and egg situation for network interfaces that are modules. I also have a patch to network.subr that will look for any manually configured interfaces in rc.conf that are not in the list of 'ifconfig -l', and will try to start those interfaces as well. {specifically looking for ifconfig_xxx and wlans_xxx and ipv6_ifconfig_xxx} /etc/network.subr --- network.subr.base_0317 2009-03-17 17:00:01.000000000 -0400 +++ network.subr 2009-03-17 17:10:15.000000000 -0400 @@ -690,6 +690,34 @@ return 0 } +# getconf_ifnames +# Return the value of all of the interfaces names referenced in rc.conf +# This is used to attempt to dynamically load kernel modules that +# are not already loaded, but could also be useful elsewhere +# +# wlans_IF, ifconfig_IF, ipv6_ifconfig_IF are currently used +getconf_ifnames() +{ + local val + matching_vars=`set | grep -e "ifconfig_" -e "^wlans_" | tr "\n" " " | tr -d "'=."` + debug "Here is a list of all of the matching variables: $matching_vars" + for i in ${matching_vars}; do + val="" + val="`expr "${i}" : 'ifconfig_\([a-zA-Z]*[0-9]*\).*'`" + if [ -z "$val" ]; then + val="`expr "${i}" : 'wlans_\([a-zA-Z]*[0-9]*\).*'`" + fi + if [ val != "0" -a -n "$val" ]; then + interfaces="${interfaces} $val" + fi + done + + debug "Here are the rc.conf potential interfaces: $interfaces" + echo "$interfaces" + exit 0 +} + + # # list_net_interfaces type # List all network interfaces. The type of interface returned @@ -712,6 +740,9 @@ [Aa][Uu][Tt][Oo]) _prefix='' _autolist="`ifconfig -l`" + _manuallist="`getconf_ifnames`" + _autolist="$_autolist$_manuallist" + debug "list of all interfaces: $_autolist" _lo= for _if in ${_autolist} ; do if autoif $_if; then Is this something that people would be interested in having commited? If so, I can clean up a little bit and remove the duplicate interfaces and debugging, and add getconf_ifnames() in more places. Both patches are against current from today (031709). --Thanks! -_Dave Horn From volker at vwsoft.com Tue Mar 17 14:59:07 2009 From: volker at vwsoft.com (Volker) Date: Tue Mar 17 14:59:14 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <49BF54EB.3070800@incunabulum.net> References: <49BF54EB.3070800@incunabulum.net> Message-ID: <49C02653.9040100@vwsoft.com> On 03/17/09 07:44, Bruce Simpson wrote: > Hi, > > I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did. > > However, WOL support is now there, and it looks like the change can just > go in: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7&tr1=1.1&r2=1.3%3AHEAD&tr2=1.3 > > > I am tied up looking at other stuff at the moment, it would be nice to > merge the change, but low priority for me right now. > > BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD > branches since the SVN change, > does anyone know an easier way? > > thanks > BMS The following can be used: svn diff svn://svn.freebsd.org/base/stable/7/sys/dev/ae/if_ae.c \ svn://svn.freebsd.org/base/head/sys/dev/ae/if_ae.c For exact revisions, append @{rev} to URLs (consult ``svn diff --help``). It also works for directories and trees but you need to be play with that a bit. Volker From pyunyh at gmail.com Tue Mar 17 17:39:44 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Mar 17 17:39:51 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <49BF54EB.3070800@incunabulum.net> References: <49BF54EB.3070800@incunabulum.net> Message-ID: <20090318003944.GA41410@michelle.cdnetworks.co.kr> On Tue, Mar 17, 2009 at 07:44:43AM +0000, Bruce Simpson wrote: > Hi, > > I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did. > I think WOL MFC was done before ae(4) MFC. > However, WOL support is now there, and it looks like the change can just > go in: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7&tr1=1.1&r2=1.3%3AHEAD&tr2=1.3 > > I am tied up looking at other stuff at the moment, it would be nice to > merge the change, but low priority for me right now. > Do you have ae(4) hardware? I'm not sure why stas@ removed WOL part in the MFC but it could be lack of testing(CCed to stas@). I've attached diff that includes WOL support from HEAD. > BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD > branches since the SVN change, > does anyone know an easier way? > > thanks > BMS -------------- next part -------------- A non-text attachment was scrubbed... Name: ae.wol.diff Type: text/x-diff Size: 2176 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090318/18417b13/ae.wol.bin From linimon at FreeBSD.org Tue Mar 17 20:26:02 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Mar 17 20:26:08 2009 Subject: kern/132734: [if_mib] [panic] panic in net/if_mib.c Message-ID: <200903180326.n2I3Q2ce008506@freefall.freebsd.org> Old Synopsis: panic in net/if_mib.c New Synopsis: [if_mib] [panic] panic in net/if_mib.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 18 03:23:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132734 From scf at FreeBSD.org Tue Mar 17 20:36:45 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Mar 17 20:36:51 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49BFF258.4020207@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> Message-ID: On Tue, 17 Mar 2009, Sam Leffler wrote: > Sean C. Farley wrote: *snip* >> Is the AP made by Aruba Networks? >> >> On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of >> wpa_supplicant for it to associate correctly. With v0.5.10, I could >> see DHCP requests from my laptop but no responses. This is the patch >> I am using currently: >> http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch >> >> Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. > > His setup is static key wep; not wpa so I don't think wpa_supplicant > is the issue. Oops. I missed that. :) Sean -- scf@FreeBSD.org From ash at aeria.net Tue Mar 17 20:44:44 2009 From: ash at aeria.net (Ash Gokhale) Date: Tue Mar 17 20:45:15 2009 Subject: netgraph modules won't unload after use Message-ID: <6CBA0923-DAF1-4FD5-A670-F5888BCA47B1@aeria.net> I'm developing a kernel module that will be doing inspection and needed access to raw network frames, so I turned to netgraph as the solution.However it seems that netgraph will not permit a module to unload once it's participated in a mkpeer/connect operation. Rebooting to remove a module is angrymaking (not like mtx/sleep crashes). This going into the kernel because my bpf based userland stuff is probably not going to hold up to the packet rate. Should I file a PR? Or is there magic in the documentation I havn't found? I've observed the trouble in 7.0 release, and tonight's 7_RELENG, with GENERIC + WITNESS/INVARIANTS The module code ( cobbled together from netgraph/ng_sample.c / ng_echo.c) http://pastebin.com/m31b6ece6 The module loads and unloads fine until connected to a netgraph hook: > #make load :ro:~/tmp/ > food.ko:3:06:42:20 > /sbin/kldload -v /root/tmp/food.ko/food.ko > Loaded /root/tmp/food.ko/food.ko, id=3 > #Mar 18 03:06:44 kernel: foodmod loaded :ro:~/tmp/ > food.ko:3:06:44:21 > #make unload :ro:~/tmp/ > food.ko:3:10:16:21 > /sbin/kldunload -v food.ko > Unloading food.ko, id=3 > #Mar 18 03:10:19 kernel: quiesced :ro:~/tmp/ > food.ko:3:10:19:22 > Mar 18 03:10:19 kernel: foodmod unloaded Fine.. so let's connect it: > #make ath :ro:~/tmp/ > food.ko:3:10:59:23 > kldload ng_ether > ifconfig ath0 ssid ')(allmightytallest' > ifconfig ath0 promisc >> > #Mar 18 03:11:04 kernel: ath0: permanently promiscuous mode > enabledo:3:11:04:24 > make connect > #make load :ro:~/tmp/ > food.ko:3:11:13:26 > /sbin/kldload -v /root/tmp/food.ko/food.ko > Loaded /root/tmp/food.ko/food.ko, id=7 > #Mar 18 03:12:05 kernel: foodmod loaded > make connect > ngctl mkpeer ath0: food lower fredhook > ngctl name ath0:lower eater > sleep 1 > Mar 18 03:12:15 kernel: ngconstruct > ifconfig ath0 down > ifconfig ath0 up > #Mar 18 03:12:18 kernel: not our messageunrecognized command/ > food.ko:3:12:16:28 > Mar 18 03:12:18 kernel: ath0: link state changed to UP > # :ro:~/tmp/ > food.ko:3:12:18:28 > #Mar 18 03:12:21 kernel: .... Fine; we get packets to the ng_rx_data procedure .. now we pull the plug on the netgraph > #make discon :ro:~/tmp/ > food.ko:3:12:35:28 > ngctl shutdown eater: > #Mar 18 03:12:37 kernel: discondiconnecting last ng > nodengshutdownko:3:12:36:29 > > #ngctl list :ro:~/tmp/ > food.ko:3:12:39:29 > There are 3 total nodes: > Name: bge0 Type: ether ID: 00000001 Num > hooks: 0 > Name: ngctl1058 Type: socket ID: 00000008 Num > hooks: 0 > Name: ath0 Type: ether ID: 00000002 Num > hooks: 0 > But the module will never unload: ( but the UNLOAD and QUIESE event handlers are invoked) > #make unload :ro:~/tmp/ > food.ko:3:14:28:31 > /sbin/kldunload -vf food.ko > Unloading food.ko, id=7 > kldunload: can't unload file: Device busy > *** Error code 1 > > Stop in /root/tmp/food.ko. > Exit 1 > #Mar 18 03:14:31 kernel: quiesced :ro:~/tmp/ > food.ko:3:14:31:32 > Mar 18 03:14:31 kernel: foodmod unloaded Seems that I can't unload some of the other netgraph types either ( it's not just me): > #kldunload ng_ether :ro:~/tmp/ > food.ko:3:24:07:41 > kldunload: can't unload file: Device busy > Exit 1 From yongari at FreeBSD.org Tue Mar 17 23:12:15 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Tue Mar 17 23:12:21 2009 Subject: kern/126469: [fxp] [panic] fxp(4) related kernel panic Message-ID: <200903180612.n2I6CEk3032233@freefall.freebsd.org> Synopsis: [fxp] [panic] fxp(4) related kernel panic State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Mar 18 06:09:32 UTC 2009 State-Changed-Why: Is this still issue on latest stable? I think I've fixed all known buffer exhausation issues of fxp(4). Would you give it spin on latest stable? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Mar 18 06:09:32 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=126469 From olli at lurza.secnetix.de Wed Mar 18 02:38:25 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Mar 18 02:38:32 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <25ff90d60903171427y4032d11es516d7b757fc3b8e0@mail.gmail.com> Message-ID: <200903180937.n2I9btPQ036563@lurza.secnetix.de> David Horn wrote: > I made a minor change to ifconfig to try kldloading the interface name > specified on the create wlandev XXXX (ifconfig already tries for > normal invocations, just needed to try with the wlandev interface) > [...] > This works nicely, however at startup, I still do not get the > interface up, or the kernel module loaded, so a second patch is > needed. I don't understand why you have to patch anything. It seems to work for me out of the box. For example, with the following entries in /etc/rc.conf, all required KLD modules are loaded automatically, and the interfaces are up: ifconfig_bge0="up" cloned_interfaces="vlan103 vlan105" ifconfig_vlan103="inet 10.103.0.20/16 vlan 103 vlandev bge0" ifconfig_vlan105="inet 10.105.0.20/16 vlan 105 vlandev bge0" Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman From dhorn2000 at gmail.com Wed Mar 18 08:18:27 2009 From: dhorn2000 at gmail.com (David Horn) Date: Wed Mar 18 08:18:34 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <200903180937.n2I9btPQ036563@lurza.secnetix.de> References: <25ff90d60903171427y4032d11es516d7b757fc3b8e0@mail.gmail.com> <200903180937.n2I9btPQ036563@lurza.secnetix.de> Message-ID: <25ff90d60903180818j16996fd5vf9dda27a1ebd0d0f@mail.gmail.com> On Wed, Mar 18, 2009 at 5:37 AM, Oliver Fromme wrote: > David Horn wrote: > ?> I made a minor change to ifconfig to try kldloading the interface name > ?> specified on the create wlandev XXXX (ifconfig already tries for > ?> normal invocations, just needed to try with the wlandev interface) > ?> [...] > ?> This works nicely, however at startup, I still do not get the > ?> interface up, or the kernel module loaded, so a second patch is > ?> needed. > > I don't understand why you have to patch anything. ?It > seems to work for me out of the box. ?For example, with > the following entries in /etc/rc.conf, all required KLD > modules are loaded automatically, and the interfaces > are up: The first patch is required for dynamic kernel loading in the wlandev invocation of ifconfig. e.g.: ifconfig wlan create wlandev iwn0 This is part of the vaps changes, and ifconfig was not updated yet for this new kernel load case. > > ifconfig_bge0="up" > cloned_interfaces="vlan103 vlan105" > ifconfig_vlan103="inet 10.103.0.20/16 vlan 103 vlandev bge0" > ifconfig_vlan105="inet 10.105.0.20/16 vlan 105 vlandev bge0" Interesting. Are you certain that bge is a kernel module, and not statically built into your kernel ? Are you using /boot/loader.conf to load the module ? What does kldstat show ? I ran through all of the case scenarios I can find, and the rc.d scripts would not call ifconfig on an interface that did not already have a kernel module loaded. If you know something here that I do not, please share. :) --Thanks! --Dave H > > Best regards > ? Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, ?Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, ?Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: ?http://www.secnetix.de/bsd > > "Unix gives you just enough rope to hang yourself -- > and then a couple of more feet, just to be sure." > ? ? ? ?-- Eric Allman > From olli at lurza.secnetix.de Wed Mar 18 08:50:51 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Mar 18 08:50:59 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <200903180937.n2I9btPQ036563@lurza.secnetix.de> Message-ID: <200903181550.n2IFoIVZ052377@lurza.secnetix.de> Oliver Fromme wrote: > ifconfig_bge0="up" > cloned_interfaces="vlan103 vlan105" > ifconfig_vlan103="inet 10.103.0.20/16 vlan 103 vlandev bge0" > ifconfig_vlan105="inet 10.105.0.20/16 vlan 105 vlandev bge0" Sorry, I forgot to paste one line: network_interfaces="bge0 lo0" That one is essential. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz From dhorn2000 at gmail.com Wed Mar 18 09:04:39 2009 From: dhorn2000 at gmail.com (David Horn) Date: Wed Mar 18 09:04:46 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <200903181550.n2IFoIVZ052377@lurza.secnetix.de> References: <200903180937.n2I9btPQ036563@lurza.secnetix.de> <200903181550.n2IFoIVZ052377@lurza.secnetix.de> Message-ID: <25ff90d60903180904ud077fcdy344cda5307a9037e@mail.gmail.com> On Wed, Mar 18, 2009 at 11:50 AM, Oliver Fromme wrote: > Oliver Fromme wrote: > ?> ifconfig_bge0="up" > ?> cloned_interfaces="vlan103 vlan105" > ?> ifconfig_vlan103="inet 10.103.0.20/16 vlan 103 vlandev bge0" > ?> ifconfig_vlan105="inet 10.105.0.20/16 vlan 105 vlandev bge0" > > Sorry, I forgot to paste one line: > > ?network_interfaces="bge0 lo0" Ah. Ok, now I am understanding your scenario. I thought that using 'network_interfaces' with anything other than "AUTO" was in the process of being depreciated ? rc.conf man page: network_interfaces (str) Set to the list of network interfaces to configure on this host or ``AUTO'' (the default) for all current inter- faces. Setting the network_interfaces variable to anything other than the default is deprecated. Interfaces that the administrator wishes to store configuration for, but not start at boot should be configured with the ``NOAUTO'' key- word in their ifconfig_ variables as described below. An ifconfig_ variable is also assumed to exist for each value of interface. When an interface name contains any of the characters ``.-/+'' they are translated to ``_'' before lookup. The variable can contain arguments to ifconfig(8), as well as special case-insensitive keywords described below. Such keywords are removed before passing the value to ifconfig(8) while the order of the other argu- ments is preserved. --Thanks! --_Dave Horn > > That one is essential. ?:-) > > Best regards > ? Oliver > > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, ?Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, ?Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: ?http://www.secnetix.de/bsd > > "anyone new to programming should be kept as far from C++ as > possible; ?actually showing the stuff should be considered a > criminal offence" -- Jacek Generowicz > From julian at elischer.org Wed Mar 18 09:16:15 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Mar 18 09:16:22 2009 Subject: netgraph modules won't unload after use In-Reply-To: <6CBA0923-DAF1-4FD5-A670-F5888BCA47B1@aeria.net> References: <6CBA0923-DAF1-4FD5-A670-F5888BCA47B1@aeria.net> Message-ID: <49C11E56.7090809@elischer.org> Ash Gokhale wrote: > I'm developing a kernel module that will be doing inspection and needed > access to raw network frames, > so I turned to netgraph as the solution.However it seems that netgraph > will not permit a module > to unload once it's participated in a mkpeer/connect operation. > Rebooting to remove a module is > angrymaking (not like mtx/sleep crashes). > > This going into the kernel because my bpf based userland stuff is > probably not going to hold up to the packet rate. > > Should I file a PR? Or is there magic in the documentation I havn't found? > > > I've observed the trouble in 7.0 release, and tonight's 7_RELENG, with > GENERIC + WITNESS/INVARIANTS > > The module code ( cobbled together from netgraph/ng_sample.c / ng_echo.c) > http://pastebin.com/m31b6ece6 > > The module loads and unloads fine until connected to a netgraph hook: hmm they are supposed to, and they did in the past.. let me check... root@trafmon1:kldload ng_ether root@trafmon1:ifconfig bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:43:30:fb:8a inet 10.7.2.3 netmask 0xffffff00 broadcast 10.7.2.255 media: Ethernet autoselect (100baseTX ) status: active bge1: flags=8802 metric 0 mtu 1500 options=9b ether 00:11:43:30:fb:8b media: Ethernet autoselect (none) status: no carrier fxp0: flags=8843 metric 0 mtu 1500 options=b ether 00:0e:0c:62:aa:14 inet 10.7.0.101 netmask 0xffffff00 broadcast 10.7.0.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 root@trafmon1:ngctl + list There are 4 total nodes: Name: bge0 Type: ether ID: 00000002 Num hooks: 0 Name: bge1 Type: ether ID: 00000003 Num hooks: 0 Name: ngctl4252 Type: socket ID: 00000005 Num hooks: 0 Name: fxp0 Type: ether ID: 00000004 Num hooks: 0 + mkpeer bge0: hole lower hook + list There are 5 total nodes: Name: Type: hole ID: 00000006 Num hooks: 1 Name: bge0 Type: ether ID: 00000002 Num hooks: 1 Name: bge1 Type: ether ID: 00000003 Num hooks: 0 Name: ngctl4252 Type: socket ID: 00000005 Num hooks: 0 Name: fxp0 Type: ether ID: 00000004 Num hooks: 0 + shutdown [6]: + list There are 4 total nodes: Name: bge0 Type: ether ID: 00000002 Num hooks: 0 Name: bge1 Type: ether ID: 00000003 Num hooks: 0 Name: ngctl4252 Type: socket ID: 00000005 Num hooks: 0 Name: fxp0 Type: ether ID: 00000004 Num hooks: 0 + quit root@trafmon1:kldstat -v Id Refs Address Size Name 1 36 0xc0400000 6a9c28 kernel (/boot/kernel/kernel) [...] 7 1 0xccb16000 4000 ng_ether.ko (/boot/kernel/ng_ether.ko) Contains modules: Id Name 246 ng_ether 8 1 0xccb1b000 2000 ng_hole.ko (/boot/kernel/ng_hole.ko) Contains modules: Id Name 247 ng_hole root@trafmon1:klunload ng_hole klunload: Command not found. root@trafmon1:kldunload ng_hole root@trafmon1:kldunload ng_ether kldunload: can't unload file: Device busy root@trafmon1:kldstat -v Id Refs Address Size Name 1 36 0xc0400000 6a9c28 kernel (/boot/kernel/kernel) [...] 7 1 0xccb16000 4000 ng_ether.ko (/boot/kernel/ng_ether.ko) Contains modules: Id Name 246 ng_ether root@trafmon1: this is expected. ng-ether is not unloadable as the connections are too complicated to unwind easily.. one day.... root@trafmon1: >> Stop in /root/tmp/food.ko. >> Exit 1 >> #Mar 18 03:14:31 kernel: quiesced >> :ro:~/tmp/food.ko:3:14:31:32 >> Mar 18 03:14:31 kernel: foodmod unloaded > > > Seems that I can't unload some of the other netgraph types either ( it's > not just me): > >> #kldunload ng_ether >> :ro:~/tmp/food.ko:3:24:07:41 >> kldunload: can't unload file: Device busy >> Exit 1 try unloading a node that IS unloadable.. see the following comment in ng_ehter.c: /* * Note that the base code won't try to unload us until * all nodes have been removed, and that can't happen * until all Ethernet interfaces are removed. In any * case, we know there are no nodes left if the action * is MOD_UNLOAD, so there's no need to detach any nodes. */ so we can't run this unless you have removeable ethernet interfaces, and have removed them. > > > _______________________________________________ > 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 olli at lurza.secnetix.de Wed Mar 18 09:27:08 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Mar 18 09:27:15 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <25ff90d60903180904ud077fcdy344cda5307a9037e@mail.gmail.com> Message-ID: <200903181626.n2IGQgqt054487@lurza.secnetix.de> David Horn wrote: > Oliver Fromme wrote: > > > > ?network_interfaces="bge0 lo0" > > Ah. Ok, now I am understanding your scenario. > > I thought that using 'network_interfaces' with anything other than > "AUTO" was in the process of being depreciated ? Well, the manual page says so, but I think that is a mistake. There are cases where you have to specify the list of interfaces explicitly. The situation described in this thread is one such case. My opinion is that it is good to have the ability to let things be done automatically, but it is bad to remove the ability to do things manually. This is UNIX, after all. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 From sam at freebsd.org Wed Mar 18 09:43:35 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Mar 18 09:43:42 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <200903181626.n2IGQgqt054487@lurza.secnetix.de> References: <200903181626.n2IGQgqt054487@lurza.secnetix.de> Message-ID: <49C124B6.2030503@freebsd.org> Oliver Fromme wrote: > David Horn wrote: > > Oliver Fromme wrote: > > > > > > network_interfaces="bge0 lo0" > > > > Ah. Ok, now I am understanding your scenario. > > > > I thought that using 'network_interfaces' with anything other than > > "AUTO" was in the process of being depreciated ? > > Well, the manual page says so, but I think that is a > mistake. There are cases where you have to specify the > list of interfaces explicitly. The situation described > in this thread is one such case. > > My opinion is that it is good to have the ability to let > things be done automatically, but it is bad to remove the > ability to do things manually. This is UNIX, after all. > I personally hate the auto-magic-loading of modules that ifconfig does. Remember that we tried to yank it once before but had to bring it back for compatibility. If one argues that ifconfig should be consistent in it's treatment of module loading then the patch is fine and should go in. Otherwise... Sam From bms at incunabulum.net Wed Mar 18 10:15:08 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Mar 18 10:15:15 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <20090318003944.GA41410@michelle.cdnetworks.co.kr> References: <49BF54EB.3070800@incunabulum.net> <20090318003944.GA41410@michelle.cdnetworks.co.kr> Message-ID: <49C12C19.7060404@incunabulum.net> Pyun YongHyeon wrote: > Do you have ae(4) hardware? I'm not sure why stas@ removed WOL part > in the MFC but it could be lack of testing(CCed to stas@). I've > attached diff that includes WOL support from HEAD. > > Thanks. I tested this OK on the EeePC 701 so I've committed it! cheers BMS From dhorn2000 at gmail.com Wed Mar 18 10:33:12 2009 From: dhorn2000 at gmail.com (David Horn) Date: Wed Mar 18 10:33:19 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <200903181626.n2IGQgqt054487@lurza.secnetix.de> References: <25ff90d60903180904ud077fcdy344cda5307a9037e@mail.gmail.com> <200903181626.n2IGQgqt054487@lurza.secnetix.de> Message-ID: <25ff90d60903181033n5d3f0a79w7a8ea504f911ecf@mail.gmail.com> On Wed, Mar 18, 2009 at 12:26 PM, Oliver Fromme wrote: > David Horn wrote: > ?> Oliver Fromme wrote: > ?> > > ?> > ?network_interfaces="bge0 lo0" > ?> > ?> Ah. ?Ok, now I am understanding your scenario. > ?> > ?> I thought that using 'network_interfaces' with anything other than > ?> "AUTO" ?was in the process of being depreciated ? > > Well, the manual page says so, but I think that is a > mistake. ?There are cases where you have to specify the > list of interfaces explicitly. ?The situation described > in this thread is one such case. Good point. > > My opinion is that it is good to have the ability to let > things be done automatically, but it is bad to remove the > ability to do things manually. ?This is UNIX, after all. Exactly. Both scenarios should probably be supported, but I guess we would need to ask brooks for some history on the depreciated warning for network_interfaces. ================================================= src/etc/network.subr Revision 1.185: download - view: text, markup, annotated - [selected for diffs] Wed Apr 30 16:29:15 2008 UTC (10 months, 2 weeks ago) by brooks Branches: MAIN Diff to: previous 1.184: preferred, colored Changes since revision 1.184: +4 -0 lines Emit a warning when the network_interfaces variable is not set to AUTO. MFC after: 3 days ================================================== --Thanks! -_Dave H > > Best regards > ? Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, ?Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, ?Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: ?http://www.secnetix.de/bsd > > "The ITU has offered the IETF formal alignment with its > corresponding technology, Penguins, but that won't fly." > ? ? ? ?-- RFC 2549 > From rpaulo at freebsd.org Wed Mar 18 16:30:06 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed Mar 18 16:30:22 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200903182330.n2INU4rH015615@freefall.freebsd.org> The following reply was made to PR kern/131153; it has been noted by GNATS. From: Rui Paulo To: bug-followup@FreeBSD.org, adamk@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Wed, 18 Mar 2009 22:58:10 +0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--735631158 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Please include the result of the following command: wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0 -dd Thanks. --Apple-Mail-10--735631158 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknBfIIACgkQfD8M/ASTygIScACdG3Vq1VaZ/+hB259pIWmwLVuX p98AoNhqHBex14lagyuoMP2OoBKxUpqU =3wfU -----END PGP SIGNATURE----- --Apple-Mail-10--735631158-- From pyunyh at gmail.com Wed Mar 18 18:24:36 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Mar 18 18:25:09 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <49C12C19.7060404@incunabulum.net> References: <49BF54EB.3070800@incunabulum.net> <20090318003944.GA41410@michelle.cdnetworks.co.kr> <49C12C19.7060404@incunabulum.net> Message-ID: <20090319012449.GJ41410@michelle.cdnetworks.co.kr> On Wed, Mar 18, 2009 at 05:15:05PM +0000, Bruce Simpson wrote: > Pyun YongHyeon wrote: > >Do you have ae(4) hardware? I'm not sure why stas@ removed WOL part > >in the MFC but it could be lack of testing(CCed to stas@). I've > >attached diff that includes WOL support from HEAD. > > > > > > Thanks. I tested this OK on the EeePC 701 so I've committed it! > Great! Thanks. From linimon at FreeBSD.org Wed Mar 18 21:35:34 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 18 21:35:47 2009 Subject: kern/123890: [ppp] [panic] crash & reboot on work with PPP low-speed connection Message-ID: <200903190435.n2J4ZXb5020684@freefall.freebsd.org> Synopsis: [ppp] [panic] crash & reboot on work with PPP low-speed connection Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 19 04:35:24 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123890 From linimon at FreeBSD.org Thu Mar 19 04:19:07 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Mar 19 04:19:20 2009 Subject: bin/132798: [patch] ggatec(8): ggated/ggatec connection slowdown problem Message-ID: <200903191119.n2JBJ4HF075405@freefall.freebsd.org> Old Synopsis: ggated/ggatec New Synopsis: [patch] ggatec(8): ggated/ggatec connection slowdown problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 19 11:17:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132798 From stas at FreeBSD.org Thu Mar 19 07:12:06 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Mar 19 07:12:12 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <49C12C19.7060404@incunabulum.net> References: <49BF54EB.3070800@incunabulum.net> <20090318003944.GA41410@michelle.cdnetworks.co.kr> <49C12C19.7060404@incunabulum.net> Message-ID: <20090319165924.fadd1e27.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 18 Mar 2009 17:15:05 +0000 Bruce Simpson mentioned: > Pyun YongHyeon wrote: > > Do you have ae(4) hardware? I'm not sure why stas@ removed WOL part > > in the MFC but it could be lack of testing(CCed to stas@). I've > > attached diff that includes WOL support from HEAD. > > > > > > Thanks. I tested this OK on the EeePC 701 so I've committed it! > So, basically WOL works on 7.1 with ae and the PC resumes correctly? Thanks for committing this! - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknCT8IACgkQK/VZk+smlYHk6gCeMI1lvEnr/FTYwNgZSHEruD+h OTQAnRDWyKNEv3qF5jZONvlhJhWCFs4h =IUCd -----END PGP SIGNATURE----- !DSPAM:49c24f14967005928620533! From ivan at serezhkin.com Thu Mar 19 07:21:53 2009 From: ivan at serezhkin.com (Vany Serezhkin) Date: Thu Mar 19 07:22:00 2009 Subject: 802.1x broken after SVN rev 189592 Message-ID: <49C2504F.2030003@serezhkin.com> Hello. I do not really sure in this, but : after the current updated to 20090309 Merge IGMPv3 and Source-Specific Multicast (SSM) to the FreeBSD IPv4 stack. I can't use any wpa_supplicant related networks. It faulted in any WPA authentications , that i tried. Also it faulted when i try to login via 802.1x in my job network. All happens after i starts wpa_supplicant and looks like these: #11 0xc05cabec in panic (fmt=0xc08b16e9 "sbappendaddr_locked") at /opt/src/sys/kern/kern_shutdown.c:559 #12 0xc061fd40 in sbappendaddr_locked (sb=0xc66dd670, asa=0xc09021b4, m0=0xce435b00, control=0x0) at /opt/src/sys/kern/uipc_sockbuf.c:632 #13 0xc0620418 in sbappendaddr (sb=0xc66dd670, asa=0xc09021b4, m0=0xce435b00, control=0x0) at /opt/src/sys/kern/uipc_sockbuf.c:679 #14 0xc0671be4 in raw_input (m0=0xc64b0100, proto=0xe664ec60, src=0xc09021b4) at /opt/src/sys/net/raw_usrreq.c:96 #15 0xc06749e7 in rts_input (m=0xc64b0100) at /opt/src/sys/net/rtsock.c:151 #16 0xc066f752 in swi_net (dummy=0x0) at /opt/src/sys/net/netisr.c:145 #17 0xc05aa148 in intr_event_execute_handlers (p=0xc61617ec, ie=0xc61a2d00) at /opt/src/sys/kern/kern_intr.c:1134 #18 0xc05ab4d4 in ithread_loop (arg=0xc60ec660) at /opt/src/sys/kern/kern_intr.c:1147 #19 0xc05a7ac9 in fork_exit (callout=0xc05ab469 , arg=0xc60ec660, frame=0xe664ed38) at /opt/src/sys/kern/kern_fork.c:821 #20 0xc0833170 in fork_trampoline () at /opt/src/sys/i386/i386/exception.s:270 -- Vany Serezhkin. Yandex. http://yandex.ru/ From guru at unixarea.de Thu Mar 19 07:42:55 2009 From: guru at unixarea.de (Matthias Apitz) Date: Thu Mar 19 07:43:02 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49BFF258.4020207@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> Message-ID: <20090319144251.GA13320@rebelion.Sisis.de> El d?a Tuesday, March 17, 2009 a las 11:56:24AM -0700, Sam Leffler escribi?: > His setup is static key wep; not wpa so I don't think wpa_supplicant is > the issue. > > Matthias, your tcpdump of the dhclient packets isn't usable; please try: > > tcpdump -i ath0 -n -y IEEE802_11_RADIO > > I reviewed the driver to the code in HEAD and the only difference in the > crypto area should not matter in this case. It's possible wme is > somehow enabled and causing problems but the ifconfig output doesn't > indicate that. > > If you can find out the model of ap that might be helpful. > Unfortunately the best thing to try is HEAD. I will try to collect a better tcpdump of the dhclient packets on the weekend and as well figure out what kind of model the AP is; would it be helpful to connect with a Windows XP laptop (which seems to work) to gather some information of the Wifi and other network parameters? how this could be seen in Windows? maybe there is some special compression of the payload of the packages in place? I have seen such 'options' in another AP (a Netgear WGT624 v3), the option was called "[ ] Disable Advanced 108Mbps Features" and this must be checked (i.e. disabled) to make DHCP happy with the ath0 EeePC; unfortunately I can't look into the AP about this problem is :-( thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From pgoggins at cc.edu Thu Mar 19 08:02:48 2009 From: pgoggins at cc.edu (Patrick Goggins) Date: Thu Mar 19 08:02:55 2009 Subject: multiple interfaces and pf rdr bug Message-ID: When configuring a system with three interfaces, two of them as a transparent bridge and a management interface one could configure the rules to allow users to connect to the management interface from being behind the bridge. However, if an rdr rule is applied to force this then, the clients connections time out. If the clients with this rule applied attempt to go directly to the management interface they are able to and if the rdr rule is changed to anything other than the management interface it works. There are allow rules created on the inside interface of the bridge and all other interfaces are set to skip. Can anyone else confirm this is a bug or correct me on my logic? ~Patrick From sam at freebsd.org Thu Mar 19 08:44:32 2009 From: sam at freebsd.org (Sam Leffler) Date: Thu Mar 19 08:44:39 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090319144251.GA13320@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> Message-ID: <49C2685D.6040801@freebsd.org> Matthias Apitz wrote: > El d?a Tuesday, March 17, 2009 a las 11:56:24AM -0700, Sam Leffler escribi?: > > >> His setup is static key wep; not wpa so I don't think wpa_supplicant is >> the issue. >> >> Matthias, your tcpdump of the dhclient packets isn't usable; please try: >> >> tcpdump -i ath0 -n -y IEEE802_11_RADIO >> >> I reviewed the driver to the code in HEAD and the only difference in the >> crypto area should not matter in this case. It's possible wme is >> somehow enabled and causing problems but the ifconfig output doesn't >> indicate that. >> >> If you can find out the model of ap that might be helpful. >> Unfortunately the best thing to try is HEAD. >> > > I will try to collect a better tcpdump of the dhclient packets on the > weekend and as well figure out what kind of model the AP is; > > would it be helpful to connect with a Windows XP laptop (which seems to > work) to gather some information of the Wifi and other network > parameters? how this could be seen in Windows? maybe there is some > special compression of the payload of the packages in place? > Having a packet trace of a working connection to compare would be very helpful. > I have seen such 'options' in another AP (a Netgear WGT624 v3), > the option was called "[ ] Disable Advanced 108Mbps Features" > and this must be checked (i.e. disabled) to make DHCP happy with > the ath0 EeePC; > That controls SuperG support in Atheros-based ap's and is unrelated. There is a known problem with SuperG support that has been fixed in HEAD but not yet backmerged. For reasons unknown your (apparently) simple setup is not working. I do not use RELENG_7 w/ the stock wireless and have no familiarity with it's status so it's more likely there's just some bug fix not back-merged. > unfortunately I can't look into the AP about this problem is :-( > > thx > > matthias > From sam at freebsd.org Thu Mar 19 09:12:34 2009 From: sam at freebsd.org (Sam Leffler) Date: Thu Mar 19 09:12:41 2009 Subject: 802.1x broken after SVN rev 189592 In-Reply-To: <49C2504F.2030003@serezhkin.com> References: <49C2504F.2030003@serezhkin.com> Message-ID: <49C26EE8.3040100@freebsd.org> Vany Serezhkin wrote: > Hello. > > I do not really sure in this, but : > > after the current updated to > 20090309 Merge IGMPv3 and Source-Specific Multicast (SSM) to the FreeBSD > IPv4 stack. > > I can't use any wpa_supplicant related networks. > > It faulted in any WPA authentications , that i tried. > Also it faulted when i try to login via 802.1x in my job network. > > All happens after i starts wpa_supplicant and looks like these: > > #11 0xc05cabec in panic (fmt=0xc08b16e9 "sbappendaddr_locked") at > /opt/src/sys/kern/kern_shutdown.c:559 > #12 0xc061fd40 in sbappendaddr_locked (sb=0xc66dd670, asa=0xc09021b4, > m0=0xce435b00, control=0x0) > at /opt/src/sys/kern/uipc_sockbuf.c:632 > #13 0xc0620418 in sbappendaddr (sb=0xc66dd670, asa=0xc09021b4, > m0=0xce435b00, control=0x0) > at /opt/src/sys/kern/uipc_sockbuf.c:679 > #14 0xc0671be4 in raw_input (m0=0xc64b0100, proto=0xe664ec60, > src=0xc09021b4) at /opt/src/sys/net/raw_usrreq.c:96 > #15 0xc06749e7 in rts_input (m=0xc64b0100) at > /opt/src/sys/net/rtsock.c:151 > #16 0xc066f752 in swi_net (dummy=0x0) at /opt/src/sys/net/netisr.c:145 > #17 0xc05aa148 in intr_event_execute_handlers (p=0xc61617ec, > ie=0xc61a2d00) at /opt/src/sys/kern/kern_intr.c:1134 > #18 0xc05ab4d4 in ithread_loop (arg=0xc60ec660) at > /opt/src/sys/kern/kern_intr.c:1147 > #19 0xc05a7ac9 in fork_exit (callout=0xc05ab469 , > arg=0xc60ec660, frame=0xe664ed38) > at /opt/src/sys/kern/kern_fork.c:821 > #20 0xc0833170 in fork_trampoline () at > /opt/src/sys/i386/i386/exception.s:270 > Are you certain it's that revision? Have you tried r189931 which worked around certain problems in the initial commit? Can you provide sufficient info to reproduce your problem? Filing a PR for reference is likely the best thing to do. Sam From bms at incunabulum.net Thu Mar 19 09:13:29 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Mar 19 09:13:36 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <20090319165924.fadd1e27.stas@FreeBSD.org> References: <49BF54EB.3070800@incunabulum.net> <20090318003944.GA41410@michelle.cdnetworks.co.kr> <49C12C19.7060404@incunabulum.net> <20090319165924.fadd1e27.stas@FreeBSD.org> Message-ID: <49C26F1E.6020701@incunabulum.net> Stanislav Sedov wrote: > > So, basically WOL works on 7.1 with ae and the PC resumes correctly? > That's what I saw. Video is still broken for me on resume, though everything else on the EeePC 701 resumed OK. cheers, BMS From bms at incunabulum.net Thu Mar 19 09:13:48 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Mar 19 09:13:55 2009 Subject: 802.1x broken after SVN rev 189592 In-Reply-To: <49C2504F.2030003@serezhkin.com> References: <49C2504F.2030003@serezhkin.com> Message-ID: <49C26F2F.9080401@incunabulum.net> Hi, Based on the backtrace you've provided, this doesn't seem like a multicast related issue. I skimmed wpa_supplicant and I see that whilst it requests a link-layer multicast address, it does not use IPv4 multicast. Vany Serezhkin wrote: > Hello. > > I do not really sure in this, but : > > after the current updated to > 20090309 Merge IGMPv3 and Source-Specific Multicast (SSM) to the FreeBSD > IPv4 stack. > > I can't use any wpa_supplicant related networks. > > It faulted in any WPA authentications , that i tried. > Also it faulted when i try to login via 802.1x in my job network. General questions: Are you running any routing protocols on this machine, or anything which opens a multicast socket at system startup? Do you have more than one processor core enabled? Can you transcribe the console panic message so we can see which process has panicked in the routing socket path? thanks, BMS From stas at FreeBSD.org Thu Mar 19 09:42:53 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Mar 19 09:43:01 2009 Subject: ae(4) Wake-on-Lan MFC In-Reply-To: <49C26F1E.6020701@incunabulum.net> References: <49BF54EB.3070800@incunabulum.net> <20090318003944.GA41410@michelle.cdnetworks.co.kr> <49C12C19.7060404@incunabulum.net> <20090319165924.fadd1e27.stas@FreeBSD.org> <49C26F1E.6020701@incunabulum.net> Message-ID: <20090319194543.79efb4c9.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 19 Mar 2009 16:13:18 +0000 Bruce Simpson mentioned: > Stanislav Sedov wrote: > > > > So, basically WOL works on 7.1 with ae and the PC resumes correctly? > > > > That's what I saw. Video is still broken for me on resume, though everything > else on the EeePC 701 resumed OK. > For video you will probably need sysctl hw.acpi.asus.lcd_brightness=8 in rc.resume. At least, this is required to bring the screen back to light. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknCdrcACgkQK/VZk+smlYH+HACfYBiDVlymoUTr2weNn3A+2ZT0 v50AnRGpfsGEJz5mMJ5PzvPfFC+ek17b =XgJ0 -----END PGP SIGNATURE----- !DSPAM:49c27609967005190327887! From ivan at serezhkin.com Thu Mar 19 09:57:55 2009 From: ivan at serezhkin.com (Vany Serezhkin) Date: Thu Mar 19 09:58:03 2009 Subject: 802.1x broken after SVN rev 189592 In-Reply-To: <49C26F2F.9080401@incunabulum.net> References: <49C2504F.2030003@serezhkin.com> <49C26F2F.9080401@incunabulum.net> Message-ID: <49C2797C.3060900@serezhkin.com> Hello again. Bruce Simpson wrote: > General questions: > Are you running any routing protocols on this machine, or anything > which opens a multicast socket at system startup? No, any it is a simple work notebook. May be it avahi or hald starts something, but i think they isn't. > Do you have more than one processor core enabled? Yes, dualcore T7500 on i945. > Can you transcribe the console panic message so we can see which > process has panicked in the routing socket path? Please help me, i not too familiar with kdb, I can only type panic and kernel dumps to file, an then use kgdb. Is it enough ? Now i update system to current state and try this manipulations again. -- Vany Serezhkin. Yandex. http://yandex.ru/ From bms at FreeBSD.org Thu Mar 19 10:45:43 2009 From: bms at FreeBSD.org (bms@FreeBSD.org) Date: Thu Mar 19 10:45:49 2009 Subject: kern/122427: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast) Message-ID: <200903191745.n2JHjgdq089544@freefall.freebsd.org> Synopsis: [apm] [panic] apm and mDNSResponder cause panic during shutdown (multicast) State-Changed-From-To: open->closed State-Changed-By: bms State-Changed-When: Thu 19 Mar 2009 17:45:25 UTC State-Changed-Why: fixed in RELENG_6 and up http://www.freebsd.org/cgi/query-pr.cgi?pr=122427 From bms at incunabulum.net Thu Mar 19 10:50:03 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Mar 19 10:50:10 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Message-ID: <200903191750.n2JHo2rX089652@freefall.freebsd.org> The following reply was made to PR kern/122839; it has been noted by GNATS. From: Bruce Simpson To: Eugene <4pr@legis.krsn.ru>, freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Thu, 19 Mar 2009 17:47:38 +0000 Hi, Have you managed to chase the em(4) patch upstream? It would be great if you could let me know so this PR can either be closed, or assigned to the em(4) driver maintainer. thanks, BMS From 4pr at legis.krsn.ru Thu Mar 19 23:23:03 2009 From: 4pr at legis.krsn.ru (4pr@legis.krsn.ru) Date: Thu Mar 19 23:23:09 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem In-Reply-To: <49C2853A.9090602@incunabulum.net> Message-ID: Hi, As i wrote before, based on the patch, suggested by Tomas Svensson, we have made our version of that patch. And about a year already we using it on a production inside core router without any problems. Also we patched if_msk.c, and it also working just fine same amount of time on the same router. Both our patches for if_em.c and if_msk.c i have posted to the list. So i did not chased the em or msk patch upstream. Thanks, Eugene H. Brezin Bruce Simpson 20.03.2009 00:47 ????: Eugene <4pr@legis.krsn.ru>, freebsd-gnats-submit@freebsd.org ?????: ????: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Hi, Have you managed to chase the em(4) patch upstream? It would be great if you could let me know so this PR can either be closed, or assigned to the em(4) driver maintainer. thanks, BMS From 4pr at legis.krsn.ru Thu Mar 19 23:30:06 2009 From: 4pr at legis.krsn.ru (4pr@legis.krsn.ru) Date: Thu Mar 19 23:30:13 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Message-ID: <200903200630.n2K6U5Bo001757@freefall.freebsd.org> The following reply was made to PR kern/122839; it has been noted by GNATS. From: 4pr@legis.krsn.ru To: bug-followup@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Fri, 20 Mar 2009 12:54:41 +0700 SGksIA0KDQpBcyBpIHdyb3RlIGJlZm9yZSwgYmFzZWQgb24gdGhlIHBhdGNoLCBzdWdnZXN0ZWQg YnkgVG9tYXMgU3ZlbnNzb24sIHdlIA0KaGF2ZSBtYWRlIG91ciB2ZXJzaW9uIG9mIHRoYXQgcGF0 Y2guIEFuZCBhYm91dA0KYSB5ZWFyIGFscmVhZHkgd2UgdXNpbmcgaXQgb24gYSBwcm9kdWN0aW9u IGluc2lkZSBjb3JlIHJvdXRlciB3aXRob3V0IGFueSANCnByb2JsZW1zLiBBbHNvIHdlIHBhdGNo ZWQgIGlmX21zay5jLCBhbmQgaXQgYWxzbw0Kd29ya2luZyBqdXN0IGZpbmUgc2FtZSBhbW91bnQg b2YgdGltZSBvbiB0aGUgc2FtZSByb3V0ZXIuIEJvdGggb3VyIHBhdGNoZXMgDQpmb3IgaWZfZW0u YyBhbmQgaWZfbXNrLmMgaSBoYXZlIHBvc3RlZCB0byB0aGUgbGlzdC4NClNvIGkgZGlkIG5vdCBj aGFzZWQgdGhlIGVtIG9yIG1zayBwYXRjaCB1cHN0cmVhbS4NCg0KVGhhbmtzLCANCkV1Z2VuZSBI LiBCcmV6aW4NCg0KDQoNCg0KDQpCcnVjZSBTaW1wc29uIDxibXNAaW5jdW5hYnVsdW0ubmV0Pg0K MjAuMDMuMjAwOSAwMDo0Nw0KIA0KICAgICAgICDrz83VOiAgIEV1Z2VuZSA8NHByQGxlZ2lzLmty c24ucnU+LCANCmZyZWVic2QtZ25hdHMtc3VibWl0QGZyZWVic2Qub3JnDQogICAgICAgIOvP0MnR OiANCiAgICAgICAg9MXNwTogICBSZToga2Vybi8xMjI4Mzk6IFttdWx0aWNhc3RdIEZyZWVCU0Qg NyBtdWx0aWNhc3Qgcm91dGluZyANCnByb2JsZW0NCg0KDQpIaSwNCg0KSGF2ZSB5b3UgbWFuYWdl ZCB0byBjaGFzZSB0aGUgZW0oNCkgcGF0Y2ggdXBzdHJlYW0/DQoNCkl0IHdvdWxkIGJlIGdyZWF0 IGlmIHlvdSBjb3VsZCBsZXQgbWUga25vdyBzbyB0aGlzIFBSIGNhbiBlaXRoZXIgYmUgDQpjbG9z ZWQsDQpvciBhc3NpZ25lZCB0byB0aGUgZW0oNCkgZHJpdmVyIG1haW50YWluZXIuDQoNCnRoYW5r cywNCkJNUw0KDQoNCg== From guru at unixarea.de Fri Mar 20 01:53:10 2009 From: guru at unixarea.de (Matthias Apitz) Date: Fri Mar 20 01:53:17 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C2685D.6040801@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> Message-ID: <20090320085306.GA3399@rebelion.Sisis.de> El d?a Thursday, March 19, 2009 a las 08:44:29AM -0700, Sam Leffler escribi?: > Matthias Apitz wrote: > >El d?a Tuesday, March 17, 2009 a las 11:56:24AM -0700, Sam Leffler > >escribi?: > > > > > >>His setup is static key wep; not wpa so I don't think wpa_supplicant is > >>the issue. > >> > >>Matthias, your tcpdump of the dhclient packets isn't usable; please try: > >> > >>tcpdump -i ath0 -n -y IEEE802_11_RADIO > >> > >>I reviewed the driver to the code in HEAD and the only difference in the > >>crypto area should not matter in this case. It's possible wme is > >>somehow enabled and causing problems but the ifconfig output doesn't > >>indicate that. > >> > >>If you can find out the model of ap that might be helpful. > >>Unfortunately the best thing to try is HEAD. > >>... I'm going to build a HEAD kernel now with # cd /usr # mv src/sys src/sys.RELENG_7 # setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs # cvs checkout src/sys ... I've checked the FreeBSD handbook about SVN / CVS and it reads that all changes in SVN are back ported to CVS trees... just to make sure, is that reality? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From guru at unixarea.de Fri Mar 20 02:56:08 2009 From: guru at unixarea.de (Matthias Apitz) Date: Fri Mar 20 02:56:14 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C2685D.6040801@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> Message-ID: <20090320095603.GA5239@rebelion.Sisis.de> El d?a Thursday, March 19, 2009 a las 08:44:29AM -0700, Sam Leffler escribi?: > Matthias Apitz wrote: > >I will try to collect a better tcpdump of the dhclient packets on the > >weekend and as well figure out what kind of model the AP is; > > > >would it be helpful to connect with a Windows XP laptop (which seems to > >work) to gather some information of the Wifi and other network > >parameters? how this could be seen in Windows? maybe there is some > >special compression of the payload of the packages in place? > > > > Having a packet trace of a working connection to compare would be very > helpful. What would be the best tool in WinXP to log Wifi traffic, like tcpdump does? I see some 'Tcpdump for Windows' as http://microolap.com/products/network/tcpdump/ but it seems that it does not work for wireless adapters; any hints? matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From spawk at acm.poly.edu Fri Mar 20 03:10:57 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Fri Mar 20 03:11:05 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090320095603.GA5239@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> <20090320095603.GA5239@rebelion.Sisis.de> Message-ID: <49C36B85.2050202@acm.poly.edu> Matthias Apitz wrote: > El d?a Thursday, March 19, 2009 a las 08:44:29AM -0700, Sam Leffler escribi?: > > >> Matthias Apitz wrote: >> >>> I will try to collect a better tcpdump of the dhclient packets on the >>> weekend and as well figure out what kind of model the AP is; >>> >>> would it be helpful to connect with a Windows XP laptop (which seems to >>> work) to gather some information of the Wifi and other network >>> parameters? how this could be seen in Windows? maybe there is some >>> special compression of the payload of the packages in place? >>> >>> >> Having a packet trace of a working connection to compare would be very >> helpful. >> > > What would be the best tool in WinXP to log Wifi traffic, like tcpdump > does? I see some 'Tcpdump for Windows' as > http://microolap.com/products/network/tcpdump/ > but it seems that it does not work for wireless adapters; > any hints? > > matthias > http://www.wireshark.org/download.html -Boris From 4pr at legis.krsn.ru Fri Mar 20 04:12:26 2009 From: 4pr at legis.krsn.ru (4pr@legis.krsn.ru) Date: Fri Mar 20 04:12:35 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem In-Reply-To: <49C2853A.9090602@incunabulum.net> Message-ID: Hi, As i wrote before, based on the patch, suggested by Tomas Svensson, we have made our version of that patch. And about a year already we using it on a production inside core router without any problems. Also we patched if_msk.c, and it also working just fine same amount of time on the same router. Both our patches for if_em.c and if_msk.c i have posted to the list. So i did not chased the em or msk patch upstream. Thanks, Eugene H. Brezin From 4pr at legis.krsn.ru Fri Mar 20 04:20:03 2009 From: 4pr at legis.krsn.ru (4pr@legis.krsn.ru) Date: Fri Mar 20 04:20:10 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Message-ID: <200903201120.n2KBK2aR005744@freefall.freebsd.org> The following reply was made to PR kern/122839; it has been noted by GNATS. From: 4pr@legis.krsn.ru To: bug-followup@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Fri, 20 Mar 2009 17:56:11 +0700 Hi, As i wrote before, based on the patch, suggested by Tomas Svensson, we have made our version of that patch. And about a year already we using it on a production inside core router without any problems. Also we patched if_msk.c, and it also working just fine same amount of time on the same router. Both our patches for if_em.c and if_msk.c i have posted to the list. So i did not chased the em or msk patch upstream. Thanks, Eugene H. Brezin From pyunyh at gmail.com Fri Mar 20 04:39:21 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Mar 20 04:39:27 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem In-Reply-To: References: <49C2853A.9090602@incunabulum.net> Message-ID: <20090320113954.GF50100@michelle.cdnetworks.co.kr> On Fri, Mar 20, 2009 at 05:56:11PM +0700, 4pr@legis.krsn.ru wrote: > Hi, > > As i wrote before, based on the patch, suggested by Tomas Svensson, we > have made our version of that patch. And about > a year already we using it on a production inside core router without any > problems. Also we patched if_msk.c, and it also > working just fine same amount of time on the same router. Both our patches > for if_em.c and if_msk.c i have posted to the list. > So i did not chased the em or msk patch upstream. > Would you try attached msk(4) patch? I think em(4) patch you posted looks right. Jack may handle this(CCed). -------------- next part -------------- A non-text attachment was scrubbed... Name: msk.allmulti.patch Type: text/x-diff Size: 3425 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090320/6be3d474/msk.allmulti.bin From pyunyh at gmail.com Fri Mar 20 04:40:05 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Mar 20 04:40:15 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Message-ID: <200903201140.n2KBe47h035602@freefall.freebsd.org> The following reply was made to PR kern/122839; it has been noted by GNATS. From: Pyun YongHyeon To: 4pr@legis.krsn.ru Cc: bug-followup@freebsd.org, bms@freebsd.org, freebsd-net@freebsd.org, jfv@FreeBSD.org Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Fri, 20 Mar 2009 20:39:54 +0900 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 20, 2009 at 05:56:11PM +0700, 4pr@legis.krsn.ru wrote: > Hi, > > As i wrote before, based on the patch, suggested by Tomas Svensson, we > have made our version of that patch. And about > a year already we using it on a production inside core router without any > problems. Also we patched if_msk.c, and it also > working just fine same amount of time on the same router. Both our patches > for if_em.c and if_msk.c i have posted to the list. > So i did not chased the em or msk patch upstream. > Would you try attached msk(4) patch? I think em(4) patch you posted looks right. Jack may handle this(CCed). --7JfCtLOvnd9MIVvH Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.allmulti.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 190121) +++ sys/dev/msk/if_msk.c (working copy) @@ -287,9 +287,8 @@ static void msk_miibus_statchg(device_t); static void msk_link_task(void *, int); -static void msk_setmulti(struct msk_if_softc *); +static void msk_rxfilter(struct msk_if_softc *); static void msk_setvlan(struct msk_if_softc *, struct ifnet *); -static void msk_setpromisc(struct msk_if_softc *); static void msk_stats_clear(struct msk_if_softc *); static void msk_stats_update(struct msk_if_softc *); @@ -560,7 +559,7 @@ } static void -msk_setmulti(struct msk_if_softc *sc_if) +msk_rxfilter(struct msk_if_softc *sc_if) { struct msk_softc *sc; struct ifnet *ifp; @@ -577,15 +576,14 @@ bzero(mchash, sizeof(mchash)); mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL); - mode |= GM_RXCR_UCF_ENA; - if ((ifp->if_flags & (IFF_PROMISC | IFF_ALLMULTI)) != 0) { - if ((ifp->if_flags & IFF_PROMISC) != 0) - mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA); - else if ((ifp->if_flags & IFF_ALLMULTI) != 0) { - mchash[0] = 0xffff; - mchash[1] = 0xffff; - } + if ((ifp->if_flags & IFF_PROMISC) != 0) + mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA); + else if ((ifp->if_flags & IFF_ALLMULTI) != 0) { + mode |= GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA; + mchash[0] = 0xffff; + mchash[1] = 0xffff; } else { + mode |= GM_RXCR_UCF_ENA; IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { if (ifma->ifma_addr->sa_family != AF_LINK) @@ -598,7 +596,8 @@ mchash[crc >> 5] |= 1 << (crc & 0x1f); } IF_ADDR_UNLOCK(ifp); - mode |= GM_RXCR_MCF_ENA; + if (mchash[0] != 0 || mchash[1] != 0) + mode |= GM_RXCR_MCF_ENA; } GMAC_WRITE_2(sc, sc_if->msk_port, GM_MC_ADDR_H1, @@ -631,26 +630,6 @@ } } -static void -msk_setpromisc(struct msk_if_softc *sc_if) -{ - struct msk_softc *sc; - struct ifnet *ifp; - uint16_t mode; - - MSK_IF_LOCK_ASSERT(sc_if); - - sc = sc_if->msk_softc; - ifp = sc_if->msk_ifp; - - mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL); - if (ifp->if_flags & IFF_PROMISC) - mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA); - else - mode |= (GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA); - GMAC_WRITE_2(sc, sc_if->msk_port, GM_RX_CTRL, mode); -} - static int msk_init_rx_ring(struct msk_if_softc *sc_if) { @@ -954,10 +933,8 @@ if ((ifp->if_flags & IFF_UP) != 0) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { if (((ifp->if_flags ^ sc_if->msk_if_flags) - & IFF_PROMISC) != 0) { - msk_setpromisc(sc_if); - msk_setmulti(sc_if); - } + & (IFF_PROMISC | IFF_ALLMULTI)) != 0) + msk_rxfilter(sc_if); } else { if (sc_if->msk_detach == 0) msk_init_locked(sc_if); @@ -973,7 +950,7 @@ case SIOCDELMULTI: MSK_IF_LOCK(sc_if); if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) - msk_setmulti(sc_if); + msk_rxfilter(sc_if); MSK_IF_UNLOCK(sc_if); break; case SIOCGIFMEDIA: @@ -3594,12 +3571,9 @@ CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, RX_GMF_CTRL_T), GMF_OPER_ON | GMF_RX_F_FL_ON); - /* Set promiscuous mode. */ - msk_setpromisc(sc_if); + /* Set receive filter. */ + msk_rxfilter(sc_if); - /* Set multicast filter. */ - msk_setmulti(sc_if); - /* Flush Rx MAC FIFO on any flow control or error. */ CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, RX_GMF_FL_MSK), GMR_FS_ANY_ERR); --7JfCtLOvnd9MIVvH-- From guru at unixarea.de Fri Mar 20 05:10:36 2009 From: guru at unixarea.de (Matthias Apitz) Date: Fri Mar 20 05:10:44 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C2685D.6040801@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> Message-ID: <20090320121021.GA2051@rebelion.Sisis.de> El d?a Thursday, March 19, 2009 a las 08:44:29AM -0700, Sam Leffler escribi?: > Matthias Apitz wrote: > >El d?a Tuesday, March 17, 2009 a las 11:56:24AM -0700, Sam Leffler > >escribi?: > > > > > >>His setup is static key wep; not wpa so I don't think wpa_supplicant is > >>the issue. > >> > >>Matthias, your tcpdump of the dhclient packets isn't usable; please try: > >> > >>tcpdump -i ath0 -n -y IEEE802_11_RADIO > >> > >>I reviewed the driver to the code in HEAD and the only difference in the > >>crypto area should not matter in this case. It's possible wme is > >>somehow enabled and causing problems but the ifconfig output doesn't > >>indicate that. > >> > >>If you can find out the model of ap that might be helpful. > >>Unfortunately the best thing to try is HEAD. > >> I've updated /usr/src/sys to HEAD, configured a kernel based on the new GENERIC (without any changes), compiled it and installed it; the kernel crashes on loading (note: on loading, not on booting): http://www.unixarea.de/trap.jpg i.e. without knowing any inconsistency of user land or file system; what I did wrong? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From adamk at voicenet.com Fri Mar 20 05:20:04 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Fri Mar 20 05:20:14 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200903201220.n2KCK4hm088493@freefall.freebsd.org> The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Fri, 20 Mar 2009 08:07:48 -0400 There is no wlan0 interface, just iwi0. The output from 'wpa_supplicant -c /etc/wpa_supplicant.conf -i iwi0 -dd', though, was: Initializing interface 'iwi0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Line: 2 - start of a new network block ssid - hexdump_ascii(len=15): 4d 63 6b 65 6c 6c 61 32 38 30 46 72 6f 6e 74 Mckella280Front key_mgmt: 0x2 pairwise: 0x8 PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Line 8: removed CCMP from group cipher list since it was not allowed for pairwise cipher Priority group 0 id=0 ssid='Mckella280Front' Initializing interface (2) 'iwi0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Own MAC address: 00:13:ce:a8:10:ea wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Added interface iwi0 State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - no WPA/RSN IE Try to find non-WPA AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - SSID mismatch No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - no WPA/RSN IE Try to find non-WPA AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - SSID mismatch No suitable AP found. It kept scanning, but tmobile was the only wireless network it ever saw at this location. Adam From adamk at voicenet.com Fri Mar 20 05:30:04 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Fri Mar 20 05:30:10 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200903201230.n2KCU3H7001631@freefall.freebsd.org> The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Fri, 20 Mar 2009 08:07:48 -0400 There is no wlan0 interface, just iwi0. The output from 'wpa_supplicant -c /etc/wpa_supplicant.conf -i iwi0 -dd', though, was: Initializing interface 'iwi0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Line: 2 - start of a new network block ssid - hexdump_ascii(len=15): 4d 63 6b 65 6c 6c 61 32 38 30 46 72 6f 6e 74 Mckella280Front key_mgmt: 0x2 pairwise: 0x8 PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Line 8: removed CCMP from group cipher list since it was not allowed for pairwise cipher Priority group 0 id=0 ssid='Mckella280Front' Initializing interface (2) 'iwi0' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Own MAC address: 00:13:ce:a8:10:ea wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Added interface iwi0 State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - no WPA/RSN IE Try to find non-WPA AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - SSID mismatch No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - no WPA/RSN IE Try to find non-WPA AP 0: 36:00:e5:51:f1:55 ssid='tmobile' wpa_ie_len=0 rsn_ie_len=0 caps=0x2 skip - SSID mismatch No suitable AP found. It kept scanning, but tmobile was the only wireless network it ever saw at this location. Adam From 4pr at legis.krsn.ru Fri Mar 20 05:35:28 2009 From: 4pr at legis.krsn.ru (4pr@legis.krsn.ru) Date: Fri Mar 20 05:35:35 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem In-Reply-To: <20090320113954.GF50100@michelle.cdnetworks.co.kr> Message-ID: Hi, Thank you for your response. Sorry, but i'm unable to test your patch for if_msk.c wich you suggested, becouse our production core router need to be up and ready 24 hours a day, and our quick fix for if_msk.c also helped us with multicast routing problem. Right now i don't have the other hardware to simulate our network condition for testings too. Thank you, Eugene H. Brezin From 4pr at legis.krsn.ru Fri Mar 20 05:40:03 2009 From: 4pr at legis.krsn.ru (4pr@legis.krsn.ru) Date: Fri Mar 20 05:40:10 2009 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Message-ID: <200903201240.n2KCe2eH016481@freefall.freebsd.org> The following reply was made to PR kern/122839; it has been noted by GNATS. From: 4pr@legis.krsn.ru To: pyunyh@gmail.com Cc: bug-followup@freebsd.org, bms@freebsd.org, freebsd-net@freebsd.org, jfv@freebsd.org Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Fri, 20 Mar 2009 19:19:15 +0700 Hi, Thank you for your response. Sorry, but i'm unable to test your patch for if_msk.c wich you suggested, becouse our production core router need to be up and ready 24 hours a day, and our quick fix for if_msk.c also helped us with multicast routing problem. Right now i don't have the other hardware to simulate our network condition for testings too. Thank you, Eugene H. Brezin From gavin at FreeBSD.org Fri Mar 20 07:51:31 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Mar 20 07:51:37 2009 Subject: conf/132851: [fib] [patch] allow to setup fib for service running from rc.conf Message-ID: <200903201451.n2KEpU3P002172@freefall.freebsd.org> Old Synopsis: patch to allow to setup fib for service running from rc.conf New Synopsis: [fib] [patch] allow to setup fib for service running from rc.conf Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri Mar 20 14:49:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s), although this may be more appropriate assigned to -rc http://www.freebsd.org/cgi/query-pr.cgi?pr=132851 From stb at lassitu.de Fri Mar 20 07:59:54 2009 From: stb at lassitu.de (Stefan Bethke) Date: Fri Mar 20 08:00:00 2009 Subject: if_bridge and .1q VLANs Message-ID: Hi there, it appears if_bridge bridges tagged frames alongside non-tagged frames. Is there a way to either stop if_bridge from doing so, or otherwise filtering out the tagged frames? My trunk currently has one untagged network and two tagged VLANs on it (the untagged one being the main LAN), and I'm bridging the LAN to another site via OpenVPN. But I'd rather not bridge the other two VLANs, if at all possible. I can switch the untagged VLAN to tagged on the switch, if that turns out to be the easiest option, and bridge between tap and another vlan interface. Thanks, Stefan -- Stefan Bethke Fon +49 151 14070811 From laks_guy at yahoo.com Fri Mar 20 08:59:54 2009 From: laks_guy at yahoo.com (rajasooriyar lakshman) Date: Fri Mar 20 09:00:00 2009 Subject: Freebsd7.0 - errors in compilation Message-ID: <700496.6430.qm@web45211.mail.sp1.yahoo.com> Hello, I am new to FreeBSD....My question is regarding a compilation of a routing protocol in FreeBSD 7.0. I am trying to run a adhoc routing protocol called, Dynamic Source Routing (DSR) on my freebsd router (7.0).. I have got the implementation from the link given below. http://www.monarch.cs.rice.edu/pran/Rice_PRAN_v2.tar.gz Infact the implementation on the link is compatible with FreeBSD 5.1. That is why I get?errors such as files, opt_ bdg.h, opt_ random_ ip_ id.h ?are missing. Because of this I could not compile the kernel. ? Can any one please suggest me as to how can I compile the package successfully on FreeBSD 7.0. I would very much appreciate, if some one could fix the errors for me. ? Thanks in advance. ? Regards, ? Raj. From sam at freebsd.org Fri Mar 20 09:06:06 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Mar 20 09:06:13 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090320121021.GA2051@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> <20090320121021.GA2051@rebelion.Sisis.de> Message-ID: <49C3BEEC.6010809@freebsd.org> Matthias Apitz wrote: > El d?a Thursday, March 19, 2009 a las 08:44:29AM -0700, Sam Leffler escribi?: > > >> Matthias Apitz wrote: >> >>> El d?a Tuesday, March 17, 2009 a las 11:56:24AM -0700, Sam Leffler >>> escribi?: >>> >>> >>> >>>> His setup is static key wep; not wpa so I don't think wpa_supplicant is >>>> the issue. >>>> >>>> Matthias, your tcpdump of the dhclient packets isn't usable; please try: >>>> >>>> tcpdump -i ath0 -n -y IEEE802_11_RADIO >>>> >>>> I reviewed the driver to the code in HEAD and the only difference in the >>>> crypto area should not matter in this case. It's possible wme is >>>> somehow enabled and causing problems but the ifconfig output doesn't >>>> indicate that. >>>> >>>> If you can find out the model of ap that might be helpful. >>>> Unfortunately the best thing to try is HEAD. >>>> >>>> > > I've updated /usr/src/sys to HEAD, configured a kernel based on the new GENERIC > (without any changes), compiled it and installed it; > > the kernel crashes on loading (note: on loading, not on booting): > http://www.unixarea.de/trap.jpg > > i.e. without knowing any inconsistency of user land or file system; what I > did wrong? > This looks like a longstanding bug in handling modules loaded by loader that have undefined references (e.g. because your kernel is misconfigured). In general I don't think you're going to get very far booting a HEAD kernel against RELENG_7 world. This will certainly not work for wireless where you need all the changes to ifconfig. If you're trying to test HEAD you will want a separate partition with a fresh install/build of HEAD. Sam From guru at unixarea.de Fri Mar 20 09:21:00 2009 From: guru at unixarea.de (Matthias Apitz) Date: Fri Mar 20 09:21:08 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C3BEEC.6010809@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> <20090320121021.GA2051@rebelion.Sisis.de> <49C3BEEC.6010809@freebsd.org> Message-ID: <20090320162037.GA8587@rebelion.Sisis.de> El d?a Friday, March 20, 2009 a las 09:06:04AM -0700, Sam Leffler escribi?: > In general I don't think you're going to get very far booting a HEAD > kernel against RELENG_7 world. This will certainly not work for > wireless where you need all the changes to ifconfig. If you're trying > to test HEAD you will want a separate partition with a fresh > install/build of HEAD. Ok, I will prepare a complete build of HEAD in some machine and transfer it to an USB key to boot the EeePC from it; this will take some time; thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From linimon at FreeBSD.org Fri Mar 20 12:09:37 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Mar 20 12:09:47 2009 Subject: bin/132847: [patch] bsnmpd(8): snmp_pf: add support for retrieving pf filter rule counters Message-ID: <200903201909.n2KJ9a6h040045@freefall.freebsd.org> Old Synopsis: [patch] snmp_pf: add support for retrieving pf filter rule counters New Synopsis: [patch] bsnmpd(8): snmp_pf: add support for retrieving pf filter rule counters Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 20 19:08:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132847 From redchin at gmail.com Fri Mar 20 12:16:01 2009 From: redchin at gmail.com (Kevin Downey) Date: Fri Mar 20 12:16:09 2009 Subject: change in ifconfig out put for wlan devices on -CURRENT Message-ID: <1d3ed48c0903201151o1a0a3ee1te758e70f1be98eb0@mail.gmail.com> I did not notice a heads up about this, but recently (maybe in the last few weeks?) wlan devices on -CURRENT no longer show information like what ssid they are associated with. How can I find this information now? this what the current output looks like: wlan0: flags=8843 metric 0 mtu 1500 ether 00:1d:7d:78:2a:69 inet6 fe80::21d:7dff:fe78:2a69%wlan0 prefixlen 64 scopeid 0x4 inet 192.168.0.197 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g status: associated -- And what is good, Phaedrus, And what is not good? Need we ask anyone to tell us these things? From stb at lassitu.de Fri Mar 20 13:21:27 2009 From: stb at lassitu.de (Stefan Bethke) Date: Fri Mar 20 13:21:37 2009 Subject: change in ifconfig out put for wlan devices on -CURRENT In-Reply-To: <1d3ed48c0903201151o1a0a3ee1te758e70f1be98eb0@mail.gmail.com> References: <1d3ed48c0903201151o1a0a3ee1te758e70f1be98eb0@mail.gmail.com> Message-ID: <0C3154EE-CED4-433C-B0A9-CC16EE2EB5AD@lassitu.de> Am 20.03.2009 um 19:51 schrieb Kevin Downey: > I did not notice a heads up about this, but recently (maybe in the > last few weeks?) wlan devices on -CURRENT no longer show information > like what ssid they are associated with. How can I find this > information now? > > this what the current output looks like: > > wlan0: flags=8843 metric 0 > mtu 1500 > ether 00:1d:7d:78:2a:69 > inet6 fe80::21d:7dff:fe78:2a69%wlan0 prefixlen 64 scopeid 0x4 > inet 192.168.0.197 netmask 0xffffff00 broadcast 192.168.0.255 > media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g > status: associated Maybe it's the same issue as in this thread? HTH, Stefan -- Stefan Bethke Fon +49 151 14070811 From julian at elischer.org Fri Mar 20 13:41:59 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Mar 20 13:42:05 2009 Subject: if_bridge and .1q VLANs In-Reply-To: References: Message-ID: <49C3FFA2.5090501@elischer.org> Stefan Bethke wrote: > Hi there, > > it appears if_bridge bridges tagged frames alongside non-tagged frames. > Is there a way to either stop if_bridge from doing so, or otherwise > filtering out the tagged frames? > > My trunk currently has one untagged network and two tagged VLANs on it > (the untagged one being the main LAN), and I'm bridging the LAN to > another site via OpenVPN. But I'd rather not bridge the other two > VLANs, if at all possible. > > I can switch the untagged VLAN to tagged on the switch, if that turns > out to be the easiest option, and bridge between tap and another vlan > interface. I don't know how much this helps but you may be able to plumb something up using the netgraph vlan and bridge nodes. I have not used the vlan nodes so I do not talk from experience.. > > > Thanks, > Stefan > From rwatson at FreeBSD.org Fri Mar 20 15:20:05 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Mar 20 15:20:20 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed (was: Re: Wiki page for non-MPSAFE network stack de-orbit scheduling) In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: On Mon, 16 Feb 2009, Robert Watson wrote: > The following schedule is proposed, assuming nothing goes horribly wrong > with the new USB code in the next few weeks, and remaining nits relating to > USB network and 802.11 drivers are handled: > > 16 February 2009 HEADS UP to lists (this e-mail) > 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x > 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x Just a teminder that 1 April is gradually approaching. At that point I will remove from the tree the various non-MPSAFE network device drivers that are already disconnected from the build, incuding if_sl, if_ppp, if_ar, and the old USB ethernet drivers. Robert N M Watson Computer Laboratory University of Cambridge From ivan at serezhkin.com Fri Mar 20 15:59:33 2009 From: ivan at serezhkin.com (Vany Serezhkin) Date: Fri Mar 20 15:59:39 2009 Subject: 802.1x broken after SVN rev 189592 In-Reply-To: <49C26EE8.3040100@freebsd.org> References: <49C2504F.2030003@serezhkin.com> <49C26EE8.3040100@freebsd.org> Message-ID: <49C41FBA.1000906@serezhkin.com> Hello. Sam Leffler wrote: > Are you certain it's that revision? Have you tried r189931 which > worked around certain problems in the initial commit? Yes, problem still here. > > Can you provide sufficient info to reproduce your problem? Filing a > PR for reference is likely the best thing to do. ok. http://www.freebsd.org/cgi/query-pr.cgi?pr=132885 I store kernel, dump and symbols, and can provide anything, that kgdb can present, Also i have read kernel debugging tutorial an ready to work =) But still can't understand kernel network structure, mostly i explore acpi and smbuses. -- Vany Serezhkin. Yandex. http://yandex.ru/ From dfilter at FreeBSD.ORG Fri Mar 20 17:30:03 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Mar 20 17:30:10 2009 Subject: kern/119361: commit references a PR Message-ID: <200903210030.n2L0U3kC083193@freefall.freebsd.org> The following reply was made to PR kern/119361; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/119361: commit references a PR Date: Sat, 21 Mar 2009 00:23:17 +0000 (UTC) Author: marius Date: Sat Mar 21 00:23:07 2009 New Revision: 190194 URL: http://svn.freebsd.org/changeset/base/190194 Log: - In bge_ifmedia_upd_locked() take advantrage of LIST_FOREACH(). - If boot verbose, print asicrev, chiprev and bus type on attach. - For PCI Express devices: 1) Adjust max read request size to 4Kbytes 2) Turn on FIFO_LONG_BURST in RDMA during bge_blockinit() Though 1) does not seem to have much to do with the poor TX performance observed on PCI Express bge(4), 2) does fix the problem. [1] - Nuke the RX CPU self-diag, which prevents working cards from working (Linux tg3 does not have this diag neither does OpenBSD's bge(4)). The increasing of the firmware handshaking timeout to 20000 retries done as part of the original commit isn't merged as way already have a way higher BGE_TIMEOUT of 100000. PR: 119361 [1] Obtained from: tg3 via DragonflyBSD [1], DragonflyBSD Modified: head/sys/dev/bge/if_bge.c head/sys/dev/bge/if_bgereg.h Modified: head/sys/dev/bge/if_bge.c ============================================================================== --- head/sys/dev/bge/if_bge.c Fri Mar 20 23:55:01 2009 (r190193) +++ head/sys/dev/bge/if_bge.c Sat Mar 21 00:23:07 2009 (r190194) @@ -384,6 +384,7 @@ static uint32_t bge_readreg_ind(struct b #endif static void bge_writemem_direct(struct bge_softc *, int, int); static void bge_writereg_ind(struct bge_softc *, int, int); +static void bge_set_max_readrq(struct bge_softc *, int); static int bge_miibus_readreg(device_t, int, int); static int bge_miibus_writereg(device_t, int, int, int); @@ -523,6 +524,34 @@ bge_writemem_ind(struct bge_softc *sc, i pci_write_config(dev, BGE_PCI_MEMWIN_BASEADDR, 0, 4); } +/* + * PCI Express only + */ +static void +bge_set_max_readrq(struct bge_softc *sc, int expr_ptr) +{ + device_t dev; + uint16_t val; + + KASSERT((sc->bge_flags & BGE_FLAG_PCIE) && expr_ptr != 0, + ("%s: not applicable", __func__)); + + dev = sc->bge_dev; + + val = pci_read_config(dev, expr_ptr + BGE_PCIE_DEVCTL, 2); + if ((val & BGE_PCIE_DEVCTL_MAX_READRQ_MASK) != + BGE_PCIE_DEVCTL_MAX_READRQ_4096) { + if (bootverbose) + device_printf(dev, "adjust device control 0x%04x ", + val); + val &= ~BGE_PCIE_DEVCTL_MAX_READRQ_MASK; + val |= BGE_PCIE_DEVCTL_MAX_READRQ_4096; + pci_write_config(dev, expr_ptr + BGE_PCIE_DEVCTL, val, 2); + if (bootverbose) + printf("-> 0x%04x\n", val); + } +} + #ifdef notdef static uint32_t bge_readreg_ind(struct bge_softc *sc, int off) @@ -1278,18 +1307,6 @@ bge_chipinit(struct bge_softc *sc) /* Set endianness before we access any non-PCI registers. */ pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4); - /* - * Check the 'ROM failed' bit on the RX CPU to see if - * self-tests passed. Skip this check when there's no - * chip containing the Ethernet address fitted, since - * in that case it will always fail. - */ - if ((sc->bge_flags & BGE_FLAG_EADDR) && - CSR_READ_4(sc, BGE_RXCPU_MODE) & BGE_RXCPUMODE_ROMFAIL) { - device_printf(sc->bge_dev, "RX CPU self-diagnostics failed!\n"); - return (ENODEV); - } - /* Clear the MAC control register */ CSR_WRITE_4(sc, BGE_MAC_MODE, 0); @@ -1742,14 +1759,18 @@ bge_blockinit(struct bge_softc *sc) /* Enable host coalescing bug fix. */ if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || sc->bge_asicrev == BGE_ASICREV_BCM5787) - val |= 1 << 29; + val |= 1 << 29; /* Turn on write DMA state machine */ CSR_WRITE_4(sc, BGE_WDMA_MODE, val); + DELAY(40); /* Turn on read DMA state machine */ - CSR_WRITE_4(sc, BGE_RDMA_MODE, - BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS); + val = BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS; + if (sc->bge_flags & BGE_FLAG_PCIE) + val |= BGE_RDMAMODE_FIFO_LONG_BURST; + CSR_WRITE_4(sc, BGE_RDMA_MODE, val); + DELAY(40); /* Turn on RX data completion state machine */ CSR_WRITE_4(sc, BGE_RDC_MODE, BGE_RDCMODE_ENABLE); @@ -2387,7 +2408,7 @@ bge_attach(device_t dev) goto fail; } - /* Save ASIC rev. */ + /* Save various chip information. */ sc->bge_chipid = pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & BGE_PCIMISCCTL_ASICREV; @@ -2470,14 +2491,17 @@ bge_attach(device_t dev) * Found a PCI Express capabilities register, this * must be a PCI Express device. */ - if (reg != 0) + if (reg != 0) { sc->bge_flags |= BGE_FLAG_PCIE; #else if (BGE_IS_5705_PLUS(sc)) { reg = pci_read_config(dev, BGE_PCIE_CAPID_REG, 4); - if ((reg & 0xFF) == BGE_PCIE_CAPID) + if ((reg & 0xFF) == BGE_PCIE_CAPID) { sc->bge_flags |= BGE_FLAG_PCIE; + reg = BGE_PCIE_CAPID; #endif + bge_set_max_readrq(sc, reg); + } } else { /* * Check if the device is in PCI-X Mode. @@ -2522,6 +2546,13 @@ bge_attach(device_t dev) goto fail; } + if (bootverbose) + device_printf(dev, + "CHIP ID 0x%08x; ASIC REV 0x%02x; CHIP REV 0x%02x; %s\n", + sc->bge_chipid, sc->bge_asicrev, sc->bge_chiprev, + (sc->bge_flags & BGE_FLAG_PCIX) ? "PCI-X" : + ((sc->bge_flags & BGE_FLAG_PCIE) ? "PCI-E" : "PCI")); + BGE_LOCK_INIT(sc, device_get_nameunit(dev)); /* Try to reset the chip. */ @@ -3882,6 +3913,7 @@ bge_ifmedia_upd_locked(struct ifnet *ifp { struct bge_softc *sc = ifp->if_softc; struct mii_data *mii; + struct mii_softc *miisc; struct ifmedia *ifm; BGE_LOCK_ASSERT(sc); @@ -3932,12 +3964,9 @@ bge_ifmedia_upd_locked(struct ifnet *ifp sc->bge_link_evt++; mii = device_get_softc(sc->bge_miibus); - if (mii->mii_instance) { - struct mii_softc *miisc; - for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; - miisc = LIST_NEXT(miisc, mii_list)) + if (mii->mii_instance) + LIST_FOREACH(miisc, &mii->mii_phys, mii_list) mii_phy_reset(miisc); - } mii_mediachg(mii); /* Modified: head/sys/dev/bge/if_bgereg.h ============================================================================== --- head/sys/dev/bge/if_bgereg.h Fri Mar 20 23:55:01 2009 (r190193) +++ head/sys/dev/bge/if_bgereg.h Sat Mar 21 00:23:07 2009 (r190194) @@ -176,6 +176,22 @@ #define BGE_PCI_MSI_ADDR_LO 0x60 #define BGE_PCI_MSI_DATA 0x64 +/* + * PCI Express definitions + * According to + * PCI Express base specification, REV. 1.0a + */ + +/* PCI Express device control, 16bits */ +#define BGE_PCIE_DEVCTL 0x08 +#define BGE_PCIE_DEVCTL_MAX_READRQ_MASK 0x7000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_128 0x0000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_256 0x1000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_512 0x2000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_1024 0x3000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_2048 0x4000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_4096 0x5000 + /* PCI MSI. ??? */ #define BGE_PCIE_CAPID_REG 0xD0 #define BGE_PCIE_CAPID 0x10 @@ -1359,6 +1375,8 @@ #define BGE_RDMAMODE_PCI_FIFOOREAD_ATTN 0x00000100 #define BGE_RDMAMODE_LOCWRITE_TOOBIG 0x00000200 #define BGE_RDMAMODE_ALL_ATTNS 0x000003FC +#define BGE_RDMAMODE_FIFO_SIZE_128 0x00020000 +#define BGE_RDMAMODE_FIFO_LONG_BURST 0x00030000 /* Read DMA status register */ #define BGE_RDMASTAT_PCI_TGT_ABRT_ATTN 0x00000004 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From dikshie at gmail.com Sat Mar 21 02:41:24 2009 From: dikshie at gmail.com (dikshie) Date: Sat Mar 21 02:41:30 2009 Subject: if_ath Message-ID: <910e60e80903210241p5683c52bue9432fff6b29f246@mail.gmail.com> this is on RELENG_7 totoro# ident /usr/src/sys/dev/ath/if_ath.c /usr/src/sys/dev/ath/if_ath.c: $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.177.2.3 2009/03/12 03:09:11 bms Exp $ cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' *** Error code 1 -- -dikshie- From bzeeb-lists at lists.zabbadoz.net Sat Mar 21 03:50:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Mar 21 03:50:16 2009 Subject: change in ifconfig out put for wlan devices on -CURRENT In-Reply-To: <0C3154EE-CED4-433C-B0A9-CC16EE2EB5AD@lassitu.de> References: <1d3ed48c0903201151o1a0a3ee1te758e70f1be98eb0@mail.gmail.com> <0C3154EE-CED4-433C-B0A9-CC16EE2EB5AD@lassitu.de> Message-ID: <20090321104550.Q67075@maildrop.int.zabbadoz.net> On Fri, 20 Mar 2009, Stefan Bethke wrote: > Am 20.03.2009 um 19:51 schrieb Kevin Downey: > >> I did not notice a heads up about this, but recently (maybe in the >> last few weeks?) wlan devices on -CURRENT no longer show information >> like what ssid they are associated with. How can I find this >> information now? >> >> this what the current output looks like: >> >> wlan0: flags=8843 metric 0 mtu 1500 >> ether 00:1d:7d:78:2a:69 >> inet6 fe80::21d:7dff:fe78:2a69%wlan0 prefixlen 64 scopeid 0x4 >> inet 192.168.0.197 netmask 0xffffff00 broadcast 192.168.0.255 >> media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g >> status: associated > > Maybe it's the same issue as in this thread? > > If that's your thread, it is. Updating to latest HEAD should have the fix. It would be great if you could confirm that everything is working again with just a plain HEAD. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bms at incunabulum.net Sat Mar 21 06:32:53 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Mar 21 06:33:00 2009 Subject: if_ath In-Reply-To: <910e60e80903210241p5683c52bue9432fff6b29f246@mail.gmail.com> References: <910e60e80903210241p5683c52bue9432fff6b29f246@mail.gmail.com> Message-ID: <49C4EC81.1030207@incunabulum.net> Hi, I have been doing repeated build runs of RELENG_7 using NanoBSD, and haven't seen this issue. How exactly are you building the kernel? Are you using 'make buildkernel KERNCONF=...' ? Do you have any old ath(4) build options present? I believe Sam removed the HAL_ABI_VERSION define in the -CURRENT branch so you should not need it. thanks BMS dikshie wrote: > this is on RELENG_7 > > totoro# ident /usr/src/sys/dev/ath/if_ath.c > /usr/src/sys/dev/ath/if_ath.c: > $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.177.2.3 2009/03/12 > 03:09:11 bms Exp $ > > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc > -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c > -I/usr/src/sys/dev/ath > /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': > /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct > ath_rx_status' has no member named 'rs_flags' > *** Error code 1 > > > > > From bz at FreeBSD.org Sat Mar 21 06:43:18 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Sat Mar 21 06:43:24 2009 Subject: bin/132847: [patch] bsnmpd(8): snmp_pf: add support for retrieving pf filter rule counters Message-ID: <200903211343.n2LDhH9r006661@freefall.freebsd.org> Synopsis: [patch] bsnmpd(8): snmp_pf: add support for retrieving pf filter rule counters Responsible-Changed-From-To: freebsd-net->syrinx Responsible-Changed-By: bz Responsible-Changed-When: Sat Mar 21 13:42:37 UTC 2009 Responsible-Changed-Why: She'll review and test it in a few days she said. http://www.freebsd.org/cgi/query-pr.cgi?pr=132847 From bms at incunabulum.net Sat Mar 21 06:48:01 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Mar 21 06:48:07 2009 Subject: if_ath In-Reply-To: <49C4EC81.1030207@incunabulum.net> References: <910e60e80903210241p5683c52bue9432fff6b29f246@mail.gmail.com> <49C4EC81.1030207@incunabulum.net> Message-ID: <49C4F00E.9010401@incunabulum.net> Bruce Simpson wrote: > I believe Sam removed the HAL_ABI_VERSION define in the -CURRENT > branch so you should not need it. Please see here for the relevant change (MFC was set to 1 week):- http://svn.freebsd.org/changeset/base/190096 thanks BMS From linimon at FreeBSD.org Sat Mar 21 08:15:17 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Mar 21 08:15:22 2009 Subject: kern/132885: [wlan] 802.1x broken after SVN rev 189592 Message-ID: <200903211515.n2LFFGqk027021@freefall.freebsd.org> Synopsis: [wlan] 802.1x broken after SVN rev 189592 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 21 15:15:07 UTC 2009 Responsible-Changed-Why: Reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=132885 From linimon at FreeBSD.org Sat Mar 21 08:25:37 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Mar 21 08:25:43 2009 Subject: kern/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver Message-ID: <200903211525.n2LFPajC040197@freefall.freebsd.org> Old Synopsis: NDIS kernel crash on load BCM4321 AGN driver New Synopsis: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 21 15:25:09 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132889 From sam at freebsd.org Sat Mar 21 10:14:47 2009 From: sam at freebsd.org (Sam Leffler) Date: Sat Mar 21 10:14:57 2009 Subject: if_ath In-Reply-To: <910e60e80903210241p5683c52bue9432fff6b29f246@mail.gmail.com> References: <910e60e80903210241p5683c52bue9432fff6b29f246@mail.gmail.com> Message-ID: <49C52084.3060000@freebsd.org> dikshie wrote: > this is on RELENG_7 > > totoro# ident /usr/src/sys/dev/ath/if_ath.c > /usr/src/sys/dev/ath/if_ath.c: > $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.177.2.3 2009/03/12 > 03:09:11 bms Exp $ > > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc > -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c > -I/usr/src/sys/dev/ath > /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': > /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct > ath_rx_status' has no member named 'rs_flags' > *** Error code 1 > > > > Read UPDATING; you need options AH_SUPPORT_AR5416 in your config file. Sam From rpaulo at gmail.com Sat Mar 21 11:46:05 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Sat Mar 21 11:46:11 2009 Subject: HEADSUP: tcpdump updated to 4.0.0 Message-ID: <99991DAF-1988-476E-89E7-97BAA8873AC4@gmail.com> Hi folks, I just updated the base system tcpdump to 4.0.0. Most noticeably this new version includes a new output format. Please report any regressions. Thanks, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090321/9ad56de9/PGP.pgp From redchin at gmail.com Sat Mar 21 13:13:35 2009 From: redchin at gmail.com (Kevin Downey) Date: Sat Mar 21 13:13:42 2009 Subject: change in ifconfig out put for wlan devices on -CURRENT In-Reply-To: <20090321104550.Q67075@maildrop.int.zabbadoz.net> References: <1d3ed48c0903201151o1a0a3ee1te758e70f1be98eb0@mail.gmail.com> <0C3154EE-CED4-433C-B0A9-CC16EE2EB5AD@lassitu.de> <20090321104550.Q67075@maildrop.int.zabbadoz.net> Message-ID: <1d3ed48c0903211313s5cb44a3fsea09e905031ef24f@mail.gmail.com> On Sat, Mar 21, 2009 at 3:46 AM, Bjoern A. Zeeb wrote: > On Fri, 20 Mar 2009, Stefan Bethke wrote: > >> Am 20.03.2009 um 19:51 schrieb Kevin Downey: >> >>> I did not notice a heads up about this, but recently (maybe in the >>> last few weeks?) wlan devices on -CURRENT no longer show information >>> like what ssid they are associated with. How can I find this >>> information now? >>> >>> this what the current output looks like: >>> >>> wlan0: flags=8843 metric 0 mtu >>> 1500 >>> ether 00:1d:7d:78:2a:69 >>> inet6 fe80::21d:7dff:fe78:2a69%wlan0 prefixlen 64 scopeid 0x4 >>> inet 192.168.0.197 netmask 0xffffff00 broadcast 192.168.0.255 >>> media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g >>> status: associated >> >> Maybe it's the same issue as in this thread? >> >> >> > > If that's your thread, it is. Updating to latest HEAD should have the > fix. ?It would be great if you could confirm that everything is > working again with just a plain HEAD. > > /bz > > -- > Bjoern A. Zeeb ? ? ? ? ? ? ? ? ? ? ?The greatest risk is not taking one. > Moved to yesterday's -CURRENT, all is well, thanks guys -- And what is good, Phaedrus, And what is not good? Need we ask anyone to tell us these things? From rpaulo at gmail.com Sat Mar 21 16:01:52 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Sat Mar 21 16:02:06 2009 Subject: HEADS UP: libpcap updated to 1.0.0 Message-ID: Hi folks, I just updated the base system libcap to 1.0.0. This new version comes with a new API. Please report any regressions. Thanks, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090321/0c02fb9b/PGP.pgp From dougb at FreeBSD.org Sat Mar 21 16:45:53 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Mar 21 16:46:00 2009 Subject: change in ifconfig out put for wlan devices on -CURRENT In-Reply-To: <20090321104550.Q67075@maildrop.int.zabbadoz.net> References: <1d3ed48c0903201151o1a0a3ee1te758e70f1be98eb0@mail.gmail.com> <0C3154EE-CED4-433C-B0A9-CC16EE2EB5AD@lassitu.de> <20090321104550.Q67075@maildrop.int.zabbadoz.net> Message-ID: <49C57C2A.7020007@FreeBSD.org> Bjoern A. Zeeb wrote: > If that's your thread, it is. Updating to latest HEAD should have the > fix. It would be great if you could confirm that everything is > working again with just a plain HEAD. I can confirm that with latest HEAD it's back to normal for me with my wpi+wlan. Thanks! Doug -- This .signature sanitized for your protection From linimon at FreeBSD.org Sat Mar 21 19:37:17 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Mar 21 19:37:30 2009 Subject: bin/132911: ip6fw(8): argument type of fill_icmptypes is wrong and causes problem on amd64 platform Message-ID: <200903220237.n2M2bGC5043654@freefall.freebsd.org> Old Synopsis: ip6fw: argument type of fill_icmptypes is wrong and causes problem on amd64 platform New Synopsis: ip6fw(8): argument type of fill_icmptypes is wrong and causes problem on amd64 platform State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sun Mar 22 02:35:04 UTC 2009 State-Changed-Why: Reclassify. Note to submitter: the patch did not make it into the PR; can you please reply and include it again? Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 22 02:35:04 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=132911 From linimon at lonesome.com Sat Mar 21 20:00:09 2009 From: linimon at lonesome.com (Mark Linimon) Date: Sat Mar 21 20:00:18 2009 Subject: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte Message-ID: <200903220300.n2M308TI069844@freefall.freebsd.org> The following reply was made to PR kern/96268; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte Date: Sat, 21 Mar 2009 21:57:07 -0500 ----- Forwarded message from Jost Boekemeier ----- From: Jost Boekemeier To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/96268: [socket] TCP socket performance drops by 3000% if packets are split at the first byte Hi, from my point of view this issue can be closed. TCP write/write/read sequences are bad on any operating system, it's just that other OS are a little bit smarter. -- I think Jon Nagle has had a proposal to fix/remove this unconditional delay, but I don't know if it has been implemented. Furthermore this problem has been fixed on application level. And I think Patrick van Staveren maintains a FreeBSD port which uses unix domain- instead of TCP socket communication. Regards, Jost Bökemeier _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" ----- End forwarded message ----- From yaharen at gm.dns-lab.jp Sat Mar 21 23:50:05 2009 From: yaharen at gm.dns-lab.jp (Yoshitaka AHAREN) Date: Sat Mar 21 23:50:12 2009 Subject: bin/132911: ip6fw(8): argument type of fill_icmptypes is wrong and causes problem on amd64 platform Message-ID: <200903220650.n2M6o4Ia092214@freefall.freebsd.org> The following reply was made to PR bin/132911; it has been noted by GNATS. From: Yoshitaka AHAREN To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/132911: ip6fw(8): argument type of fill_icmptypes is wrong and causes problem on amd64 platform Date: Sun, 22 Mar 2009 15:11:27 +0900 --------_49C5D0DF000000007233_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The patch is included in this message. Sorry for your inconvenience. --------_49C5D0DF000000007233_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="patch.txt" Content-Disposition: attachment; filename="patch.txt" Content-Transfer-Encoding: base64 LS0tIHNiaW4vaXA2ZncvaXA2ZncuYy5vcmlnICAgICAyMDA5LTAzLTIyIDE0OjMyOjA1LjAwMDAw MDAwMCArMDkwMAorKysgc2Jpbi9pcDZmdy9pcDZmdy5jICAyMDA5LTAzLTIyIDE0OjMyOjE5LjAw MDAwMDAwMCArMDkwMApAQCAtNzY0LDcgKzc2NCw3IEBACiAKIHZvaWQKIGZpbGxfaWNtcHR5cGVz KHR5cGVzLCB2cCwgZndfZmxnKQotCXVfbG9uZyAqdHlwZXM7CisJdW5zaWduZWQgKnR5cGVzOwog CWNoYXIgKip2cDsKIAl1X3Nob3J0ICpmd19mbGc7CiB7Cg== --------_49C5D0DF000000007233_MULTIPART_MIXED_-- From rwatson at FreeBSD.org Sun Mar 22 10:05:11 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Mar 22 10:05:17 2009 Subject: HEADSUP: tcpdump updated to 4.0.0 In-Reply-To: <99991DAF-1988-476E-89E7-97BAA8873AC4@gmail.com> References: <99991DAF-1988-476E-89E7-97BAA8873AC4@gmail.com> Message-ID: On Sat, 21 Mar 2009, Rui Paulo wrote: > I just updated the base system tcpdump to 4.0.0. Most noticeably this new > version includes a new output format. > > Please report any regressions. Cool, thanks for working on this! Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Sun Mar 22 10:11:28 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Mar 22 10:11:36 2009 Subject: Freebsd7.0 - errors in compilation In-Reply-To: <700496.6430.qm@web45211.mail.sp1.yahoo.com> References: <700496.6430.qm@web45211.mail.sp1.yahoo.com> Message-ID: On Fri, 20 Mar 2009, rajasooriyar lakshman wrote: > I am new to FreeBSD....My question is regarding a compilation of a routing > protocol in FreeBSD 7.0. > > I am trying to run a adhoc routing protocol called, Dynamic Source Routing > (DSR) on my freebsd router (7.0).. I have got the implementation from the > link given below. > > http://www.monarch.cs.rice.edu/pran/Rice_PRAN_v2.tar.gz > > Infact the implementation on the link is compatible with FreeBSD 5.1. That > is why I get?errors such as files, opt_ bdg.h, opt_ random_ ip_ id.h ?are > missing. Because of this I could not compile the kernel. ? Can any one > please suggest me as to how can I compile the package successfully on > FreeBSD 7.0. I would very much appreciate, if some one could fix the errors > for me. ? Thanks in advance. ? Regards, ? Raj. Hi Raj: I believe the PRAN package includes kernel modifications to FreeBSD 5.1; it is likely that they will require significant modification in order to compile on FreeBSD 7.x, as the network stack has changed quite a lot in that time (especially relating to SMP). From a glance at the tarball, they also distributed the changes as replacements to existing kernel files, rather than patches, so it's not immediately obvious to me what changes they've made, and how much work would be required to get them up-to-date. As a starting point, I would download a copy of FreeBSD 5.1 and generated explicit patches, which you can post if you would like comments on whether they would apply easily to more recent versions or not. Robert N M Watson Computer Laboratory University of Cambridge From brett at lariat.net Sun Mar 22 12:27:45 2009 From: brett at lariat.net (Brett Glass) Date: Sun Mar 22 12:27:51 2009 Subject: Problems with inward PPTP tunnel Message-ID: <200903221927.NAA16655@lariat.net> Everyone: I've routinely used FreeBSD to create firewall routers which protect the machines inside the firewall from attempted connections from the outside world, but allow an administrator to "tunnel into" the LAN using PPTP to do maintenance. I've done this by making the firewall into a PPTP server using the PoPToP PPTP daemon. To tunnel into the LAN (which, in the example below, is the subnet 172.17/16), I connect to the router using PPTP, and it establishes an encrypted tunnel into the LAN. This worked well on FreeBSD versions up to 6.x, but has abruptly stopped working on 7.1. I could establish a PPTP connection, but couldn't reach hosts inside the LAN! I investigated, and here's what I found. First, using tcpdump(8), I saw that when I tried to ping hosts inside the LAN from the computer that was tunneling in, the packets were reaching them and they were responding. However, the responses were not being returned over the VPN connection. I needed to understand why. I knew that the PPTP daemon invokes FreeBSD's userland PPP program, which creates the routing table entries that make the tunnel work. The PPP configuration contains (among other things) the following lines: set ifaddr 172.17.0.1/32 set mtu maximum 1496 enable proxy enable mschapv2 mppe set mppe * stateless The external machine's address is specified in the ppp.secret file. In the examples below, it was 172.17.0.7. Because of the "enable proxy" command, the PPP program does proxy arp for the inward-tunneling machine. The server is also SUPPOSED to route packets from the LAN which are destined for the inward-tunneling machine to the PPP tunnel. The result is that the machine that's tunneling in is, for all practical purposes, on the internal LAN. It looks, to machines on the LAN, as if it is at the same MAC address as the router but has a unique IP address that's different from the router's. On FreeBSD 6.x and prior, the routing table looks like this once the connection is established: FreeBSD 6.x 172.17 link#1 UC 0 0 fxp0 172.17.0.1 00:50:8b:xx:xx:xx UHLW 1 190427 lo0 172.17.0.7 172.17.0.1 UH 0 8 tun0 172.17.0.7 00:50:8b:xx:xx:xx UHLS2 1 0 fxp0 Note that packets destined for 172.17.0.7 are correctly routed out through the tun0 interface. On FreeBSD 7.1, however, we see: FreeBSD 7.1 172.17.0.0/16 link#2 UC 0 0 dc0 172.17.0.1 00:50:8b:xx:xx:xx UHLW 2 0 lo0 172.17.0.7 172.17.0.1 UGH 0 0 dc0 172.17.0.7 00:50:8b:xx:xx:xx UHLS2 1 0 dc0 Note that the "tun" interface through which the packets are supposed to be routed does not appear where it should; in fact, it does not appear ANYWHERE IN THE ROUTING TABLE. This is obviously an error, because without such an entry no packets can ever be sent back to the host which is tunneling in! (It occurs to me that this could affect not only a VPN server but any PPP server, including one that answered calls on dialup modems.) I tried to work around the problem by adding the lines shell route delete HISADDR shell route add -host HISADDR MYADDR -ifp INTERFACE to the ppp.linkup file, but to no avail. However, executing the command route add 172.17.0.7 172.17.0.1 -ifp tun0 from the shell, as root, after the link was fully established DID work, suggesting that PPP was somehow interfering with my attempts to fix the routing table in the ppp.linkup file. Adding "disable sroutes" to the configuration didn't solve this. It seems to me that the root (route?) cause of the problem is that the PPP program isn't correctly specifying the "tun" interface when it sets up routes. What's the best solution to this problem? This problem clearly would affect anyone who wanted to set up a similar tunneling arrangement using userland PPP, and may also cause problems in dialup servers. --Brett Glass From brett at lariat.net Sun Mar 22 14:14:39 2009 From: brett at lariat.net (Brett Glass) Date: Sun Mar 22 14:15:06 2009 Subject: Problems with inward PPTP tunnel Message-ID: <200903222114.PAA17884@lariat.net> Just a quick followup: I've finally figured out a workaround. A hack, to be sure, but a workaround nonetheless. I've created a shell script called /etc/ppp/pppfix, which looks like this: #!/bin/sh # Fix up PPP routes sleep 1; logger -i -t ppp Fixing route: route change -host $1 $2 -ifp $3 route change -host $1 $2 -ifp $3 I invoke this from the relevant section of /etc/ppp.linkup with the line !bg /etc/ppp/pppfix HISADDR MYADDR INTERFACE Note that the "sleep" may not be absolutely necessary, but it seems like a good idea just in case there's a race condition. I also added the following lines in the relevant section of ppp.linkdown: iface clear delete! HISADDR delete! ALL shell arp -d HISADDR quit all I found that if I did not do this, the modified route persisted after the connection terminated. The "arp -d HISADDR" should only be used if proxy arp is being done, and may not be strictly necessary; I wanted to make sure I tore down any residual proxy arp entry. Of course, all of this is an awful hack and the relevant code in userland PPP still needs to be looked at. --Brett Glass From linimon at FreeBSD.org Sun Mar 22 21:50:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Mar 22 21:50:41 2009 Subject: kern/132669: [xl] 3c905-TX send DUP! in reply on ping (sometime) Message-ID: <200903230450.n2N4oSsg050277@freefall.freebsd.org> Old Synopsis: 3c905-TX send DUP! in reply on ping (sometime) New Synopsis: [xl] 3c905-TX send DUP! in reply on ping (sometime) Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 23 04:49:58 UTC 2009 Responsible-Changed-Why: probably not i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=132669 From linimon at FreeBSD.org Sun Mar 22 21:54:12 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Mar 22 21:54:18 2009 Subject: sparc64/118932: [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output Message-ID: <200903230454.n2N4sBRx059968@freefall.freebsd.org> Old Synopsis: 7.0-BETA4/sparc-64 kernel panic in rip_output New Synopsis: [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output Responsible-Changed-From-To: freebsd-sparc64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 23 04:53:49 UTC 2009 Responsible-Changed-Why: Maybe someone on -net has an idea. http://www.freebsd.org/cgi/query-pr.cgi?pr=118932 From guru at unixarea.de Sun Mar 22 23:27:06 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sun Mar 22 23:27:12 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C3BEEC.6010809@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> <20090320121021.GA2051@rebelion.Sisis.de> <49C3BEEC.6010809@freebsd.org> Message-ID: <20090322121423.GA66444@rebelion.Sisis.de> El d?a Friday, March 20, 2009 a las 09:06:04AM -0700, Sam Leffler escribi?: > This looks like a longstanding bug in handling modules loaded by loader > that have undefined references (e.g. because your kernel is misconfigured). > > In general I don't think you're going to get very far booting a HEAD > kernel against RELENG_7 world. This will certainly not work for > wireless where you need all the changes to ifconfig. If you're trying > to test HEAD you will want a separate partition with a fresh > install/build of HEAD. Well, I've built an USB key with CURRENT and it boots fine. But there seems to be a problem with the ath0 interface: # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # dmesg | fgrep ath ath0: mem 0xfbff0000-0xfbffffff irq 18 at device 0.0 on pci1 ath0: [ITHREAD] ath0: AR2425 mac 14.2 RF5424 phy 7.0 # ifconfig ath0 ath0: flags=8802 metric 0 mtu 2290 ether 00:15:af:b2:ae:e6 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier # /usr/sbin/wpa_supplicant -i ath0 -c /etc/wpa_supplicant.conf ioctl[SIOCG80211, op 98, len 32]: Invalid argument Failed to initialize driver interface ELOOP: remaining socket: sock=5 eloop_data=0x28406140 user_data=0x2840d040 handler=0x8069f40 With the RELENG_7 kernel I've collected yesterday a better tcpdump when DHCP starts: http://www.unixarea.de/tcp2.txt Thx for any hint matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From guru at unixarea.de Sun Mar 22 23:54:16 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sun Mar 22 23:54:22 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090322121423.GA66444@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090319144251.GA13320@rebelion.Sisis.de> <49C2685D.6040801@freebsd.org> <20090320121021.GA2051@rebelion.Sisis.de> <49C3BEEC.6010809@freebsd.org> <20090322121423.GA66444@rebelion.Sisis.de> Message-ID: <20090323065401.GA3011@rebelion.Sisis.de> El d?a Sunday, March 22, 2009 a las 01:14:24PM +0100, Matthias Apitz escribi?: > Well, I've built an USB key with CURRENT and it boots fine. But there > seems to be a problem with the ath0 interface: > > # uname -a > FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 > root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 > > # dmesg | fgrep ath > ath0: mem 0xfbff0000-0xfbffffff irq 18 at device 0.0 on pci1 > ath0: [ITHREAD] > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > # ifconfig ath0 > ath0: flags=8802 metric 0 mtu 2290 > ether 00:15:af:b2:ae:e6 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > > # /usr/sbin/wpa_supplicant -i ath0 -c /etc/wpa_supplicant.conf > ioctl[SIOCG80211, op 98, len 32]: Invalid argument > Failed to initialize driver interface > ELOOP: remaining socket: sock=5 eloop_data=0x28406140 user_data=0x2840d040 handler=0x8069f40 ... Ah, I found the solution with Don Google... I have now in CURRENT to do: # ifconfig wlan0 create wlandev ath0 # /etc/rc.d/wpa_supplicant start wlan0 or via /etc/rc.conf: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" and the interface wlan0 comes up fine and get in my home office the IP with DHCP; will test this the other day in the Wifi zone where RELENG_7 does not get IP with DHCP; thx so far; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From b93502044 at ntu.edu.tw Mon Mar 23 03:44:32 2009 From: b93502044 at ntu.edu.tw (Andrew Chen) Date: Mon Mar 23 03:44:42 2009 Subject: Problems in using SCTP CMT Message-ID: <20090323182021.ysrn0ogu84cg084g@wmail1.cc.ntu.edu.tw> Hi, We have some problems when we tried to send data using CMT-SCTP. Actually, we are not sure if we do enable CMT functionalities. We set up two PCs with FreeBSD-7.0. Each PC has two NICs and two IPs. One is public and the other is private. We wrote simple FTP server and client programs. On both sides, local addresses are bound as INADDR_ANY. According to http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-14#section-4.1.5 , if we bind INADDR_ANY and then call connect(), the multi-homing capability of SCTP is automatically enabled. Further, we also turn on sysctl states by setting sysctl net.inet.sctp.cmt_pf=1 sysctl net.inet.sctp.cmt_use_dac=1 sysctl net.inet.sctp.cmt_on_off=1 Then we start transmission and capture the traffics. Unfortunately, the captured packet shows data were transmitted on primary path and there were only heartbeat/HB ACKs on the other path. To our knowledge, to use CMT, the only things we have to do is to establish a multihomed association, and turn on the sysctl options. Can anyone point out something we did wrong or steps we missed? Thanks in advance. From bugmaster at FreeBSD.org Mon Mar 23 04:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 23 04:08:46 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200903231107.n2NB70CD004080@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132342 net [ndis] [patch] incorrect number used in for loop; fix o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131310 net [netgraph] [panic] 7.1 panics with mpd netgraph interf o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 274 problems total. From Michael.Tuexen at lurchi.franken.de Mon Mar 23 04:31:35 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Mon Mar 23 04:31:43 2009 Subject: Problems in using SCTP CMT In-Reply-To: <20090323182021.ysrn0ogu84cg084g@wmail1.cc.ntu.edu.tw> References: <20090323182021.ysrn0ogu84cg084g@wmail1.cc.ntu.edu.tw> Message-ID: <71A21E16-168D-4883-B452-42C66AB57759@lurchi.franken.de> H Andrew, what you describe is correct. Are there actually multiple addresses changed within the INIT/INIT-ACK chunk? If yes, you have done everything correctly. The interesting thing: I also noticed that there are CMT problems on FreeBSD 8.0 Current. Randall Stewart and myself have started debugging the problem yesterday... We'll send you a notice, once we have found the problem and fixed it. Best regards Michael On Mar 23, 2009, at 3:20 AM, Andrew Chen wrote: > Hi, > We have some problems when we tried to send data using CMT-SCTP. > Actually, we are not sure if we do enable CMT functionalities. We > set up two PCs with FreeBSD-7.0. Each PC has two NICs and two IPs. > One is public and the other is private. We wrote simple FTP server > and client programs. On both sides, local addresses are bound as > INADDR_ANY. According to http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-14#section-4.1.5 > , if we bind INADDR_ANY and then call connect(), the multi-homing > capability of SCTP is automatically enabled. Further, we also turn > on sysctl states by setting > sysctl net.inet.sctp.cmt_pf=1 > sysctl net.inet.sctp.cmt_use_dac=1 > sysctl net.inet.sctp.cmt_on_off=1 > Then we start transmission and capture the traffics. Unfortunately, > the captured packet shows data were transmitted on primary path and > there were only heartbeat/HB ACKs on the other path. > To our knowledge, to use CMT, the only things we have to do is to > establish a multihomed association, and turn on the sysctl options. > Can anyone point out something we did wrong or steps we missed? > Thanks in advance. > > _______________________________________________ > 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 lists.br at gmail.com Mon Mar 23 04:32:19 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Mon Mar 23 04:49:07 2009 Subject: Problems with inward PPTP tunnel References: <200903222114.PAA17884@lariat.net> Message-ID: <87153F88702C4FBCA3FC799082960C45@adnote989> > Just a quick followup: I've finally figured out a workaround. A hack, to > be sure, but a workaround nonetheless. > > I've created a shell script called /etc/ppp/pppfix, which looks like this: > > #!/bin/sh > # Fix up PPP routes > sleep 1; > logger -i -t ppp Fixing route: route change -host $1 $2 -ifp $3 > route change -host $1 $2 -ifp $3 > > I invoke this from the relevant section of /etc/ppp.linkup with the line > > !bg /etc/ppp/pppfix HISADDR MYADDR INTERFACE > > Note that the "sleep" may not be absolutely necessary, but it seems like a > good idea just in case there's a race condition. > > I also added the following lines in the relevant section of ppp.linkdown: > > iface clear > delete! HISADDR > delete! ALL > shell arp -d HISADDR > quit all > > I found that if I did not do this, the modified route persisted after the > connection terminated. The "arp -d HISADDR" should only be used if proxy > arp is being done, and may not be strictly necessary; I wanted to make > sure I tore down any residual proxy arp entry. > > Of course, all of this is an awful hack and the relevant code in userland > PPP still needs to be looked at. > > --Brett Glass Brett, I've fixed these two issues with ppp(8), please check the PRs: bin/130159 and bin/131250. If it works for you please let a note and maybe someone commit this. Best regards, Luiz From onemda at gmail.com Mon Mar 23 07:59:33 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Mar 23 07:59:39 2009 Subject: kern/132342: commit references a PR In-Reply-To: <200903090240.n292e4Ov062176@freefall.freebsd.org> References: <200903090240.n292e4Ov062176@freefall.freebsd.org> Message-ID: <3a142e750903230759s272f90abs4c6eb783f6f06d0@mail.gmail.com> On 3/9/09, dfilter service wrote: > The following reply was made to PR kern/132342; it has been noted by GNATS. > > From: dfilter@FreeBSD.ORG (dfilter service) > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/132342: commit references a PR > Date: Mon, 9 Mar 2009 02:38:02 +0000 (UTC) > > Author: sam > Date: Mon Mar 9 02:37:52 2009 > New Revision: 189550 > URL: http://svn.freebsd.org/changeset/base/189550 > > Log: > Fix TXPMGT handling: > o correct dBm<->mW conversion logic > o set net80211 TXPMGT capability only if driver reports it is capable > > PR: kern/132342 > Submitted by: "Paul B. Mahol" > > Modified: > head/sys/dev/if_ndis/if_ndis.c > > Modified: head/sys/dev/if_ndis/if_ndis.c > ============================================================================== > --- head/sys/dev/if_ndis/if_ndis.c Mon Mar 9 02:34:02 2009 (r189549) > +++ head/sys/dev/if_ndis/if_ndis.c Mon Mar 9 02:37:52 2009 (r189550) > @@ -102,7 +102,7 @@ SYSCTL_INT(_hw_ndisusb, OID_AUTO, halt, > "Halt NDIS USB driver when it's attached"); > > /* 0 - 30 dBm to mW conversion table */ > -const uint16_t dBm2mW[] = { > +static const uint16_t dBm2mW[] = { > 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, > 3, 4, 4, 4, 5, 6, 6, 7, 8, 9, > 10, 11, 13, 14, 16, 18, 20, 22, 25, 28, > @@ -749,7 +749,7 @@ ndis_attach(dev) > ic->ic_ifp = ifp; > ic->ic_opmode = IEEE80211_M_STA; > ic->ic_phytype = IEEE80211_T_DS; > - ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS | IEEE80211_C_TXPMGT; > + ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS; > setbit(ic->ic_modecaps, IEEE80211_MODE_AUTO); > len = 0; > r = ndis_get_info(sc, OID_802_11_NETWORK_TYPES_SUPPORTED, > @@ -928,6 +928,11 @@ got_crypto: > r = ndis_get_info(sc, OID_802_11_POWER_MODE, &arg, &i); > if (r == 0) > ic->ic_caps |= IEEE80211_C_PMGT; > + > + r = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &i); > + if (r == 0) > + ic->ic_caps |= IEEE80211_C_TXPMGT; > + > bcopy(eaddr, &ic->ic_myaddr, sizeof(eaddr)); > ieee80211_ifattach(ic); > ic->ic_raw_xmit = ndis_raw_xmit; > @@ -2325,9 +2330,10 @@ ndis_setstate_80211(sc) > ndis_set_info(sc, OID_802_11_POWER_MODE, &arg, &len); > > /* Set TX power */ > - if (ic->ic_txpowlimit < sizeof(dBm2mW)) { > - len = sizeof(arg); > + if ((ic->ic_caps & IEEE80211_C_TXPMGT) && > + ic->ic_txpowlimit < (sizeof(dBm2mW) / sizeof(dBm2mW[0]))) { > arg = dBm2mW[ic->ic_txpowlimit]; > + len = sizeof(arg); > ndis_set_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len); > } > > @@ -2798,11 +2804,10 @@ ndis_getstate_80211(sc) > } > > /* Get TX power */ > - len = sizeof(arg); > - rval = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len); > - > - if (!rval) { > - for (i = 0; i < sizeof(dBm2mW); i++) > + if (ic->ic_caps & IEEE80211_C_TXPMGT) { > + len = sizeof(arg); > + ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len); > + for (i = 0; i < (sizeof(dBm2mW) / sizeof(dBm2mW[0])); i++) > if (dBm2mW[i] >= arg) > break; > ic->ic_txpowlimit = i; > _______________________________________________ > svn-src-all@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-all > To unsubscribe, send any mail to "svn-src-all-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" > Looks to be still open, should get closed. I dont expect anybody is going to MFC this and similar changes. -- Paul From brett at lariat.net Mon Mar 23 08:38:45 2009 From: brett at lariat.net (Brett Glass) Date: Mon Mar 23 08:38:52 2009 Subject: Problems with inward PPTP tunnel In-Reply-To: <87153F88702C4FBCA3FC799082960C45@adnote989> References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> Message-ID: <200903231538.JAA00486@lariat.net> Luis: It looks as if bin/130159 ought to fix the problem I am having. I see that it sets the "IFP" flag in the route update request and specifies the interface, which ought to be what is needed. I am not seeing problems with proxy ARP, but that may be because I am running 7.1-RELEASE and not -STABLE. The patch in bin/131250 should probably also be committed to keep things working. --Brett Glass At 05:06 AM 3/23/2009, Luiz Otavio O Souza wrote: >Brett, > >I've fixed these two issues with ppp(8), please check the PRs: >bin/130159 and bin/131250. > >If it works for you please let a note and maybe someone commit this. > >Best regards, >Luiz From onemda at gmail.com Mon Mar 23 09:42:29 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Mar 23 09:42:35 2009 Subject: kern/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver In-Reply-To: <200903211525.n2LFPajC040197@freefall.freebsd.org> References: <200903211525.n2LFPajC040197@freefall.freebsd.org> Message-ID: <3a142e750903230942y379cb1f4v4b2b72337548e0db@mail.gmail.com> On 3/21/09, linimon@freebsd.org wrote: > Old Synopsis: NDIS kernel crash on load BCM4321 AGN driver > New Synopsis: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Sat Mar 21 15:25:09 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=132889 > _______________________________________________ > 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" > Cause of this panic may already been fixed in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118439 But it still unknown why attach failed, so OP could provide more info with changing sysctl debug.ndis to 1. -- Paul From ash at aeria.net Mon Mar 23 10:20:22 2009 From: ash at aeria.net (Ash Gokhale) Date: Mon Mar 23 10:20:30 2009 Subject: netgraph modules won't unload after use Message-ID: <6CE36549-DDB7-43A2-88B4-C2D171FA13F1@aeria.net> > Thanks for looking at it Julian, I still can't figure out which resource it needs to release before exiting. I've replaced the raw ether_input routine on the interface to continue my module until I can figure out what's wrong with my netgraph glue. Again this minimal module demonstrates the trouble, I'd appreciate it if some sage could say "there's your trouble" http://pastebin.com/m31b6ece6 > netgraph modules won't unload after use > Julian Elischer julian at elischer.org > Wed Mar 18 09:16:15 PDT 2009 > > * Previous message: netgraph modules won't unload after use > * Next message: kern/126469: [fxp] [panic] fxp(4) related kernel > panic > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > Ash Gokhale wrote: > > I'm developing a kernel module that will be doing inspection and > needed > > access to raw network frames, > > so I turned to netgraph as the solution.However it seems that > netgraph > > will not permit a module > > to unload once it's participated in a mkpeer/connect operation. > > Rebooting to remove a module is > > angrymaking (not like mtx/sleep crashes). > > > > This going into the kernel because my bpf based userland stuff > is > > probably not going to hold up to the packet rate. > > > > Should I file a PR? Or is there magic in the documentation I > havn't found? > > > > > > I've observed the trouble in 7.0 release, and tonight's 7_RELENG, > with > > GENERIC + WITNESS/INVARIANTS > > > > The module code ( cobbled together from netgraph/ng_sample.c / > ng_echo.c) > > http://pastebin.com/m31b6ece6 > > > > The module loads and unloads fine until connected to a netgraph > hook: > > hmm they are supposed to, and they did in the past.. > let me check... > > root at trafmon1:kldload ng_ether > root at trafmon1:ifconfig > bge0: flags=8843 metric 0 > mtu 1500 > options=9b > ether 00:11:43:30:fb:8a > inet 10.7.2.3 netmask 0xffffff00 broadcast 10.7.2.255 > media: Ethernet autoselect (100baseTX ) > status: active > bge1: flags=8802 metric 0 mtu 1500 > options=9b > ether 00:11:43:30:fb:8b > media: Ethernet autoselect (none) > status: no carrier > fxp0: flags=8843 metric 0 > mtu 1500 > options=b > ether 00:0e:0c:62:aa:14 > inet 10.7.0.101 netmask 0xffffff00 broadcast 10.7.0.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > root at trafmon1:ngctl > + list > There are 4 total nodes: > Name: bge0 Type: ether ID: 00000002 Num > hooks: 0 > Name: bge1 Type: ether ID: 00000003 Num > hooks: 0 > Name: ngctl4252 Type: socket ID: 00000005 Num > hooks: 0 > Name: fxp0 Type: ether ID: 00000004 Num > hooks: 0 > + mkpeer bge0: hole lower hook > + list > There are 5 total nodes: > Name: Type: hole ID: 00000006 Num > hooks: 1 > Name: bge0 Type: ether ID: 00000002 Num > hooks: 1 > Name: bge1 Type: ether ID: 00000003 Num > hooks: 0 > Name: ngctl4252 Type: socket ID: 00000005 Num > hooks: 0 > Name: fxp0 Type: ether ID: 00000004 Num > hooks: 0 > + shutdown [6]: > + list > There are 4 total nodes: > Name: bge0 Type: ether ID: 00000002 Num > hooks: 0 > Name: bge1 Type: ether ID: 00000003 Num > hooks: 0 > Name: ngctl4252 Type: socket ID: 00000005 Num > hooks: 0 > Name: fxp0 Type: ether ID: 00000004 Num > hooks: 0 > + quit > root at trafmon1:kldstat -v > Id Refs Address Size Name > 1 36 0xc0400000 6a9c28 kernel (/boot/kernel/kernel) > > [...] > > 7 1 0xccb16000 4000 ng_ether.ko (/boot/kernel/ng_ether.ko) > Contains modules: > Id Name > 246 ng_ether > 8 1 0xccb1b000 2000 ng_hole.ko (/boot/kernel/ng_hole.ko) > Contains modules: > Id Name > 247 ng_hole > root at trafmon1:klunload ng_hole > klunload: Command not found. > root at trafmon1:kldunload ng_hole > root at trafmon1:kldunload ng_ether > kldunload: can't unload file: Device busy > root at trafmon1:kldstat -v > Id Refs Address Size Name > 1 36 0xc0400000 6a9c28 kernel (/boot/kernel/kernel) > > [...] > > 7 1 0xccb16000 4000 ng_ether.ko (/boot/kernel/ng_ether.ko) > Contains modules: > Id Name > 246 ng_ether > root at trafmon1: > > > this is expected. ng-ether is not unloadable as the connections are > too complicated to unwind easily.. one day.... > > root at trafmon1: > > >> Stop in /root/tmp/food.ko. > >> Exit 1 > >> #Mar 18 03:14:31 kernel: quiesced > >> :ro:~/tmp/food.ko:3:14:31:32 > >> Mar 18 03:14:31 kernel: foodmod unloaded > > > > > > Seems that I can't unload some of the other netgraph types either > ( it's > > not just me): > > > >> #kldunload ng_ether > >> :ro:~/tmp/food.ko:3:24:07:41 > >> kldunload: can't unload file: Device busy > >> Exit 1 > > try unloading a node that IS unloadable.. > > see the following comment in ng_ehter.c: > /* > * Note that the base code won't try to unload us until > * all nodes have been removed, and that can't happen > * until all Ethernet interfaces are removed. In any > * case, we know there are no nodes left if the action > * is MOD_UNLOAD, so there's no need to detach any nodes. > */ > > so we can't run this unless you have removeable ethernet interfaces, > and have removed them. > > > > > > > > > _______________________________________________ > > freebsd-net at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe at > freebsd.org" > > * Previous message: netgraph modules won't unload after use > * Next message: kern/126469: [fxp] [panic] fxp(4) related kernel > panic > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > More information about the freebsd-net mailing list > From brett at lariat.net Mon Mar 23 10:50:09 2009 From: brett at lariat.net (Brett Glass) Date: Mon Mar 23 10:50:14 2009 Subject: Problems with inward PPTP tunnel Message-ID: <200903231750.LAA02992@lariat.net> P.S. -- Just tried the patches in bin/130159 and bin/131250 and they do seem to function properly. Please commit. --Brett Glass From brett at lariat.net Mon Mar 23 11:20:03 2009 From: brett at lariat.net (Brett Glass) Date: Mon Mar 23 11:20:09 2009 Subject: bin/130159: [patch] ppp(8) fails to correctly set routes Message-ID: <200903231820.n2NIK3bv000108@freefall.freebsd.org> The following reply was made to PR bin/130159; it has been noted by GNATS. From: Brett Glass To: bug-followup@FreeBSD.org, loos.br@gmail.com Cc: Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes Date: Mon, 23 Mar 2009 11:48:50 -0600 Patch appears to work properly. Please commit. From guru at unixarea.de Mon Mar 23 11:23:21 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Mar 23 11:23:29 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49BFF258.4020207@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> Message-ID: <20090323182310.GA1825@rebelion.Sisis.de> I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) below are some information concerning the AP, ifconfig ... the output of the tcpdump is on my server as http://www.unixarea.de/ath-current.txt let me know if you need more information; HIH matthias info about AP: Siemens Gigaset SE 505 dsl/cable S30853-S1006-R107-3 (handwritten label says: "this is no DSL router; IP 192.168.2.1") as DSL-modem some Fritz!Box is connected to this box http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ifconfig -a ath0: flags=8843 metric 0 mtu 2290 ether 00:15:af:b2:ae:e6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 wlan0: flags=8843 metric 0 mtu 1500 ether 00:15:af:b2:ae:e6 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g status: associated ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL # tcpdump -n -i ath0 -y IEEE802_11_RADIO 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.750225 436598477774us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] ... full log see: http://www.unixarea.de/ath-current.txt From rrs at lakerest.net Mon Mar 23 11:36:19 2009 From: rrs at lakerest.net (Randall Stewart) Date: Mon Mar 23 11:36:52 2009 Subject: Problems in using SCTP CMT In-Reply-To: <20090323182021.ysrn0ogu84cg084g@wmail1.cc.ntu.edu.tw> References: <20090323182021.ysrn0ogu84cg084g@wmail1.cc.ntu.edu.tw> Message-ID: <74A67587-66D0-41B2-84C6-BEC507918231@lakerest.net> Michael and I have developed a fix here at the IETF. at least with pf=0 dac=1 and off=1 We will next test with pf.. I will commit the code to Head... I can also send you a 7.x version tarball.. not sure if it will compile (it will work for 7.1 I know for sure) Let me know if you want such a tar.. R On Mar 23, 2009, at 6:20 AM, Andrew Chen wrote: > Hi, > We have some problems when we tried to send data using CMT-SCTP. > Actually, we are not sure if we do enable CMT functionalities. We > set up two PCs with FreeBSD-7.0. Each PC has two NICs and two IPs. > One is public and the other is private. We wrote simple FTP server > and client programs. On both sides, local addresses are bound as > INADDR_ANY. According to http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-14#section-4.1.5 > , if we bind INADDR_ANY and then call connect(), the multi-homing > capability of SCTP is automatically enabled. Further, we also turn > on sysctl states by setting > sysctl net.inet.sctp.cmt_pf=1 > sysctl net.inet.sctp.cmt_use_dac=1 > sysctl net.inet.sctp.cmt_on_off=1 > Then we start transmission and capture the traffics. Unfortunately, > the captured packet shows data were transmitted on primary path and > there were only heartbeat/HB ACKs on the other path. > To our knowledge, to use CMT, the only things we have to do is to > establish a multihomed association, and turn on the sysctl options. > Can anyone point out something we did wrong or steps we missed? > Thanks in advance. > > _______________________________________________ > 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 803-317-4952 (cell) 803-345-0391(direct) From bms at incunabulum.net Mon Mar 23 11:44:49 2009 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Mar 23 11:44:56 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090323182310.GA1825@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> Message-ID: <49C7D89A.6070502@incunabulum.net> Matthias Apitz wrote: > I went today evening with my EeePC and CURRENT on USB key > to that Greek restaurant; DHCP does not get IP in CURRENT either; > this is somehow good news, isn't it :-) > This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. We have yet to produce a tcpdump to catch it 'in the act' and observe the DLT_IEEE80211 traffic when it actually happens, I have only seen the symptoms. The AP does not show the EeePC units as being associated any more at this point, but ath0 still shows 'status: associated'. The AP involved is a Netgear WG602 V2, and is running the vendor's firmware. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). cheers BMS From bms at incunabulum.net Mon Mar 23 11:50:08 2009 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Mar 23 11:50:17 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903231850.n2NIo7wG041686@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce M Simpson To: Matthias Apitz Cc: bug-followup@freebsd.org, Sam Leffler , freebsd-net@freebsd.org, "Sean C. Farley" Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 18:44:42 +0000 Matthias Apitz wrote: > I went today evening with my EeePC and CURRENT on USB key > to that Greek restaurant; DHCP does not get IP in CURRENT either; > this is somehow good news, isn't it :-) > This may be orthogonal, but: A lab colleague and I have been seeing a sporadic problem where the ath0 exhibits the symptoms of being disassociated from its AP. We are running RELENG_7 on the EeePC 701 since the open source HAL merge. In the behaviour we're seeing, we don't see any problem with the initial dhclient run, the ath0 just seems to get disassociated within 5-10 minutes of associating. If we leave 'ping ' running in the background, we don't see this problem. We have yet to produce a tcpdump to catch it 'in the act' and observe the DLT_IEEE80211 traffic when it actually happens, I have only seen the symptoms. The AP does not show the EeePC units as being associated any more at this point, but ath0 still shows 'status: associated'. The AP involved is a Netgear WG602 V2, and is running the vendor's firmware. I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot (including dhcp and anything we bump into). cheers BMS From guru at unixarea.de Mon Mar 23 11:54:02 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Mar 23 11:54:16 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C7D89A.6070502@incunabulum.net> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7D89A.6070502@incunabulum.net> Message-ID: <20090323185321.GA2352@rebelion.Sisis.de> El d?a Monday, March 23, 2009 a las 06:44:42PM +0000, Bruce M Simpson escribi?: > Matthias Apitz wrote: > >I went today evening with my EeePC and CURRENT on USB key > >to that Greek restaurant; DHCP does not get IP in CURRENT either; > >this is somehow good news, isn't it :-) > > > > This may be orthogonal, but: > A lab colleague and I have been seeing a sporadic problem where the > ath0 exhibits the symptoms of being disassociated from its AP. We are > running RELENG_7 on the EeePC 701 since the open source HAL merge. > In the behaviour we're seeing, we don't see any problem with the > initial dhclient run, the ath0 just seems to get disassociated within > 5-10 minutes of associating. > > If we leave 'ping ' running in the background, we don't > see this problem. ... This must be a complete different problem, because in my case the AP stays (at least what ifconfig shows) always associated, but don't get offered IP addr; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From sam at freebsd.org Mon Mar 23 12:12:13 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Mar 23 12:12:20 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090323182310.GA1825@rebelion.Sisis.de> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> Message-ID: <49C7DF04.1020100@freebsd.org> Matthias Apitz wrote: > I went today evening with my EeePC and CURRENT on USB key > to that Greek restaurant; DHCP does not get IP in CURRENT either; > this is somehow good news, isn't it :-) > > below are some information concerning the AP, ifconfig ... > the output of the tcpdump is on my server as > http://www.unixarea.de/ath-current.txt > let me know if you need more information; > > HIH > > matthias > > > info about AP: > Siemens Gigaset SE 505 dsl/cable > S30853-S1006-R107-3 > (handwritten label says: "this is no DSL router; IP 192.168.2.1") > as DSL-modem some Fritz!Box is connected to this box > http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html > > > # uname -a > FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 > > # ifconfig -a > ath0: flags=8843 metric 0 mtu 2290 > ether 00:15:af:b2:ae:e6 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:15:af:b2:ae:e6 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g > status: associated > ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 > regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 > wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS > wme burst roaming MANUAL > > > > # tcpdump -n -i ath0 -y IEEE802_11_RADIO > 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.750225 436598477774us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > ... > > full log see: http://www.unixarea.de/ath-current.txt > > > If you have the raw pcap capture please provide a url to it. From the log it appears you're sending+receiving wep-encrypted frames. They keyid is the same and since you're receiving frames I have to assume the key matter is correct as otherwise the h/w would drop the frame. You can verify this by feeding the key into wireshark to check if the frame contents make sense. I'm out of ideas. About the only thing I can suggest is you setup a different ap w/ the same wep key and see if things work. If so then you know it's something this ap is doing. I can't recall when I last tested wep on HEAD but I'm pretty sure it works. I will re-test that when I get a chance. Sam From sam at freebsd.org Mon Mar 23 12:14:21 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Mar 23 12:14:28 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C7D89A.6070502@incunabulum.net> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7D89A.6070502@incunabulum.net> Message-ID: <49C7DF8A.8070408@freebsd.org> Bruce M Simpson wrote: > Matthias Apitz wrote: >> I went today evening with my EeePC and CURRENT on USB key >> to that Greek restaurant; DHCP does not get IP in CURRENT either; >> this is somehow good news, isn't it :-) >> > > This may be orthogonal, but: > A lab colleague and I have been seeing a sporadic problem where the > ath0 exhibits the symptoms of being disassociated from its AP. We are > running RELENG_7 on the EeePC 701 since the open source HAL merge. > In the behaviour we're seeing, we don't see any problem with the > initial dhclient run, the ath0 just seems to get disassociated within > 5-10 minutes of associating. > > If we leave 'ping ' running in the background, we don't > see this problem. > > We have yet to produce a tcpdump to catch it 'in the act' and > observe the DLT_IEEE80211 traffic when it actually happens, I have > only seen the symptoms. The AP does not show the EeePC units as being > associated any more at this point, but ath0 still shows 'status: > associated'. The AP involved is a Netgear WG602 V2, and is running the > vendor's firmware. > > I'll try to get set up with 'tcpdump -y ieee802_11' from initial boot > (including dhcp and anything we bump into). There are many issues with the wireless code in RELENG_7. Now that the hal is merged we can try to address them. Unfortunately the 7.2 release has just begun so it's unclear what we can get in. I'm also limited in what I'm willing to commit given that I do not run RELENG_7. Sam From sam at freebsd.org Mon Mar 23 12:20:04 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Mar 23 12:20:10 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903231920.n2NJK2qL081828@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Sam Leffler To: Matthias Apitz Cc: bug-followup@freebsd.org, freebsd-net@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 12:12:04 -0700 Matthias Apitz wrote: > I went today evening with my EeePC and CURRENT on USB key > to that Greek restaurant; DHCP does not get IP in CURRENT either; > this is somehow good news, isn't it :-) > > below are some information concerning the AP, ifconfig ... > the output of the tcpdump is on my server as > http://www.unixarea.de/ath-current.txt > let me know if you need more information; > > HIH > > matthias > > > info about AP: > Siemens Gigaset SE 505 dsl/cable > S30853-S1006-R107-3 > (handwritten label says: "this is no DSL router; IP 192.168.2.1") > as DSL-modem some Fritz!Box is connected to this box > http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html > > > # uname -a > FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 > > # ifconfig -a > ath0: flags=8843 metric 0 mtu 2290 > ether 00:15:af:b2:ae:e6 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:15:af:b2:ae:e6 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g > status: associated > ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 > regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 > wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS > wme burst roaming MANUAL > > > > # tcpdump -n -i ath0 -y IEEE802_11_RADIO > 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.750225 436598477774us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] > ... > > full log see: http://www.unixarea.de/ath-current.txt > > > If you have the raw pcap capture please provide a url to it. From the log it appears you're sending+receiving wep-encrypted frames. They keyid is the same and since you're receiving frames I have to assume the key matter is correct as otherwise the h/w would drop the frame. You can verify this by feeding the key into wireshark to check if the frame contents make sense. I'm out of ideas. About the only thing I can suggest is you setup a different ap w/ the same wep key and see if things work. If so then you know it's something this ap is doing. I can't recall when I last tested wep on HEAD but I'm pretty sure it works. I will re-test that when I get a chance. Sam From guru at unixarea.de Mon Mar 23 13:00:06 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Mar 23 13:00:15 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903232000.n2NK05VC035641@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz To: bug-followup@freebsd.org Cc: Sam Leffler , freebsd-net@freebsd.org, Bruce Simpson , "Sean C. Farley" Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 19:23:11 +0100 I went today evening with my EeePC and CURRENT on USB key to that Greek restaurant; DHCP does not get IP in CURRENT either; this is somehow good news, isn't it :-) below are some information concerning the AP, ifconfig ... the output of the tcpdump is on my server as http://www.unixarea.de/ath-current.txt let me know if you need more information; HIH matthias info about AP: Siemens Gigaset SE 505 dsl/cable S30853-S1006-R107-3 (handwritten label says: "this is no DSL router; IP 192.168.2.1") as DSL-modem some Fritz!Box is connected to this box http://reviews.cnet.com/routers/siemens-gigaset-se505-dsl/1707-3319_7-30799508.html # uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 # ifconfig -a ath0: flags=8843 metric 0 mtu 2290 ether 00:15:af:b2:ae:e6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 wlan0: flags=8843 metric 0 mtu 1500 ether 00:15:af:b2:ae:e6 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet DS/5.5Mbps mode 11g status: associated ssid ConnectionPoint channel 11 (2462 Mhz 11g) bssid 00:01:e3:0e:97:99 regdomain 96 indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL # tcpdump -n -i ath0 -y IEEE802_11_RADIO 17:56:24.647835 436598375373us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.750225 436598477774us tsft 1.0 Mb/s -81dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.852621 436598580174us tsft 1.0 Mb/s -79dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] 17:56:24.955019 436598682572us tsft 1.0 Mb/s -80dB signal -96dB noise antenna 1 [0x00000012] Beacon (ConnectionPoint) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS[|802.11] ... full log see: http://www.unixarea.de/ath-current.txt From bms at incunabulum.net Mon Mar 23 13:12:21 2009 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Mar 23 13:12:27 2009 Subject: ath0 apparent silent disassociation In-Reply-To: <49C7DF8A.8070408@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7D89A.6070502@incunabulum.net> <49C7DF8A.8070408@freebsd.org> Message-ID: <49C7ED1F.2060608@incunabulum.net> [Repost without attachment] OK. We've managed to reproduce this set of symptoms now in our work area. [If anyone needs to see a pcap, please Cc: me offlist.] Timebase: beginning of the pcap is in sync with a bringup from single-user mode; the tcpdump runs in the background from init whilst the system is brought up. OK, so I timed the apparent loss of connectivity as 6m 30s from that point I hit the stopwatch, to when I hit it again when the AP's Web GUI no longer shows the STA affected as being associated. Obviously such a timing is subject to human/visual jitter, and how often Netgear's firmware pulls the STA association list from the AP into the web GUI. What stands out in the pcap is that 302.291s in (almost 5m exactly), the STA (ath0) sends an IEEE 802.11 NULL frame to the AP with the PWR MGT bit set (I'm going to sleep!). This more or less coincides with a normal beacon from the Netgear AP. It does not advertise Auto Power Save Delivery (apsd), that bit is 0. This is puzzling as we don't enable power management by default. As I understand it, this may be an AP feature in some environments... I can try reproducing this with an explicit 'ifconfig ath0 -powersave' and see if it reoccurs. You'll see that after this NULL frame is sent, there is another Probe Request, and the Netgear AP does Probe Respond, but this makes no difference (I ended the capture around 150s after the NULL frame was sent). At this point we can't send traffic from the ath0, or rather, the AP is acting as though it never even heard the STA. The STA learns the AP's IP address/MAC mapping through passive ARP -- we still see broadcasts on the SSID -- but the AP has started to totally ignore the STA, and seemed to have ignored its ARP requests also. We are using MAC address ACL control with this AP, and the ath0 affected is definitely listed in its ACL table, configured up, rebooted etc. It is as though the STA is entering power saving mode when not explicitly told to, and the AP is not waking up the STA as it should. If any more information needed, or where to look, please let me know what's involved (I MFCed the change after all, so I'll help where I can until I'm on holiday this week...) My lab colleague is just working around this with 'ping ' for now, that keeps things up, as does OpenVPN... cheers BMS From jhay at meraka.org.za Mon Mar 23 13:40:55 2009 From: jhay at meraka.org.za (John Hay) Date: Mon Mar 23 13:41:01 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C7D89A.6070502@incunabulum.net> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7D89A.6070502@incunabulum.net> Message-ID: <20090323204050.GA5477@zibbi.meraka.csir.co.za> On Mon, Mar 23, 2009 at 06:44:42PM +0000, Bruce M Simpson wrote: > Matthias Apitz wrote: > >I went today evening with my EeePC and CURRENT on USB key > >to that Greek restaurant; DHCP does not get IP in CURRENT either; > >this is somehow good news, isn't it :-) > > > > This may be orthogonal, but: > A lab colleague and I have been seeing a sporadic problem where the > ath0 exhibits the symptoms of being disassociated from its AP. We are > running RELENG_7 on the EeePC 701 since the open source HAL merge. > In the behaviour we're seeing, we don't see any problem with the > initial dhclient run, the ath0 just seems to get disassociated within > 5-10 minutes of associating. > > If we leave 'ping ' running in the background, we don't > see this problem. > I found doing a -bgscan before it happens, make it not happen. I now have -bgscan in my rc.conf. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From jhay at meraka.org.za Mon Mar 23 13:50:03 2009 From: jhay at meraka.org.za (John Hay) Date: Mon Mar 23 13:50:10 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903232050.n2NKo3mi004059@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: John Hay To: Bruce M Simpson Cc: Matthias Apitz , freebsd-net@freebsd.org, Sam Leffler , "Sean C. Farley" , bug-followup@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 22:40:50 +0200 On Mon, Mar 23, 2009 at 06:44:42PM +0000, Bruce M Simpson wrote: > Matthias Apitz wrote: > >I went today evening with my EeePC and CURRENT on USB key > >to that Greek restaurant; DHCP does not get IP in CURRENT either; > >this is somehow good news, isn't it :-) > > > > This may be orthogonal, but: > A lab colleague and I have been seeing a sporadic problem where the > ath0 exhibits the symptoms of being disassociated from its AP. We are > running RELENG_7 on the EeePC 701 since the open source HAL merge. > In the behaviour we're seeing, we don't see any problem with the > initial dhclient run, the ath0 just seems to get disassociated within > 5-10 minutes of associating. > > If we leave 'ping ' running in the background, we don't > see this problem. > I found doing a -bgscan before it happens, make it not happen. I now have -bgscan in my rc.conf. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From dfilter at FreeBSD.ORG Mon Mar 23 14:00:08 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Mar 23 14:00:15 2009 Subject: kern/119361: commit references a PR Message-ID: <200903232100.n2NL03Gg017121@freefall.freebsd.org> The following reply was made to PR kern/119361; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/119361: commit references a PR Date: Mon, 23 Mar 2009 20:54:04 +0000 (UTC) Author: marius Date: Mon Mar 23 20:53:38 2009 New Revision: 190335 URL: http://svn.freebsd.org/changeset/base/190335 Log: MFC: r190194 - In bge_ifmedia_upd_locked() take advantrage of LIST_FOREACH(). - If boot verbose, print asicrev, chiprev and bus type on attach. - For PCI Express devices: 1) Adjust max read request size to 4Kbytes 2) Turn on FIFO_LONG_BURST in RDMA during bge_blockinit() Though 1) does not seem to have much to do with the poor TX performance observed on PCI Express bge(4), 2) does fix the problem. [1] - Nuke the RX CPU self-diag, which prevents working cards from working (Linux tg3 does not have this diag neither does OpenBSD's bge(4)). The increasing of the firmware handshaking timeout to 20000 retries done as part of the original commit isn't merged as way already have a way higher BGE_TIMEOUT of 100000. PR: 119361 [1] Obtained from: tg3 via DragonflyBSD [1], DragonflyBSD Modified: stable/7/sys/ (props changed) stable/7/sys/contrib/pf/ (props changed) stable/7/sys/dev/ath/ath_hal/ (props changed) stable/7/sys/dev/bge/if_bge.c stable/7/sys/dev/bge/if_bgereg.h stable/7/sys/dev/cxgb/ (props changed) Modified: stable/7/sys/dev/bge/if_bge.c ============================================================================== --- stable/7/sys/dev/bge/if_bge.c Mon Mar 23 20:37:37 2009 (r190334) +++ stable/7/sys/dev/bge/if_bge.c Mon Mar 23 20:53:38 2009 (r190335) @@ -384,6 +384,7 @@ static uint32_t bge_readreg_ind(struct b #endif static void bge_writemem_direct(struct bge_softc *, int, int); static void bge_writereg_ind(struct bge_softc *, int, int); +static void bge_set_max_readrq(struct bge_softc *, int); static int bge_miibus_readreg(device_t, int, int); static int bge_miibus_writereg(device_t, int, int, int); @@ -523,6 +524,34 @@ bge_writemem_ind(struct bge_softc *sc, i pci_write_config(dev, BGE_PCI_MEMWIN_BASEADDR, 0, 4); } +/* + * PCI Express only + */ +static void +bge_set_max_readrq(struct bge_softc *sc, int expr_ptr) +{ + device_t dev; + uint16_t val; + + KASSERT((sc->bge_flags & BGE_FLAG_PCIE) && expr_ptr != 0, + ("%s: not applicable", __func__)); + + dev = sc->bge_dev; + + val = pci_read_config(dev, expr_ptr + BGE_PCIE_DEVCTL, 2); + if ((val & BGE_PCIE_DEVCTL_MAX_READRQ_MASK) != + BGE_PCIE_DEVCTL_MAX_READRQ_4096) { + if (bootverbose) + device_printf(dev, "adjust device control 0x%04x ", + val); + val &= ~BGE_PCIE_DEVCTL_MAX_READRQ_MASK; + val |= BGE_PCIE_DEVCTL_MAX_READRQ_4096; + pci_write_config(dev, expr_ptr + BGE_PCIE_DEVCTL, val, 2); + if (bootverbose) + printf("-> 0x%04x\n", val); + } +} + #ifdef notdef static uint32_t bge_readreg_ind(struct bge_softc *sc, int off) @@ -1278,18 +1307,6 @@ bge_chipinit(struct bge_softc *sc) /* Set endianness before we access any non-PCI registers. */ pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4); - /* - * Check the 'ROM failed' bit on the RX CPU to see if - * self-tests passed. Skip this check when there's no - * chip containing the Ethernet address fitted, since - * in that case it will always fail. - */ - if ((sc->bge_flags & BGE_FLAG_EADDR) && - CSR_READ_4(sc, BGE_RXCPU_MODE) & BGE_RXCPUMODE_ROMFAIL) { - device_printf(sc->bge_dev, "RX CPU self-diagnostics failed!\n"); - return (ENODEV); - } - /* Clear the MAC control register */ CSR_WRITE_4(sc, BGE_MAC_MODE, 0); @@ -1742,14 +1759,18 @@ bge_blockinit(struct bge_softc *sc) /* Enable host coalescing bug fix. */ if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || sc->bge_asicrev == BGE_ASICREV_BCM5787) - val |= 1 << 29; + val |= 1 << 29; /* Turn on write DMA state machine */ CSR_WRITE_4(sc, BGE_WDMA_MODE, val); + DELAY(40); /* Turn on read DMA state machine */ - CSR_WRITE_4(sc, BGE_RDMA_MODE, - BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS); + val = BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS; + if (sc->bge_flags & BGE_FLAG_PCIE) + val |= BGE_RDMAMODE_FIFO_LONG_BURST; + CSR_WRITE_4(sc, BGE_RDMA_MODE, val); + DELAY(40); /* Turn on RX data completion state machine */ CSR_WRITE_4(sc, BGE_RDC_MODE, BGE_RDCMODE_ENABLE); @@ -2387,7 +2408,7 @@ bge_attach(device_t dev) goto fail; } - /* Save ASIC rev. */ + /* Save various chip information. */ sc->bge_chipid = pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & BGE_PCIMISCCTL_ASICREV; @@ -2470,14 +2491,17 @@ bge_attach(device_t dev) * Found a PCI Express capabilities register, this * must be a PCI Express device. */ - if (reg != 0) + if (reg != 0) { sc->bge_flags |= BGE_FLAG_PCIE; #else if (BGE_IS_5705_PLUS(sc)) { reg = pci_read_config(dev, BGE_PCIE_CAPID_REG, 4); - if ((reg & 0xFF) == BGE_PCIE_CAPID) + if ((reg & 0xFF) == BGE_PCIE_CAPID) { sc->bge_flags |= BGE_FLAG_PCIE; + reg = BGE_PCIE_CAPID; #endif + bge_set_max_readrq(sc, reg); + } } else { /* * Check if the device is in PCI-X Mode. @@ -2522,6 +2546,13 @@ bge_attach(device_t dev) goto fail; } + if (bootverbose) + device_printf(dev, + "CHIP ID 0x%08x; ASIC REV 0x%02x; CHIP REV 0x%02x; %s\n", + sc->bge_chipid, sc->bge_asicrev, sc->bge_chiprev, + (sc->bge_flags & BGE_FLAG_PCIX) ? "PCI-X" : + ((sc->bge_flags & BGE_FLAG_PCIE) ? "PCI-E" : "PCI")); + BGE_LOCK_INIT(sc, device_get_nameunit(dev)); /* Try to reset the chip. */ @@ -3882,6 +3913,7 @@ bge_ifmedia_upd_locked(struct ifnet *ifp { struct bge_softc *sc = ifp->if_softc; struct mii_data *mii; + struct mii_softc *miisc; struct ifmedia *ifm; BGE_LOCK_ASSERT(sc); @@ -3932,12 +3964,9 @@ bge_ifmedia_upd_locked(struct ifnet *ifp sc->bge_link_evt++; mii = device_get_softc(sc->bge_miibus); - if (mii->mii_instance) { - struct mii_softc *miisc; - for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; - miisc = LIST_NEXT(miisc, mii_list)) + if (mii->mii_instance) + LIST_FOREACH(miisc, &mii->mii_phys, mii_list) mii_phy_reset(miisc); - } mii_mediachg(mii); /* Modified: stable/7/sys/dev/bge/if_bgereg.h ============================================================================== --- stable/7/sys/dev/bge/if_bgereg.h Mon Mar 23 20:37:37 2009 (r190334) +++ stable/7/sys/dev/bge/if_bgereg.h Mon Mar 23 20:53:38 2009 (r190335) @@ -176,6 +176,22 @@ #define BGE_PCI_MSI_ADDR_LO 0x60 #define BGE_PCI_MSI_DATA 0x64 +/* + * PCI Express definitions + * According to + * PCI Express base specification, REV. 1.0a + */ + +/* PCI Express device control, 16bits */ +#define BGE_PCIE_DEVCTL 0x08 +#define BGE_PCIE_DEVCTL_MAX_READRQ_MASK 0x7000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_128 0x0000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_256 0x1000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_512 0x2000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_1024 0x3000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_2048 0x4000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_4096 0x5000 + /* PCI MSI. ??? */ #define BGE_PCIE_CAPID_REG 0xD0 #define BGE_PCIE_CAPID 0x10 @@ -1359,6 +1375,8 @@ #define BGE_RDMAMODE_PCI_FIFOOREAD_ATTN 0x00000100 #define BGE_RDMAMODE_LOCWRITE_TOOBIG 0x00000200 #define BGE_RDMAMODE_ALL_ATTNS 0x000003FC +#define BGE_RDMAMODE_FIFO_SIZE_128 0x00020000 +#define BGE_RDMAMODE_FIFO_LONG_BURST 0x00030000 /* Read DMA status register */ #define BGE_RDMASTAT_PCI_TGT_ABRT_ATTN 0x00000004 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Mon Mar 23 14:00:15 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Mar 23 14:00:24 2009 Subject: kern/119361: commit references a PR Message-ID: <200903232100.n2NL05Bj017135@freefall.freebsd.org> The following reply was made to PR kern/119361; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/119361: commit references a PR Date: Mon, 23 Mar 2009 20:54:30 +0000 (UTC) Author: marius Date: Mon Mar 23 20:53:50 2009 New Revision: 190336 URL: http://svn.freebsd.org/changeset/base/190336 Log: MFC: r190194 - In bge_ifmedia_upd_locked() take advantrage of LIST_FOREACH(). - If boot verbose, print asicrev, chiprev and bus type on attach. - For PCI Express devices: 1) Adjust max read request size to 4Kbytes 2) Turn on FIFO_LONG_BURST in RDMA during bge_blockinit() Though 1) does not seem to have much to do with the poor TX performance observed on PCI Express bge(4), 2) does fix the problem. [1] - Nuke the RX CPU self-diag, which prevents working cards from working (Linux tg3 does not have this diag neither does OpenBSD's bge(4)). The increasing of the firmware handshaking timeout to 20000 retries done as part of the original commit isn't merged as way already have a way higher BGE_TIMEOUT of 100000. PR: 119361 [1] Obtained from: tg3 via DragonflyBSD [1], DragonflyBSD Modified: stable/6/sys/ (props changed) stable/6/sys/contrib/pf/ (props changed) stable/6/sys/dev/bge/if_bge.c stable/6/sys/dev/bge/if_bgereg.h stable/6/sys/dev/cxgb/ (props changed) Modified: stable/6/sys/dev/bge/if_bge.c ============================================================================== --- stable/6/sys/dev/bge/if_bge.c Mon Mar 23 20:53:38 2009 (r190335) +++ stable/6/sys/dev/bge/if_bge.c Mon Mar 23 20:53:50 2009 (r190336) @@ -383,6 +383,7 @@ static uint32_t bge_readreg_ind(struct b #endif static void bge_writemem_direct(struct bge_softc *, int, int); static void bge_writereg_ind(struct bge_softc *, int, int); +static void bge_set_max_readrq(struct bge_softc *, int); static int bge_miibus_readreg(device_t, int, int); static int bge_miibus_writereg(device_t, int, int, int); @@ -521,6 +522,34 @@ bge_writemem_ind(struct bge_softc *sc, i pci_write_config(dev, BGE_PCI_MEMWIN_BASEADDR, 0, 4); } +/* + * PCI Express only + */ +static void +bge_set_max_readrq(struct bge_softc *sc, int expr_ptr) +{ + device_t dev; + uint16_t val; + + KASSERT((sc->bge_flags & BGE_FLAG_PCIE) && expr_ptr != 0, + ("%s: not applicable", __func__)); + + dev = sc->bge_dev; + + val = pci_read_config(dev, expr_ptr + BGE_PCIE_DEVCTL, 2); + if ((val & BGE_PCIE_DEVCTL_MAX_READRQ_MASK) != + BGE_PCIE_DEVCTL_MAX_READRQ_4096) { + if (bootverbose) + device_printf(dev, "adjust device control 0x%04x ", + val); + val &= ~BGE_PCIE_DEVCTL_MAX_READRQ_MASK; + val |= BGE_PCIE_DEVCTL_MAX_READRQ_4096; + pci_write_config(dev, expr_ptr + BGE_PCIE_DEVCTL, val, 2); + if (bootverbose) + printf("-> 0x%04x\n", val); + } +} + #ifdef notdef static uint32_t bge_readreg_ind(struct bge_softc *sc, int off) @@ -1261,18 +1290,6 @@ bge_chipinit(struct bge_softc *sc) /* Set endianness before we access any non-PCI registers. */ pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4); - /* - * Check the 'ROM failed' bit on the RX CPU to see if - * self-tests passed. Skip this check when there's no - * chip containing the Ethernet address fitted, since - * in that case it will always fail. - */ - if ((sc->bge_flags & BGE_FLAG_EADDR) && - CSR_READ_4(sc, BGE_RXCPU_MODE) & BGE_RXCPUMODE_ROMFAIL) { - device_printf(sc->bge_dev, "RX CPU self-diagnostics failed!\n"); - return (ENODEV); - } - /* Clear the MAC control register */ CSR_WRITE_4(sc, BGE_MAC_MODE, 0); @@ -1736,14 +1753,18 @@ bge_blockinit(struct bge_softc *sc) /* Enable host coalescing bug fix. */ if (sc->bge_asicrev == BGE_ASICREV_BCM5755 || sc->bge_asicrev == BGE_ASICREV_BCM5787) - val |= 1 << 29; + val |= 1 << 29; /* Turn on write DMA state machine */ CSR_WRITE_4(sc, BGE_WDMA_MODE, val); + DELAY(40); /* Turn on read DMA state machine */ - CSR_WRITE_4(sc, BGE_RDMA_MODE, - BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS); + val = BGE_RDMAMODE_ENABLE | BGE_RDMAMODE_ALL_ATTNS; + if (sc->bge_flags & BGE_FLAG_PCIE) + val |= BGE_RDMAMODE_FIFO_LONG_BURST; + CSR_WRITE_4(sc, BGE_RDMA_MODE, val); + DELAY(40); /* Turn on RX data completion state machine */ CSR_WRITE_4(sc, BGE_RDC_MODE, BGE_RDCMODE_ENABLE); @@ -2383,8 +2404,7 @@ bge_attach(device_t dev) sc->bge_btag = rman_get_bustag(sc->bge_res); sc->bge_bhandle = rman_get_bushandle(sc->bge_res); - /* Save ASIC rev. */ - + /* Save various chip information. */ sc->bge_chipid = pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & BGE_PCIMISCCTL_ASICREV; @@ -2457,14 +2477,17 @@ bge_attach(device_t dev) * Found a PCI Express capabilities register, this * must be a PCI Express device. */ - if (reg != 0) + if (reg != 0) { sc->bge_flags |= BGE_FLAG_PCIE; #else if (BGE_IS_5705_PLUS(sc)) { reg = pci_read_config(dev, BGE_PCIE_CAPID_REG, 4); - if ((reg & 0xFF) == BGE_PCIE_CAPID) + if ((reg & 0xFF) == BGE_PCIE_CAPID) { sc->bge_flags |= BGE_FLAG_PCIE; + reg = BGE_PCIE_CAPID; #endif + bge_set_max_readrq(sc, reg); + } } else { /* * Check if the device is in PCI-X Mode. @@ -2509,6 +2532,13 @@ bge_attach(device_t dev) goto fail; } + if (bootverbose) + device_printf(dev, + "CHIP ID 0x%08x; ASIC REV 0x%02x; CHIP REV 0x%02x; %s\n", + sc->bge_chipid, sc->bge_asicrev, sc->bge_chiprev, + (sc->bge_flags & BGE_FLAG_PCIX) ? "PCI-X" : + ((sc->bge_flags & BGE_FLAG_PCIE) ? "PCI-E" : "PCI")); + BGE_LOCK_INIT(sc, device_get_nameunit(dev)); /* Try to reset the chip. */ @@ -3860,6 +3890,7 @@ bge_ifmedia_upd_locked(struct ifnet *ifp { struct bge_softc *sc = ifp->if_softc; struct mii_data *mii; + struct mii_softc *miisc; struct ifmedia *ifm; BGE_LOCK_ASSERT(sc); @@ -3910,12 +3941,9 @@ bge_ifmedia_upd_locked(struct ifnet *ifp sc->bge_link_evt++; mii = device_get_softc(sc->bge_miibus); - if (mii->mii_instance) { - struct mii_softc *miisc; - for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; - miisc = LIST_NEXT(miisc, mii_list)) + if (mii->mii_instance) + LIST_FOREACH(miisc, &mii->mii_phys, mii_list) mii_phy_reset(miisc); - } mii_mediachg(mii); return (0); Modified: stable/6/sys/dev/bge/if_bgereg.h ============================================================================== --- stable/6/sys/dev/bge/if_bgereg.h Mon Mar 23 20:53:38 2009 (r190335) +++ stable/6/sys/dev/bge/if_bgereg.h Mon Mar 23 20:53:50 2009 (r190336) @@ -176,6 +176,22 @@ #define BGE_PCI_MSI_ADDR_LO 0x60 #define BGE_PCI_MSI_DATA 0x64 +/* + * PCI Express definitions + * According to + * PCI Express base specification, REV. 1.0a + */ + +/* PCI Express device control, 16bits */ +#define BGE_PCIE_DEVCTL 0x08 +#define BGE_PCIE_DEVCTL_MAX_READRQ_MASK 0x7000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_128 0x0000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_256 0x1000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_512 0x2000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_1024 0x3000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_2048 0x4000 +#define BGE_PCIE_DEVCTL_MAX_READRQ_4096 0x5000 + /* PCI MSI. ??? */ #define BGE_PCIE_CAPID_REG 0xD0 #define BGE_PCIE_CAPID 0x10 @@ -1357,6 +1373,8 @@ #define BGE_RDMAMODE_PCI_FIFOOREAD_ATTN 0x00000100 #define BGE_RDMAMODE_LOCWRITE_TOOBIG 0x00000200 #define BGE_RDMAMODE_ALL_ATTNS 0x000003FC +#define BGE_RDMAMODE_FIFO_SIZE_128 0x00020000 +#define BGE_RDMAMODE_FIFO_LONG_BURST 0x00030000 /* Read DMA status register */ #define BGE_RDMASTAT_PCI_TGT_ABRT_ATTN 0x00000004 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From marius at FreeBSD.org Mon Mar 23 14:04:58 2009 From: marius at FreeBSD.org (marius@FreeBSD.org) Date: Mon Mar 23 14:05:04 2009 Subject: kern/119361: [bge] bge(4) transmit performance problem Message-ID: <200903232104.n2NL4sDR029916@freefall.freebsd.org> Synopsis: [bge] bge(4) transmit performance problem State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Mon Mar 23 21:04:40 UTC 2009 State-Changed-Why: close http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 From sam at freebsd.org Mon Mar 23 14:08:24 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Mar 23 14:08:31 2009 Subject: ath0 apparent silent disassociation In-Reply-To: <49C7EBD8.8010708@incunabulum.net> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7D89A.6070502@incunabulum.net> <49C7DF8A.8070408@freebsd.org> <49C7EBD8.8010708@incunabulum.net> Message-ID: <49C7FA44.8010801@freebsd.org> Bruce M Simpson wrote: > Sam Leffler wrote: >> Bruce M Simpson wrote: >>> ... >>> This may be orthogonal, but: >>> A lab colleague and I have been seeing a sporadic problem where >>> the ath0 exhibits the symptoms of being disassociated from its AP. >>> We are running RELENG_7 on the EeePC 701 since the open source HAL >>> merge. >>> In the behaviour we're seeing, we don't see any problem with the >>> initial dhclient run, the ath0 just seems to get disassociated >>> within 5-10 minutes of associating. >>> >>> If we leave 'ping ' running in the background, we >>> don't see this problem. >>> >>> >>> I'll try to get set up with 'tcpdump -y ieee802_11' from initial >>> boot (including dhcp and anything we bump into). >> >> There are many issues with the wireless code in RELENG_7. Now that >> the hal is merged we can try to address them. Unfortunately the 7.2 >> release has just begun so it's unclear what we can get in. I'm also >> limited in what I'm willing to commit given that I do not run RELENG_7. > > OK. We've managed to reproduce this set of symptoms now in our work area. > I've attached some script(1) output of netstat -in being run, and a > pcap dump. > > Timebase: beginning of the pcap is in sync with a bringup from > single-user mode; the tcpdump runs in the background from init whilst > the system is brought up. > > OK, so I timed the apparent loss of connectivity as 6m 30s from > that point I hit the stopwatch, to when I hit it again when the AP's > Web GUI no longer shows the STA affected as being associated. > Obviously such a timing is subject to human/visual jitter, and how > often Netgear's firmware pulls the STA association list from the AP > into the web GUI. > > What stands out in the pcap is that 302.291s in (almost 5m > exactly), the STA (ath0) sends an IEEE 802.11 NULL frame to the AP > with the PWR MGT bit set (I'm going to sleep!). This more or less > coincides with a normal beacon from the Netgear AP. It does not > advertise Auto Power Save Delivery (apsd), that bit is 0. > This is puzzling as we don't enable power management by default. As > I understand it, this may be an AP feature in some environments... I > can try reproducing this with an explicit 'ifconfig ath0 -powersave' > and see if it reoccurs. > > You'll see that after this NULL frame is sent, there is another > Probe Request, and the Netgear AP does Probe Respond, but this makes > no difference (I ended the capture around 150s after the NULL frame > was sent). > > At this point we can't send traffic from the ath0, or rather, the > AP is acting as though it never even heard the STA. The STA learns the > AP's IP address/MAC mapping through passive ARP -- we still see > broadcasts on the SSID -- but the AP has started to totally ignore the > STA, and seemed to have ignored its ARP requests also. > We are using MAC address ACL control with this AP, and the ath0 > affected is definitely listed in its ACL table, configured up, > rebooted etc. > > It is as though the STA is entering power saving mode when not > explicitly told to, and the AP is not waking up the STA as it should. > > If any more information needed, or where to look, please let me know > what's involved (I MFCed the change after all, so I'll help where I > can until I'm on holiday this week...) > > My lab colleague is just working around this with 'ping ' for > now, that keeps things up, as does OpenVPN... Your sta did a background scan. There are bugs in this area fixed in HEAD. One was that periodic calibration in the driver might kick in while off channel and setup state that was wrong for the channel where the ap was. As I said, now that the hal code is finally in RELENG_7 I'm willing to look at stuff. You or someone else can do likewise but given things have sat basically untouched since 7.0RC1 I suspect that's expecting too much. Of course if people don't test HEAD then once 8.0 goes out we'll likely have a similar situation on that branch. I do feel more confident about HEAD as that code has gone through multiple product cycles outside the tree. Sam From brucec at FreeBSD.org Mon Mar 23 14:19:20 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Mon Mar 23 14:19:26 2009 Subject: bin/128167: [patch] [libc] add support for SCTP to getaddrinfo(3) Message-ID: <200903232119.n2NLJIig044168@freefall.freebsd.org> Synopsis: [patch] [libc] add support for SCTP to getaddrinfo(3) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:18:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128167 From sam at freebsd.org Mon Mar 23 14:24:04 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Mar 23 14:24:11 2009 Subject: ath0 apparent silent disassociation In-Reply-To: <49C7FA44.8010801@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7D89A.6070502@incunabulum.net> <49C7DF8A.8070408@freebsd.org> <49C7EBD8.8010708@incunabulum.net> <49C7FA44.8010801@freebsd.org> Message-ID: <49C7FDF1.4040207@freebsd.org> Sam Leffler wrote: > You or someone else can do likewise but given things > have sat basically untouched since 7.0RC1 I suspect that's expecting too > much. Sorry, this wasn't directed at you; it was meant at the community as a whole. I don't run RELENG_7 and when I do I use a backport of the wireless code in HEAD. Folks running RELENG_7 need to pitch in and help maintain the wireless code. I'm always available to help/advise. Sam From brucec at FreeBSD.org Mon Mar 23 14:33:40 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Mon Mar 23 14:33:52 2009 Subject: kern/30186: [libc] getaddrinfo(3) does not handle incorrect servname Message-ID: <200903232133.n2NLXdKf071898@freefall.freebsd.org> Synopsis: [libc] getaddrinfo(3) does not handle incorrect servname Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:33:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=30186 From brucec at FreeBSD.org Mon Mar 23 14:34:15 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Mon Mar 23 14:34:27 2009 Subject: kern/100709: [libc] getaddrinfo(3) should return TTL info Message-ID: <200903232134.n2NLYBOh072114@freefall.freebsd.org> Synopsis: [libc] getaddrinfo(3) should return TTL info Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:33:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=100709 From brucec at FreeBSD.org Mon Mar 23 14:34:42 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Mon Mar 23 14:34:54 2009 Subject: bin/51827: [libc] [patch] getaddrinfo(3) is broken with numeric service Message-ID: <200903232134.n2NLYeSj072166@freefall.freebsd.org> Synopsis: [libc] [patch] getaddrinfo(3) is broken with numeric service Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:34:21 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=51827 From brucec at FreeBSD.org Mon Mar 23 14:36:25 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Mon Mar 23 14:36:32 2009 Subject: kern/92880: [libc] [patch] almost rewritten inet_network(3) function Message-ID: <200903232136.n2NLaOl5072266@freefall.freebsd.org> Synopsis: [libc] [patch] almost rewritten inet_network(3) function Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:35:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=92880 From brucec at FreeBSD.org Mon Mar 23 14:41:39 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Mon Mar 23 14:41:45 2009 Subject: kern/31647: [libc] socket calls can return undocumented EINVAL Message-ID: <200903232141.n2NLfc9h081962@freefall.freebsd.org> Synopsis: [libc] socket calls can return undocumented EINVAL Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:41:14 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=31647 From guru at unixarea.de Mon Mar 23 14:42:37 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Mar 23 14:42:43 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <49C7DF04.1020100@freebsd.org> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7DF04.1020100@freebsd.org> Message-ID: <20090323214207.GA6371@rebelion.Sisis.de> El d?a Monday, March 23, 2009 a las 12:12:04PM -0700, Sam Leffler escribi?: > If you have the raw pcap capture please provide a url to it. I have to capture it and will provide it; > > From the log it appears you're sending+receiving wep-encrypted frames. > They keyid is the same and since you're receiving frames I have to > assume the key matter is correct as otherwise the h/w would drop the > frame. You can verify this by feeding the key into wireshark to check > if the frame contents make sense. > > I'm out of ideas. About the only thing I can suggest is you setup a > different ap w/ the same wep key and see if things work. If so then you > know it's something this ap is doing. I can't recall when I last tested > wep on HEAD but I'm pretty sure it works. I will re-test that when I > get a chance. > > Sam WEP in general works; my AP at home is configured as WEP and the entries in wpa_supplicant.conf are nearly the same, only the key differs: # my home # network={ ssid="tarara" scan_ssid=0 key_mgmt=NONE wep_tx_keyidx=0 wep_key0=xxxxxxxxxx } # Restaurante Odyssee (2007-11-18) # network={ ssid="ConnectionPoint" scan_ssid=0 key_mgmt=NONE wep_tx_keyidx=0 wep_key0=xxxxxxxxxxxxxxxxxxxx } but I will configure another AP to also use the same wep_key0, if you think that the problem could depend on the key itself; and I will check if I could get somewhere this model of AP for a test; matthias From brucec at FreeBSD.org Mon Mar 23 14:46:18 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Mon Mar 23 14:46:25 2009 Subject: kern/124282: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value Message-ID: <200903232146.n2NLkFZI085793@freefall.freebsd.org> Synopsis: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Mon Mar 23 21:45:54 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124282 From guru at unixarea.de Mon Mar 23 14:50:05 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Mar 23 14:50:12 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903232150.n2NLo5Q9086144@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz To: Sam Leffler Cc: bug-followup@freebsd.org, freebsd-net@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Mon, 23 Mar 2009 22:42:07 +0100 El día Monday, March 23, 2009 a las 12:12:04PM -0700, Sam Leffler escribió: > If you have the raw pcap capture please provide a url to it. I have to capture it and will provide it; > > From the log it appears you're sending+receiving wep-encrypted frames. > They keyid is the same and since you're receiving frames I have to > assume the key matter is correct as otherwise the h/w would drop the > frame. You can verify this by feeding the key into wireshark to check > if the frame contents make sense. > > I'm out of ideas. About the only thing I can suggest is you setup a > different ap w/ the same wep key and see if things work. If so then you > know it's something this ap is doing. I can't recall when I last tested > wep on HEAD but I'm pretty sure it works. I will re-test that when I > get a chance. > > Sam WEP in general works; my AP at home is configured as WEP and the entries in wpa_supplicant.conf are nearly the same, only the key differs: # my home # network={ ssid="tarara" scan_ssid=0 key_mgmt=NONE wep_tx_keyidx=0 wep_key0=xxxxxxxxxx } # Restaurante Odyssee (2007-11-18) # network={ ssid="ConnectionPoint" scan_ssid=0 key_mgmt=NONE wep_tx_keyidx=0 wep_key0=xxxxxxxxxxxxxxxxxxxx } but I will configure another AP to also use the same wep_key0, if you think that the problem could depend on the key itself; and I will check if I could get somewhere this model of AP for a test; matthias From bms at FreeBSD.org Mon Mar 23 15:41:02 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Mar 23 15:41:10 2009 Subject: kern/124282: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value In-Reply-To: <200903232146.n2NLkFZI085793@freefall.freebsd.org> References: <200903232146.n2NLkFZI085793@freefall.freebsd.org> Message-ID: <49C80BE0.8060707@FreeBSD.org> brucec@FreeBSD.org wrote: > Synopsis: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: brucec > Responsible-Changed-When: Mon Mar 23 21:45:54 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > rwatson@ saw this crop up in -CURRENT and I believe he has a fix. Not sure about MFC but it clearly needs to get fixed... cheers, BMS From mdrbal at nymfe.net Mon Mar 23 16:40:05 2009 From: mdrbal at nymfe.net (Miroslav Drbal) Date: Mon Mar 23 16:40:11 2009 Subject: kern/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver Message-ID: <200903232340.n2NNe43B035541@freefall.freebsd.org> The following reply was made to PR kern/132889; it has been noted by GNATS. From: Miroslav Drbal To: bug-followup@freebsd.org, mdrbal@nymfe.net Cc: Subject: Re: kern/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver Date: Tue, 24 Mar 2009 00:38:31 +0100 Additional debug info: Unread portion of the kernel message buffer: ndis0: mem 0xf1efc000-0xf1efffff,0xf0000000-0xf00fffff irq 17 at device 0.0 on pci11 ndis0: [ITHREAD] ndis0: NDIS API version: 5.1 ndis0: NDIS ERROR: c000138d (unknown error) ndis0: init handler failed From bms at incunabulum.net Mon Mar 23 18:08:37 2009 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Mar 23 18:08:43 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work In-Reply-To: <20090323204050.GA5477@zibbi.meraka.csir.co.za> References: <20090317103650.GA6156@rebelion.Sisis.de> <49BF7DE4.4010804@incunabulum.net> <20090317104548.GB6182@rebelion.Sisis.de> <49BFF258.4020207@freebsd.org> <20090323182310.GA1825@rebelion.Sisis.de> <49C7D89A.6070502@incunabulum.net> <20090323204050.GA5477@zibbi.meraka.csir.co.za> Message-ID: <49C83291.6020603@incunabulum.net> John Hay wrote: > I found doing a -bgscan before it happens, make it not happen. I now > have -bgscan in my rc.conf. > That's exactly the workaround I needed. Thanks John. As Sam points out, the root fix is probably already in HEAD; it would be nice to find time to backport, but this works for us for now as a workaround (we are just using ath0 as a STA for testing in the lab at the moment, it is likely we will use hostap later). cheers, BMS From bms at incunabulum.net Mon Mar 23 18:10:05 2009 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Mar 23 18:10:15 2009 Subject: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Message-ID: <200903240110.n2O1A4LH055577@freefall.freebsd.org> The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce M Simpson To: John Hay Cc: Matthias Apitz , freebsd-net@freebsd.org, Sam Leffler , "Sean C. Farley" , bug-followup@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 24 Mar 2009 01:08:33 +0000 John Hay wrote: > I found doing a -bgscan before it happens, make it not happen. I now > have -bgscan in my rc.conf. > That's exactly the workaround I needed. Thanks John. As Sam points out, the root fix is probably already in HEAD; it would be nice to find time to backport, but this works for us for now as a workaround (we are just using ath0 as a STA for testing in the lab at the moment, it is likely we will use hostap later). cheers, BMS From linimon at FreeBSD.org Mon Mar 23 18:16:24 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Mar 23 18:16:35 2009 Subject: kern/132984: [netgraph] swi1: net 100% cpu usage Message-ID: <200903240116.n2O1GN0L069532@freefall.freebsd.org> Synopsis: [netgraph] swi1: net 100% cpu usage Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 24 01:16:17 UTC 2009 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=132984 From steve at ibctech.ca Mon Mar 23 22:09:41 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon Mar 23 22:09:47 2009 Subject: #netstat -rn output Message-ID: <49C86B14.1090905@ibctech.ca> Hi all, I don't know if this belongs here or not, but here it is anyway. I'm in the middle of troubleshooting why two sub-interfaces on two FreeBSD boxes (directly connected via XO cable) within a /30 can't communicate, and I found that output when doing ``netstat'' is carved at a char length for interface name. Can the Netif column be expanded via the command line? If not, could someone let me know where the format is declared, so I might have a crack at forging it a bit? (I need to see 7 chars, not 6. ie: em3.30N): pe-test-4# netstat -rn | grep 208.70.111 Destination Gateway Flags Refs Use Netif 142.46.193.0/24 208.70.111.66 UG1 0 95133 em6 172.16.104.2 208.70.111.66 UGH1 0 16184 em6 172.16.104.3 208.70.111.54 UGH1 0 11745 em3.30 172.16.104.99 208.70.111.62 UGH1 0 1171 em1.99 208.70.107.0/25 208.70.111.54 UG1 0 28066384 em3.30 Steve From bz at FreeBSD.org Tue Mar 24 00:13:31 2009 From: bz at FreeBSD.org (bz@FreeBSD.org) Date: Tue Mar 24 00:13:38 2009 Subject: kern/124282: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value Message-ID: <200903240713.n2O7DUbp064173@freefall.freebsd.org> Synopsis: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: bz Responsible-Changed-When: Tue Mar 24 07:12:57 UTC 2009 Responsible-Changed-Why: Robert has fixed this in HEAD already. http://www.freebsd.org/cgi/query-pr.cgi?pr=124282 From qing.li at bluecoat.com Tue Mar 24 00:21:08 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Tue Mar 24 00:21:17 2009 Subject: Problems with inward PPTP tunnel In-Reply-To: <87153F88702C4FBCA3FC799082960C45@adnote989> References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> Message-ID: Hi, I read over your patch and I don't think you need to change the definition of rt_Update() to fix this bug. Have you read my patch committed to head/user.sbin/ppp/route.c on 12/18/2008? svn r186308, cvs r1.96. Please take a look. Thanks, -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Luiz Otavio O Souza > Sent: Monday, March 23, 2009 4:07 AM > To: net@freebsd.org; Brett Glass > Subject: Re: Problems with inward PPTP tunnel > > > Just a quick followup: I've finally figured out a workaround. A hack, > to > > be sure, but a workaround nonetheless. > > > > I've created a shell script called /etc/ppp/pppfix, which looks like > this: > > > > #!/bin/sh > > # Fix up PPP routes > > sleep 1; > > logger -i -t ppp Fixing route: route change -host $1 $2 -ifp $3 > > route change -host $1 $2 -ifp $3 > > > > I invoke this from the relevant section of /etc/ppp.linkup with the > line > > > > !bg /etc/ppp/pppfix HISADDR MYADDR INTERFACE > > > > Note that the "sleep" may not be absolutely necessary, but it seems > like a > > good idea just in case there's a race condition. > > > > I also added the following lines in the relevant section of > ppp.linkdown: > > > > iface clear > > delete! HISADDR > > delete! ALL > > shell arp -d HISADDR > > quit all > > > > I found that if I did not do this, the modified route persisted after > the > > connection terminated. The "arp -d HISADDR" should only be used if > proxy > > arp is being done, and may not be strictly necessary; I wanted to > make > > sure I tore down any residual proxy arp entry. > > > > Of course, all of this is an awful hack and the relevant code in > userland > > PPP still needs to be looked at. > > > > --Brett Glass > > Brett, > > I've fixed these two issues with ppp(8), please check the PRs: > bin/130159 > and bin/131250. > > If it works for you please let a note and maybe someone commit this. > > Best regards, > Luiz > > _______________________________________________ > 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 Tue Mar 24 01:53:29 2009 From: max at love2party.net (Max Laier) Date: Tue Mar 24 01:53:44 2009 Subject: #netstat -rn output In-Reply-To: <49C86B14.1090905@ibctech.ca> References: <49C86B14.1090905@ibctech.ca> Message-ID: <200903240953.25453.max@love2party.net> On Tuesday 24 March 2009 06:09:40 Steve Bertrand wrote: > Hi all, > > I don't know if this belongs here or not, but here it is anyway. > > I'm in the middle of troubleshooting why two sub-interfaces on two > FreeBSD boxes (directly connected via XO cable) within a /30 can't > communicate, and I found that output when doing ``netstat'' is carved at > a char length for interface name. > > Can the Netif column be expanded via the command line? If not, could > someone let me know where the format is declared, so I might have a > crack at forging it a bit? (I need to see 7 chars, not 6. ie: em3.30N): -W is your friend. See also netstat(1) > pe-test-4# netstat -rn | grep 208.70.111 > Destination Gateway Flags Refs Use Netif > 142.46.193.0/24 208.70.111.66 UG1 0 95133 em6 > 172.16.104.2 208.70.111.66 UGH1 0 16184 em6 > 172.16.104.3 208.70.111.54 UGH1 0 11745 em3.30 > 172.16.104.99 208.70.111.62 UGH1 0 1171 em1.99 > 208.70.107.0/25 208.70.111.54 UG1 0 28066384 em3.30 -- /"\ 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 andrey.kropachev at gmail.com Tue Mar 24 01:56:52 2009 From: andrey.kropachev at gmail.com (Andrey Kropachev) Date: Tue Mar 24 01:56:58 2009 Subject: dummynet and smp Message-ID: <776ee5610903240136q78af39ddj6924bd479725c26e@mail.gmail.com> Hi all, Is there an opportunity to scale dummynet on a number of cpu's? Currently my router processes about 200Mbit/s and around 50kpps. The dummynet takes about 80% of one processor. So, can dummynet be scaled, or can i somehow decrease the cpu usage of dummynet? Regards, Andrey Kropachev From lists.br at gmail.com Tue Mar 24 04:31:50 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Tue Mar 24 04:33:51 2009 Subject: Problems with inward PPTP tunnel References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> Message-ID: <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> > Hi, > > I read over your patch and I don't think you need to > change the definition of rt_Update() to fix this bug. > > Have you read my patch committed to head/user.sbin/ppp/route.c > on 12/18/2008? svn r186308, cvs r1.96. > > Please take a look. > > Thanks, > > -- Qing Hi Qing, Yes i've read your patch, but i don't understand what you are meaning... and yes, changing the definition of rt_Update is not my first intention, but it is the way i've found to fix this. Backing to the patch... The rt_Update need the ifp and ifa information to correctly update the route, and this is available only in route_UpdateMTU (wich read the current route table). You are suggesting that this information could be found at sa[RTAX_GATEWAY] (if sa[RTAX_GATEWAY]->sa_family == AF_LINK) ? And i don't need to pass the sa[RTAX_IFP] and sa[RTAX_IFA] ? Well, i really don't remember, but i'll check and post an update later. Thanks, Luiz From steve at ibctech.ca Tue Mar 24 05:17:41 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Mar 24 05:17:48 2009 Subject: #netstat -rn output In-Reply-To: <200903240953.25453.max@love2party.net> References: <49C86B14.1090905@ibctech.ca> <200903240953.25453.max@love2party.net> Message-ID: <49C8CF63.9030205@ibctech.ca> Max Laier wrote: > On Tuesday 24 March 2009 06:09:40 Steve Bertrand wrote: >> Can the Netif column be expanded via the command line? > -W is your friend. See also netstat(1) It most certainly is... thanks :) Steve From sepron at gmail.com Tue Mar 24 05:33:27 2009 From: sepron at gmail.com (Sergey Pronin) Date: Tue Mar 24 05:33:34 2009 Subject: dummynet and smp Message-ID: Very strange. I have freebsd 7.0-RELEASE-p10 with dummynet in use and about 700 Mbit/s traffic passing through. dummynet process CPU usage is 0% to 10%. Let me see your ipfw rules. What FreeBSD version do you have? What about swi: net and taskq (irq) processes? Hardware configuration? From mav at FreeBSD.org Tue Mar 24 07:14:37 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Mar 24 07:14:43 2009 Subject: dummynet and smp In-Reply-To: <1237897382.00091371.1237885201@10.7.7.3> References: <1237897382.00091371.1237885201@10.7.7.3> Message-ID: <49C8DCB9.5040406@FreeBSD.org> Andrey Kropachev wrote: > Is there an opportunity to scale dummynet on a number of cpu's? Currently my > router processes about 200Mbit/s and around 50kpps. The dummynet takes about > 80% of one processor. So, can dummynet be scaled, or can i somehow decrease > the cpu usage of dummynet? Dummynet itself quite effective. The 80% you see is probably some other routines called after packets leaving dummynet. So you should try to optimize other things as much as possible. 200Mbit/s and 50kpps is a quite moderate traffic now. Dummynet queue handler is really single-threaded, so the only thing you can do is to enable new dummynet feature, that allows to bypass delay when queue is not congested. -- Alexander Motin From andrey.kropachev at gmail.com Tue Mar 24 07:21:20 2009 From: andrey.kropachev at gmail.com (Andrey Kropachev) Date: Tue Mar 24 07:21:28 2009 Subject: dummynet and smp In-Reply-To: References: Message-ID: <49C90EEC.5030703@gmail.com> > Very strange. > I have freebsd 7.0-RELEASE-p10 with dummynet in use and about 700 Mbit/s > traffic passing through. dummynet process CPU usage is 0% to 10%. > Let me see your ipfw rules. > What FreeBSD version do you have? > What about swi: net and taskq (irq) processes? > Hardware configuration? > ipfw rules: 00010 68893 4016154 allow tcp from any to me dst-port 22 00020 74773 24184400 allow tcp from me 22 to any 00030 0 0 allow ip from 10.0.1.0/28 to me 00040 59053707 88088134092 allow ip from me to 10.0.1.0/28 00500 172527273 8241845066 allow ip from table(111) to any 00510 6826373984 4635126371384 skipto 10000 ip from any to table(111) 01000 6155688044 1067046574713 pipe tablearg ip from table(17) to any in via bge1 01010 0 0 ngtee 21 ip from table(23) to any in via bge1 01020 6095478668 1046703088138 ngtee 31 ip from table(24) to any in via bge1 01030 20156002 8768866847 ngtee 41 ip from table(30) to any in via bge1 15000 12300189888 2098823866830 nat tablearg ip from table(24) to any 15010 0 0 nat tablearg ip from table(23) to any 15020 40322035 17538211139 nat tablearg ip from table(30) to any 15030 6826373494 4635126305893 nat tablearg ip from any to table(111) 15040 6498744726 4605209022143 pipe tablearg ip from any to table(18) out via bge0 15050 0 0 ngtee 21 ip from any to table(23) out via bge0 15060 6391831428 4515717639848 ngtee 31 ip from any to table(24) out via bge0 15070 12348264 7632683598 ngtee 41 ip from any to table(30) out via bge0 65000 25551327312 11269101015139 allow ip from any to any 65535 79 17383 deny ip from any to any My router configuration: FreeBSD nat3 7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Mar 17 16:09:20 MSK 2009 root@nat3:/usr/src/sys/amd64/compile/nat3 amd64 2 x CPU: Intel(R) Xeon(R) CPU X5472 @ 3.00GHz (2992.51-MHz K8-class CPU) 2 gigabit bge pci-e cards. polling is disabled. kern.hz=1000 top -SH 81 processes: 7 running, 58 sleeping, 16 waiting CPU: 0.8% user, 0.0% nice, 13.0% system, 11.4% interrupt, 74.8% idle Mem: 31M Active, 1320M Inact, 529M Wired, 43M Cache, 63M Buf, 55M Free Swap: 4062M Total, 4062M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 13 root 171 ki31 0K 16K RUN 1 134.9H 100.00% idle: cpu1 11 root 171 ki31 0K 16K CPU3 3 120.6H 96.39% idle: cpu3 14 root 171 ki31 0K 16K RUN 0 107.1H 71.09% idle: cpu0 12 root 171 ki31 0K 16K CPU2 2 119.7H 65.28% idle: cpu2 42 root -68 - 0K 16K - 2 45.8H 46.09% dummynet 25 root -68 - 0K 16K CPU0 0 35.8H 35.69% irq256: bge0 26 root -68 - 0K 16K WAIT 1 383:21 4.88% irq257: bge1 16 root -32 - 0K 16K WAIT 1 153:17 1.17% swi4: clock sio Regards, Andrey Kropachev From gavin at FreeBSD.org Tue Mar 24 08:07:12 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue Mar 24 08:07:25 2009 Subject: kern/114714: [gre] [patch] gre(4) is not MPSAFE and does not support keys Message-ID: <200903241507.n2OF7BrC032999@freefall.freebsd.org> Synopsis: [gre] [patch] gre(4) is not MPSAFE and does not support keys State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Tue Mar 24 15:06:19 UTC 2009 State-Changed-Why: Patch in PR was committed and MFC'd in mid 2008 Responsible-Changed-From-To: freebsd-net->thompsa Responsible-Changed-By: gavin Responsible-Changed-When: Tue Mar 24 15:06:19 UTC 2009 Responsible-Changed-Why: thompsa@ committed this http://www.freebsd.org/cgi/query-pr.cgi?pr=114714 From brett at lariat.net Tue Mar 24 09:02:13 2009 From: brett at lariat.net (Brett Glass) Date: Tue Mar 24 09:02:19 2009 Subject: Problems with inward PPTP tunnel In-Reply-To: <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> Message-ID: <200903241602.KAA20824@lariat.net> At 05:31 AM 3/24/2009, Luiz Otavio O Souza wrote: >>Hi, >> >>I read over your patch and I don't think you need to >>change the definition of rt_Update() to fix this bug. >> >>Have you read my patch committed to head/user.sbin/ppp/route.c >>on 12/18/2008? svn r186308, cvs r1.96. >> >>Please take a look. >> >>Thanks, >> >>-- Qing > >Hi Qing, > >Yes i've read your patch, but i don't understand what you are >meaning... and yes, changing the definition of rt_Update is not my >first intention, but it is the way i've found to fix this. > >Backing to the patch... The rt_Update need the ifp and ifa >information to correctly update the route, and this is available >only in route_UpdateMTU (wich read the current route table). > >You are suggesting that this information could be found at >sa[RTAX_GATEWAY] (if sa[RTAX_GATEWAY]->sa_family == AF_LINK) ? And >i don't need to pass the sa[RTAX_IFP] and sa[RTAX_IFA] ? > >Well, i really don't remember, but i'll check and post an update later. > >Thanks, >Luiz I personally think that, from a style perspective, changing the definition of rt_Update is good. I was thinking of doing it myself when I was inspecting the code and trying to figure out how to ensure that the interface was specified in the routing table entry. Adding the additional arguments makes the routine more flexible and makes the intent of calls to it more explicit. That being said, any change that fixes the bug is welcome. (The code that shipped with 7.1-RELEASE will break many if not most systems that rely on userland PPP to implement a server.) I might consider using mpd instead, but it would be a big implementation change and mpd lacks a few capabilities that I really need. --Brett Glass From brooks at freebsd.org Tue Mar 24 09:33:31 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Mar 24 09:33:38 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <25ff90d60903181033n5d3f0a79w7a8ea504f911ecf@mail.gmail.com> References: <25ff90d60903180904ud077fcdy344cda5307a9037e@mail.gmail.com> <200903181626.n2IGQgqt054487@lurza.secnetix.de> <25ff90d60903181033n5d3f0a79w7a8ea504f911ecf@mail.gmail.com> Message-ID: <20090324155746.GC5281@lor.one-eyed-alien.net> On Wed, Mar 18, 2009 at 01:33:06PM -0400, David Horn wrote: > On Wed, Mar 18, 2009 at 12:26 PM, Oliver Fromme wrote: > > David Horn wrote: > > ?> Oliver Fromme wrote: > > ?> > > > ?> > ?network_interfaces="bge0 lo0" > > ?> > > ?> Ah. ?Ok, now I am understanding your scenario. > > ?> > > ?> I thought that using 'network_interfaces' with anything other than > > ?> "AUTO" ?was in the process of being depreciated ? > > > > Well, the manual page says so, but I think that is a > > mistake. ?There are cases where you have to specify the > > list of interfaces explicitly. ?The situation described > > in this thread is one such case. > > Good point. > > > > > My opinion is that it is good to have the ability to let > > things be done automatically, but it is bad to remove the > > ability to do things manually. ?This is UNIX, after all. > > Exactly. Both scenarios should probably be supported, but I guess we > would need to ask brooks for some history on the depreciated warning > for network_interfaces. I think network_interfaces and the autoloading support in ifconfig are a massive mistake that we've been unable to kill. The relativly large amount of code you've written to hack around yet another edge case proves my point. :) If you want to load if_iwn at boot just do: echo 'if_iwn_load="YES"' >> /boot/loader.conf and be done with it. -- Brooks > ================================================= > src/etc/network.subr > Revision 1.185: download - view: text, markup, annotated - [selected for diffs] > Wed Apr 30 16:29:15 2008 UTC (10 months, 2 weeks ago) by brooks > Branches: MAIN > Diff to: previous 1.184: preferred, colored > Changes since revision 1.184: +4 -0 lines > > Emit a warning when the network_interfaces variable is not set to AUTO. > > MFC after: 3 days > ================================================== > > --Thanks! > > -_Dave H > > > > > Best regards > > ? Oliver > > > > -- > > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > > Handelsregister: Registergericht Muenchen, HRA 74606, ?Gesch?ftsfuehrung: > > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > > chen, HRB 125758, ?Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > > > FreeBSD-Dienstleistungen, -Produkte und mehr: ?http://www.secnetix.de/bsd > > > > "The ITU has offered the IETF formal alignment with its > > corresponding technology, Penguins, but that won't fly." > > ? ? ? ?-- RFC 2549 > > > _______________________________________________ > 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" > -------------- 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/20090324/b03802a0/attachment.pgp From dfilter at FreeBSD.ORG Tue Mar 24 10:50:06 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Mar 24 10:50:13 2009 Subject: bin/51827: commit references a PR Message-ID: <200903241750.n2OHo5g5052996@freefall.freebsd.org> The following reply was made to PR bin/51827; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/51827: commit references a PR Date: Tue, 24 Mar 2009 17:47:37 +0000 (UTC) Author: ume Date: Tue Mar 24 17:47:24 2009 New Revision: 190382 URL: http://svn.freebsd.org/changeset/base/190382 Log: getaddrinfo(3) should accept numeric when ai_socktype is not specified in hint or hints is NULL. PR: bin/51827 Submitted by: Mark Andrews MFC after: 1 week Modified: head/lib/libc/net/getaddrinfo.c Modified: head/lib/libc/net/getaddrinfo.c ============================================================================== --- head/lib/libc/net/getaddrinfo.c Tue Mar 24 17:22:10 2009 (r190381) +++ head/lib/libc/net/getaddrinfo.c Tue Mar 24 17:47:24 2009 (r190382) @@ -1347,7 +1347,17 @@ get_port(struct addrinfo *ai, const char allownumeric = 1; break; case ANY: - allownumeric = 0; + switch (ai->ai_family) { + case AF_INET: +#ifdef AF_INET6 + case AF_INET6: +#endif + allownumeric = 1; + break; + default: + allownumeric = 0; + break; + } break; default: return EAI_SOCKTYPE; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From ume at FreeBSD.org Tue Mar 24 10:53:24 2009 From: ume at FreeBSD.org (ume@FreeBSD.org) Date: Tue Mar 24 10:53:30 2009 Subject: bin/51827: [libc] [patch] getaddrinfo(3) is broken with numeric service Message-ID: <200903241753.n2OHrLB8065733@freefall.freebsd.org> Synopsis: [libc] [patch] getaddrinfo(3) is broken with numeric service State-Changed-From-To: open->patched State-Changed-By: ume State-Changed-When: Tue Mar 24 17:51:47 UTC 2009 State-Changed-Why: Thank you! I've just committed it into HEAD. I'll MFC it after 1 week. Responsible-Changed-From-To: freebsd-net->ume Responsible-Changed-By: ume Responsible-Changed-When: Tue Mar 24 17:51:47 UTC 2009 Responsible-Changed-Why: Thank you! I've just committed it into HEAD. I'll MFC it after 1 week. http://www.freebsd.org/cgi/query-pr.cgi?pr=51827 From qing.li at bluecoat.com Tue Mar 24 13:01:27 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Tue Mar 24 13:01:34 2009 Subject: Problems with inward PPTP tunnel In-Reply-To: <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> Message-ID: > > Yes i've read your patch, but i don't understand what you are meaning... > and yes, changing the definition of rt_Update is not my first intention, > but it is the way i've found to fix this. > > Backing to the patch... The rt_Update need the ifp and ifa information > to correctly update the route, and this is available only in > route_UpdateMTU (wich read the current route table). > > You are suggesting that this information could be found at > sa[RTAX_GATEWAY] (if sa[RTAX_GATEWAY]->sa_family == AF_LINK) ? And i > don't need to pass the sa[RTAX_IFP] and sa[RTAX_IFA] ? > Yes. The concept should be similar to the handling code for route insertion where one does, e.g.: route add -net a.b.c.d/24 -iface em0 Joe Marcus verified my patch in his environment. My suggestion is for you to try it out and see if that patch also fixes whatever problem that you are running into. Thanks, -- Qing From brett at lariat.net Tue Mar 24 14:38:42 2009 From: brett at lariat.net (Brett Glass) Date: Tue Mar 24 14:38:50 2009 Subject: Problems with inward PPTP tunnel In-Reply-To: <0DC74661A0F84C5EA642A274E0CEF595@adnote989> References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> <0DC74661A0F84C5EA642A274E0CEF595@adnote989> Message-ID: <200903242138.PAA27632@lariat.net> >Qing, > >Sorry, but your patch doesn't fix the issue, everytime the >route_UpdateMTU* is called the route is set to the ethernet >interface using the gateway address instead of the correct tun interface. > >The patch in PR works exactly in that situation as confirmed by Brett. > >Thanks, >Luiz > >* This will happen every time you provide ppp over ethernet (pppoe, vpns) Qing: I can confirm that Luiz' patch does work. I applied it and was able to disable my workaround. The only thing I would change is that I would turn off the "gateway" flag (RTF_GATEWAY) in the routing table entry. (You suggested this, implicitly, when you mentioned using the -iface flag.) This is because the "tun" interface is really a bridge, not a gateway. --Brett Glass From lists.br at gmail.com Tue Mar 24 14:25:14 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Tue Mar 24 14:51:03 2009 Subject: Problems with inward PPTP tunnel References: <200903222114.PAA17884@lariat.net> <87153F88702C4FBCA3FC799082960C45@adnote989> <5E03C21CD6544D23B4E4A61E85C7E2C8@adnote989> Message-ID: <0DC74661A0F84C5EA642A274E0CEF595@adnote989> >> >> Yes i've read your patch, but i don't understand what you are meaning... >> and yes, changing the definition of rt_Update is not my first intention, >> but it is the way i've found to fix this. >> >> Backing to the patch... The rt_Update need the ifp and ifa information >> to correctly update the route, and this is available only in >> route_UpdateMTU (wich read the current route table). >> >> You are suggesting that this information could be found at >> sa[RTAX_GATEWAY] (if sa[RTAX_GATEWAY]->sa_family == AF_LINK) ? And i >> don't need to pass the sa[RTAX_IFP] and sa[RTAX_IFA] ? >> > > Yes. The concept should be similar to the handling code for route > insertion > where one does, e.g.: > > route add -net a.b.c.d/24 -iface em0 > > Joe Marcus verified my patch in his environment. My suggestion is for > you > to try it out and see if that patch also fixes whatever problem that you > are > running into. > Qing, Sorry, but your patch doesn't fix the issue, everytime the route_UpdateMTU* is called the route is set to the ethernet interface using the gateway address instead of the correct tun interface. The patch in PR works exactly in that situation as confirmed by Brett. Thanks, Luiz * This will happen every time you provide ppp over ethernet (pppoe, vpns) From chris at young-alumni.com Tue Mar 24 18:43:02 2009 From: chris at young-alumni.com (Chris Ruiz) Date: Tue Mar 24 18:43:09 2009 Subject: NDIS - True OR False Message-ID: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> True OR False 1) NDIS only works with XP drivers. 2) NDIS only works with 32-bit drivers and wont work on amd64. There is a lot of conflicting information on various lists, forums and websites regarding NDIS. Thanks, Chris From wollman at hergotha.csail.mit.edu Tue Mar 24 19:22:10 2009 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Tue Mar 24 19:22:16 2009 Subject: NDIS - True OR False In-Reply-To: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> Message-ID: <200903250159.n2P1xMti096589@hergotha.csail.mit.edu> In article <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com>, "Chris" writes: >True OR False > >1) NDIS only works with XP drivers. Can't answer that as I've never needed to try a Vista driver. >2) NDIS only works with 32-bit drivers and wont work on amd64. False, unless someone has broken it recently. Project Evil has worked on 64-bit systems (and *requires* 64-bit drivers on such systems) since I bought my current laptop ~three years ago. -GAWollman From weongyo.jeong at gmail.com Tue Mar 24 23:00:33 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Tue Mar 24 23:00:39 2009 Subject: NDIS - True OR False In-Reply-To: <200903250159.n2P1xMti096589@hergotha.csail.mit.edu> References: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> <200903250159.n2P1xMti096589@hergotha.csail.mit.edu> Message-ID: <20090325054021.GA9518@weongyo.cdnetworks.kr> On Tue, Mar 24, 2009 at 09:59:22PM -0400, Garrett Wollman wrote: > In article <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com>, > "Chris" writes: > > >True OR False > > > >1) NDIS only works with XP drivers. > > Can't answer that as I've never needed to try a Vista driver. AFAIK NDISulator try to mimic that it works on Windows XP and the driver depends on the version of NDIS driver that normally it's 5.0 or 5.1. I know Vista driver uses NDIS 6.x that isn't supported by NDISulator. > >2) NDIS only works with 32-bit drivers and wont work on amd64. > > False, unless someone has broken it recently. Project Evil has worked > on 64-bit systems (and *requires* 64-bit drivers on such systems) > since I bought my current laptop ~three years ago. Yes it should work on amd64. If not it's a regression. regards, Weongyo Jeong From sepron at gmail.com Wed Mar 25 02:23:17 2009 From: sepron at gmail.com (Sergey Pronin) Date: Wed Mar 25 02:23:28 2009 Subject: Synopsis: process swi1:net gives 100% CPU usage. Message-ID: This topic is also related to: http://lists.freebsd.org/pipermail/freebsd-net/2009-March/021345.html > And I have the 4th server with the same hardware and software configuration > but with FreeBSD 7.1-RELEASE-p1. Everything works fine. I've experienced the same problems with: FreeBSD 7.1-RELEASE-p1 and p2 FreeBSD 7.0-RELEASE-p9 and p10 FreeBSD 6.4-RELEASE-p3 Report about this problem with FreeBSD 7.1-STABLE http://www.freebsd.org/cgi/query-pr.cgi?pr=132984 From brucec at FreeBSD.org Wed Mar 25 05:27:14 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 05:27:21 2009 Subject: kern/129197: [panic] 7.0 IP stack related panic Message-ID: <200903251227.n2PCREnf007152@freefall.freebsd.org> Synopsis: [panic] 7.0 IP stack related panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 12:26:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129197 From brucec at FreeBSD.org Wed Mar 25 05:31:51 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 05:31:58 2009 Subject: kern/132991: [bge] if_bge low performance problem Message-ID: <200903251231.n2PCVoZg014197@freefall.freebsd.org> Synopsis: [bge] if_bge low performance problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 12:31:28 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132991 From brucec at FreeBSD.org Wed Mar 25 05:34:09 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 05:34:21 2009 Subject: kern/85780: 'panic: bogus refcnt 0' in routing/ipv6 Message-ID: <200903251234.n2PCY8eK022115@freefall.freebsd.org> Synopsis: 'panic: bogus refcnt 0' in routing/ipv6 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 12:33:50 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=85780 From aman.jassal at esigetel.fr Wed Mar 25 05:45:52 2009 From: aman.jassal at esigetel.fr (Aman Jassal) Date: Wed Mar 25 05:45:59 2009 Subject: NDIS - True OR False In-Reply-To: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> References: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> Message-ID: Hello Chris, 1) >From my personal experience, NDIS doesn't work well with Vista drivers, but I was working with Wifi USB dongles (and it was about 5 months ago). I had tried to make a NDIS driver for a Netgear WG111v2 Wifi USB dongle, using the Vista driver provided by Netgear, but it just never worked. However I also had a Netgear WG111v2 Wifi USB dongle, but I had the XP driver for it, and NDIS managed to produce a module that could support my dongle on a FreeBSD 7.0 box. Now the thing is, I have been working on that about 5 or 6 months ago, perhaps now the people from Project Evil have done some work to support Vista drivers. I was working with Wifi USB dongles, and I knew that NDIS does struggle to make modules to support such devices. 2) As said previously, NDIS should work with drivers for AMD-64. But then again, I haven't worked with AMD-64 myself, so I can't provide strong support T_T If you are looking to use FreeBSD with wireless cards or devices, I would suggest you take a look at the various drivers included in FreeBSD : an ; ath ; awi ; ipw ; iwi ; netintro ; ral ; rum ; ural ; wi ; wlan_ccmp ; wlan_tkip ; wlan_wep ; wlan_wauth ; zyd. Have a look at the man-pages of these drivers, the various devices and chipsets supported are mentionned, that way you can use a wireless card without having the trouble to use Ndis to make a kernel module to support your device. Just in case... Hope you find it useful. Good luck Aman Jassal ----- Original Message ----- From: "Chris Ruiz" To: Sent: Wednesday, March 25, 2009 2:21 AM Subject: NDIS - True OR False > > True OR False > > 1) NDIS only works with XP drivers. > > 2) NDIS only works with 32-bit drivers and wont work on amd64. > > There is a lot of conflicting information on various lists, forums and > websites regarding NDIS. > > Thanks, > > Chris > _______________________________________________ > 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 adamk at voicenet.com Wed Mar 25 07:06:47 2009 From: adamk at voicenet.com (adamk@voicenet.com) Date: Wed Mar 25 07:07:24 2009 Subject: NDIS - True OR False In-Reply-To: References: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> Message-ID: <59696.67.102.187.39.1237988404.squirrel@webmail.voicenet.com> > > If you are looking to use FreeBSD with wireless cards or devices, I would > suggest you take a look at the various drivers included in FreeBSD : an ; > ath ; awi ; ipw ; iwi ; netintro ; ral ; rum ; ural ; wi ; wlan_ccmp ; > wlan_tkip ; wlan_wep ; wlan_wauth ; zyd. Have a look at the man-pages of > these drivers, the various devices and chipsets supported are mentionned, > that way you can use a wireless card without having the trouble to use Ndis > to make a kernel module to support your device. Just in case... For what it's worth, I've actually had more luck with ndis with my 2200BG than I had with the iwi driver: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/131153 Adam From onemda at gmail.com Wed Mar 25 08:31:20 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Mar 25 08:31:27 2009 Subject: NDIS - True OR False In-Reply-To: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> References: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> Message-ID: <3a142e750903250805q524d06aavc41070627cc17d20@mail.gmail.com> On 3/25/09, Chris Ruiz wrote: > > True OR False > > 1) NDIS only works with XP drivers. > > 2) NDIS only works with 32-bit drivers and wont work on amd64. > > There is a lot of conflicting information on various lists, forums and > websites regarding NDIS. http://en.wikipedia.org/wiki/NDIS -- Paul From ume at FreeBSD.org Wed Mar 25 09:29:02 2009 From: ume at FreeBSD.org (ume@FreeBSD.org) Date: Wed Mar 25 09:29:09 2009 Subject: bin/128167: [patch] [libc] add support for SCTP to getaddrinfo(3) Message-ID: <200903251629.n2PGT13n035039@freefall.freebsd.org> Synopsis: [patch] [libc] add support for SCTP to getaddrinfo(3) State-Changed-From-To: open->patched State-Changed-By: ume State-Changed-When: Wed Mar 25 16:27:38 UTC 2009 State-Changed-Why: Thank you! Committed it with modification. At least Apache didn't work with getaddrinfo(3) which your patch is applied. Responsible-Changed-From-To: freebsd-net->ume Responsible-Changed-By: ume Responsible-Changed-When: Wed Mar 25 16:27:38 UTC 2009 Responsible-Changed-Why: Thank you! Committed it with modification. At least Apache didn't work with getaddrinfo(3) which your patch is applied. http://www.freebsd.org/cgi/query-pr.cgi?pr=128167 From brucec at FreeBSD.org Wed Mar 25 10:01:59 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 10:02:05 2009 Subject: bin/121895: [patch] rtsol(8)/rtsold(8) doesn't handle managed networks Message-ID: <200903251701.n2PH1ueF088933@freefall.freebsd.org> Synopsis: [patch] rtsol(8)/rtsold(8) doesn't handle managed networks Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 17:01:29 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121895 From brucec at FreeBSD.org Wed Mar 25 10:04:11 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 10:04:22 2009 Subject: bin/92370: [pppd] ppp server not accessible to IPV4 unless built with NO_INET6 Message-ID: <200903251704.n2PH48qW089657@freefall.freebsd.org> Synopsis: [pppd] ppp server not accessible to IPV4 unless built with NO_INET6 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 17:03:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=92370 From brucec at FreeBSD.org Wed Mar 25 10:05:25 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 10:05:32 2009 Subject: bin/81465: /bin/host: resolver is not working properly when INET6 is not in kernel and nameserver is dual Message-ID: <200903251705.n2PH5N8D089719@freefall.freebsd.org> Synopsis: /bin/host: resolver is not working properly when INET6 is not in kernel and nameserver is dual Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 17:05:02 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=81465 From brucec at FreeBSD.org Wed Mar 25 10:15:28 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Wed Mar 25 10:15:34 2009 Subject: bin/121359: [patch] ppp(8): fix local stack overflow in ppp Message-ID: <200903251715.n2PHFP2x004319@freefall.freebsd.org> Synopsis: [patch] ppp(8): fix local stack overflow in ppp Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Mar 25 17:15:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121359 From dougb at FreeBSD.org Wed Mar 25 11:26:54 2009 From: dougb at FreeBSD.org (dougb@FreeBSD.org) Date: Wed Mar 25 11:27:01 2009 Subject: bin/81465: /bin/host: resolver is not working properly when INET6 is not in kernel and nameserver is dual Message-ID: <200903251826.n2PIQrvI000179@freefall.freebsd.org> Synopsis: /bin/host: resolver is not working properly when INET6 is not in kernel and nameserver is dual State-Changed-From-To: open->closed State-Changed-By: dougb State-Changed-When: Wed Mar 25 18:25:36 UTC 2009 State-Changed-Why: FreeBSD 4 is well past End of Life, and this bug should no longer be present in modern versions of BIND, or the OS. If you are still experiencing this issue with FreeBSD 6 or newer please feel free to file a new PR. Regards, Doug Responsible-Changed-From-To: freebsd-net->dougb Responsible-Changed-By: dougb Responsible-Changed-When: Wed Mar 25 18:25:36 UTC 2009 Responsible-Changed-Why: host(1) is part of BIND http://www.freebsd.org/cgi/query-pr.cgi?pr=81465 From pierre at userid.org Wed Mar 25 15:20:11 2009 From: pierre at userid.org (Pierre Lamy) Date: Wed Mar 25 15:20:18 2009 Subject: FreeBSD Router Problem In-Reply-To: <200902262341.35069.shawn@tandac.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> Message-ID: <49CAB28A.9030406@userid.org> tcp.established 86400s ^^ This should be 3600. Pierre Shawn Everett wrote: >> Any error messages in dmesg output ? >> Significant changes in "netstat -m" output before and after ? >> The same for "pfctl -s all" output... >> > > The box has been up for about 12 hours now. As a point of discussion here > is the output from netstat and pfctl in case anything obvious jumps out. > > 385/905/1290 mbufs in use (current/cache/total) > 384/484/868/25600 mbuf clusters in use (current/cache/total/max) > 256/384 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/44/44/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 864K/1370K/2234K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/5/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > > # pfctl -s all > No ALTQ support in kernel > ALTQ related functions disabled > TRANSLATION RULES: > nat on ste0 inet from 172.16.3.0/24 to any -> (ste0) round-robin > nat on ste1 inet from 172.16.3.0/24 to any -> (ste1) round-robin > > FILTER RULES: > pass out on em0 inet from any to 172.16.3.0/24 flags S/SA keep state > pass in quick on em0 inet from 172.16.3.0/24 to 172.16.3.253 flags S/SA > keep state > pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } > round-robin inet proto tcp from 172.16.3.0/24 to any flags S/SA modulate > state > pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } > round-robin inet proto udp from 172.16.3.0/24 to any keep state > pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } > round-robin inet proto icmp from 172.16.3.0/24 to any keep state > pass out on ste0 proto tcp all flags S/SA modulate state > pass out on ste0 proto udp all keep state > pass out on ste0 proto icmp all keep state > pass out on ste1 proto tcp all flags S/SA modulate state > pass out on ste1 proto udp all keep state > pass out on ste1 proto icmp all keep state > pass out on ste0 route-to (ste1 204.244.159.254) inet from 204.244.159.55 > to any flags S/SA keep state > pass out on ste1 route-to (ste0 204.244.159.254) inet from 204.244.159.68 > to any flags S/SA keep state > > STATES: > all udp 172.16.3.255:137 <- 172.16.3.17:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.17:137 -> 204.244.159.68:57827 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.71:3064 CLOSED:SYN_SENT > all tcp 172.16.3.71:3064 -> 204.244.159.55:56563 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.30:2021 CLOSED:SYN_SENT > all tcp 172.16.3.30:2021 -> 204.244.159.68:54557 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.72:1414 CLOSED:SYN_SENT > all tcp 172.16.3.72:1414 -> 204.244.159.55:52567 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.31:2865 CLOSED:SYN_SENT > all tcp 172.16.3.31:2865 -> 204.244.159.68:59429 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.72:1415 CLOSED:SYN_SENT > all tcp 172.16.3.72:1415 -> 204.244.159.55:61425 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.49:1914 CLOSED:SYN_SENT > all tcp 172.16.3.49:1914 -> 204.244.159.68:58532 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:138 <- 172.16.3.39:138 NO_TRAFFIC:SINGLE > all udp 172.16.3.39:138 -> 204.244.159.68:62224 -> 172.16.3.255:138 > SINGLE:NO_TRAFFIC > all tcp 64.56.145.72:110 <- 172.16.3.48:1494 FIN_WAIT_2:FIN_WAIT_2 > all tcp 172.16.3.48:1494 -> 204.244.159.55:62928 -> 64.56.145.72:110 > FIN_WAIT_2:FIN_WAIT_2 > all udp 172.16.3.255:137 <- 172.16.3.49:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.49:137 -> 204.244.159.55:61053 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.37:1508 CLOSED:SYN_SENT > all tcp 172.16.3.37:1508 -> 204.244.159.68:54656 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.74:3126 CLOSED:SYN_SENT > all tcp 172.16.3.74:3126 -> 204.244.159.55:61282 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.18:2446 CLOSED:SYN_SENT > all tcp 172.16.3.18:2446 -> 204.244.159.68:58385 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.73:2057 CLOSED:SYN_SENT > all tcp 172.16.3.73:2057 -> 204.244.159.55:61692 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 198.208.22.27:53 <- 172.16.3.74:58071 SINGLE:MULTIPLE > all udp 172.16.3.74:58071 -> 204.244.159.68:54669 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.74:57503 SINGLE:MULTIPLE > all udp 172.16.3.74:57503 -> 204.244.159.55:64923 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.74:51153 SINGLE:MULTIPLE > all udp 172.16.3.74:51153 -> 204.244.159.68:61637 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 172.16.3.255:137 <- 172.16.3.74:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.74:137 -> 204.244.159.55:53474 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.71:3065 CLOSED:SYN_SENT > all tcp 172.16.3.71:3065 -> 204.244.159.68:63354 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.29:4434 CLOSED:SYN_SENT > all tcp 172.16.3.29:4434 -> 204.244.159.55:62977 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:137 <- 172.16.3.30:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.30:137 -> 204.244.159.68:61298 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 63.241.234.60:443 <- 172.16.3.37:1509 ESTABLISHED:ESTABLISHED > all tcp 172.16.3.37:1509 -> 204.244.159.68:61873 -> 63.241.234.60:443 > ESTABLISHED:ESTABLISHED > all udp 198.208.22.27:53 <- 172.16.3.72:59314 SINGLE:MULTIPLE > all udp 172.16.3.72:59314 -> 204.244.159.55:62186 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.72:55934 SINGLE:MULTIPLE > all udp 172.16.3.72:55934 -> 204.244.159.68:51479 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.72:52983 SINGLE:MULTIPLE > all udp 172.16.3.72:52983 -> 204.244.159.55:55523 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 172.16.3.255:137 <- 172.16.3.72:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.72:137 -> 204.244.159.68:58218 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.31:2868 CLOSED:SYN_SENT > all tcp 172.16.3.31:2868 -> 204.244.159.55:60911 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:137 <- 172.16.3.77:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.77:137 -> 204.244.159.55:59287 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.72:1416 CLOSED:SYN_SENT > all tcp 172.16.3.72:1416 -> 204.244.159.68:59828 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.49:1915 CLOSED:SYN_SENT > all tcp 172.16.3.49:1915 -> 204.244.159.55:64580 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.29:4435 CLOSED:SYN_SENT > all tcp 172.16.3.29:4435 -> 204.244.159.68:60089 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:137 <- 172.16.3.8:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.8:137 -> 204.244.159.68:60176 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.51:3433 CLOSED:SYN_SENT > all tcp 172.16.3.51:3433 -> 204.244.159.55:63158 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.37:1510 CLOSED:SYN_SENT > all tcp 172.16.3.37:1510 -> 204.244.159.68:63197 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.74:3127 CLOSED:SYN_SENT > all tcp 172.16.3.74:3127 -> 204.244.159.55:61760 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.18:2447 CLOSED:SYN_SENT > all tcp 172.16.3.18:2447 -> 204.244.159.68:61951 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.73:2058 CLOSED:SYN_SENT > all tcp 172.16.3.73:2058 -> 204.244.159.55:53396 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 198.208.22.27:53 <- 172.16.3.74:62024 SINGLE:MULTIPLE > all udp 172.16.3.74:62024 -> 204.244.159.55:63136 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all tcp 72.14.162.41:80 <- 172.16.3.74:3128 TIME_WAIT:TIME_WAIT > all tcp 172.16.3.74:3128 -> 204.244.159.68:58088 -> 72.14.162.41:80 > TIME_WAIT:TIME_WAIT > all tcp 72.14.162.41:80 <- 172.16.3.74:3129 FIN_WAIT_2:FIN_WAIT_2 > all tcp 172.16.3.74:3129 -> 204.244.159.55:62718 -> 72.14.162.41:80 > FIN_WAIT_2:FIN_WAIT_2 > all udp 172.16.3.255:138 <- 172.16.3.71:138 NO_TRAFFIC:SINGLE > all udp 172.16.3.71:138 -> 204.244.159.68:52993 -> 172.16.3.255:138 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.71:3066 CLOSED:SYN_SENT > all tcp 172.16.3.71:3066 -> 204.244.159.68:50898 -> 10.170.54.1:81 > SYN_SENT:CLOSED > > INFO: > Status: Enabled for 0 days 11:42:09 Debug: Urgent > > State Table Total Rate > current entries 84 > searches 4907040 116.5/s > inserts 131271 3.1/s > removals 131187 3.1/s > Counters > match 157214 3.7/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 40 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 2 0.0/s > state-mismatch 215 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 0 0.0/s > > TIMEOUTS: > tcp.first 120s > tcp.opening 30s > tcp.established 86400s > tcp.closing 900s > tcp.finwait 45s > tcp.closed 90s > tcp.tsdiff 30s > udp.first 60s > udp.single 30s > udp.multiple 60s > icmp.first 20s > icmp.error 10s > other.first 60s > other.single 30s > other.multiple 60s > frag 30s > interval 10s > adaptive.start 6000 states > adaptive.end 12000 states > src.track 0s > > LIMITS: > states hard limit 10000 > src-nodes hard limit 10000 > frags hard limit 5000 > tables hard limit 1000 > table-entries hard limit 200000 > > TABLES: > > OS FINGERPRINTS: > 696 fingerprints loaded > > _______________________________________________ > 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 shawn at tandac.com Wed Mar 25 15:21:42 2009 From: shawn at tandac.com (Shawn Everett) Date: Wed Mar 25 15:21:56 2009 Subject: FreeBSD Router Problem In-Reply-To: <49CAB28A.9030406@userid.org> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> <49CAB28A.9030406@userid.org> Message-ID: <1865.206.108.16.89.1238019698.squirrel@alder.hosix.com> > tcp.established 86400s > > ^^ This should be 3600. > > Pierre That's an interesting thought. Why would that matter? Shawn From linimon at FreeBSD.org Wed Mar 25 16:20:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Mar 25 16:26:01 2009 Subject: kern/133060: [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfsync + gif on FreeBSD 7 Message-ID: <200903252320.n2PNKmFe036448@freefall.freebsd.org> Old Synopsis: Kernel panic with ipsec + pfsync + gif on FreeBSD 7 New Synopsis: [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfsync + gif on FreeBSD 7 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 25 23:20:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133060 From dcornejo at gmail.com Wed Mar 25 19:52:26 2009 From: dcornejo at gmail.com (David Cornejo) Date: Wed Mar 25 19:52:33 2009 Subject: wds how-to? Message-ID: <6b8e8f4f0903251921h285c65c6i41444d577631158d@mail.gmail.com> Aloha, I'm trying to get WDS running - I am working my way through the stuff in /usr/src/tools/tools/net80211/scripts, but it really only gives examples and doesn't explain the why of it - is there a more verbose how to somewhere that would help me understand this? thanks, dave c From sam at freebsd.org Wed Mar 25 20:31:36 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Mar 25 20:31:42 2009 Subject: wds how-to? In-Reply-To: <6b8e8f4f0903251921h285c65c6i41444d577631158d@mail.gmail.com> References: <6b8e8f4f0903251921h285c65c6i41444d577631158d@mail.gmail.com> Message-ID: <49CAF716.6080105@freebsd.org> David Cornejo wrote: > Aloha, > > I'm trying to get WDS running - I am working my way through the stuff > in /usr/src/tools/tools/net80211/scripts, but it really only gives > examples and doesn't explain the why of it - is there a more verbose > how to somewhere that would help me understand this? > I've written nothing. You say the "why" is missing but you don't ask any questions. There are 2 flavors of wds, legacy and dynamic. The legacy stuff is trivial to setup; ifconfig wlan create wlandev ath0 wlanmode wds wlanbssid ... wdslegacy The bssid is the peer's mac address. This is just a fixed 4-address conduit for frames. There must be an ap vap already created. You want to plumb the vap into a bridge or assign it an ip address and route (not sure about routing; I always use it bridged). Dynamic wds setup depends on whether you're on the ap side or the sta side; the scripts are the best examples. The idea is you have a sta-ap association that carries 4-address traffic. Because there's a full-blown association you get discovery, roaming, and security for free. This is what you'll find in Apple's ap products though they've done a bunch of work to make it more production-quality. Note that wds is implemented above the drivers (modulo a bit of glue code). ath is just one driver that supports wds, ral is another. Sam From piston at otel.net Thu Mar 26 04:04:29 2009 From: piston at otel.net (S.I) Date: Thu Mar 26 04:04:36 2009 Subject: adding routes via interface bug in FreenBSD Message-ID: <20090326130427.6d1ab0e4.piston@otel.net> Hello, As of quagga-0.99.3_2 zebra doesn't add static routes via interface on any freebsd versions from 6-STABLE to FreeBSD 7.2-PRERELEASE #3: Wed Mar 25 11:38:45 EET 2009. Here is the example: ##################################################################################### zebra.conf interface vlan11 ip route 10.10.0.0/16 vlan11 ---------------------------- #ifconfig vlan11 vlan11: flags=8843 metric 0 mtu 1500 options=3 ether 00:04:23:a7:60:48 inet 172.16.16.1 netmask 0xffffffff broadcast 172.16.16.1 media: Ethernet autoselect (1000baseTX ) status: active vlan: 11 parent interface: em0 #################################################################################### Regards S.I From gavin at FreeBSD.org Thu Mar 26 05:27:51 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Mar 26 05:27:57 2009 Subject: kern/132342: [ndis] [patch] incorrect number used in for loop; fix TXPMGT reporting Message-ID: <200903261227.n2QCRoe2071576@freefall.freebsd.org> Synopsis: [ndis] [patch] incorrect number used in for loop; fix TXPMGT reporting State-Changed-From-To: open->patched State-Changed-By: gavin State-Changed-When: Thu Mar 26 12:24:48 UTC 2009 State-Changed-Why: Mark as patched, as it is fixed in HEAD. I'm not sure if this actually applies to 7.x, however, so it is possible that this should instead be closed. To submitter: do you know if this is also an issue in 7.x? http://www.freebsd.org/cgi/query-pr.cgi?pr=132342 From ady at freebsd.ady.ro Thu Mar 26 05:52:23 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Thu Mar 26 05:52:30 2009 Subject: FreeBSD Router Problem In-Reply-To: <1865.206.108.16.89.1238019698.squirrel@alder.hosix.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> <49CAB28A.9030406@userid.org> <1865.206.108.16.89.1238019698.squirrel@alder.hosix.com> Message-ID: <78cb3d3f0903260552g372fd4b6k886bba1ebc05a77c@mail.gmail.com> Hi, On Wed, Mar 25, 2009 at 11:21 PM, Shawn Everett wrote: > > tcp.established 86400s > > > > ^^ This should be 3600. > > > > Pierre > > That's an interesting thought. Why would that matter? It's the PF TCP established session timeout, which defaults to 1 day. This is relevant only if you see a lot of ESTABLISHED sessions in the 'pfctl -s state' output, which appears not to be the case... Regards, Adrian. From gavin at FreeBSD.org Thu Mar 26 07:19:39 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Mar 26 07:19:46 2009 Subject: kern/132342: [ndis] [patch] incorrect number used in for loop; fix TXPMGT reporting Message-ID: <200903261419.n2QEJRQb021647@freefall.freebsd.org> Synopsis: [ndis] [patch] incorrect number used in for loop; fix TXPMGT reporting State-Changed-From-To: patched->closed State-Changed-By: gavin State-Changed-When: Thu Mar 26 14:18:54 UTC 2009 State-Changed-Why: Close, submitter confirms that this is not an issue with 7.x or earlier. http://www.freebsd.org/cgi/query-pr.cgi?pr=132342 From brucec at FreeBSD.org Thu Mar 26 08:57:07 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Thu Mar 26 08:57:19 2009 Subject: kern/98597: [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedure Message-ID: <200903261557.n2QFv71S057981@freefall.freebsd.org> Synopsis: [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedure Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Mar 26 15:56:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=98597 From brucec at FreeBSD.org Thu Mar 26 08:58:10 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Thu Mar 26 08:58:22 2009 Subject: kern/77341: [ip6] problems with IPV6 implementation Message-ID: <200903261558.n2QFw9W0058042@freefall.freebsd.org> Synopsis: [ip6] problems with IPV6 implementation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Mar 26 15:57:51 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=77341 From dhorn2000 at gmail.com Thu Mar 26 08:59:31 2009 From: dhorn2000 at gmail.com (David Horn) Date: Thu Mar 26 08:59:38 2009 Subject: Dynamic loading of network kernel modules? In-Reply-To: <20090324155746.GC5281@lor.one-eyed-alien.net> References: <25ff90d60903180904ud077fcdy344cda5307a9037e@mail.gmail.com> <200903181626.n2IGQgqt054487@lurza.secnetix.de> <25ff90d60903181033n5d3f0a79w7a8ea504f911ecf@mail.gmail.com> <20090324155746.GC5281@lor.one-eyed-alien.net> Message-ID: <25ff90d60903260859h649ab2fbw4b7462601b192beb@mail.gmail.com> On Tue, Mar 24, 2009 at 11:57 AM, Brooks Davis wrote: > On Wed, Mar 18, 2009 at 01:33:06PM -0400, David Horn wrote: >> On Wed, Mar 18, 2009 at 12:26 PM, Oliver Fromme wrote: >> > David Horn wrote: >> > ?> Oliver Fromme wrote: >> > ?> > >> > ?> > ?network_interfaces="bge0 lo0" >> > ?> >> > ?> Ah. ?Ok, now I am understanding your scenario. >> > ?> >> > ?> I thought that using 'network_interfaces' with anything other than >> > ?> "AUTO" ?was in the process of being depreciated ? >> > >> > Well, the manual page says so, but I think that is a >> > mistake. ?There are cases where you have to specify the >> > list of interfaces explicitly. ?The situation described >> > in this thread is one such case. >> >> Good point. >> >> > >> > My opinion is that it is good to have the ability to let >> > things be done automatically, but it is bad to remove the >> > ability to do things manually. ?This is UNIX, after all. >> >> Exactly. ?Both scenarios should probably be supported, but I guess we >> would need to ask brooks for some history on the depreciated warning >> for network_interfaces. > > I think network_interfaces and the autoloading support in ifconfig are > a massive mistake that we've been unable to kill. ?The relativly large > amount of code you've written to hack around yet another edge case proves > my point. :) If you want to load if_iwn at boot just do: > > echo 'if_iwn_load="YES"' >> /boot/loader.conf > > and be done with it. Yep, now that I have had some time to think about it, this is probably not worth patching. Thanks for the feedback. --Dave H > > -- Brooks > >> ================================================= >> src/etc/network.subr >> Revision 1.185: download - view: text, markup, annotated - [selected for diffs] >> Wed Apr 30 16:29:15 2008 UTC (10 months, 2 weeks ago) by brooks >> Branches: MAIN >> Diff to: previous 1.184: preferred, colored >> Changes since revision 1.184: +4 -0 lines >> >> Emit a warning when the network_interfaces variable is not set to AUTO. >> >> MFC after: ? ?3 days >> ================================================== >> >> --Thanks! >> >> -_Dave H >> >> > >> > Best regards >> > ? Oliver >> > >> > -- >> > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. >> > Handelsregister: Registergericht Muenchen, HRA 74606, ?Gesch?ftsfuehrung: >> > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- >> > chen, HRB 125758, ?Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart >> > >> > FreeBSD-Dienstleistungen, -Produkte und mehr: ?http://www.secnetix.de/bsd >> > >> > "The ITU has offered the IETF formal alignment with its >> > corresponding technology, Penguins, but that won't fly." >> > ? ? ? ?-- RFC 2549 >> > >> _______________________________________________ >> 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 pierre at userid.org Thu Mar 26 10:43:16 2009 From: pierre at userid.org (Pierre Lamy) Date: Thu Mar 26 10:43:22 2009 Subject: FreeBSD Router Problem In-Reply-To: <78cb3d3f0903260552g372fd4b6k886bba1ebc05a77c@mail.gmail.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> <49CAB28A.9030406@userid.org> <1865.206.108.16.89.1238019698.squirrel@alder.hosix.com> <78cb3d3f0903260552g372fd4b6k886bba1ebc05a77c@mail.gmail.com> Message-ID: <49CBA72F.3020600@userid.org> states hard limit 10000 If I want to dos this box all I need to do is hold 10k tcp connections open in established. A 1 day default timeout for established connections is retarded, since virtually all client apps and OSs as well as intervening stateful firewalls will lose state after 1 hour. A session which is idle for more than an hour can't be considered to be active. Coupled with an extremely low state limit, and you're asking for problems. If the session is active at all before the session timeout is hit, the timer is reset. I'm not saying he's getting DOSd, but with such low limits, even a normal home network is going to run into problems at some point. We can see from the diagnostic output provided earlier that there were no issues when it was collected, but was it collected while there was an outage? If the problem still occurs, it may be worth scripting something to collect some pfctl -g -v -v -v -s all and some sysctl -a, vmstat output as well. Pierre Adrian Penisoara wrote: > Hi, > > On Wed, Mar 25, 2009 at 11:21 PM, Shawn Everett wrote: > > >>> tcp.established 86400s >>> >>> ^^ This should be 3600. >>> >>> Pierre >>> >> That's an interesting thought. Why would that matter? >> > > > It's the PF TCP established session timeout, which defaults to 1 day. This > is relevant only if you see a lot of ESTABLISHED sessions in the 'pfctl -s > state' output, which appears not to be the case... > > > Regards, > Adrian. > _______________________________________________ > 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 brucec at FreeBSD.org Thu Mar 26 11:37:10 2009 From: brucec at FreeBSD.org (brucec@FreeBSD.org) Date: Thu Mar 26 11:37:17 2009 Subject: kern/75873: Usability problem with non-RFC-compliant IP spoof protection implementation Message-ID: <200903261837.n2QIb9hn075109@freefall.freebsd.org> Synopsis: Usability problem with non-RFC-compliant IP spoof protection implementation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Thu Mar 26 18:36:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=75873 From brampton+freebsd-net at gmail.com Thu Mar 26 18:14:13 2009 From: brampton+freebsd-net at gmail.com (Andrew Brampton) Date: Thu Mar 26 18:14:20 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) Message-ID: Hi, Linux has a feature called NAPI, which amongst other things has this Interrupt initiated polling mode. Whilst the network traffic is quiet the network interfaces use interrupts, however as soon as the load becomes higher polling kicks in and stays like that until the load drops again. I know that FreeBSD can do interrupts or polling, but not together. I think that that NAPI pretty neat as it provides the benefits of both interrupts and polling, namely low CPU load (when the network is not busy), and high performance. I was wondering if anyone has considered this approach in FreeBSD? If not why not? Is there some reason why the binary FreeBSD approach is better? Or is it just that no one has dedicated the time and effort to implement this feature? Thanks Andrew From rizzo at iet.unipi.it Fri Mar 27 00:28:09 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Mar 27 00:28:16 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: References: Message-ID: <20090327071742.GA87385@onelab2.iet.unipi.it> On Fri, Mar 27, 2009 at 12:47:45AM +0000, Andrew Brampton wrote: > Hi, > Linux has a feature called NAPI, which amongst other things has this > Interrupt initiated polling mode. Whilst the network traffic is quiet > the network interfaces use interrupts, however as soon as the load > becomes higher polling kicks in and stays like that until the load > drops again. > > I know that FreeBSD can do interrupts or polling, but not together. I > think that that NAPI pretty neat as it provides the benefits of both > interrupts and polling, namely low CPU load (when the network is not > busy), and high performance. I was wondering if anyone has considered > this approach in FreeBSD? If not why not? Is there some reason why the > binary FreeBSD approach is better? Or is it just that no one has > dedicated the time and effort to implement this feature? The load of polling is pretty low (within 1% or so) even with polling. The advantage of having interrupts is faster response to incoming traffic, not CPU load. There is nothing difficult in having both active, except figuring out a good logic for when to disable polling on an interface that has been quiet for a while. I don't know what is the status of polling these days -- when i wrote it, the architecture was designed for UP kernels, and I don't know if/how it has been revised to deal efficiently with the SMP kernels we have now (in other words: one or multiple polling loops, interaction with interrupt threads, etc.) cheers luigi From vova at fbsd.ru Fri Mar 27 03:47:30 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Mar 27 03:47:37 2009 Subject: Crash while disconnecting notebook from dock, network related Message-ID: <1238150844.1666.48.camel@localhost> Hi Recent 8-CURRENT kernel crashes on disconnection notebook from dock station. It happens sometimes. Most probably bug actually related to network stack, on dock disconnect following commands executed: /opt/bin/service netif stop em0; /opt/bin/service netif start ath0 (un-configure em0, configure ath0) all network devices are on board, so they are not disconnected for bus physically. # uname -a FreeBSD vbook 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Wed Mar 18 17:18:28 MSK 2009 root@vbook:/usr/obj/usr/src/sys/VBOOK i386 # kgdb /boot/kernel/kernel /var/crash/vmcore.2 ... Unread portion of the kernel message buffer: panic: sbflush_internal: cc 94 || mb 0 || mbcnt 0 KDB: enter: panic KDB: stack backtrace: Uptime: 3h5m31s Physical memory: 2038 MB Dumping 229 MB: 214 198 182 166 150 134 118 102 86 70 54 38 22 6 ... #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0550573 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc05507ad in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc059f58e in sbflush_internal (sb=0xc5681b08) at /usr/src/sys/kern/uipc_sockbuf.c:817 #4 0xc059f661 in sbrelease_internal (sb=0xc5681b08, so=0xc5681ab8) at /usr/src/sys/kern/uipc_sockbuf.c:329 #5 0xc059f6c8 in sbdestroy (sb=0xc5681b08, so=0xc5681ab8) at /usr/src/sys/kern/uipc_sockbuf.c:357 #6 0xc05a0f7a in sofree (so=0xc5681ab8) at /usr/src/sys/kern/uipc_socket.c:623 #7 0xc05a1fe1 in soclose (so=0xc5681ab8) at /usr/src/sys/kern/uipc_socket.c:694 #8 0xc058d669 in soo_close (fp=0xc559a6c8, td=0xc5043880) at /usr/src/sys/kern/sys_socket.c:282 #9 0xc051db13 in _fdrop (fp=0xc559a6c8, td=0xc5043880) at file.h:293 #10 0xc051f008 in closef (fp=0xc559a6c8, td=0xc5043880) at /usr/src/sys/kern/kern_descrip.c:2006 #11 0xc051f4fd in kern_close (td=0xc5043880, fd=10) at /usr/src/sys/kern/kern_descrip.c:1105 #12 0xc051f5da in close (td=0xc5043880, uap=0xe783fcf8) at /usr/src/sys/kern/kern_descrip.c:1057 #13 0xc06bb747 in syscall (frame=0xe783fd38) at /usr/src/sys/i386/i386/trap.c:1066 #14 0xc06a2dd0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #15 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 3 #3 0xc059f58e in sbflush_internal (sb=0xc5681b08) at /usr/src/sys/kern/uipc_sockbuf.c:817 817 panic("sbflush_internal: cc %u || mb %p || mbcnt %u", (kgdb) l sbflush_internal 800 /* 801 * Free all mbufs in a sockbuf. Check that all resources are reclaimed. 802 */ 803 static void 804 sbflush_internal(struct sockbuf *sb) 805 { 806 807 while (sb->sb_mbcnt) { 808 /* 809 * Don't call sbdrop(sb, 0) if the leading mbuf is non-empty: (kgdb) 810 * we would loop forever. Panic instead. 811 */ 812 if (!sb->sb_cc && (sb->sb_mb == NULL || sb->sb_mb->m_len)) 813 break; 814 sbdrop_internal(sb, (int)sb->sb_cc); 815 } 816 if (sb->sb_cc || sb->sb_mb || sb->sb_mbcnt) 817 panic("sbflush_internal: cc %u || mb %p || mbcnt %u", 818 sb->sb_cc, (void *)sb->sb_mb, sb->sb_mbcnt); 819 } (kgdb) p sb->sb_cc $1 = 94 (kgdb) p sb->sb_mb $2 = (struct mbuf *) 0x0 (kgdb) p sb->sb_mbcnt $3 = 0 (kgdb) -- Vladimir B. Grebenschikov vova@fbsd.ru From brampton+freebsd-net at gmail.com Fri Mar 27 04:05:02 2009 From: brampton+freebsd-net at gmail.com (Andrew Brampton) Date: Fri Mar 27 04:05:09 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: <20090327071742.GA87385@onelab2.iet.unipi.it> References: <20090327071742.GA87385@onelab2.iet.unipi.it> Message-ID: 2009/3/27 Luigi Rizzo : > The load of polling is pretty low (within 1% or so) even with > polling. The advantage of having interrupts is faster response > to incoming traffic, not CPU load. oh, I was under the impression that polling spun in a tight loop, thus using 100% of the processor. After a quick test I see this is not the case. I assume it will get to 100% CPU load if I saturate my network. > > There is nothing difficult in having both active, except figuring > out a good logic for when to disable polling on an interface > that has been quiet for a while. Looking at Linux's logic, it appears to poll until there are no more packets, and thus re-enables interrupts. > > I don't know what is the status of polling these days -- when i > wrote it, the architecture was designed for UP kernels, and I > don't know if/how it has been revised to deal efficiently with > the SMP kernels we have now (in other words: one or multiple > polling loops, interaction with interrupt threads, etc.) So, do you think the interrupt+polling has a place in FreeBSD? Now that I know that Polling doesn't consume 100% of the processor, it might be best to "keep it simple stupid". > > ? ? ? ?cheers > ? ? ? ?luigi > Thanks for answer my questions, and thanks for writing polling support in the beginning! Andrew From rizzo at iet.unipi.it Fri Mar 27 04:11:56 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Mar 27 04:12:03 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: References: <20090327071742.GA87385@onelab2.iet.unipi.it> Message-ID: <20090327111654.GA95104@onelab2.iet.unipi.it> On Fri, Mar 27, 2009 at 11:05:00AM +0000, Andrew Brampton wrote: > 2009/3/27 Luigi Rizzo : > > The load of polling is pretty low (within 1% or so) even with > > polling. The advantage of having interrupts is faster response > > to incoming traffic, not CPU load. > > oh, I was under the impression that polling spun in a tight loop, thus > using 100% of the processor. After a quick test I see this is not the > case. I assume it will get to 100% CPU load if I saturate my network. Well the motivation for the original polling code in FreeBSD was to keep the CPU usage under strict control -- you could set the max CPU fraction that you wanted to dedicate to packet handling, and you were guaranteed not to exceed that fraction. > > There is nothing difficult in having both active, except figuring > > out a good logic for when to disable polling on an interface > > that has been quiet for a while. > > Looking at Linux's logic, it appears to poll until there are no more > packets, and thus re-enables interrupts. the complete definition should be "no more packets for X seconds". Enabling and disabling interrupts is slightly expensive so you don't want to do it too often. cheers luigi From piston at otel.net Fri Mar 27 04:54:46 2009 From: piston at otel.net (S.I) Date: Fri Mar 27 04:54:55 2009 Subject: Quagga adding routes via interface in FreenBSD Message-ID: <20090327135445.e71e0012.piston@otel.net> Hello, As of quagga-0.99.3_2 zebra doesn't add static routes via interface on any freebsd versions from 6-STABLE to FreeBSD 7.2-PRERELEASE #3: Wed Mar 25 11:38:45 EET 2009. quagga-0.99.3 is working but everything after that version including 0.99.11 is not working. Here is the example: ##################################################################################### zebra.conf interface vlan11 ip route 10.10.0.0/16 vlan11 ---------------------------- #ifconfig vlan11 vlan11: flags=8843 metric 0 mtu 1500 options=3 ether 00:04:23:a7:60:48 inet 172.16.16.1 netmask 0xffffffff broadcast 172.16.16.1 media: Ethernet autoselect (1000baseTX ) status: active vlan: 11 parent interface: em0 #################################################################################### Regards S.I From bzeeb-lists at lists.zabbadoz.net Fri Mar 27 05:35:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Mar 27 05:35:14 2009 Subject: Quagga adding routes via interface in FreenBSD In-Reply-To: <20090327135445.e71e0012.piston@otel.net> References: <20090327135445.e71e0012.piston@otel.net> Message-ID: <20090327123152.E67075@maildrop.int.zabbadoz.net> On Fri, 27 Mar 2009, S.I wrote: Hi, > As of quagga-0.99.3_2 zebra doesn't add static routes via interface on any > freebsd versions from 6-STABLE to FreeBSD 7.2-PRERELEASE #3: Wed Mar 25 11:38:45 > EET 2009. > quagga-0.99.3 is working but everything after that version including 0.99.11 is > not working. So maybe it's a quagga bug? > Here is the example: > ##################################################################################### > zebra.conf > interface vlan11 > ip route 10.10.0.0/16 vlan11 > ---------------------------- > #ifconfig vlan11 > > vlan11: flags=8843 metric 0 mtu 1500 > options=3 > ether 00:04:23:a7:60:48 > inet 172.16.16.1 netmask 0xffffffff broadcast 172.16.16.1 > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 11 parent interface: em0 > #################################################################################### your sample is showing the interface configuration not the routing table. You want to look at or show us the netstat -rn output; for your example netstat -rn | grep vlan11 | grep ^10.10 would be enough. -- Bjoern A. Zeeb The greatest risk is not taking one. From ady at freebsd.ady.ro Fri Mar 27 06:18:05 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Fri Mar 27 06:18:11 2009 Subject: FreeBSD Router Problem In-Reply-To: <49CBA72F.3020600@userid.org> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> <49CAB28A.9030406@userid.org> <1865.206.108.16.89.1238019698.squirrel@alder.hosix.com> <78cb3d3f0903260552g372fd4b6k886bba1ebc05a77c@mail.gmail.com> <49CBA72F.3020600@userid.org> Message-ID: <78cb3d3f0903270618u229986c1idddd0e5548444c60@mail.gmail.com> Hi, On Thu, Mar 26, 2009 at 5:02 PM, Pierre Lamy wrote: > states hard limit 10000 > > If I want to dos this box all I need to do is hold 10k tcp connections open > in established. > > A 1 day default timeout for established connections is retarded, since > virtually all client apps and OSs as well as intervening stateful firewalls > will lose state after 1 hour. A session which is idle for more than an hour > can't be considered to be active. Coupled with an extremely low state limit, > and you're asking for problems. If the session is active at all before the > session timeout is hit, the timer is reset. I'm sorry but I have to object. Having past experience in Oracle Support for networking issues I did see many problems with statefull firewalls which were cutting off idle Oracle connections. The base line is: DO NOT assume connections are dead even if they are idle for more than an hour... > > > I'm not saying he's getting DOSd, but with such low limits, even a normal > home network is going to run into problems at some point. We can see from > the diagnostic output provided earlier that there were no issues when it was > collected, but was it collected while there was an outage? > > If the problem still occurs, it may be worth scripting something to collect > some pfctl -g -v -v -v -s all and some sysctl -a, vmstat output as well. Well, just keep a 'pfctl -s state >/var/tmp/pf-states.txt' running in cron every few minutes then and let's check it out... Regards, Adrian. > > > Pierre > > Adrian Penisoara wrote: > >> Hi, >> >> On Wed, Mar 25, 2009 at 11:21 PM, Shawn Everett wrote: >> >> >> >>> tcp.established 86400s >>>> >>>> ^^ This should be 3600. >>>> >>>> Pierre >>>> >>>> >>> That's an interesting thought. Why would that matter? >>> >>> >> >> >> It's the PF TCP established session timeout, which defaults to 1 day. This >> is relevant only if you see a lot of ESTABLISHED sessions in the 'pfctl -s >> state' output, which appears not to be the case... >> >> >> Regards, >> Adrian. >> _______________________________________________ >> 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 _pppp at mail.ru Fri Mar 27 06:31:26 2009 From: _pppp at mail.ru (Dmitriy) Date: Fri Mar 27 06:31:32 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: <20090327111654.GA95104@onelab2.iet.unipi.it> References: <20090327111654.GA95104@onelab2.iet.unipi.it> Message-ID: -----Original Message----- From: Luigi Rizzo To: Andrew Brampton Date: Fri, 27 Mar 2009 12:16:54 +0100 Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > On Fri, Mar 27, 2009 at 11:05:00AM +0000, Andrew Brampton wrote: > > 2009/3/27 Luigi Rizzo : > > > The load of polling is pretty low (within 1% or so) even with > > > polling. The advantage of having interrupts is faster response > > > to incoming traffic, not CPU load. > > > > oh, I was under the impression that polling spun in a tight loop, thus > > using 100% of the processor. After a quick test I see this is not the > > case. I assume it will get to 100% CPU load if I saturate my network. > > Well the motivation for the original polling code in FreeBSD was > to keep the CPU usage under strict control -- you could set the > max CPU fraction that you wanted to dedicate to packet handling, > and you were guaranteed not to exceed that fraction. Well, polling(4) usually reduces the CPU load. But this is not essential for modern CPUs, except some software-only NICs (namely, Realtek 8139). It provides an average of 0.5ms delay for a packet delivery which is not suitable for many usage patterns, though. > > > There is nothing difficult in having both active, except figuring > > > out a good logic for when to disable polling on an interface > > > that has been quiet for a while. > > > > Looking at Linux's logic, it appears to poll until there are no more > > packets, and thus re-enables interrupts. > > the complete definition should be "no more packets for X seconds". > Enabling and disabling interrupts is slightly expensive so you > don't want to do it too often. I'd rather say "no more than N packets for the recent T seconds". > > 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 ash at aeria.net Fri Mar 27 07:42:28 2009 From: ash at aeria.net (Ash Gokhale) Date: Fri Mar 27 07:42:34 2009 Subject: netgraph modules won't unload after use Message-ID: <4E7EE2F9-F213-4005-A915-819A2B8B6B66@aeria.net> > I'm developing a kernel module that will be doing inspection and > needed access to raw network frames, > > > But the module will never unload: ( but the UNLOAD and QUIESE event > handlers are invoked) > > #make unload :ro:~/tmp/ > > food.ko:3:14:28:31 > > /sbin/kldunload -vf food.ko > > Unloading food.ko, id=7 > > kldunload: can't unload file: Device busy > > *** Error code 1 > > > > Stop in /root/tmp/food.ko. > > Exit 1 > > #Mar 18 03:14:31 kernel: quiesced :ro:~/tmp/ > > food.ko:3:14:31:32 > > Mar 18 03:14:31 kernel: foodmod unloaded > > > Thanks so much for looking at it Julian, I never could get my netgraph module to unload, out of frustration I replaced the interfaces if_input routine with my own. I don't share this interface with the host's stack, so this measure seems appropriate. Now I have to grab about 10Gb of ram for a data structure.. I hope that's just tuning. From sam at freebsd.org Fri Mar 27 08:55:52 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Mar 27 08:55:58 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: References: Message-ID: <49CCF707.40101@freebsd.org> Andrew Brampton wrote: > Hi, > Linux has a feature called NAPI, which amongst other things has this > Interrupt initiated polling mode. Whilst the network traffic is quiet > the network interfaces use interrupts, however as soon as the load > becomes higher polling kicks in and stays like that until the load > drops again. > > I know that FreeBSD can do interrupts or polling, but not together. I > think that that NAPI pretty neat as it provides the benefits of both > interrupts and polling, namely low CPU load (when the network is not > busy), and high performance. I was wondering if anyone has considered > this approach in FreeBSD? If not why not? Is there some reason why the > binary FreeBSD approach is better? Or is it just that no one has > dedicated the time and effort to implement this feature? > NAPI is essentially interrupt moderation in s/w. As Luigi noted elsewhere polling in freebsd is rather different with livelock avoidance being just one of the goals. I've had several projects where people coming from linux felt is was critical to implement NAPI or something similar on a bsd system. In the end they found it was not a significant win if the hardware is reasonably designed and the driver properly tuned. Some of this relates to how the network stacks differ in design. I think a NAPI-like facility would mostly be used for legacy devices which is not to say it's a bad idea or that you shouldn't work on it. Whether or not it's incorporated into the system would depend on how much of a win it turns out to be and how intrusive it is as you'd need to mod all the drivers. Sam From piston at otel.net Fri Mar 27 09:48:14 2009 From: piston at otel.net (S.I) Date: Fri Mar 27 09:48:24 2009 Subject: Quagga adding routes via interface in FreenBSD In-Reply-To: <20090327160046.L67075@maildrop.int.zabbadoz.net> References: <20090327135445.e71e0012.piston@otel.net> <20090327123152.E67075@maildrop.int.zabbadoz.net> <20090327150023.70ecffb8.piston@otel.net> <20090327160046.L67075@maildrop.int.zabbadoz.net> Message-ID: <20090327184810.f90bb631.piston@otel.net> On Fri, 27 Mar 2009 16:02:10 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Fri, 27 Mar 2009, S.I wrote: > > 1) it's always good to show people in a problem report, especially > when showing other things. > 2) you could use rc.conf to install the route instead of doing it by > hand. By "hand" I ment that i was using rc.conf and not quagga :) > 3) I'd talk to the quagga people to look at this. > Thanks, I've submited a bug report there too, but if more people bug them about this it's probably better ;) From peterjeremy at optushome.com.au Fri Mar 27 12:50:43 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Mar 27 12:50:49 2009 Subject: FreeBSD Router Problem In-Reply-To: <49CBA72F.3020600@userid.org> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> <49CAB28A.9030406@userid.org> <1865.206.108.16.89.1238019698.squirrel@alder.hosix.com> <78cb3d3f0903260552g372fd4b6k886bba1ebc05a77c@mail.gmail.com> <49CBA72F.3020600@userid.org> Message-ID: <20090327193451.GA16310@server.vk2pj.dyndns.org> On 2009-Mar-26 11:02:55 -0500, Pierre Lamy wrote: >A 1 day default timeout for established connections is retarded, since >virtually all client apps and OSs as well as intervening stateful >firewalls will lose state after 1 hour. With respect, this is nonsense. An app or OS should never "lose state" for an established TCP connection - if it does, it is broken. Note that the default TCP keepalive interval (in many OSs, not just FreeBSD) is 2 hours. Firewalls are a different case - far more variable and far more often tweaked to suit the owner. IPFW2 defaults to 4096 dynamic rules and defaults to a 5 minute timeout (it also supports its own keepalive generation). IPfilter defaults to a 120 hour timeout. Our corporate firewall at $work times out after about a minute. Again - none of these match your '1 hour' statement. > A session which is idle for more >than an hour can't be considered to be active. This depends on what you consider active. I manage one firewall-like device at work where access to services through the device is controlled be the presence of a specific TCP connection (ie, the user sets up a TCP connection to an app on the box and that app then allows that user to have access to other services mediated by that box whilst that connection remains established). In this case, once the initial authentication phase is complete, the control connection never carries any further application-level data but its continued presence is required (and monitored via TCP-level keepalives). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090327/74935a34/attachment.pgp From dcornejo at gmail.com Fri Mar 27 15:22:39 2009 From: dcornejo at gmail.com (David Cornejo) Date: Fri Mar 27 15:22:46 2009 Subject: wds how-to? In-Reply-To: <49CAF716.6080105@freebsd.org> References: <6b8e8f4f0903251921h285c65c6i41444d577631158d@mail.gmail.com> <49CAF716.6080105@freebsd.org> Message-ID: <6b8e8f4f0903271522l69751d4eu92f4c87e56387837@mail.gmail.com> That brief description was a big help in itself, thank you. One question: should the BSSID in the legacy mode be the same as the MAC address of the main WDS node? Or can it be a random number? thanks, dave c On Wed, Mar 25, 2009 at 5:31 PM, Sam Leffler wrote: > David Cornejo wrote: >> >> Aloha, >> >> I'm trying to get WDS running - I am working my way through the stuff >> in /usr/src/tools/tools/net80211/scripts, but it really only gives >> examples and doesn't explain the why of it - is there a more verbose >> how to somewhere that would help me understand this? >> > > I've written nothing. ?You say the "why" is missing but you don't ask any > questions. > > There are 2 flavors of wds, legacy and dynamic. ?The legacy stuff is trivial > to setup; > > ifconfig wlan create wlandev ath0 wlanmode wds wlanbssid ... wdslegacy > > The bssid is the peer's mac address. ?This is just a fixed 4-address conduit > for frames. ?There must be an ap vap already created. ?You want to plumb the > vap into a bridge or assign it an ip address and route (not sure about > routing; I always use it bridged). > > Dynamic wds setup depends on whether you're on the ap side or the sta side; > the scripts are the best examples. ?The idea is you have a sta-ap > association that carries 4-address traffic. ?Because there's a full-blown > association you get discovery, roaming, and security for free. ?This is what > you'll find in Apple's ap products though they've done a bunch of work to > make it more production-quality. > > Note that wds is implemented above the drivers (modulo a bit of glue code). > ?ath is just one driver that supports wds, ral is another. > > ? Sam > > From sam at freebsd.org Fri Mar 27 15:55:43 2009 From: sam at freebsd.org (Sam Leffler) Date: Fri Mar 27 15:55:49 2009 Subject: wds how-to? In-Reply-To: <6b8e8f4f0903271522l69751d4eu92f4c87e56387837@mail.gmail.com> References: <6b8e8f4f0903251921h285c65c6i41444d577631158d@mail.gmail.com> <49CAF716.6080105@freebsd.org> <6b8e8f4f0903271522l69751d4eu92f4c87e56387837@mail.gmail.com> Message-ID: <49CD596E.3060609@freebsd.org> It must be the bssid of the peer; it is used to form the 4-address frames. Sam David Cornejo wrote: > That brief description was a big help in itself, thank you. > > One question: should the BSSID in the legacy mode be the same as the > MAC address of the main WDS node? Or can it be a random number? > > thanks, > dave c > > On Wed, Mar 25, 2009 at 5:31 PM, Sam Leffler wrote: > >> David Cornejo wrote: >> >>> Aloha, >>> >>> I'm trying to get WDS running - I am working my way through the stuff >>> in /usr/src/tools/tools/net80211/scripts, but it really only gives >>> examples and doesn't explain the why of it - is there a more verbose >>> how to somewhere that would help me understand this? >>> >>> >> I've written nothing. You say the "why" is missing but you don't ask any >> questions. >> >> There are 2 flavors of wds, legacy and dynamic. The legacy stuff is trivial >> to setup; >> >> ifconfig wlan create wlandev ath0 wlanmode wds wlanbssid ... wdslegacy >> >> The bssid is the peer's mac address. This is just a fixed 4-address conduit >> for frames. There must be an ap vap already created. You want to plumb the >> vap into a bridge or assign it an ip address and route (not sure about >> routing; I always use it bridged). >> >> Dynamic wds setup depends on whether you're on the ap side or the sta side; >> the scripts are the best examples. The idea is you have a sta-ap >> association that carries 4-address traffic. Because there's a full-blown >> association you get discovery, roaming, and security for free. This is what >> you'll find in Apple's ap products though they've done a bunch of work to >> make it more production-quality. >> >> Note that wds is implemented above the drivers (modulo a bit of glue code). >> ath is just one driver that supports wds, ral is another. >> >> 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 daniel at roe.ch Sat Mar 28 08:31:41 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Sat Mar 28 08:31:48 2009 Subject: iwn(4): Porting Intel 5100/5300 support from OpenBSD? Message-ID: <20090328153138.GA78279@hobbes.ustdmz.roe.ch> Is anyone already working on porting Damien Bergamini's updates to OpenBSD iwn(4) in order to support Intel 5100/5300 chipsets? Is there anything preventing this work (except ENOTIME)? -- Daniel Roethlisberger http://daniel.roe.ch/ From sam at freebsd.org Sat Mar 28 09:39:07 2009 From: sam at freebsd.org (Sam Leffler) Date: Sat Mar 28 09:39:13 2009 Subject: iwn(4): Porting Intel 5100/5300 support from OpenBSD? In-Reply-To: <20090328153138.GA78279@hobbes.ustdmz.roe.ch> References: <20090328153138.GA78279@hobbes.ustdmz.roe.ch> Message-ID: <49CE52AA.6060500@freebsd.org> Daniel Roethlisberger wrote: > Is anyone already working on porting Damien Bergamini's updates > to OpenBSD iwn(4) in order to support Intel 5100/5300 chipsets? > Is there anything preventing this work (except ENOTIME)? > > I've been working with another person on this. It looks like the mods are straightforward but both of us have 4965 cards so can't test the new stuff. I suggest you not wait if you're motivated. Sam From daniel at roe.ch Sat Mar 28 10:30:44 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Sat Mar 28 10:30:51 2009 Subject: iwn(4): Porting Intel 5100/5300 support from OpenBSD? In-Reply-To: <49CE52AA.6060500@freebsd.org> References: <20090328153138.GA78279@hobbes.ustdmz.roe.ch> <49CE52AA.6060500@freebsd.org> Message-ID: <20090328173042.GC78279@hobbes.ustdmz.roe.ch> Sam Leffler 2009-03-28: > Daniel Roethlisberger wrote: > > Is anyone already working on porting Damien Bergamini's > > updates to OpenBSD iwn(4) in order to support Intel 5100/5300 > > chipsets? Is there anything preventing this work (except > > ENOTIME)? > > I've been working with another person on this. It looks like > the mods are straightforward but both of us have 4965 cards so > can't test the new stuff. I suggest you not wait if you're > motivated. I have a 5300 card (0x4236) and I am indeed motivated to work on this. Are there any patches resulting from your work with that other person? -- Daniel Roethlisberger http://daniel.roe.ch/ From chris at young-alumni.com Sat Mar 28 12:02:45 2009 From: chris at young-alumni.com (Chris Ruiz) Date: Sat Mar 28 12:02:51 2009 Subject: NDIS - True OR False In-Reply-To: <20090325054021.GA9518@weongyo.cdnetworks.kr> References: <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com> <200903250159.n2P1xMti096589@hergotha.csail.mit.edu> <20090325054021.GA9518@weongyo.cdnetworks.kr> Message-ID: <0A57F174-7219-4E5D-AF02-0F03D5CC286E@young-alumni.com> On Mar 25, 2009, at 12:40 AM, Weongyo Jeong wrote: > On Tue, Mar 24, 2009 at 09:59:22PM -0400, Garrett Wollman wrote: >> In article <41D96B7F-F76D-4F35-BA1D-0EDF810E6140@young-alumni.com>, >> "Chris" writes: >> >>> True OR False >>> >>> 1) NDIS only works with XP drivers. >> >> Can't answer that as I've never needed to try a Vista driver. > > AFAIK NDISulator try to mimic that it works on Windows XP and the > driver > depends on the version of NDIS driver that normally it's 5.0 or > 5.1. I > know Vista driver uses NDIS 6.x that isn't supported by NDISulator. Thank you. >>> 2) NDIS only works with 32-bit drivers and wont work on amd64. >> >> False, unless someone has broken it recently. Project Evil has >> worked >> on 64-bit systems (and *requires* 64-bit drivers on such systems) >> since I bought my current laptop ~three years ago. > > Yes it should work on amd64. If not it's a regression. I am reporting back that I have successfully got my MacBook's Broadcom 4328 to work with a bcmwl5 driver from a Dell driver distribution on amd64 8-CURRENT. The drivers that came with my MacBook were Vista drivers. A few problems: transfers rarely go over 200kb/s, the system dead locks when rebooting, I have to manually run dhclient even though it's set to run in rc.conf, and I get error messages about an unsupported mode. I don't expect any of these problems to get fixed, I would just like others to know what to expect. Chris From eri at freebsd.org Sat Mar 28 12:38:22 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Sat Mar 28 12:38:28 2009 Subject: netgraph modules won't unload after use In-Reply-To: <49C11E56.7090809@elischer.org> References: <6CBA0923-DAF1-4FD5-A670-F5888BCA47B1@aeria.net> <49C11E56.7090809@elischer.org> Message-ID: <9a542da30903281210v1b4ce5a6w148bb60a8a6bc90c@mail.gmail.com> On Wed, Mar 18, 2009 at 5:16 PM, Julian Elischer wrote: > Ash Gokhale wrote: >> >> ?I'm developing a kernel module that will be doing inspection and needed >> access to raw network frames, >> ?so I turned to netgraph ?as the solution.However it seems that netgraph >> will not permit a module >> ?to unload once it's participated in a mkpeer/connect operation. Rebooting >> to remove a module is >> ?angrymaking (not like mtx/sleep crashes). >> >> ? ?This going into the kernel because my bpf based userland stuff is >> probably not going to hold up to the packet rate. >> >> Should I file a PR? Or is there magic in the documentation I havn't found? >> >> >> I've observed the trouble in 7.0 release, and tonight's ?7_RELENG, with >> GENERIC + WITNESS/INVARIANTS >> >> The module code ?( cobbled together from netgraph/ng_sample.c / ng_echo.c) >> http://pastebin.com/m31b6ece6 >> >> The module loads and unloads fine until connected to a netgraph hook: > > hmm they are supposed to, and they did in the past.. > let me check... > > root@trafmon1:kldload ng_ether > root@trafmon1:ifconfig > bge0: flags=8843 metric 0 mtu 1500 > ? ? ? ?options=9b > ? ? ? ?ether 00:11:43:30:fb:8a > ? ? ? ?inet 10.7.2.3 netmask 0xffffff00 broadcast 10.7.2.255 > ? ? ? ?media: Ethernet autoselect (100baseTX ) > ? ? ? ?status: active > bge1: flags=8802 metric 0 mtu 1500 > ? ? ? ?options=9b > ? ? ? ?ether 00:11:43:30:fb:8b > ? ? ? ?media: Ethernet autoselect (none) > ? ? ? ?status: no carrier > fxp0: flags=8843 metric 0 mtu 1500 > ? ? ? ?options=b > ? ? ? ?ether 00:0e:0c:62:aa:14 > ? ? ? ?inet 10.7.0.101 netmask 0xffffff00 broadcast 10.7.0.255 > ? ? ? ?media: Ethernet autoselect (100baseTX ) > ? ? ? ?status: active > lo0: flags=8049 metric 0 mtu 16384 > ? ? ? ?inet 127.0.0.1 netmask 0xff000000 > root@trafmon1:ngctl > + list > There are 4 total nodes: > ?Name: bge0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000002 ? Num hooks: 0 > ?Name: bge1 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000003 ? Num hooks: 0 > ?Name: ngctl4252 ? ? ? Type: socket ? ? ? ? ?ID: 00000005 ? Num hooks: 0 > ?Name: fxp0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000004 ? Num hooks: 0 > + mkpeer bge0: hole lower hook > + list > There are 5 total nodes: > ?Name: ? ? ? Type: hole ? ? ? ? ? ?ID: 00000006 ? Num hooks: 1 > ?Name: bge0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000002 ? Num hooks: 1 > ?Name: bge1 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000003 ? Num hooks: 0 > ?Name: ngctl4252 ? ? ? Type: socket ? ? ? ? ?ID: 00000005 ? Num hooks: 0 > ?Name: fxp0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000004 ? Num hooks: 0 > + shutdown [6]: > + list > There are 4 total nodes: > ?Name: bge0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000002 ? Num hooks: 0 > ?Name: bge1 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000003 ? Num hooks: 0 > ?Name: ngctl4252 ? ? ? Type: socket ? ? ? ? ?ID: 00000005 ? Num hooks: 0 > ?Name: fxp0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000004 ? Num hooks: 0 > + quit > root@trafmon1:kldstat -v > Id Refs Address ? ?Size ? ? Name > ?1 ? 36 0xc0400000 6a9c28 ? kernel (/boot/kernel/kernel) > > [...] > > ?7 ? ?1 0xccb16000 4000 ? ? ng_ether.ko (/boot/kernel/ng_ether.ko) > ? ? ? ?Contains modules: > ? ? ? ? ? ? ? ?Id Name > ? ? ? ? ? ? ? ?246 ng_ether > ?8 ? ?1 0xccb1b000 2000 ? ? ng_hole.ko (/boot/kernel/ng_hole.ko) > ? ? ? ?Contains modules: > ? ? ? ? ? ? ? ?Id Name > ? ? ? ? ? ? ? ?247 ng_hole > root@trafmon1:klunload ng_hole > klunload: Command not found. > root@trafmon1:kldunload ng_hole > root@trafmon1:kldunload ng_ether > kldunload: can't unload file: Device busy > root@trafmon1:kldstat -v > Id Refs Address ? ?Size ? ? Name > ?1 ? 36 0xc0400000 6a9c28 ? kernel (/boot/kernel/kernel) > > [...] > > ?7 ? ?1 0xccb16000 4000 ? ? ng_ether.ko (/boot/kernel/ng_ether.ko) > ? ? ? ?Contains modules: > ? ? ? ? ? ? ? ?Id Name > ? ? ? ? ? ? ? ?246 ng_ether > root@trafmon1: > > > this is expected. ?ng-ether is not unloadable as the connections are too > complicated to unwind easily.. one day.... > > root@trafmon1: > >>> Stop in /root/tmp/food.ko. >>> Exit 1 >>> #Mar 18 03:14:31 ?kernel: quiesced >>> ?:ro:~/tmp/food.ko:3:14:31:32 >>> Mar 18 03:14:31 ?kernel: foodmod unloaded >> >> >> Seems that I can't unload some of the other netgraph types either ( it's >> not just me): >> >>> #kldunload ng_ether >>> :ro:~/tmp/food.ko:3:24:07:41 >>> kldunload: can't unload file: Device busy >>> Exit 1 > > try unloading a node that IS unloadable.. > > see the following comment in ng_ehter.c: > ? ? ? ? /* > ? ? ? ? ?* Note that the base code won't try to unload us until > ? ? ? ? ?* all nodes have been removed, and that can't happen > ? ? ? ? ?* until all Ethernet interfaces are removed. In any > ? ? ? ? ?* case, we know there are no nodes left if the action > ? ? ? ? ?* is MOD_UNLOAD, so there's no need to detach any nodes. > ? ? ? ? ?*/ > > so we can't run this unless you have removeable ethernet interfaces, and > have removed them. > > > Just saw the message. Actually ng_ether can be unloaded but this is left at your own risk and there is a comment in code about this. for each $if in `ifconfig -l` ngctl shutdown $if: kldunload ng_ether This brings the question that should ng_ether be taught about ifnet events(arrival/departure)?! -- Ermal From eri at freebsd.org Sat Mar 28 13:38:44 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Sat Mar 28 13:38:51 2009 Subject: netgraph modules won't unload after use In-Reply-To: <9a542da30903281210v1b4ce5a6w148bb60a8a6bc90c@mail.gmail.com> References: <6CBA0923-DAF1-4FD5-A670-F5888BCA47B1@aeria.net> <49C11E56.7090809@elischer.org> <9a542da30903281210v1b4ce5a6w148bb60a8a6bc90c@mail.gmail.com> Message-ID: <9a542da30903281338h269030e3wbc4d5cbcb66d8e59@mail.gmail.com> On Sat, Mar 28, 2009 at 8:10 PM, Ermal Lu?i wrote: > On Wed, Mar 18, 2009 at 5:16 PM, Julian Elischer wrote: >> Ash Gokhale wrote: >>> >>> ?I'm developing a kernel module that will be doing inspection and needed >>> access to raw network frames, >>> ?so I turned to netgraph ?as the solution.However it seems that netgraph >>> will not permit a module >>> ?to unload once it's participated in a mkpeer/connect operation. Rebooting >>> to remove a module is >>> ?angrymaking (not like mtx/sleep crashes). >>> >>> ? ?This going into the kernel because my bpf based userland stuff is >>> probably not going to hold up to the packet rate. >>> >>> Should I file a PR? Or is there magic in the documentation I havn't found? >>> >>> >>> I've observed the trouble in 7.0 release, and tonight's ?7_RELENG, with >>> GENERIC + WITNESS/INVARIANTS >>> >>> The module code ?( cobbled together from netgraph/ng_sample.c / ng_echo.c) >>> http://pastebin.com/m31b6ece6 >>> >>> The module loads and unloads fine until connected to a netgraph hook: >> >> hmm they are supposed to, and they did in the past.. >> let me check... >> >> root@trafmon1:kldload ng_ether >> root@trafmon1:ifconfig >> bge0: flags=8843 metric 0 mtu 1500 >> ? ? ? ?options=9b >> ? ? ? ?ether 00:11:43:30:fb:8a >> ? ? ? ?inet 10.7.2.3 netmask 0xffffff00 broadcast 10.7.2.255 >> ? ? ? ?media: Ethernet autoselect (100baseTX ) >> ? ? ? ?status: active >> bge1: flags=8802 metric 0 mtu 1500 >> ? ? ? ?options=9b >> ? ? ? ?ether 00:11:43:30:fb:8b >> ? ? ? ?media: Ethernet autoselect (none) >> ? ? ? ?status: no carrier >> fxp0: flags=8843 metric 0 mtu 1500 >> ? ? ? ?options=b >> ? ? ? ?ether 00:0e:0c:62:aa:14 >> ? ? ? ?inet 10.7.0.101 netmask 0xffffff00 broadcast 10.7.0.255 >> ? ? ? ?media: Ethernet autoselect (100baseTX ) >> ? ? ? ?status: active >> lo0: flags=8049 metric 0 mtu 16384 >> ? ? ? ?inet 127.0.0.1 netmask 0xff000000 >> root@trafmon1:ngctl >> + list >> There are 4 total nodes: >> ?Name: bge0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000002 ? Num hooks: 0 >> ?Name: bge1 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000003 ? Num hooks: 0 >> ?Name: ngctl4252 ? ? ? Type: socket ? ? ? ? ?ID: 00000005 ? Num hooks: 0 >> ?Name: fxp0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000004 ? Num hooks: 0 >> + mkpeer bge0: hole lower hook >> + list >> There are 5 total nodes: >> ?Name: ? ? ? Type: hole ? ? ? ? ? ?ID: 00000006 ? Num hooks: 1 >> ?Name: bge0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000002 ? Num hooks: 1 >> ?Name: bge1 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000003 ? Num hooks: 0 >> ?Name: ngctl4252 ? ? ? Type: socket ? ? ? ? ?ID: 00000005 ? Num hooks: 0 >> ?Name: fxp0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000004 ? Num hooks: 0 >> + shutdown [6]: >> + list >> There are 4 total nodes: >> ?Name: bge0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000002 ? Num hooks: 0 >> ?Name: bge1 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000003 ? Num hooks: 0 >> ?Name: ngctl4252 ? ? ? Type: socket ? ? ? ? ?ID: 00000005 ? Num hooks: 0 >> ?Name: fxp0 ? ? ? ? ? ?Type: ether ? ? ? ? ? ID: 00000004 ? Num hooks: 0 >> + quit >> root@trafmon1:kldstat -v >> Id Refs Address ? ?Size ? ? Name >> ?1 ? 36 0xc0400000 6a9c28 ? kernel (/boot/kernel/kernel) >> >> [...] >> >> ?7 ? ?1 0xccb16000 4000 ? ? ng_ether.ko (/boot/kernel/ng_ether.ko) >> ? ? ? ?Contains modules: >> ? ? ? ? ? ? ? ?Id Name >> ? ? ? ? ? ? ? ?246 ng_ether >> ?8 ? ?1 0xccb1b000 2000 ? ? ng_hole.ko (/boot/kernel/ng_hole.ko) >> ? ? ? ?Contains modules: >> ? ? ? ? ? ? ? ?Id Name >> ? ? ? ? ? ? ? ?247 ng_hole >> root@trafmon1:klunload ng_hole >> klunload: Command not found. >> root@trafmon1:kldunload ng_hole >> root@trafmon1:kldunload ng_ether >> kldunload: can't unload file: Device busy >> root@trafmon1:kldstat -v >> Id Refs Address ? ?Size ? ? Name >> ?1 ? 36 0xc0400000 6a9c28 ? kernel (/boot/kernel/kernel) >> >> [...] >> >> ?7 ? ?1 0xccb16000 4000 ? ? ng_ether.ko (/boot/kernel/ng_ether.ko) >> ? ? ? ?Contains modules: >> ? ? ? ? ? ? ? ?Id Name >> ? ? ? ? ? ? ? ?246 ng_ether >> root@trafmon1: >> >> >> this is expected. ?ng-ether is not unloadable as the connections are too >> complicated to unwind easily.. one day.... >> >> root@trafmon1: >> >>>> Stop in /root/tmp/food.ko. >>>> Exit 1 >>>> #Mar 18 03:14:31 ?kernel: quiesced >>>> ?:ro:~/tmp/food.ko:3:14:31:32 >>>> Mar 18 03:14:31 ?kernel: foodmod unloaded >>> >>> >>> Seems that I can't unload some of the other netgraph types either ( it's >>> not just me): >>> >>>> #kldunload ng_ether >>>> :ro:~/tmp/food.ko:3:24:07:41 >>>> kldunload: can't unload file: Device busy >>>> Exit 1 >> >> try unloading a node that IS unloadable.. >> >> see the following comment in ng_ehter.c: >> ? ? ? ? /* >> ? ? ? ? ?* Note that the base code won't try to unload us until >> ? ? ? ? ?* all nodes have been removed, and that can't happen >> ? ? ? ? ?* until all Ethernet interfaces are removed. In any >> ? ? ? ? ?* case, we know there are no nodes left if the action >> ? ? ? ? ?* is MOD_UNLOAD, so there's no need to detach any nodes. >> ? ? ? ? ?*/ >> >> so we can't run this unless you have removeable ethernet interfaces, and >> have removed them. >> >> >> > Just saw the message. > Actually ng_ether can be unloaded but this is left at your own risk > and there is a comment in code about this. > for each $if in `ifconfig -l` > ngctl shutdown $if: actually ngctl msg $if: disconnect > kldunload ng_ether > > This brings the question that should ng_ether be taught about ifnet > events(arrival/departure)?! > > -- > Ermal > -- Ermal From linimon at FreeBSD.org Sun Mar 29 04:44:54 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Mar 29 04:45:00 2009 Subject: kern/133178: [lagg] [wlan] lagg with wlan laggpport does not work Message-ID: <200903291144.n2TBir2E031032@freefall.freebsd.org> Old Synopsis: lagg with wlan laggpport does not work New Synopsis: [lagg] [wlan] lagg with wlan laggpport does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 29 11:44:29 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133178 From c.r.n.a at wanadoo.fr Sun Mar 29 05:09:14 2009 From: c.r.n.a at wanadoo.fr (Nicolas) Date: Sun Mar 29 05:09:20 2009 Subject: iwn(4): Porting Intel 5100/5300 support from OpenBSD? References: 49CE52AA.6060500@freebsd.org Message-ID: <49CF47BE.6030505@wanadoo.fr> Hi, I'm also interested. If you have a patch, I can test it, I have a 5100 card. Thanks in advance, Niko. From fjo-lists at ogris.de Sun Mar 29 06:21:57 2009 From: fjo-lists at ogris.de (Felix J. Ogris) Date: Sun Mar 29 06:22:04 2009 Subject: CARP IP level load balancing In-Reply-To: <278464.35012.qm@web63907.mail.re1.yahoo.com> References: <278464.35012.qm@web63907.mail.re1.yahoo.com> Message-ID: <49CF75F3.6010808@ogris.de> Barney Cordoba wrote: > > > --- On Sun, 3/8/09, Felix J. Ogris wrote: > > >> From: Felix J. Ogris >> Subject: Re: CARP IP level load balancing >> To: freebsd-net@freebsd.org >> Date: Sunday, March 8, 2009, 4:24 AM >> On 1/20/09 3:30 PM, "Alexey Ivanov" >> wrote: >> >> >>> Is there any plans to port IP level LB from OpenBSD, >>> >> and, if yes, will it be >> >>> ported to 7x and 6x? >>> >> Feel free to port http://ogris.de/carp/carp_aa.patch to >> 7.x. >> >> Felix >> >> > > Is there some difference from LAGG? > > Barney > > > > Yes. It is similar to netfilter's clusterip target. Felix From sam at FreeBSD.org Sun Mar 29 10:20:22 2009 From: sam at FreeBSD.org (sam@FreeBSD.org) Date: Sun Mar 29 10:20:28 2009 Subject: kern/133178: [lagg] [wlan] lagg with wlan laggpport does not work Message-ID: <200903291720.n2THKLhb076687@freefall.freebsd.org> Synopsis: [lagg] [wlan] lagg with wlan laggpport does not work Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Sun Mar 29 17:19:47 UTC 2009 Responsible-Changed-Why: take responsibility http://www.freebsd.org/cgi/query-pr.cgi?pr=133178 From ghe at slsware.com Sun Mar 29 14:43:08 2009 From: ghe at slsware.com (ghe) Date: Sun Mar 29 14:43:17 2009 Subject: 7.1 network problem Message-ID: <49CFE6C4.1080809@slsware.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This morning I put 7.1 on a Via box with RealTek 8139C+/8169/8169S/8110S Ethernet card (from sysinstall). I'm new to FreeBSD, but I've been playing with this box to learn a little about the BSD side. The network seems not to work unless the interface (re0) is in promiscuous mode. I don't understand this. arp -a looks reasonable, and it doesn't change when promisc is turned off. ping works to localhost and to re0, but if I start a ping to outside the machine, nothing happens until I enable promisc by starting tcpdump or by issuing a command to ifconfig. Then the echoes start. And disabling stops them again. I don't think it's hardware because this box ran Debian Linux for several months with no problems -- unless maybe the Debian driver kept it in promisc all the time; I didn't look... rc.conf: > # -- sysinstall generated deltas -- # Sun Mar 29 09:52:35 2009 > # Created: Sun Mar 29 09:52:35 2009 > # Enable network daemons for user convenience. > # Please make all changes to this file, not to /etc/defaults/rc.conf. > # This file now contains just the overrides from /etc/defaults/rc.conf. > hostname="otto.slsware.lan" > ifconfig_re0="inet 192.168.3.177 netmask 255.255.255.0" > defaultrouter="192.168.3.1" > font8x14="NO" > font8x16="swiss-8x16" > font8x8="swiss-8x8" > ### linux_enable="YES" > ### nfs_client_enable="YES" > ### saver="daemon" > webmin_enable="YES" > # -- sysinstall generated deltas -- # Sun Mar 29 12:45:49 2009 > gateway_enable="NO" > router_enable="YES" > ftpd_enable="YES" > inetd_enable="YES" > named_enable="YES" > ntpd_enable="YES" > postfix_enable="YES" > routed_enable="YES" > rsyncd_enable="YES" > sshd_enable="YES" ifconfig -a: > re0: flags=8943 metric 0 mtu 1500 > options=389b > ether 00:30:18:a0:29:dc > inet 192.168.3.177 netmask 0xffffff00 broadcast 192.168.3.255 > media: Ethernet autoselect (100baseTX ) > status: active > re1: flags=8802 metric 0 mtu 1500 > options=389b > ether 00:30:18:a0:29:dd > media: Ethernet autoselect (10baseT/UTP ) > status: no carrier > 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 This is with promisc on. The output is identical with it off, except the PROMISC flag is off. - -- Glenn English ghe@slsware.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknP5sMACgkQ04yQfZbbTLa5TQCeKToOFTJKy9B7xkZ1TTV3q2tG yBsAnRzLRjJJlnE1y8ZZFc/L9V1OUtzz =K+D6 -----END PGP SIGNATURE----- From pyunyh at gmail.com Sun Mar 29 18:55:58 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Mar 29 18:56:05 2009 Subject: 7.1 network problem In-Reply-To: <49CFE6C4.1080809@slsware.com> References: <49CFE6C4.1080809@slsware.com> Message-ID: <20090330015453.GA7076@michelle.cdnetworks.co.kr> On Sun, Mar 29, 2009 at 03:23:16PM -0600, ghe wrote: [...] > This morning I put 7.1 on a Via box with RealTek 8139C+/8169/8169S/8110S > Ethernet card (from sysinstall). I'm new to FreeBSD, but I've been > playing with this box to learn a little about the BSD side. > > The network seems not to work unless the interface (re0) is in > promiscuous mode. > > I don't understand this. arp -a looks reasonable, and it doesn't change > when promisc is turned off. ping works to localhost and to re0, but if I > start a ping to outside the machine, nothing happens until I enable > promisc by starting tcpdump or by issuing a command to ifconfig. Then > the echoes start. And disabling stops them again. > Would you show me dmesg output(re(4) related part only)? From ume at FreeBSD.org Mon Mar 30 02:46:43 2009 From: ume at FreeBSD.org (ume@FreeBSD.org) Date: Mon Mar 30 02:49:19 2009 Subject: bin/92370: [pppd] ppp server not accessible to IPV4 unless built with NO_INET6 Message-ID: <200903300946.n2U9kfZv044288@freefall.freebsd.org> Synopsis: [pppd] ppp server not accessible to IPV4 unless built with NO_INET6 State-Changed-From-To: open->feedback State-Changed-By: ume State-Changed-When: Mon Mar 30 09:43:57 UTC 2009 State-Changed-Why: Responsible-Changed-From-To: freebsd-net->ume Responsible-Changed-By: ume Responsible-Changed-When: Mon Mar 30 09:43:57 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=92370 From bugmaster at FreeBSD.org Mon Mar 30 04:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 30 04:08:43 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200903301106.n2UB6uRt054820@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131310 net [netgraph] [panic] 7.1 panics with mpd netgraph interf o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 285 problems total. From davidch at broadcom.com Mon Mar 30 15:53:12 2009 From: davidch at broadcom.com (David Christensen) Date: Mon Mar 30 15:53:19 2009 Subject: Availability of Programmer's Guide for Broadcom 57XX LAN Controllers Message-ID: <5D267A3F22FD854F8F48B3D2B5238193397DC21622@IRVEXCHCCR01.corp.ad.broadcom.com> For those who are interested in working on the bge(4) driver, Broadcom has now posted its Programmer's Guide at http://www.broadcom.com/collateral/pg/57XX-PG105-R.pdf. This document covers most of the older chips including 5700, 5701, 5703, 5704, 5714, and 5721, though since much of the architecture is shared with newer chips such as 5754 and 5761, it is still a useful reference. We're working on releasing the PG's for other members of the bge(4) family and also the PG for the bce(4) family soon. Dave From linimon at FreeBSD.org Mon Mar 30 22:50:04 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Mar 30 22:50:10 2009 Subject: kern/133235: [netinet] [patch] Process SIOCDLIFADDR command incorrectly in in_control() Message-ID: <200903310550.n2V5o22X075727@freefall.freebsd.org> Old Synopsis: Process SIOCDLIFADDR command incorrectly in in_control() New Synopsis: [netinet] [patch] Process SIOCDLIFADDR command incorrectly in in_control() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 31 05:49:29 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133235 From sfourman at gmail.com Mon Mar 30 23:39:00 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Mon Mar 30 23:39:07 2009 Subject: 802.11 QinQ in need of some help Message-ID: <11167f520903302315u28f2dffdqe79f493a49b96863@mail.gmail.com> Hello List, I have searched hi and low, and I have not found the answer to my question, So I am seeking help. We have a small dedicated server webhosting company, and we need support for QinQ vlan tags actually I need the following Customers Vlan tag our Vlan tag aka service provider Would someone have the spare time, to provide me with a working sample on how to use ng_vlan on a bridge between Customer and core service network to apply at least Double stacked VLAN tags, I am confused on how to Double tag specific Ethernet frames with a specific "Service Provider tag" based on destination ip address. and then how to "unstack the frame on the other end" Thank you very much for your time Sam Fourman Jr. From ivan at serezhkin.com Tue Mar 31 00:00:10 2009 From: ivan at serezhkin.com (Vany Serezhkin) Date: Tue Mar 31 00:00:16 2009 Subject: kern/132885: [wlan] 802.1x broken after SVN rev 189592 Message-ID: <200903310700.n2V709k6072929@freefall.freebsd.org> The following reply was made to PR kern/132885; it has been noted by GNATS. From: Vany Serezhkin To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132885: [wlan] 802.1x broken after SVN rev 189592 Date: Tue, 31 Mar 2009 10:35:57 +0400 Hello again. In last weekend i update system and this bug is 'magically' disappeared. All works now. -- Vany Serezhkin. Yandex. http://yandex.ru/ From sergey at vavilov.org Tue Mar 31 01:25:29 2009 From: sergey at vavilov.org (Sergey Vavilov) Date: Tue Mar 31 01:25:39 2009 Subject: Availability of Programmer's Guide for Broadcom 57XX LAN Controllers In-Reply-To: <5D267A3F22FD854F8F48B3D2B5238193397DC21622@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B5238193397DC21622@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <49D1D019.6090906@vavilov.org> Hello! BCM5721 now supported in 7.1-RELEASE ? Thank you! David Christensen wrote: > For those who are interested in working on the bge(4) driver, Broadcom has now posted its Programmer's Guide at http://www.broadcom.com/collateral/pg/57XX-PG105-R.pdf. This document covers most of the older chips including 5700, 5701, 5703, 5704, 5714, and 5721, though since much of the architecture is shared with newer chips such as 5754 and 5761, it is still a useful reference. We're working on releasing the PG's for other members of the bge(4) family and also the PG for the bce(4) family soon. > > Dave > _______________________________________________ > 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" > -- Sergey Vavilov, Perm, Russia From liangzy at arraynetworks.com.cn Tue Mar 31 03:40:03 2009 From: liangzy at arraynetworks.com.cn (LiangZhenyu) Date: Tue Mar 31 03:40:10 2009 Subject: kern/133235: [netinet] [patch] Process SIOCDLIFADDR command incorrectly in in_control() Message-ID: <200903311040.n2VAe314002561@freefall.freebsd.org> The following reply was made to PR kern/133235; it has been noted by GNATS. From: LiangZhenyu To: bug-followup@FreeBSD.org, soflare@gmail.com Cc: Subject: Re: kern/133235: [netinet] [patch] Process SIOCDLIFADDR command incorrectly in in_control() Date: Tue, 31 Mar 2009 18:02:50 +0800 The long expression: candidate.s_addr = ((struct sockaddr_in *)&ifa->ifa_addr)->sin_addr.s_addr; will cause a compilation problem in my machine. The target can be generated but was wrong. So I split it to 2 short expressions. From sepron at gmail.com Tue Mar 31 05:40:02 2009 From: sepron at gmail.com (Sergey Pronin) Date: Tue Mar 31 05:40:09 2009 Subject: kern/132984: [netgraph] swi1: net 100% cpu usage Message-ID: <200903311240.n2VCe2qR068732@freefall.freebsd.org> The following reply was made to PR kern/132984; it has been noted by GNATS. From: Sergey Pronin To: bug-followup@FreeBSD.org, vlad@prokk.net Cc: Subject: Re: kern/132984: [netgraph] swi1: net 100% cpu usage Date: Tue, 31 Mar 2009 15:01:39 +0300 --001636c5a72e353f32046668f6ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This bug is also related to: http://lists.freebsd.org/pipermail/freebsd-net/2009-March/021345.html http://lists.freebsd.org/pipermail/freebsd-net/2009-March/021518.html I've experienced the same problem with: FreeBSD 7.1-RELEASE-p1 and p2 FreeBSD 7.0-RELEASE-p9 and p10 FreeBSD 6.4-RELEASE-p3 --001636c5a72e353f32046668f6ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This bug is also related to:
http://lists.freebsd.org/pipermail/f= reebsd-net/2009-March/021345.html
http://lists.freebsd.org/pi= permail/freebsd-net/2009-March/021518.html

I've experienced=
  the same problem with:
FreeBSD 7.1-RELEASE-p1 and p2
FreeBSD 7.0-REL=
 EASE-p9 and p10
FreeBSD 6.4-RELEASE-p3

--001636c5a72e353f32046668f6ec--