Re: SSH Brute Force attempts
Hi, On 30 Sep 2008, at 01:10, Rich Healey wrote: Recently I'm getting a lot of brute force attempts on my server, in the past I've used various tips and tricks with linux boxes but many of them were fairly linux specific. What do you BSD guys use for this purpose? [various solutions proposed] I too would worry about having something automatically updating filter rulesets. An alternative is to blackhole route the offending source, eg: route -nq add -host a.b.c.d 127.0.0.1 -blackhole WHatever solution you adopt, the ability to whitelist is a very good idea (especially if you are as inaccurate a typist as I am). And I'd second what others have said about avoiding passwords altogether if it's possible in your situation. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED]fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
-On [20080930 05:14], Rich Healey ([EMAIL PROTECTED]) wrote: What do you BSD guys use for this purpose? I actually use blockhosts, which is a Python solution you tie into hosts.allow. http://www.aczoom.com/cms/blockhosts -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Happiness is the absence of the striving for happiness... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
According to Henrik Hudson:
Yeap, -security
However, also try this in pf.conf (specific rules related to this; you'll
need
more for a real pf.conf):
table badguys { } persist
block in quick from badguys
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload badguys flush global)
That one is very effective.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
Darwin sidhe.keltia.net Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; i386
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Rich Healey wrote: Recently I'm getting a lot of brute force attempts on my server, in the past I've used various tips and tricks with linux boxes but many of them were fairly linux specific. What do you BSD guys use for this purpose? There's nothing that replaces using either *good* passwords or *no* passwords at all (i.e. ssh keys instead). I completely agree with Jeremy Chadwick that using programs that change your packet filter rules automatically can be dangerous. I recommend against this. Especially it does not protect you if you have weak passwords. In fact it might open a hole that someone can successfully run a DoS attack against your machine by spoofing one of your own IP addresses, or the IP address of your upstream router, or DNS server, or whatever. If you're merely annoyed about the large amount of logging entries caused by the break-in attempts, a good solution is to move the sshd service from the standard port 22 to a different, non-standard port (e.g. 222 or whatever, but it should be a reserved port, i.e. less than 1024 which is the default high limit for the reserved port range). Most attackers are just script kiddies that use automated software that tries only port 22. You can put an entry in ~/.ssh/config on your client machines so you don't even have to remember to specify the port number when ssh'ing to your server. Alternatively you can configure sshd to listen on port 22 *and* an alternate port, and block port 22 for everything except a few known-good addresses or networks. That way you don't have to do anything special when connecting from any of your usual clients, but you can still connect from anywhere else if necessary by using the non-standard port. Of course, the non-standard port trick is *not* a security measure. It only makes your machine a little bit more invisible to script kiddies and prevents them from filling your log files. It might also give you a very small advance in case of zero-day attacks. It does *not* help against weak passwords or lazyness to patch known holes, or other kinds of operator failure. 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 What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How do I unchown a directory after I: chown -R /etc ???
How do I unchown a directory after I: chown -R /etc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I unchown a directory after I: chown -R /etc ???
-On [20080930 11:26], Mike Price ([EMAIL PROTECTED]) wrote: How do I unchown a directory after I: chown -R /etc There is no unchown. You either rechown with the correct users or you use mtree with one of the dist files in /etc/mtree to recreate the directory structure with the correct rights/users. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B What's in a name? That which we call a rose by any other name would smell as sweet... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Security patch to atacontrol
Andrey V. Elsukov [EMAIL PROTECTED] 2008-09-30: Jeremy Chadwick wrote: Can you provide me datasheet and technical reference material to what ATA Security is? Which ATA specification is this documented in? I'd like to read it. I think you can found it in ATA-ATAPI-7 vol.1: 4.7 Security Mode feature set. Exactly. Even though the actual T13 standard must be purchased, you can find the documents and drafts of it online at various places by googling for appropriate keywords. For example: http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-7/ The ATA command set, including the ATA Security commands, is in vol. 1. In 2005, there was a much-cited article in the German c't magazine about the security implications of ATA Security, which might be worth a read too. It is available online in English: http://www.heise.de/ct/english/05/08/172/ -- Daniel Roethlisberger http://daniel.roe.ch/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
On Tue, Sep 30, 2008 at 09:56:32AM +0200, Jeroen Ruigrok van der Werven wrote: -On [20080930 05:14], Rich Healey ([EMAIL PROTECTED]) wrote: What do you BSD guys use for this purpose? I actually use blockhosts, which is a Python solution you tie into hosts.allow. http://www.aczoom.com/cms/blockhosts In no way shape or form does this solve the problem of the attackers being able to establish a TCP connection to you -- they are still tying up sockets, mbufs, and extra network I/O (coming from you when you respond and close the socket). TCP wrappers are absolutely 100% worthless in this day and age. -- | Jeremy Chadwickjdc at 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I unchown a directory after I: chown -R /etc ???
On Tue, Sep 30, 2008 at 02:25:54AM -0700, Mike Price wrote: How do I unchown a directory after I: chown -R /etc You can't. Restore /etc from backups. And ***please*** stop posting this stuff to -hackers. It is not the appropriate list for it. Start using -questions. -- | Jeremy Chadwickjdc at 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Oliver Fromme [EMAIL PROTECTED] writes: If you're merely annoyed about the large amount of logging entries caused by the break-in attempts, a good solution is to move the sshd service from the standard port 22 to a different, non-standard port The best choice is 443, as many corporate firewalls, especially guest wifi networks, block all but a few ports (usually 22, 80 and 443, and sometimes 25). There are other, more complicated tricks you can play; for instance, you could set up a web server on the box, and configure it to tunnel SSH using the HTTP Upgrade header; this would require modifications to both ssh (to send the initial HTTP request) and sshd (to take over the connection from the web server). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I unchown a directory after I: chown -R /etc ???
Jeremy Chadwick [EMAIL PROTECTED] writes: Mike Price [EMAIL PROTECTED] writes: How do I unchown a directory after I: chown -R /etc You can't. Restore /etc from backups. Better solution: use mtree to generate a spec file from a clean tree and apply it. You can get a clean copy of etc in /var/tmp/temproot by running mergemaster and answering no to every question. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Quoting Rich Healey [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recently I'm getting a lot of brute force attempts on my server, in the past I've used various tips and tricks with linux boxes but many of them were fairly linux specific. What do you BSD guys use for this purpose? If this belongs on -security let me know and I'll ask over there. Just do not use password authentication but public key authentication and a reasonable passphrase on it. pgpGp7TV3Xdt6.pgp Description: Digitale PGP-Unterschrift
Re: ATA Security patch to atacontrol
Daniel Roethlisberger wrote: Andrey V. Elsukov [EMAIL PROTECTED] 2008-09-30: Jeremy Chadwick wrote: Can you provide me datasheet and technical reference material to what ATA Security is? Which ATA specification is this documented in? I'd like to read it. I think you can found it in ATA-ATAPI-7 vol.1: 4.7 Security Mode feature set. Exactly. Even though the actual T13 standard must be purchased, you can find the documents and drafts of it online at various places by googling for appropriate keywords. For example: http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-7/ The ATA command set, including the ATA Security commands, is in vol. 1. In 2005, there was a much-cited article in the German c't magazine about the security implications of ATA Security, which might be worth a read too. It is available online in English: http://www.heise.de/ct/english/05/08/172 http://www.t13.org has all the latest drafts at http://www.t13.org/Documents/MinutesDefault.aspx?DocumentType=4DocumentStage=2 -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Ollivier Robert wrote:
According to Henrik Hudson:
Yeap, -security
However, also try this in pf.conf (specific rules related to this; you'll
need
more for a real pf.conf):
table badguys { } persist
block in quick from badguys
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload badguys flush global)
That one is very effective.
It's especially effective to enable to DoS you.
An attacker simply has to spoof the source address
on SYN packets, which is trivial. :-(
It is marginally better to use one of those tools
that parse the logs for failed ssh logins, and use
that information to block addresses. In order to
abuse that, and attacker would have to spoof a full
TCP connection setup plus initial SSH conversation,
which is far from trivial.
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
Perl will consistently give you what you want,
unless what you want is consistency.
-- Larry Wall
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Oliver Fromme wrote:
| Ollivier Robert wrote:
| According to Henrik Hudson:
|Yeap, -security
|
|However, also try this in pf.conf (specific rules related to this; you'll need
|more for a real pf.conf):
|
|table badguys { } persist
|block in quick from badguys
|pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
|(max-src-conn 5, max-src-conn-rate 4/300, overload badguys flush global)
|
| That one is very effective.
|
| It's especially effective to enable to DoS you.
| An attacker simply has to spoof the source address
| on SYN packets, which is trivial. :-(
Adding a whitelist of ssh addresses that should never be blocked is equally
trivial
But, like the perl folk say: TIMTOWTDI.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. Flat 3
~ 7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
~ Kent, CT11 9PW, UK
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREDAAYFAkjiQKsACgkQ3jDkPpsZ+VbzsgCfY64vNfuMhRrGRYgK4rDawWq4
xDwAnRMXY54hiooKCFBp7U/SxILUsxsa
=yQm5
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Hello guys, On Mon, 29 Sep 2008 20:30:33 -0700, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 10:10:59AM +1000, Rich Healey wrote: Recently I'm getting a lot of brute force attempts on my server, in the past I've used various tips and tricks with linux boxes but many of them were fairly linux specific. What do you BSD guys use for this purpose? This probably should've gone to -security, correct. There are 3 ports which people often use for solving this: ports/security/blocksshd ports/security/sshblock ports/security/sshguard-(pf|ipfw|ipfilter) There's also a tool written by me which can be found in security/bruteforceblocker - you may read a bit about it on http://danger.rulez.sk/index.php/bruteforceblocker/. The official release currently works only with pf, but I know there's a person working towards porting it to ipf/ipfw. He recently ported it to iptables and added CIDR support for whitelists, but I haven't had a time to review his changes, however once I get to it I will release a new version. -- Best regards Daniel Geržo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
On Tue, Sep 30, 2008 at 04:01:26PM +0200, Oliver Fromme wrote:
Ollivier Robert wrote:
According to Henrik Hudson:
Yeap, -security
However, also try this in pf.conf (specific rules related to this;
you'll need
more for a real pf.conf):
table badguys { } persist
block in quick from badguys
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload badguys flush
global)
That one is very effective.
It's especially effective to enable to DoS you.
An attacker simply has to spoof the source address
on SYN packets, which is trivial. :-(
This is not true. pf.conf(5) says:
For stateful TCP connections, limits on established connections (connec-
tions which have completed the TCP 3-way handshake) can also be enforced
per source IP.
max-src-conn number
Limits the maximum number of simultaneous TCP connections which
have completed the 3-way handshake that a single host can make.
max-src-conn-rate number / seconds
Limit the rate of new connections over a time interval. The con-
nection rate is an approximation calculated as a moving average.
Because the 3-way handshake ensures that the source address is not being
spoofed, more aggressive action can be taken based on these limits.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Pierre Riteau wrote:
Oliver Fromme wrote:
Ollivier Robert wrote:
According to Henrik Hudson:
Yeap, -security
However, also try this in pf.conf (specific rules related to this;
you'll need
more for a real pf.conf):
table badguys { } persist
block in quick from badguys
pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state
(max-src-conn 5, max-src-conn-rate 4/300, overload badguys flush
global)
That one is very effective.
It's especially effective to enable to DoS you.
An attacker simply has to spoof the source address
on SYN packets, which is trivial. :-(
This is not true. pf.conf(5) says:
For stateful TCP connections, limits on established connections (connec-
tions which have completed the TCP 3-way handshake) can also be enforced
per source IP.
Thanks for the correction. I prefer IPFW most of the time,
therefore I wasn't aware of this detail.
Because the 3-way handshake ensures that the source address is not being
spoofed, more aggressive action can be taken based on these limits.
s/not being spoofed/more difficult to spoofe/ ;-)
Still, detecting the break-in attempts on application layer
(e.g. auth log file) is better than on TCP layer.
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
It combines all the worst aspects of C and Lisp: a billion different
sublanguages in one monolithic executable. It combines the power of C
with the readability of PostScript.
-- Jamie Zawinski, when asked: What's wrong with perl?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
In response to Oliver Fromme [EMAIL PROTECTED]: Pierre Riteau wrote: Because the 3-way handshake ensures that the source address is not being spoofed, more aggressive action can be taken based on these limits. s/not being spoofed/more difficult to spoofe/ ;-) On a modern OS (like FreeBSD) where ISNs are random, the possibility of blindly spoofing an IP during a 3-way handshake is so low as to be effectively impossible. Yes, it _can_ be done, but the effort required makes it not an effective method of attack. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
Bill Moran wrote: In response to Oliver Fromme [EMAIL PROTECTED]: Pierre Riteau wrote: Because the 3-way handshake ensures that the source address is not being spoofed, more aggressive action can be taken based on these limits. s/not being spoofed/more difficult to spoofe/ ;-) On a modern OS (like FreeBSD) where ISNs are random, the possibility of blindly spoofing an IP during a 3-way handshake is so low as to be effectively impossible. It depends a lot on the environment, for example whether the attacker has access (or can somehow get access) to the server's uplink and trace packets. This can happen if the server is located with many other servers on the same network, which is often the case for co-location or so-called root servers. Of course, if the network is regarded secure, then you are right. Spoofing a TCP handshake would be very difficult in that case. (I try to avoid the word impossible. Nothing is impossible, especially in the security business.) 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 Python is executable pseudocode. Perl is executable line noise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH Brute Force attempts
2008/9/30 Oliver Fromme [EMAIL PROTECTED]: Bill Moran wrote: In response to Oliver Fromme [EMAIL PROTECTED]: Pierre Riteau wrote: Because the 3-way handshake ensures that the source address is not being spoofed, more aggressive action can be taken based on these limits. s/not being spoofed/more difficult to spoofe/ ;-) On a modern OS (like FreeBSD) where ISNs are random, the possibility of blindly spoofing an IP during a 3-way handshake is so low as to be effectively impossible. It depends a lot on the environment, for example whether the attacker has access (or can somehow get access) to the server's uplink and trace packets. This can happen if the server is located with many other servers on the same network, which is often the case for co-location or so-called root servers. Yes, but in that situation you probably have the capacity to inject enough traffic into the pipe to cause a total blackout... Of course, if the network is regarded secure, then you are right. Spoofing a TCP handshake would be very difficult in that case. (I try to avoid the word impossible. Nothing is impossible, especially in the security business.) Security is always about the balance between the effort+risk to you vs the effort+benefit to the attacker... -- Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[powerd] Adding different adaptive-mode settings for each power source
Hi,
I've needed to set different idle levels for adaptive mode while on
battery or on AC power. Cause powerd can only set mode (min, max, adp)
for each power source, I've added this ability and it seems to be a
good idea to share this improvement with others.
Best regards, gelraen.
P.S.: Sorry for my bad English :)
--- usr.sbin/powerd/powerd.c.orig 2008-09-30 18:19:04.0 +0300
+++ usr.sbin/powerd/powerd.c2008-10-01 00:49:52.0 +0300
@@ -66,6 +66,8 @@
SRC_UNKNOWN,
} power_src_t;
+#define SRCS_COUNT 3 /* Number of different power sources */
+
const char *modes[] = {
AC,
battery,
@@ -95,8 +97,8 @@
static int acline_mib[3];
/* Configuration */
-static int cpu_running_mark;
-static int cpu_idle_mark;
+static int cpu_running_mark[SRCS_COUNT];
+static int cpu_idle_mark[SRCS_COUNT];
static int poll_ival;
static int vflag;
@@ -357,7 +359,7 @@
{
fprintf(stderr,
-usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival]
[-r %%] [-P pidfile]\n);
+usage: powerd [-v] [-a mode] [-b mode] [-A %%:%%] [-B %%:%%] [-i %%]
[-n mode] [-N %%:%%] [-p ival] [-r %%] [-P pidfile]\n);
exit(1);
}
@@ -377,8 +379,11 @@
/* Default mode for all AC states is adaptive. */
mode_ac = mode_battery = mode_none = MODE_ADAPTIVE;
- cpu_running_mark = DEFAULT_ACTIVE_PERCENT;
- cpu_idle_mark = DEFAULT_IDLE_PERCENT;
+ for(i=0;iSRCS_COUNT;i++)
+ {
+ cpu_running_mark[i] = DEFAULT_ACTIVE_PERCENT;
+ cpu_idle_mark[i] = DEFAULT_IDLE_PERCENT;
+ }
poll_ival = DEFAULT_POLL_INTERVAL;
mjoules_used = 0;
vflag = 0;
@@ -387,7 +392,7 @@
if (geteuid() != 0)
errx(1, must be root to run);
- while ((ch = getopt(argc, argv, a:b:i:n:p:P:r:v)) != -1)
+ while ((ch = getopt(argc, argv, A:B:N:a:b:i:n:p:P:r:v)) != -1)
switch (ch) {
case 'a':
parse_mode(optarg, mode_ac, ch);
@@ -395,13 +400,87 @@
case 'b':
parse_mode(optarg, mode_battery, ch);
break;
+ case 'A':
+ i=0;
+ while (optarg[i]!='\0' optarg[i]!=':') i++;
+ if (optarg[i]!=':')
+ {
+ warnx(%s is not a valid setting,optarg);
+ usage();
+ }
+ optarg[i]='\0';
+ cpu_running_mark[SRC_AC] = atoi(optarg);
+ optarg[i]=':';
+ if (cpu_running_mark[SRC_AC] 0 ||
cpu_running_mark[SRC_AC] 100) {
+ warnx(%d is not a valid percent,
+ cpu_running_mark[SRC_AC]);
+ usage();
+ }
+ cpu_idle_mark[SRC_AC] = atoi(optarg+i+1);
+ if (cpu_idle_mark[SRC_AC] 0 || cpu_idle_mark[SRC_AC]
100) {
+ warnx(%d is not a valid percent,
+ cpu_idle_mark[SRC_AC]);
+ usage();
+ }
+ break;
+ case 'B':
+ i=0;
+ while (optarg[i]!='\0' optarg[i]!=':') i++;
+ if (optarg[i]!=':')
+ {
+ warnx(%s is not a valid setting,optarg);
+ usage();
+ }
+ optarg[i]='\0';
+ cpu_running_mark[SRC_BATTERY] = atoi(optarg);
+ optarg[i]=':';
+ if (cpu_running_mark[SRC_BATTERY] 0 ||
cpu_running_mark[SRC_BATTERY] 100) {
+ warnx(%d is not a valid percent,
+ cpu_running_mark[SRC_BATTERY]);
+ usage();
+ }
+ cpu_idle_mark[SRC_BATTERY] = atoi(optarg+i+1);
+ if (cpu_idle_mark[SRC_BATTERY] 0 ||
cpu_idle_mark[SRC_BATTERY] 100) {
+ warnx(%d is not a valid percent,
+ cpu_idle_mark[SRC_BATTERY]);
+ usage();
+ }
+ break;
+ case 'N':
+ i=0;
+ while (optarg[i]!='\0' optarg[i]!=':') i++;
+ if (optarg[i]!=':')
+ {
+ warnx(%s is not a valid setting,optarg);
+ usage();
+ }
+ optarg[i]='\0';
+ cpu_running_mark[SRC_UNKNOWN] = atoi(optarg);
+ optarg[i]=':';
+
Re: ATA Security patch to atacontrol
Daniel Roethlisberger [EMAIL PROTECTED] 2008-09-30: I've added experimental support for the ATA Security command set to atacontrol. Please test and review. If you have some spare disk(s) with ATA Security support and a BIOS which does not freeze the security configuration, I'd like to hear about any results of playing with this patch. See the changes to the manual page for details on the commands. Note that you may render disks unusable using the ATA Security commands. Use with great care. I've slightly improved the patch. Changes: - More sane timeouts on ATA commands - Print a security usage if parameters are illegal - Extended the manual page with some examples and notes about which commands are lethal to mounted filesystems - Teach the kernel about the ATA Security command codes (for console printf messages) Even with the kernel changes, a kernel rebuild is not required in order to test the code. http://daniel.roe.ch/code/ata/atasecurity-20081001-complete.diff Please send me feedback. -- Daniel Roethlisberger http://daniel.roe.ch/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
