Re: ipfw: Too many dynamic rules
On Thu, 9 Sep 2010, Vlad Galu wrote: > 2010/9/9 Marat N.Afanasyev : > > I wonder, are these dynamic rules really necessary? let's see, a client > > connects to your web-server and you immediately should create a new dynamic > > rule, therefore you participate in this DoS attack as well as attacker. ;) > > With a stateless firewall, you help the attacker even more. Because > he's able to connect to your httpd/whatever daemon is listening > directly and he can easily fill up the descriptor table of that > process. Limiting the number of states/connections from the same host > prevents that. Sure, those states eat up RAM, but so do the > established connections. Having a slightly more aggressive state > expiry policy always helps. Sure, there are accf_http(9), accf_data(9) > and various forking workarounds, but they don't work unless your TCP > server is specifically designed to use them. Agreed. > PF also allows you to tarpit malicious hosts based on how often they > try to reconnect - you can dynamically add them to a table which you > can refer to from ALTQ. As mentioned, ipfw 'limit' rules accomplish effectively the same without needing an extra table; eg only allowing N simultaneous connections from any one address. If N were say 4, even a distributed attack by 20 hosts will only allow 80 concurrent connections, no big deal for the firewall and no need to bother trying to limit connections later at the server. That said, I've also tables blocking noted pests, including some recent distributed bots seeking eg blocklist='scripts/setup.php p=phpinfo();' which irritated me enough to knock up a script to knock them off :) BTW, Gareth: ... while talking to mail.lordcow.org.: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote: > On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > > > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > > > Hi! > > > > > > > > > > Is this within a jail or something else along those lines? I can't > > > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > > > list > > > > > > might have ideas as to what could cause this. > > > > > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > > > would affect this? > > > > > > > > I assume it affects it. > > > > > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > > > > > Basically, when the securelevel is positive, the kernel restricts > > > > certain tasks; not even the superuser (i.e., root) is allowed to > > > > do them. > > > > > > > > There: > > > > > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > > > > > So I assume it also restricts reading /dev/kmem ? > > > > > > > > > > > OH YUCK, another root isn't really root, so is it also possibly > > > the reason for the MSIX failure?? Is this pile, er feature, on by > > default? > > > > securelevel does not affect any of the MSI/MSI-X bits. > > > > Well then there's something else funny going on with that hardware, as at > least MSI should work with the chipset, I am not able to get that exact > skew from what I am told. I think the first would be to disable the MSI blacklists via a tunable to see if that enables MSI. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > Hi! > > > > > > Is this within a jail or something else along those lines? I can't > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > list > > > > might have ideas as to what could cause this. > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > would affect this? > > > > I assume it affects it. > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > Basically, when the securelevel is positive, the kernel restricts > > certain tasks; not even the superuser (i.e., root) is allowed to > > do them. > > > > There: > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > So I assume it also restricts reading /dev/kmem ? > > > > > OH YUCK, another root isn't really root, so is it also possibly > the reason for the MSIX failure?? Is this pile, er feature, on by default? securelevel does not affect any of the MSI/MSI-X bits. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Enabling MCA causes system hangs
Hi, I recently tried enabling MCA (ie w.mca.enabled=1 in loader.conf) on an 8.0-STABLE system and found that it would cause the system to hang after a few minutes of uptime. The screen would go black and the monitor would turn off (regardless of wether it was in X or not) and only a hard reset would bring it back. Also I found that quite often I had to power cycle the whole PC or the BIOS wouldn't detect the hard disks on boot(!) after a hang. uname is.. FreeBSD midget.dons.net.au 8.0-STABLE FreeBSD 8.0-STABLE #6 r202903M: Sun Jan 24 13:45:11 CST 2010 dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 The motherboard is a Gigabyte GA-MA785GM-US2H with an Athlon II X2 240 CPU & 4Gb of RAM. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I4B: what happened, which options? [was: Policy for removing working code]
On Thu, 9 Sep 2010, Kevin Oberman wrote: Hey, I think I should try to summarize parts of the ISDN topic, which I have been disconnected from for more than 2 years now, to make this tail of a thread more helpful maybe. I agree that later release notes could have mentioned it but neither did they mention that it was back and I cannot remember anyone complaining about netatm not coming back either until now, nor can I remember many complaints after freebsd 7.0 which was more than 2 years ago. I am Cc:ing freebsd-isdn@ as that list exists and has been for years. Check the archives for the overwhelming interest. If ISDN is in any way interesting to you, respect the Reply-To: The temporary disconnect was announced there (which is where the plan to bring it back came from): http://lists.freebsd.org/pipermail/freebsd-isdn/2007-July/000711.html There was a call for help (also with GSoC): http://lists.freebsd.org/pipermail/freebsd-isdn/2008-March/000833.html There was a notice that the code will be removed: http://lists.freebsd.org/pipermail/freebsd-isdn/2008-May/000842.html And there was an UPDATING entry with the removal: http://svn.freebsd.org/viewvc/base?view=revision&revision=179315 There was probably more but those were the once I found again within five minutes. So what are the options and what is out there now and there are a few, depending on your needs: 1) the FreeBSD Foundation is sponsoring a project currently: "DAHDI FreeBSD driver port" http://www.freebsdfoundation.org/project%20announcements.shtml#Max 2) I am (was) still running C4B on amd64 on RELENG_8 with a privately hacked together capi call log, which is a hack without me even thinking about capi (specs) when doing it, but was doing the job for me for 7 and 8. Getting the last C4B compiled for 8/HEAD or amd64 isn't a lot of patching and I can probably provide patches to you, if you want to make it a port. The PRIV constants needed for this in the base system have been shiping for a while: http://svn.freebsd.org/viewvc/base?view=revision&revision=192577 3) HPSI4B exists and he seems to maintain it. If you need old drivers for cards he doesn't support, talk to him if you want to use or are using his stack with other cards. 4) The old I4B code is still here and could be brought back from Attic if someone was to invest the resources (time, coding or money, ...). People tried back then but failed for ETIME. It's not only locking. The device drivers and layers are written in a RELENG_4ish way and my conclusion was that it'll end in a partial re-write. I still have cards and I still have a machine with ISA slots to test things. If someone fixes the infrastructure and 1 driver I'll also happily ship them so (s)he can do the others as well and test and maintain things for the next couple of years. Pick your poison;-) HTH /bz -- Bjoern A. Zeeb Welcome a new stage of life. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipfw: Too many dynamic rules
2010/9/9 Marat N.Afanasyev : > I wonder, are these dynamic rules really necessary? let's see, a client > connects to your web-server and you immediately should create a new dynamic > rule, therefore you participate in this DoS attack as well as attacker. ;) With a stateless firewall, you help the attacker even more. Because he's able to connect to your httpd/whatever daemon is listening directly and he can easily fill up the descriptor table of that process. Limiting the number of states/connections from the same host prevents that. Sure, those states eat up RAM, but so do the established connections. Having a slightly more aggressive state expiry policy always helps. Sure, there are accf_http(9), accf_data(9) and various forking workarounds, but they don't work unless your TCP server is specifically designed to use them. PF also allows you to tarpit malicious hosts based on how often they try to reconnect - you can dynamically add them to a table which you can refer to from ALTQ. -- Good, fast & cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipfw: Too many dynamic rules
> Date: Thu, 09 Sep 2010 22:03:10 +0400 > From: "Marat N.Afanasyev" > Sender: owner-freebsd-sta...@freebsd.org > > Gareth de Vaux wrote: > > Hi again, I use some keep-state rules in ipfw, but get the following > > kernel message: > > > > kernel: ipfw: install_state: Too many dynamic rules > > > > when presumably my state table reaches its limit (and I effectively > > get DoS'd). > > > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > > simply be reached later on. > > > > I currently get around this with a cronjob that sets > > net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes > > every night. If I leave it at 0 for longer or indefinitely then > > idle ssh sessions and the like are dropped. This works fine for > > me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? > > Or with Apache? > > > > I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour > > on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I > > have a KeepAliveTimeout of 4 in Apache (2.2.16). > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > I wonder, are these dynamic rules really necessary? let's see, a client > connects to your web-server and you immediately should create a new > dynamic rule, therefore you participate in this DoS attack as well as > attacker. ;) I'll be more blunt...stateful firewalls should NEVER be placed in front of externally accessible services. Access filters are fine, but stateful firewalls are nothing but a denial of service waiting to happen. Security pros have always know this, but too many folks insist that there be a firewall in front of everything and that is simply an invitation to problems. Marat is right! Just don't even try. An attacker can ALWAYS overwhelm the state tables in a stateful firewall. It's just way too easy. There was a long discussion of this a while back on a network ops list I participate in and noobs kept claiming that you have to have a stateful firewall in front of everything while the real operational security folks (like those at Y! and Google) kept explaining that it just does not work. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
Gareth's email bouncing for anybody else or is it just me? Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot btw. Tell me more exactly the make/model of the hardware so I might try to get my hands on one? Jack On Thu, Sep 9, 2010 at 1:20 PM, John Baldwin wrote: > On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote: > > On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > > > > > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > > > > > Hi! > > > > > > > > > > > > Is this within a jail or something else along those lines? I > can't > > > > > > > reproduce the problem otherwise. Frustrating! Someone else on > the > > > > > list > > > > > > > might have ideas as to what could cause this. > > > > > > > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt > that > > > > > > would affect this? > > > > > > > > > > I assume it affects it. > > > > > > > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > > > > > > > Basically, when the securelevel is positive, the kernel restricts > > > > > certain tasks; not even the superuser (i.e., root) is allowed to > > > > > do them. > > > > > > > > > > There: > > > > > > > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > > > > > > > So I assume it also restricts reading /dev/kmem ? > > > > > > > > > > > > > > OH YUCK, another root isn't really root, so is it also possibly > > > > the reason for the MSIX failure?? Is this pile, er feature, on by > > > default? > > > > > > securelevel does not affect any of the MSI/MSI-X bits. > > > > > > > Well then there's something else funny going on with that hardware, as at > > least MSI should work with the chipset, I am not able to get that exact > > skew from what I am told. > > I think the first would be to disable the MSI blacklists via a tunable to > see > if that enables MSI. > > -- > John Baldwin > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > Hi! > > > > > > > > Is this within a jail or something else along those lines? I can't > > > > > reproduce the problem otherwise. Frustrating! Someone else on the > > > list > > > > > might have ideas as to what could cause this. > > > > > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > > > would affect this? > > > > > > I assume it affects it. > > > > > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > > > > > Basically, when the securelevel is positive, the kernel restricts > > > certain tasks; not even the superuser (i.e., root) is allowed to > > > do them. > > > > > > There: > > > > > > # Write to kernel memory via /dev/mem and /dev/kmem. > > > > > > So I assume it also restricts reading /dev/kmem ? > > > > > > > > OH YUCK, another root isn't really root, so is it also possibly > > the reason for the MSIX failure?? Is this pile, er feature, on by > default? > > securelevel does not affect any of the MSI/MSI-X bits. > Well then there's something else funny going on with that hardware, as at least MSI should work with the chipset, I am not able to get that exact skew from what I am told. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipfw: Too many dynamic rules
Gareth de Vaux wrote: Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. I currently get around this with a cronjob that sets net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes every night. If I leave it at 0 for longer or indefinitely then idle ssh sessions and the like are dropped. This works fine for me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? Or with Apache? I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I have a KeepAliveTimeout of 4 in Apache (2.2.16). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) may be using ipfw add XXX allow tcp from me 80 to any would be enough? I usually use keep-state rules only for outgoing connections and try to keep number of such rules as few as possible. if you're afraid of somebody trying to attack your servers using unopened connections you may filter out connections that aren't established. you can try to change, of course, net.inet.ip.fw.dyn_*_lifetime variables, but I think that using dynamic rules to filter out web-server answers is not as good practice as it seems. -- SY, Marat
Re: Policy for removing working code
> Date: Thu, 09 Sep 2010 12:33:57 +0300 > From: Andriy Gapon > Sender: owner-freebsd-sta...@freebsd.org > > on 09/09/2010 11:22 per...@pluto.rain.com said the following: > > Good, perhaps even "necessary", but is it "sufficient"? Those > > following a -STABLE branch are expected to read stable@, but > > what about those who are following a security branch? > > People, who care, are expected to read current@ and stable@ even if > they use only releases and security branches. At the very least, to > see what's cooking up for them and what to expect. > > P.S. I am surprised that this thread isn't over yet and is being kept > alive by people who do not seem to use the feature in question or > offer any work on it. While people, who really need it, have already > found a way forward for themselves. > > P.P.S. Please, please, let it go now. Watch current@, watch stable@ > and speak up next time such an announcement is made. Do it on time, > don't wait until a few years later :-) The point is that people running release code and release+security are NOT expected to be reading either stable or current. They should be reading the release notes, but the dropping of ISDN support was only mentioned in the 7.0 release notes and it stated: "ISDN4BSD and netatm have been temporarily disconnected from the build. These modules all require the Giant kernel lock for their operation; disconnecting them allows the removal of the NET_NEEDS_GIANT compatability (sic) shim. It is planned to convert these modules to fine-grained kernel locking and re-connect them for FreeBSD 7.1-RELEASE." Even if you read this, (ignoring the spelling error) you would not expect them to be gone in 7.3 or 8.1. I must say that this was very poorly documented for the "typical" user who happens to need ISDN. Yes, the code needed removal, but when a major capability is removed, it really needs to be better noted. Since the 7.0 release notes said that ISDN4BSD would be back in 7.1, the 7.1 notes should have mentioned that it was not and might not be back. I also think that, once the decision to remove all devices that required GIANT and most of the dust had settled (i.e. jhb and others had converted most of the drivers to not use GIANT) and the plea went out for people to test/patch the remaining devices, it would have been appropriate to send a message to that effect to announce. Let's face it, the removal of GIANT from the network stack was a major change and it was likely to impact users of the sub-systems removed. If they did the "usual" and skipped the ".0" release, they never installed 7.0 and probably did not read the release notes. It was never mentioned in the announcements, either. While the removal was needed, it really needed to be better publicized. ISDN is still in use. We support it (not with FreeBSD) and, if it fails, the mail comes pouring in, usually from outside of the US and the often from places where other forms of broadband Internet are not readily available or from those using appliances that use ISDN for network connectivity. This is a volunteer effort. When we screw up, and we do, we should say "sorry" and try not to do it again, not spend time sending responses that the users are at fault. Leave that to the commercial operations who do it regularly. Personally, I think we screwed up. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipfw: Too many dynamic rules
On Thu, 9 Sep 2010, Gareth de Vaux wrote: > Hi again, I use some keep-state rules in ipfw, but get the following > kernel message: > > kernel: ipfw: install_state: Too many dynamic rules > > when presumably my state table reaches its limit (and I effectively > get DoS'd). > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > simply be reached later on. Try using 'limit' rather than the unlimited 'keep-state' for inbound dynamic connections to your server/s. eg, derived from ipfw(8): ipfw add allow tcp from any to me 80 setup limit src-addr 4 ".. can be placed on a server to make sure that a single client does not use more than 4 simultaneous connections." You could add 'in recv $ext_if' to avoid limiting internal clients. > I currently get around this with a cronjob that sets > net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes > every night. If I leave it at 0 for longer or indefinitely then > idle ssh sessions and the like are dropped. This works fine for > me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? > Or with Apache? Limiting the number of source connections per source address to what apache is happy to deal with, you mightn't need to fuss with that? cheers, Ian > I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour > on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I > have a KeepAliveTimeout of 4 in Apache (2.2.16). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)
On 09/08/2010 06:44, Vadim Goncharov wrote: > Hi Mark Linimon! > > On Wed, 8 Sep 2010 07:30:19 +; Mark Linimon wrote about 'Re: HEADS UP: > FreeBSD 6.4 and 8.0 EoLs coming soon': > The reason is performance for overall network stack, not ideology. > >>> For a practical reasons, "it works but slow" is better than >>> "doesn't work at all (due to absence of code in the src tree)". >>> "Make it work. Make it right. Make it fast. In that order", know this? >>> Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is >>> it?.. >> >> It wasn't "it works but slow". It was "it works, but networking throughput >> is limited on the modern hardware that the majority of our users employ". >> In particular, IIUC, 10GB network drivers were suffering under the old >> strategy. We simply were not competitive with other OSes, and we have >> many multiples more users interested in 10GBE than in ISDN. > > I understand that we need to support modern fast hardware but that doesn't > mean > we should drop working features for that. And... > >>> You do not understand the problem. It is not in notices & volunteers, but >>> rather in the Project's policy - delete something which could still work. >> >> You do not understand how this was handled. > > ...and how this is handled in other OSes to which we have compete, er? They > all > also do dropping features to frighten away old users? Are there no alternative > ways to handle? Put network Giant code into bunch of #ifdef's, after all. > >> The situation was: an announcement was made that "in X months, all network >> drivers need to be made to run Giant-free so that FreeBSD can drop Giant >> from the neworking stack to move forward." Within that period, most of >> the drivers were updated. Repeated postings were made to the mailing list >> that "the following drivers still have not been converted, and need to be >> updated or they will be dropped." They weren't; they were droppped. > > No. See my answer to vwe@ that there were no proper announcements. With them, > for example, someone could get sponsored to update these drivers which were > needed by those FreeBSD users who can't maintain code themselves. That's a > last > resort, more likely volunteers will come, but you get the idea. > >> So while it could "still" work, it was slowing down progress. > > If it is not ideology, then what is it?.. > >> The fact of the matter is, FreeBSD is a big project with a finite number >> of developers. We try to keep as much coverage of systems as we can, but >> a reality of any large software engineering project is that older features >> sometimes have to be dropped to make progress. > >>From time to time such critical cases could possibly be handled by another > ways, I've mentioned one possible above. > >> The code still exists in the repository for any interested party to pick >> up and modernize. > > I hope that for this particular case alternative from ports will be enough. > But policy is not tied to one particular case, alas. > Would you please stop provoking a situation for which you are no more involved in other than running FreeBSD. Thank you. PS: The website in your signature is broke. This should give you enough to do for a while. -- jhell,v ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
Hi! > > Basically, when the securelevel is positive, the kernel restricts > > certain tasks; not even the superuser (i.e., root) is allowed to > > do them. > OH YUCK, another root isn't really root, so is it also possibly > the reason for the MSIX failure?? Is this pile, er feature, on by default? No, not by default. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > Hi! > > > > Is this within a jail or something else along those lines? I can't > > > reproduce the problem otherwise. Frustrating! Someone else on the > list > > > might have ideas as to what could cause this. > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > would affect this? > > I assume it affects it. > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > Basically, when the securelevel is positive, the kernel restricts > certain tasks; not even the superuser (i.e., root) is allowed to > do them. > > There: > > # Write to kernel memory via /dev/mem and /dev/kmem. > > So I assume it also restricts reading /dev/kmem ? > > OH YUCK, another root isn't really root, so is it also possibly the reason for the MSIX failure?? Is this pile, er feature, on by default? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build 8.1 GENERIC kernel
On Thu 09 Sep 2010 at 08:35:29 -0700, Jeremy Chadwick wrote: > Regardless, when it comes to building world and kernel, you should > follow the instructions in /usr/src/Makefile (there's 11 steps). Do not > skip steps, and do not avoid steps (such as doing installkernel then > skipping the boot-into-single-user step before doing installworld; this > may work the majority of the time, but I've seen cases where /libexec > binaries don't get updated without going into single-user, and the > result is a system that breaks immediately). Fortunately, I was not upgrading anything, just reducing my kernel size a bit (well, almost by half) by eliminating support for hardware that isn't applicable. Sources and installed kernel and userland were the result of ``freebsd-update'' so they should all be up to date and in sync. I'm now trying a cross-build run, I'm curious how it compares with NetBSD. (NetBSD always builds (cross-) tools when building the world. In particular when building a major upgrade this is convenient, since then you can always be sure to be building with up-to-date tools) -Olaf. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipfw: Too many dynamic rules
On Thu, Sep 09, 2010 at 05:39:02PM +0200, Gareth de Vaux wrote: > Hi again, I use some keep-state rules in ipfw, but get the following > kernel message: > > kernel: ipfw: install_state: Too many dynamic rules > > when presumably my state table reaches its limit (and I effectively > get DoS'd). > > netstat shows tons of connections in FIN_WAIT_2 state, mostly to > my webserver. Consequently net.inet.ip.fw.dyn_count is large too. > > I can increase my net.inet.ip.fw.dyn_max but the new limit will > simply be reached later on. > > I currently get around this with a cronjob that sets > net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes > every night. If I leave it at 0 for longer or indefinitely then > idle ssh sessions and the like are dropped. This works fine for > me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? > Or with Apache? > > I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour > on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I > have a KeepAliveTimeout of 4 in Apache (2.2.16). Firstly, I'm not familiar with dynamic firewall rules in ipfw. I tend to use pf these days, with ALTQ for rate-limiting. pf offers a lot of improvements over ipfw. Secondly, I'm fairly certain HTTP KeepAlive (re: KeepAliveTimeout) are unrelated to TCP keepalives[1]. I mention this because you're focusing on netstat, which will give you indication of TCP session state, not HTTP protocol statefulness. Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you should consider adjusting the following sysctl: net.inet.tcp.finwait2_timeout Try something like 15000 (15 seconds) instead of the default (6). Finally, why are you using dynamic firewall rules at all? For what purpose do you need these that, say, pf and its state tracking would not suffice? [1]: http://en.wikipedia.org/wiki/Keepalive -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ipfw: Too many dynamic rules
Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. I currently get around this with a cronjob that sets net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes every night. If I leave it at 0 for longer or indefinitely then idle ssh sessions and the like are dropped. This works fine for me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? Or with Apache? I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I have a KeepAliveTimeout of 4 in Apache (2.2.16). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build 8.1 GENERIC kernel
On Thu, Sep 09, 2010 at 05:24:00PM +0200, Olaf Seibert wrote: > Thomas Ronner wrote: > > > I don't know about the old-fashioned way, but the new way is: > > > > # cd /usr/src > > # make buildkernel KERNCONF=GENERIC > > # make installkernel KERNCONF=GENERIC > > Thank you, that worked. > > I wonder what the underlying difference is; probably something fairly > subtle. The same hack.So file was generated (byte for byte identical). > And something changed between 8.0 and 8.1, since previously, the > old-fashioned method worked. Not sure (it's been a long time since I configured a kernel the old way, dating back to 2.x), but possibly it has to do with the introduction of /usr/obj. Your "file" command doesn't indicate what your working directory was at the time. Regardless, when it comes to building world and kernel, you should follow the instructions in /usr/src/Makefile (there's 11 steps). Do not skip steps, and do not avoid steps (such as doing installkernel then skipping the boot-into-single-user step before doing installworld; this may work the majority of the time, but I've seen cases where /libexec binaries don't get updated without going into single-user, and the result is a system that breaks immediately). You should also build world before building kernel; as I understand it, the binaries built during buildworld will be used to build the kernel. There have been many situations in the past where not doing this has broken the build process (e.g. a new feature/flag/etc. being introduced which exists via the /usr/obj/usr/bin/whatever binary, but not /usr/bin/whatever). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build 8.1 GENERIC kernel
Thomas Ronner wrote: > I don't know about the old-fashioned way, but the new way is: > > # cd /usr/src > # make buildkernel KERNCONF=GENERIC > # make installkernel KERNCONF=GENERIC Thank you, that worked. I wonder what the underlying difference is; probably something fairly subtle. The same hack.So file was generated (byte for byte identical). And something changed between 8.0 and 8.1, since previously, the old-fashioned method worked. -Olaf. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu 2010-09-09 (16:54), Kurt Jaeger wrote: > -c asks for pci device capabilities, which are read in > > /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR Ah. I'll have to schedule a reboot then .. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
Jeremy Chadwick wrote: On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote: On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: That was as root, # id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) # pciconf -lc pciconf: /dev/pci: Operation not permitted Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. A kern.securelevel of 1 or higher would also cause this to happen. -Boris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
Hi! > > > Is this within a jail or something else along those lines? I can't > > > reproduce the problem otherwise. Frustrating! Someone else on the list > > > might have ideas as to what could cause this. > > > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > > would affect this? > > I assume it affects it. > > http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL > > Basically, when the securelevel is positive, the kernel restricts > certain tasks; not even the superuser (i.e., root) is allowed to > do them. > > There: > > # Write to kernel memory via /dev/mem and /dev/kmem. > > So I assume it also restricts reading /dev/kmem ? -c asks for pci device capabilities, which are read in /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR I guess that's it. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu, Sep 9, 2010 at 4:22 PM, Gareth de Vaux wrote: > On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: > > You need to be root to use the -c flag. Despite your prompt, I don't > > think you're root. Reproduction: > > That was as root, > > # id > uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) > # pciconf -lc > pciconf: /dev/pci: Operation not permitted > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > perhaps you should lower your kernel securelevel? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot install using serial console
On 7 September 2010 18:50, Jeremie Le Hen wrote: > Hi list, > > => Please Cc: me when replying, as I am not subscribed. <= > > I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think > it's important here) in a KVM-backed virtual machine on a headless Linux > host, following section 2.12.1 of the handbook. > http://www.freebsd.org/doc/handbook/install-advanced.html > > I've rebuilt the ISO image with the following lines in boot/loader.conf: > console="comconsole" > beastie_disable="YES" > > The kernel boots correctly (see output below) but the output invariably > stalls after the following lines: > Trying to mount root from ufs:/dev/md0 > /stand/sysinstal > > (Yes, only one `l'.) > > Any idea? > [strip] > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus0 > uhub0: 2 ports with 2 removable, self powered > Trying to mount root from ufs:/dev/md0 > As far as I know you need also to enable a serial terminal in /etc/ttys. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
on 09/09/2010 17:07 Vadim Goncharov said the following: > > Because this thread is not about this feature but about policy which will > slowly bring FreeBSD project to troubles if nothing will be changed. Your opinion is noted. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
Hi! > > Is this within a jail or something else along those lines? I can't > > reproduce the problem otherwise. Frustrating! Someone else on the list > > might have ideas as to what could cause this. > > Nope, this's a normal host. I've got securelevel on 1, but doubt that > would affect this? I assume it affects it. http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. There: # Write to kernel memory via /dev/mem and /dev/kmem. So I assume it also restricts reading /dev/kmem ? -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu 2010-09-09 (07:24), Jeremy Chadwick wrote: > Is this within a jail or something else along those lines? I can't > reproduce the problem otherwise. Frustrating! Someone else on the list > might have ideas as to what could cause this. Nope, this's a normal host. I've got securelevel on 1, but doubt that would affect this? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote: > On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: > > You need to be root to use the -c flag. Despite your prompt, I don't > > think you're root. Reproduction: > > That was as root, > > # id > uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) > # pciconf -lc > pciconf: /dev/pci: Operation not permitted Is this within a jail or something else along those lines? I can't reproduce the problem otherwise. Frustrating! Someone else on the list might have ideas as to what could cause this. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote: > You need to be root to use the -c flag. Despite your prompt, I don't > think you're root. Reproduction: That was as root, # id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) # pciconf -lc pciconf: /dev/pci: Operation not permitted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't build 8.1 GENERIC kernel
Hi Olaf, On 09/09/2010 16:17, Olaf Seibert wrote: I'm trying to build a custom kernel, and I got an error. So I tried GENERIC, in the perhaps old-fashioned way of # config GENERIC # cd ../compile/GENERIC # make depend # make I don't know about the old-fashioned way, but the new way is: # cd /usr/src # make buildkernel KERNCONF=GENERIC # make installkernel KERNCONF=GENERIC The KERNCONF=GENERIC is redundant, because the GENERIC config is default. Thomas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Can't build 8.1 GENERIC kernel
I'm trying to build a custom kernel, and I got an error. So I tried GENERIC, in the perhaps old-fashioned way of # config GENERIC # cd ../compile/GENERIC # make depend # make and I get a complaint about a file named ``hack.So''. Here is what happens if I remove it again to get it re-made: $ sudo make :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh ../../../conf/newvers.sh GENERIC cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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../../.. -I../../../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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug hack.So: could not read symbols: File in wrong format *** Error code 1 Stop in /usr/src/sys/amd64/compile/GENERIC. Am I the only one who is seeing this? ``file'' thinks this: $ file hack.So hack.So: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, not stripped -Olaf. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
Hi Andriy Gapon! On Thu, 09 Sep 2010 12:33:57 +0300; Andriy Gapon wrote about 'Re: Policy for removing working code': >> Good, perhaps even "necessary", but is it "sufficient"? Those >> following a -STABLE branch are expected to read stable@, but >> what about those who are following a security branch? > People, who care, are expected to read current@ and stable@ even if they use > only releases and security branches. At the very least, to see what's cooking > up for them and what to expect. Hey, by whom expected? They are NOT expected to do this! Can you quote some official docs or statements for this? > P.S. I am surprised that this thread isn't over yet and is being kept alive by > people who do not seem to use the feature in question or offer any work on it. > While people, who really need it, have already found a way forward for > themselves. Because this thread is not about this feature but about policy which will slowly bring FreeBSD project to troubles if nothing will be changed. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mountd has resolving problems
On Thu, Sep 09, 2010 at 03:10:17PM +0200, Olaf Seibert wrote: > I just upgraded a box from 8.0 to 8.1, and already when rebooting with > the new kernel (i.e. before installing new userland), I got the > following problem. > > Of course many of the messages scrolled off screen, but some were > preserved in the syslog. > > Sep 9 14:26:51 fourquid mountd[839]: can't get address info for host XYZ > Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, > skipping > > Mountd was run and wanted to determine which hosts to export to. > However, it could not resolve any of them. So, that suggests some > network issue. > > However, I use a static IP address (no DHCP) and static info in > /etc/resolv.conf, using one of the university's name servers. So > resolving should always be available. > > Running /etc/rc.d/mountd restart so far always solved the export > problem. > > I have also seen (presumably similar) issues with mounting NFS file > systems, but that was deemed so fatal that the boot was aborted. A mount > ``by hand'' of the affected file system also worked. > > Any ideas? Maybe with the new kernel the network interface is a bit > slower in coming up, and not fully working by the time /etc/rc.d/mountd > runs? In fact, I now notice this sequence of messages in > /var/log/messages: > > Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, > skipping > Sep 9 14:26:51 fourquid mountd[839]: bad exports list line /xx > Sep 9 14:26:54 fourquid kernel: fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > Sep 9 14:26:54 fourquid init: /bin/sh on /etc/rc terminated abnormally, > going to single user mode > Sep 9 14:26:55 fourquid kernel: nfe0: link state changed to UP > > so here the network interface takes a full 4 more seconds to come up, > after it was already needed. > > I can try to put a 10 sec delay somewhere, but there should be a better > solution... The problem is that the network isn't "truly" up and available by the time mountd runs, and therefore DNS resolution doesn't work. Please use my netwait script to solve this problem: http://jdc.parodius.com/freebsd/netwait Place it in /usr/local/etc/rc.d, make sure it's chmod'd to 755, then enable use of it by using /etc/rc.conf variables like so: netwait_enable="yes" netwait_ip="4.2.2.1 4.2.2.2" netwait_if="nfe0" For what the variables do, please see the script comments. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
Hi Scot Hetzel! On Thu, 9 Sep 2010 04:18:52 -0500; Scot Hetzel wrote about 'Re: Policy for removing working code': >>> We can't e-mail announce@ every time something is going to >>> be removed. That would be way too much spam for that list. >> >> That may depend on how often something substantial is removed :) >> >>> I do think stable@ is a good place to e-mail ... >> >> Good, perhaps even "necessary", but is it "sufficient"? Those >> following a -STABLE branch are expected to read stable@, but >> what about those who are following a security branch? >> > If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a > errata fix branch), then they should be reading the stable@ list. True for RELENG_X, but not for RELENG_X_Y. They shouldn't, because all information for security/errata fix branch go to announce@, they don't need to read all noise in stable@ just for this. And, what is more important, they in fact don't do. So announce@ is the only choice from purely practical means. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu, Sep 09, 2010 at 03:25:19PM +0200, Gareth de Vaux wrote: > On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote: > > Can you add the "-c" flag to your pciconf command? Thanks. > > Forbidden? > > # pciconf -lvc > pciconf: /dev/pci: Operation not permitted > # pciconf -lc > pciconf: /dev/pci: Operation not permitted > # ls -l /dev/pci > crw-r--r-- 1 root wheel0, 9 Sep 9 11:55 /dev/pci You need to be root to use the -c flag. Despite your prompt, I don't think you're root. Reproduction: $ id uid=1000(jdc) gid=1000(users) groups=1000(users),0(wheel) $ pciconf -lv | wc -l 114 $ pciconf -lc pciconf: /dev/pci: Permission denied $ sudo -i box# id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) box# pciconf -lc | wc -l 73 -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
Hi John Baldwin! On Wed, 8 Sep 2010 10:21:47 -0400; John Baldwin wrote about 'Re: Policy for removing working code': >>> No, that would require maintaining two network stacks, not just one. The >>> shims to allow unlocked code to run were not trivial. The choices were >>> this: >> >>> 1) Moving forward on work to allow the network stack to scale on SMP >>>systems (e.g. modern x86 multi-core servers) and support higher rate >>>protocols such as 10GB, 40GB, and 100GB. >> >>> 2) Stop all progress on making the network stack scale on SMP. >> >>> I'm sorry, but 2) just isn't feasible. Not if FreeBSD is to continue to be >>> a >>> modern, relevant system. >> >> If it is the only variants, then I'll agree (but only on this part). Are >> there >> really no other variants? What do other OSes to which, as was said, we have >> to >> compete? E.g. Linux? > > Yes, other OS's (Windows, Linux, Solaris) all are working on the multi-core > problem. OS's that aren't working on this will soon be obsolete. Even modern > embedded systems are multi-core (e.g. many MIPs chips now include multiple > cores on a chip, even SMT similar to Intel's HyperThreading on RMI's MIPs > SOCs). My question is not quite the same as that to which you've answered. I agree that non-SMP OS's will be obsolete, but what that OSes do in such particular cases? >>> Also, despite your claims to the contrary, there _was_ adequate notice: >>>http://lists.freebsd.org/pipermail/freebsd-current/2007-June/072977.html >>> This was also documented in the release notes for 7.0: >>>http://www.freebsd.org/releases/7.0R/relnotes.html >> >> No, my claims were that there was no _adequate_ notice, and this links >> acknowledge this. 7.0 Release notes state about broken ISDN as an already >> happened fact, user can't do anything about it already. As I've shown in >> message to vwe@, it wasn't in announce@ and even in sta...@. Number of >> users/subscribers of lists can be expressed as: >> >> # devel lists < # current@ < # stable@ < # announce@ < # of total FreeBSD >> users >> >> While we can't do anything with those who not subscribed even to announce@ >> (though should it be duplicated on www may be?), number of announce@ readers >> is still MUCH more than that of current@, not even mention devel lists. > We can't e-mail announce@ every time something is going to be removed. That > would be way too much spam for that list. No, not everytime and everything, of course. That will go to far to other end. I mean every major event, e.g. each ordinary driver is not worth noting (too much spam), but in this case there were TWO not drivers, but subsystems (ISDN and netatm). One symptom that could indicate this is major event, not minor, is call for volunteers. This is definitely happens not too often. > I do think stable@ is a good place > to e-mail, and I did in fact mail my locking patches for the various NIC > drivers to sta...@. In some cases I did only find testers via stable@ and > not via curr...@. I do think that the general rule is that stable@ should be > on the list. It is true that that did not happen in this case (and probably > should have), but it does happen in the typical case. I would chalk this up > to a one-time slip-up, not a systemic problem. You said about testers, and testers are already involved somehow to the project, at least are subscribed to lists. But testers are in general for testing new features (positive), but not all FreeBSD users need new fetures that fast. They are more concerned about feature removal (negative). Such announcements need to be made at least for them to have migration plan - just like Security Officer informs about EoL before that happens, for people have time to plan maintenance and upgrade. >>> If you wish to help work on ISDN support, I suggest you offer to test hps@' >>> ISDN stack. hps@ recently became a committer so I think there is a very >>> good >>> chance his code will be brought into the tree. >>> We do have a policy for removing code in that it only gets removed if no one >>> is able to maintain it and/or test patches for it. I locked several of the >>> remaining NIC drivers during the push to remove Giant and a few of them were >>> removed from the system because no one had the hardware around to test the >>> patches to add locking (think of really old ISA NICs that only do 10Mbps). >> >> Big thanks for your work, but unfortunately, the problem itself is not ISDN >> or >> network stack, it is deeper. It is the policy or may be style of thought, >> discourse. Something like: >>progress dictates we need fix/maintainership to feature X >> & we have no resources to maintain feature X >> -> we announce theis need, but only to _limited_ audience, not wide circles >> -> nobody responds >> -> the X code is removed >> AND we think this logic chain is correct, thought we did not things this way >> even 5 years ago. > Actually, things have worked this way far long
Re: Policy for removing working code
Hi Andriy Gapon! On Wed, 08 Sep 2010 17:13:29 +0300; Andriy Gapon wrote about 'Re: Policy for removing working code': >> network stack, it is deeper. It is the policy or may be style of thought, >> discourse. Something like: >>progress dictates we need fix/maintainership to feature X >> & we have no resources to maintain feature X >> -> we announce theis need, but only to _limited_ audience, not wide circles >> -> nobody responds >> -> the X code is removed >> AND we think this logic chain is correct, thought we did not things this way >> even 5 years ago. > So, get to work, become a committer, get elected to core and have a control > over > these procedures. [And maybe your perspectives will change along the way] > Until then, please, let's stop wasting time on this issue. And, after several years for all of this, to see that FreeBSD have lost many old users? That's will be too late. You retort here ad hominem, while the policy quoted above is true. Nobody has to be core@ member to predict this policy will eventually harm FreeBSD userbase. Anybody could say that meal is bad, he don't need to be head-cook for this to taste and say. P.S. If I couldn't explain why you were wrong here, there is an article in another language that does this much better: http://lurkmore.ru//%D0%A1%D0%BF%D0%B5%D1%80%D0%B2%D0%B0_%D0%B4%D0%BE%D0%B1%D0%B5%D0%B9%D1%81%D1%8F -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
mountd has resolving problems
I just upgraded a box from 8.0 to 8.1, and already when rebooting with the new kernel (i.e. before installing new userland), I got the following problem. Of course many of the messages scrolled off screen, but some were preserved in the syslog. Sep 9 14:26:51 fourquid mountd[839]: can't get address info for host XYZ Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, skipping Mountd was run and wanted to determine which hosts to export to. However, it could not resolve any of them. So, that suggests some network issue. However, I use a static IP address (no DHCP) and static info in /etc/resolv.conf, using one of the university's name servers. So resolving should always be available. Running /etc/rc.d/mountd restart so far always solved the export problem. I have also seen (presumably similar) issues with mounting NFS file systems, but that was deemed so fatal that the boot was aborted. A mount ``by hand'' of the affected file system also worked. Any ideas? Maybe with the new kernel the network interface is a bit slower in coming up, and not fully working by the time /etc/rc.d/mountd runs? In fact, I now notice this sequence of messages in /var/log/messages: Sep 9 14:26:51 fourquid mountd[839]: bad host XYZ in netgroup vbgroup, skipping Sep 9 14:26:51 fourquid mountd[839]: bad exports list line /xx Sep 9 14:26:54 fourquid kernel: fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Sep 9 14:26:54 fourquid init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Sep 9 14:26:55 fourquid kernel: nfe0: link state changed to UP so here the network interface takes a full 4 more seconds to come up, after it was already needed. I can try to put a 10 sec delay somewhere, but there should be a better solution... -Olaf. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote: > Can you add the "-c" flag to your pciconf command? Thanks. Forbidden? # pciconf -lvc pciconf: /dev/pci: Operation not permitted # pciconf -lc pciconf: /dev/pci: Operation not permitted # ls -l /dev/pci crw-r--r-- 1 root wheel0, 9 Sep 9 11:55 /dev/pci ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Thu, Sep 09, 2010 at 02:54:01PM +0200, Gareth de Vaux wrote: > On Wed 2010-09-08 (09:41), Jack Vogel wrote: > > This is what'd I'd expect, the onboard is PCH chipset, support was not in > > 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it > > should > > work. > > I've just paid the machine a visit and yes, MSIX fails on the onboard but > the device still works. > > The PCI card however doesn't work, whereas it did when using 8.0-RELEASE. > (There is occasional activity from tcpdump). I'm able to use the onboard > so I can survive, but FYI, the PCI card output: > > kernel: em1: port > 0x1000-0x103f mem 0xe312-0xe313,0xe310-0xe311 irq 9 at device > 1.0 on pci5 > kernel: em1: [FILTER] > kernel: em1: Ethernet address: 00:1b:21:5b:f2:18 > > (no MSIX failure here, or in 8.0-RELEASE) > > $ ifconfig em1 > em1: flags=8802 metric 0 mtu 1500 > > options=209b > ether 00:1b:21:5b:f2:18 > media: Ethernet autoselect > status: no carrier > > pciconf -lv: > > e...@pci0:5:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet Can you add the "-c" flag to your pciconf command? Thanks. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MSIX failure
On Wed 2010-09-08 (09:41), Jack Vogel wrote: > This is what'd I'd expect, the onboard is PCH chipset, support was not in > 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should > work. I've just paid the machine a visit and yes, MSIX fails on the onboard but the device still works. The PCI card however doesn't work, whereas it did when using 8.0-RELEASE. (There is occasional activity from tcpdump). I'm able to use the onboard so I can survive, but FYI, the PCI card output: kernel: em1: port 0x1000-0x103f mem 0xe312-0xe313,0xe310-0xe311 irq 9 at device 1.0 on pci5 kernel: em1: [FILTER] kernel: em1: Ethernet address: 00:1b:21:5b:f2:18 (no MSIX failure here, or in 8.0-RELEASE) $ ifconfig em1 em1: flags=8802 metric 0 mtu 1500 options=209b ether 00:1b:21:5b:f2:18 media: Ethernet autoselect status: no carrier pciconf -lv: e...@pci0:5:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing nonworking code
2010/9/9 Andriy Gapon : > on 09/09/2010 12:33 Andriy Gapon said the following: >> People, who care, are expected to read current@ and stable@ even if they use >> only releases and security branches. At the very least, to see what's >> cooking >> up for them and what to expect. > > Not to mention isdn@ for this particular case. > BTW, I changed the subject line, because the code in question became > non-working > when Giant support in network stack was dropped. Please, stop this useless thread ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing nonworking code
on 09/09/2010 14:19 nickolas...@gmail.com said the following: > 2010/9/9 Andriy Gapon : >> on 09/09/2010 12:33 Andriy Gapon said the following: >>> People, who care, are expected to read current@ and stable@ even if they use >>> only releases and security branches. At the very least, to see what's >>> cooking >>> up for them and what to expect. >> >> Not to mention isdn@ for this particular case. >> BTW, I changed the subject line, because the code in question became >> non-working >> when Giant support in network stack was dropped. > > Please, stop this useless thread You first. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
on 09/09/2010 11:22 per...@pluto.rain.com said the following: > Good, perhaps even "necessary", but is it "sufficient"? Those > following a -STABLE branch are expected to read stable@, but > what about those who are following a security branch? People, who care, are expected to read current@ and stable@ even if they use only releases and security branches. At the very least, to see what's cooking up for them and what to expect. P.S. I am surprised that this thread isn't over yet and is being kept alive by people who do not seem to use the feature in question or offer any work on it. While people, who really need it, have already found a way forward for themselves. P.P.S. Please, please, let it go now. Watch current@, watch stable@ and speak up next time such an announcement is made. Do it on time, don't wait until a few years later :-) -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing nonworking code
on 09/09/2010 12:33 Andriy Gapon said the following: > People, who care, are expected to read current@ and stable@ even if they use > only releases and security branches. At the very least, to see what's cooking > up for them and what to expect. Not to mention isdn@ for this particular case. BTW, I changed the subject line, because the code in question became non-working when Giant support in network stack was dropped. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
On Thu, Sep 9, 2010 at 3:22 AM, wrote: > John Baldwin wrote: > >> We can't e-mail announce@ every time something is going to >> be removed. That would be way too much spam for that list. > > That may depend on how often something substantial is removed :) > >> I do think stable@ is a good place to e-mail ... > > Good, perhaps even "necessary", but is it "sufficient"? Those > following a -STABLE branch are expected to read stable@, but > what about those who are following a security branch? > If someone is following a RELENG_X (a.k.a -STABLE) or a RELENG_X_Y (a errata fix branch), then they should be reading the stable@ list. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
On Thu, Sep 09, 2010 at 01:22:22AM -0700, per...@pluto.rain.com wrote: > John Baldwin wrote: > > > We can't e-mail announce@ every time something is going to > > be removed. That would be way too much spam for that list. > > That may depend on how often something substantial is removed :) If mails to announce@ were only sent at the point significant stuff actually is removed it might not be all that much traffic, but at that point it seems a bit late for people to protest against the removal since it has already happened. OTOH, if mails were sent to announce@ everytime something was proposed to be removed then there would probably be far too much traffic for that list. (Most discussions regarding removing stuff tend to end up with status quo being maintained.) > > > I do think stable@ is a good place to e-mail ... > > Good, perhaps even "necessary", but is it "sufficient"? Those > following a -STABLE branch are expected to read stable@, but > what about those who are following a security branch? That depends on what they want to know. If they are concerned about things affecting the branch they are following, then announce@ is probably sufficient since all security advisories are sent there and there are essentially no other changes made to a security branch. If, on the other hand, they are interested in what will be included/not included in future major releases, then current@ is pretty much a must-read. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Policy for removing working code
John Baldwin wrote: > We can't e-mail announce@ every time something is going to > be removed. That would be way too much spam for that list. That may depend on how often something substantial is removed :) > I do think stable@ is a good place to e-mail ... Good, perhaps even "necessary", but is it "sufficient"? Those following a -STABLE branch are expected to read stable@, but what about those who are following a security branch? > I do think that the general rule is that stable@ should be on > the list. It is true that that did not happen in this case (and > probably should have), but it does happen in the typical case. > I would chalk this up to a one-time slip-up, not a systemic problem. In light of this slip-up having now resulted in at least one user having the rug yanked out from under him, perhaps the security officer should be approached WRT continuing support for 6.4 until ISDN is resurrected (which, to judge from other postings in this thread, seems unlikely to amount to "indefinitely"). > ... we lost a few SCSI HBA drivers during the transition to CAM > (e.g. wds(4) was not present in 4.x but was eventually CAM-ified > and reappeared in 5.0). I suspect there was far less notice given > for those drivers than for ISDN (multiple notices to arch@ and > current@ spread out across many months). But, as noted previously, not to any list that someone following a security branch would be expected to read. Beyond that, I suspect that dropping an HBA or three would have been far less burdensome on users of the hardware in question than dropping ISDN is on its users. One can always replace a no-longer-supported HBA with a supported one, or (worst case) replace the whole box. In contrast, someone located beyond DSL range may have no other viable option than ISDN. Perhaps it would be advisable to e-mail announce@ when something is to be removed _and_ there is no recommended migration path. That should reduce the frequency of such postings considerably compared with the strawman suggestion that > ... every time something is going to be removed would overload the list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
