Re: system breach
On Friday 29 December 2006 21:50, Brandon S. Allbery KF8NH wrote: > That looks like CPAN to me. pear is actually like CPAN - but for PHP. I didn't have the said download directory on my FreeBSD 6.1-STABLE machine, but going to /usr/ports/devel/pear and doing make all install clean sure does create the directory and the files inside. That directory is basically used when pear is downloading modules (hope that's what they're called). [EMAIL PROTECTED] ~ #> pear config-show | grep download_dir PEAR Installer downloaddownload_dir /tmp/download [EMAIL PROTECTED] ~ #> You can change the location of that directory at any time using pear config-set (works on a per user basis writing to their $HOME/.pearrc) or by editing the file /usr/local/etc/pear.conf. Try "pear help" for more details. -- patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
gareth On Fri, Dec 29, 2006 at 10:54:36PM +0200, gareth wrote: > On Fri 2006-12-29 (10:16), Jeremy Chadwick wrote: with regards to you last post to me (personal) i had installed freebsd v6.1-release and setup xwindows (both kde & gnome) desktop environments, then left teh machine sit and settle. the machine is a compaq proliant 5500 with 2 PIII Xeon 550/100 L2 Cache off 1 mb . it has a 45 gb raid5 array (35 gb data/10 gb raid indexing etc) this is built ontop of a SMART-2/P array controller with a pair od symbiosis scsi3 host adapters. the machine is sitting idle on a shelf while i get several dozen dlt-IV tapes that i've ordered for the DLT-7000 scsi tape streamer so that i can save teh image/filesystems to tape then scour the disks clean and start again. its got a dorectory in teh root fs and several othe files pepered all over teh array and many endries in teh systems logs all started on or about 22 november about 11 pm i think .. sorry the machine is running something else at teh moment and its a bit too hard to get the relevent details but if itis of any valu e to you or anyone-else i'd be happy to run up freebsd v6.1-release and get teh details for you. the compromise seems to be a sshd couple to a X11 subsystem sned out pornography type of attack. as i told you earlier i've contacted aus-cert and give tehm teh open port numbers which they confirmed as a current local compromise thats been peretrated by several fellows in china (mainland) hongkong and from indonesia as well, it is apparent reasonably well know gang that is doing this, could be targeting anyone with freebsd v6.1-release or more likely the version of kde/gnome that installed with freebsd v6.1-release. one thing to note that is freebsd warns after installation (that is after teh first night time maintenance run) the security mail list 18 or so packages as being know to be compromiseable and or weak in that respect. i didn't think much of it as i wasn't going to be using teh machine, just let it run up as it was new (to me) its recycled from another life and is some 10 years old (pretty new in my meuseum, big grin) if anyone else is interested in details i'd be happy to furnish details off list most kind regards jonathan also, best wishes for the coming new year and hope that you christmas was happy holy safe and incident free. -- powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system === appropriate solution in an inappropriate world === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gif problems in -STABLE
Hi, I just updated one of my machines from RELENG_6 as of 2006-11-03, to RELENG_6 as of 2006-12-29. This caused the IPv6 tunnel which this box uses, which had been doing fine for months, to suddenly stop working. Reverting to my 2006-11-03 kernel restored the tunnel again, so my ISP could be ruled out. :) The symptoms are that the IPv6 default gateway cannot be reached, and you'll get "ping6: sendmsg: No route to host" when you try to ping it. For some reason, the ifconfig command now fails to create the proper routing table entries. With the 2006-11-03 kernel, if I configure my gif0 tunnel as follows: ifconfig gif0 create ifconfig gif0 213.154.244.69 193.109.122.244 ifconfig gif0 inet6 2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128 route add -inet6 default 2001:7b8:2ff:146::1 I get the following entries in the routing table: Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRSlo0 => default 2001:7b8:2ff:146::1 UGSgif0 ::1 ::1 UHL lo0 :::0.0.0.0/96 ::1 UGRSlo0 2001:7b8:2ff:146::1 link#6UHLgif0 2001:7b8:2ff:146::2 link#6UHL lo0 ... If I use the 2006-12-29 kernel, the routing table after exactly the same sequence of commands is: Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRSlo0 => default 2001:7b8:2ff:146::1 UGSgif0 ::1 ::1 UHL lo0 :::0.0.0.0/96 ::1 UGRSlo0 2001:7b8:2ff:146::2 link#6UHL lo0 ... So, for some reason, the 2001:7b8:2ff:146::1 entry is not automatically created anymore. Of course, you could add this manually, but it's rather strange that this behaviour has changed. After some Googling, I found this thread about -current, which seems to describe approximately the same problem: http://lists.freebsd.org/pipermail/freebsd-current/2006-December/067830.html However, the thread seems to have no real conclusion as to what the cause or proper solution is. There are two possible solutions mentioned, though: 1) Using something like: ipv6_defaultrouter="::1 -ifp gif0" This doesn't work for me, unless I set the prefixlen for the whole gif0 tunnel to 64; but in that case I don't need the ::1 -ifp stuff either. 2) Using something like: ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 126" This does work, though I find it strange that such functionality is changed so shortly before a release. :) Does anyone have a clue where this changed behaviour comes from, or where in the source tree I should look to find the commit that caused it? Maybe it would be nicer to revert to the previous behaviour for 6.2-RELEASE, since it will cause many non-working tunnels when people upgrade. Or otherwise at least put a big notice in UPDATING or the release notes. :) Cheers, Dimitry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Migrating vinum to gvinum
I believe the on-disk structure for vinum and gvinum are the same so you can move volumes unchanged from one to the other. I have moved vinum volumes from 4.11 to 6.1 without any problem (including mirrored, striped and raid-5 on the same host). You have to move the mount device from /dev/vinum to /dev/gvinum of course. If you're using vinum for the root drive things may be more complex - I haven't any experience of that. Simon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
BIND-9.3.2 (from 5.5-STABLE) segfault under load...
Hi--
I had named segfault a day or so ago under high load ("adnslogres -c 200"
against a webserver logfile) after logging the following:
[ ... ]
Dec 28 03:38:56 pi named[1853]: enforced delegation-only for
'AR' (ctina.ar/A/IN) from 137.39.1.3#53
Dec 28 03:40:20 pi named[1853]: enforced delegation-only for
'AR' (ctina.AR/A/IN) from 137.39.1.3#53
Dec 28 03:50:23 pi named[1853]: client 127.0.0.1#53077: no more
recursive clients: quota reached
Dec 28 03:50:24 pi last message repeated 258 times
Dec 28 03:50:24 pi kernel: pid 1853 (named), uid 53: exited on
signal 11
Named is being invoked via "-4 -u bind -c named.conf -t /var/named"; but it
could not dump core as /var/named is owned by root. I've changed that
temporarily so I ought to be able to get a corefile if I can reproduce it.
As the subject mentions, this is a Dell 1850 (rackmount PowerEdge) running
FreeBSD-5.5 & BIND-9.3.2; until just now, everything had been running stably
for months at a time.
--
-Chuck
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sleepy thread - Kernel Panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yours makes the third report of this that I know of ... one of us is running 6.2-RC, one 6.1-RELEASE ... what version are you running? I get the same 'hang' also ... Have you enabled DDB in your kernel? Also, have you enabled the dumpdev settings in /etc/rc.conf? - --On Thursday, December 28, 2006 17:27:38 +0545 Tek Bahadur Limbu <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Dear All, > > I need some help on the problem below. > > The following error occurs in my FreeBSD 6.1 (Dell 420) server: > > > Sleeping thread (tid 540242, pid 32378) owns a non-sleepable lock > panic: sleeping thread > > Cannot dump. No dump device defined. > > Automatic reboot in 15 seconds - press a key on the console to abort. > Rebooting > > > However, it does not reboot and simply hangs. > > I have tried commenting the "options PROCFS" which seemed to work for 2 > says. However on the 3rd day, the same problem surfaced again. > > I probably think that it is a hardware problem. Does anybody have > some ideas regarding this problem. > > > -- > > > With best regards and good wishes, > > Yours sincerely, > > Tek Bahadur Limbu > > (TAG/TDG Group) > Jwl Systems Department > > Worldlink Communications Pvt. Ltd. > > Jawalakhel, Nepal > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.2 (FreeBSD) > > iD8DBQFFk62uVrOl+eVhOvYRAmfRAJsFtLZOBH84ex9S2h99r1bqf2eYegCcDfgO > rJW7nsfCQAIn7Q9RFwsUA3o= > =W8n9 > -END PGP SIGNATURE- > - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFlXxO4QvfyHIvDvMRAu5wAJ9cdnO87xmzpXcvWRxZfYzK2sxqQQCeMIG3 u87sTXfYCqNGNRbM0SfKqJ8= =TJp6 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (10:16), Jeremy Chadwick wrote:
> Apparently pkg_fetch will use either $PKG_TMPDIR or $TMPDIR as a
> temporary storage location for where things are stored. Taken from
> the manpage in pkgtools-2.2.2/man/pkg_fetch.1:
>
> PKG_TMPDIR
> TMPDIR (In that order) Temporary directory where pkg_fetch down-
> loads files temporarily. If neither is not defined,
> ``/var/tmp'' is used.
>
> Do either of the reporters have PKG_TMPDIR or TMPDIR defined in
> make.conf, their own dotfiles, root's dotfiles, or within their
> php.ini?
thanx for all the detective work, i grepped for TMPDIR and download
in the ports tree and didn't find anything worthwhile. however, found
this in the go-pear file in /usr/ports/distfiles/pear-1.4.11.tar.bz2:
putenv('PHP_PEAR_DOWNLOAD_DIR=' . $temp_dir . '/download')
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (19:48), Thomas Nystr?m wrote: > It looks like this: > > ture(root)# dir > total 50 > drwxrwxr-x 5 root wheel512 29 Aug 16:29 ./ > drwxrwxrwt 11 root wheel 3072 29 Dec 19:35 ../ > drwxrwxr-x 4 root wheel512 29 Aug 16:29 Archive_Tar-1.3.1/ > drwxrwxr-x 3 root wheel512 29 Aug 16:29 Console_Getopt-1.2/ > drwxrwxr-x 3 root wheel512 29 Aug 16:29 XML_RPC-1.5.0/ > -rw-rw-r-- 1 root wheel 15433 12 Jul 02:09 package.xml > -rw-rw-r-- 1 root wheel 22193 12 Jul 02:09 package2.xml snap ;) package*.xml are also "12 Jul 02:09" > Exactly which port that did this is hard to tell. I have around > 130 ports installed and most of them were updated 29:th Aug. > I have looked at the files that exists in these directories > and according to the +CONTENTS files in /var/db/pkg all is claimed > to belong to pear-1.4.11 so that might be a candidate. ah yes, well played, md5's match too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Dec 29, 2006, at 13:53 , Thomas Nyström wrote:
I'm wondering if maybe a PHP script is trying to do something with
pkg_fetch, and does something like setenv("PKG_TMPDIR", "/tmp/
download")
before calling system("pkg_fetch ..."). Why a PHP script would do
this, I don't know, but it wouldn't surprise me.
See my other mail about a suspicous port (pear-1.4.11)
PEAR would also make sense; it's a (apparently lamer, at least
security-wise; then again, it *is* PHP :> ) CPAN-alike for PHP.
--
brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Dec 29, 2006, at 13:48 , Thomas Nyström wrote: ture(root)# dir total 50 drwxrwxr-x 5 root wheel512 29 Aug 16:29 ./ drwxrwxrwt 11 root wheel 3072 29 Dec 19:35 ../ drwxrwxr-x 4 root wheel512 29 Aug 16:29 Archive_Tar-1.3.1/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 Console_Getopt-1.2/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 XML_RPC-1.5.0/ -rw-rw-r-- 1 root wheel 15433 12 Jul 02:09 package.xml -rw-rw-r-- 1 root wheel 22193 12 Jul 02:09 package2.xml That looks like CPAN to me. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
Jeremy Chadwick wrote:
>
I've been following this thread and trying to track down what's been
reported (by two people at this point); that is, temporary ports
"stuff" getting stored in /tmp/download.
A `grep -r '/download$' /usr/ports` returns some results, but not
very many. Ones which could raise suspicion, but probably are not
the cause, are:
/usr/ports/biology/garlic/pkg-plist:[EMAIL PROTECTED] %%DOCSDIR%%/download
/usr/ports/lang/diveintopython/Makefile:DIPDLDIR= ${DOCSDIR}/download
/usr/ports/lang/diveintopython/pkg-plist:@dirrm %%DOCSDIR%%/download
/usr/ports/sysutils/jailuser/pkg-plist:%%PORTDOCSDOCSDIR%%/download
Thus, I decided to go straight to the portupgrade source and look
through that. Nothing really shined through, but I did come across
something that may or may not help:
Apparently pkg_fetch will use either $PKG_TMPDIR or $TMPDIR as a
temporary storage location for where things are stored. Taken from
the manpage in pkgtools-2.2.2/man/pkg_fetch.1:
PKG_TMPDIR
TMPDIR (In that order) Temporary directory where pkg_fetch down-
loads files temporarily. If neither is not defined,
``/var/tmp'' is used.
Do either of the reporters have PKG_TMPDIR or TMPDIR defined in
make.conf, their own dotfiles, root's dotfiles, or within their
php.ini?
Nope.
I'm wondering if maybe a PHP script is trying to do something with
pkg_fetch, and does something like setenv("PKG_TMPDIR", "/tmp/download")
before calling system("pkg_fetch ..."). Why a PHP script would do
this, I don't know, but it wouldn't surprise me.
See my other mail about a suspicous port (pear-1.4.11)
/thn
--
---
Svensk Aktuell Elektronik AB Thomas Nyström
Box 10Phone: +46 8 35 92 85
S-191 21 SollentunaFax: +46 8 35 92 86
Sweden Email: [EMAIL PROTECTED]
---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
gareth wrote: On Fri 2006-12-29 (17:25), Thomas Nystr?m wrote: I just checked one of my servers and also found a /tmp/download directory with the same files that you had. I then compared the timestamp of /tmp/download with the timestamp of the directories in /var/db/pkg: Same. My conclusion is that during a portupgrade these files were written there, directly or indirectly by portupgrade or the port itself. oh. ok. well even though that's weird behaviour from a package it's more plausible since i haven't found anything else suspicious. are the timestamps exactly the same? i have 4 packages that're 20 minutes different. which of yours are the same? or was that for all files. (since i'd like to try an reproduce it). It looks like this: ture(root)# dir total 50 drwxrwxr-x 5 root wheel512 29 Aug 16:29 ./ drwxrwxrwt 11 root wheel 3072 29 Dec 19:35 ../ drwxrwxr-x 4 root wheel512 29 Aug 16:29 Archive_Tar-1.3.1/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 Console_Getopt-1.2/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 XML_RPC-1.5.0/ -rw-rw-r-- 1 root wheel 15433 12 Jul 02:09 package.xml -rw-rw-r-- 1 root wheel 22193 12 Jul 02:09 package2.xml Exactly which port that did this is hard to tell. I have around 130 ports installed and most of them were updated 29:th Aug. I have looked at the files that exists in these directories and according to the +CONTENTS files in /var/db/pkg all is claimed to belong to pear-1.4.11 so that might be a candidate. /thn -- --- Svensk Aktuell Elektronik AB Thomas Nyström Box 10Phone: +46 8 35 92 85 S-191 21 SollentunaFax: +46 8 35 92 86 Sweden Email: [EMAIL PROTECTED] --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: does growfs actually work on -stable?
On Friday 29 December 2006 02:39, John Pettitt wrote: > I tried to grow a 600GB filesystem to 1TB and growfs barfed complaining > about a negative block number - this was a raid array (highpoint) that > looks like one drive (da0) to the system. Does growfs actually work - > google searches were not much help ... I used it successfully a couple months ago (6.1-STABLE most likely). IIRC, you need to resize the slice (fdisk) and the partition (bsdlabel) yourself before calling growfs. I think this was just on a standalone IDE disk. I don't recall the size details. HTH, JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri, Dec 29, 2006 at 07:39:16PM +0200, gareth wrote:
> oh. ok. well even though that's weird behaviour from a package it's
> more plausible since i haven't found anything else suspicious. are
> the timestamps exactly the same? i have 4 packages that're 20 minutes
> different. which of yours are the same? or was that for all files.
> (since i'd like to try an reproduce it).
Preface: I am not a portupgrade user, as I'm one of those admins
who believes that if the FreeBSD base system ports management data-
base/dependancy structure is "flawed" or "ineffective" (which is
apparently the reason portupgrade maintains its own separate copy
of ports dependancies -- which continues to induce "why are my
dependancies not working" support mails to the ports mailing list)
then the problem should be fixed in the base system and not require
reliance on a third-party tool that induces more headaches. (OK, I
am off my soapbox now)
I've been following this thread and trying to track down what's been
reported (by two people at this point); that is, temporary ports
"stuff" getting stored in /tmp/download.
A `grep -r '/download$' /usr/ports` returns some results, but not
very many. Ones which could raise suspicion, but probably are not
the cause, are:
/usr/ports/biology/garlic/pkg-plist:[EMAIL PROTECTED] %%DOCSDIR%%/download
/usr/ports/lang/diveintopython/Makefile:DIPDLDIR= ${DOCSDIR}/download
/usr/ports/lang/diveintopython/pkg-plist:@dirrm %%DOCSDIR%%/download
/usr/ports/sysutils/jailuser/pkg-plist:%%PORTDOCSDOCSDIR%%/download
Thus, I decided to go straight to the portupgrade source and look
through that. Nothing really shined through, but I did come across
something that may or may not help:
Apparently pkg_fetch will use either $PKG_TMPDIR or $TMPDIR as a
temporary storage location for where things are stored. Taken from
the manpage in pkgtools-2.2.2/man/pkg_fetch.1:
PKG_TMPDIR
TMPDIR (In that order) Temporary directory where pkg_fetch down-
loads files temporarily. If neither is not defined,
``/var/tmp'' is used.
Do either of the reporters have PKG_TMPDIR or TMPDIR defined in
make.conf, their own dotfiles, root's dotfiles, or within their
php.ini?
I'm wondering if maybe a PHP script is trying to do something with
pkg_fetch, and does something like setenv("PKG_TMPDIR", "/tmp/download")
before calling system("pkg_fetch ..."). Why a PHP script would do
this, I don't know, but it wouldn't surprise me.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://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 "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (17:25), Thomas Nystr?m wrote: > I just checked one of my servers and also found a /tmp/download > directory with the same files that you had. > > I then compared the timestamp of /tmp/download with the timestamp > of the directories in /var/db/pkg: Same. > > My conclusion is that during a portupgrade these files were written > there, directly or indirectly by portupgrade or the port itself. oh. ok. well even though that's weird behaviour from a package it's more plausible since i haven't found anything else suspicious. are the timestamps exactly the same? i have 4 packages that're 20 minutes different. which of yours are the same? or was that for all files. (since i'd like to try an reproduce it). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
On Fri, 29 Dec 2006, Wilko Bulte wrote: > On Fri, Dec 29, 2006 at 08:45:03AM +0800, lveax wrote.. > > seems there are many machines at freebsd.org network are still using > > 4-STABLE now. > > There is a mix of versions in use, upgrading is done at the discretion > of the admins team that controls the FreeBSD.org server farm. That in > turn is dependent on the amount of time admins have available etc etc. > > So what is the problem? Indeed...I still run and admin a large number of 4-STABLE servers, and even as I'm currently in the process of deploying 6-STABLE on my own servers, I still regularly deploy 4-STABLE for customers of mine. There's a lot to be said for the "why fix what isn't broken" train of thought. I bet there are still a decent number of 2.2.8 boxes floating around...perhaps there's even more to be said for version maturity in general. I was hoping to wait for 6.4-R before jumping to the 6 line, but 6.2 is looking pretty solid for my purposes, so it seems like a great time to start migrating. I'm curious if anybody else is planning to migrate a large number of 4-STABLE boxes to 6-STABLE as of 6.2-R. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: burncd 'blank' not terminating ?
On Fri, 29 Dec 2006, Jeremy Chadwick wrote: On Fri, Dec 29, 2006 at 12:15:37AM -0700, Scott Long wrote: Did you know that ATAPI is actually just the SCSI command set that is merely encapsulated into the IDE wire protocol? This is something Linux has done (you can still use the direct ATA and IDE subsystems if you want, but in most major distros I've seen as of late, they use a SCSI-to-ATA conversion layer). Thus: why haven't we moved the front-end to the ATA subsystem into atapicam(4) then? Is it just the amount of work involved, or are there technical reasons? atapicam works by using CAM (SCSI) as the front end and ATA as the back end. It's not correct to say that the rest of ATA should be moved into atapicam. Instead what you want is to teach CAM how to do more back-ends than just parallel SCSI. There are no technical reasons not to experiment with this. It is a bit of work, though. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
If memory serves me right, Wilko Bulte wrote: > On Fri, Dec 29, 2006 at 08:45:03AM +0800, lveax wrote.. >> seems there are many machines at freebsd.org network are still using >> 4-STABLE now. > > There is a mix of versions in use, upgrading is done at the discretion > of the admins team that controls the FreeBSD.org server farm. That in > turn is dependent on the amount of time admins have available etc etc. > > So what is the problem? That list isn't quite current either; at least two of the machines listed as running 4.X are really running 6.X due to recent hardware swapouts and upgrades. I'll go update the Web page to reflect this. Bruce. signature.asc Description: OpenPGP digital signature
Re: Possibility for FreeBSD 4.11 Extended Support
I wrote: > That list isn't quite current either; at least two of the machines > listed as running 4.X are really running 6.X due to recent hardware > swapouts and upgrades. I'll go update the Web page to reflect this. ...except that someone just beat me to it. :-) Bruce. signature.asc Description: OpenPGP digital signature
Re: system breach
gareth wrote: On Thu 2006-12-28 (22:10), David Todd wrote: something's up, nothing in ports will write to a /tmp/download directory, so either you or someone with root access did it. I just checked one of my servers and also found a /tmp/download directory with the same files that you had. I then compared the timestamp of /tmp/download with the timestamp of the directories in /var/db/pkg: Same. My conclusion is that during a portupgrade these files were written there, directly or indirectly by portupgrade or the port itself. About two years ago I cleaned up a system that really had a system breach (through some php-based webapplication). I could then find a directory in /tmp owned by www that contains a complete distribution with configurescript and the result of the build. This /tmp/download doesn't look like that at all. /thn -- --- Svensk Aktuell Elektronik AB Thomas Nyström Box 10Phone: +46 8 35 92 85 S-191 21 SollentunaFax: +46 8 35 92 86 Sweden Email: [EMAIL PROTECTED] --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: burncd 'blank' not terminating ?
On Fri, Dec 29, 2006 at 12:15:37AM -0700, Scott Long wrote: > Did you know that ATAPI is actually just the SCSI command set that is > merely encapsulated into the IDE wire protocol? This is something Linux has done (you can still use the direct ATA and IDE subsystems if you want, but in most major distros I've seen as of late, they use a SCSI-to-ATA conversion layer). Thus: why haven't we moved the front-end to the ATA subsystem into atapicam(4) then? Is it just the amount of work involved, or are there technical reasons? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://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 "[EMAIL PROTECTED]"
Re: rsync write fails on descriptor 3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- Original Message
Subject: Re:rsync write fails on descriptor 3
From: M. Warner Losh <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: freebsd-stable@freebsd.org
Date: Thursday, December 28, 2006 6:36:17 PM
> In message: <[EMAIL PROTECTED]>
> Ilya Vishnyakov <[EMAIL PROTECTED]> writes:
> : -BEGIN PGP SIGNED MESSAGE-
> : Hash: SHA1
> :
> : Hello, I'm in trouble with rsync. Some people think that this problem
> : is freebsd related:
> :
> : I use rsync to synchronize 2 servers (rsync versions are same on both
> : machines).
> : Most of the directories are copied fine, however, some huge ones fail
> : and produce
> : some strange output.
> :
> : Rsync guys detected this problem as: "
> : So the write fails on descriptor 3, which I think is the socket to the
> : > daemon. I Googled "FreeBSD write EPERM" and turned up the
> : > following FreeBSD bug, which you might be seeing:
> : >
> : > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F95559
> :
> : I use FreeBSD m.mycompany.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2:
> :
> : here is the detailed output of the error (I tried to run rsync in
> : different modesm however, with no luck):
> :
> : truss rsync -atlrpogHvv me at myip::public
> : - - - --password-file=/root/rsync_pass /home/public
> :
> : ARRIVALS/ARRV112806.xls",0x7fffc620) ERR#2 'No such file or
directory'
> : lstat("Company/General/2006 OLD
> : ARRIVALS/ARRV112906.xls",0x7fffc620) ERR#2 'No such file or
directory'
> : select(5,{4},{3},0x0,{60 0}) = 1 (0x1)
> : write(3,0xc2,4092) ERR#1 'Operation not permitted'
> : rsync: writefd_unbuffered failed to write 4092 bytes [generator]:
> : Operation not permitted (1)write(2,0x7fffa4f0,93) = 93 (0x5d)
> :
> : write(2,0x80083ce67,1) = 1 (0x1)
> : sigaction(SIGUSR1,{ SIG_IGN
> : 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t
> : },0x0) = 0 (0x0)
> : sigaction(SIGUSR2,{ SIG_IGN
> : 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t
> : },0x0) = 0 (0x0)
> : getpid() = 42660 (0xa6a4)
> : kill(0xa6a5,0x1e)= 0 (0x0)
> : rsync error: received SIGUSR1 (code 19) at main.c(1095) [receiver=2.6.8]
> : rsync error: error in rsync protocol data stream (code 12) at
> : io.c(1124) [generator=2.6.8]write(2,0x7fffa480,90) = 90
(0x5a)
> :
> : write(2,0x80083ce67,1) = 1 (0x1)
> : SIGNAL 20 (SIGCHLD)
> : SIGNAL 20 (SIGCHLD)
> : wait4(0x,0x7fffb394,0x1,0x0) = 42661 (0xa6a5)
> : wait4(0x,0x7fffb394,0x1,0x0) ERR#10 'No child
> : processes'
> : sigreturn(0x7fffb3b0)= 524288 (0x8)
> : exit(0xc)
> :
> :
> : process exit, rval = 3072
> :
> : here is my share from the rsync.conf:
> : - -
> : uid = 0
> : gid = 0
> : hosts allow = myhostsips
> : secrets file =/usr/local/myfile
> : auth users = ilya
> : [public]
> : path = /home/public/
> : comment = home filesystem
> : auth users = ilya
> : uid = root
> : read only = yes
> : secrets file =/usr/local/myfile
> : - ---
> :
> :
> : Please advice me what to do next. Thank you in advance.
>
> Please make sure that the rsync daemon is actually running as root,
> that there are no syslog messgaes complaining about permission
> problems, etc.
>
> Also make sure that the area you are trying to write to isn't NFS
> mounted (which denies writes to root by default), or has immutable
> file attribute set (see ls -o for a list of flags).
>
> Warner
>
rsync daemon is actually running as root
#ps -aux | grep rsync
#root97768 0.0 0.0 2712 1140 ?? Is6Dec06 0:00.28 rsync
- --daemon
filesystem is not NFS mounted, both machines run BSD 6.1
ls -o shows no flags.
Answering the previous email:
1) Actually read the PR
did that
2) Have you tried the workaround of removing the skip and/or scrub
directives to pf?
yes, with no success
3) Are you even using pf? The PR involved is related to pf, and it
appears as if the problem was related to an incorrect pf configuration,
and _not_ a bug in FreeBSD.
yes we are using pf. I understand that this bug is not FreeBSD
related, most likely. Thank you.
If anyone has more suggestions, please, feel free to reply. Thank you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFlUDObE0+gtjqpZoRAuoXAJ0d4wFs+Ywj33gS2M6t/7gcuSfrTQCfZZGB
Ma8dINxReqNhk2UZ1oucFbc=
=+2/H
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (11:07), Matthew Seaman wrote: > > Oct 23 00:31:42 lordcow kernel: pid 48464 (conftest), uid 0: exited on > > signal 12 (core dumped) > > Oct 23 01:19:26 lordcow kernel: pid 17512 (conftest), uid 0: exited on > > signal 12 (core dumped) > > These are from autoconf testing various capabilities of the system to do > with signal handling -- nothing to be worried about. ok, ta. > Are you running a web server as root on this machine? This illustrates nope, as the www user. > why that is such a bad idea... If you aren't running a web server, > but only using PHP as a command line tool, then have you been doing any > work with such things as IDEs or other large toolsets? They often > have the capability to download and install extra bits at a mouseclick. no haven't used it from the command line, only webserver > The best defense against all of this sort of stuff is to be fully > patched and up to date with all your installed software. PHP is a i use portupgrade at least once a week ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Thu 2006-12-28 (22:10), David Todd wrote: > something's up, nothing in ports will write to a /tmp/download > directory, so either you or someone with root access did it. thought as much :/ > I suggest: > checking /var/log/auth.log for attempted breachings i had a rough skim and nothing suspicious, wanted to know when this happened so i could scrutinise the logs better. > run sockstat and look for processes with ports open that shouldn't > have ports open. thx, had a look at that and netstat etc, everything's normal. > conftest cores ususally mean a ./configure was issued and parts of > said configure failed, them being so far apart suggests that some work > was done to the configure script to fix it. > > If you didn't install anything from ports at or around those periods > of time, then someone was running a configure script to build > something on the machine. ah. it could very well have been me, was compiling a lot've stuff around those 2 days. doesn't seem like portupgrade etc keeps logs to check. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
On Fri, Dec 29, 2006 at 08:45:03AM +0800, lveax wrote.. > seems there are many machines at freebsd.org network are still using > 4-STABLE now. There is a mix of versions in use, upgrading is done at the discretion of the admins team that controls the FreeBSD.org server farm. That in turn is dependent on the amount of time admins have available etc etc. So what is the problem? -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Canonical 4.x to 6.x upgrade docs?
Hi all, On Friday 29 December 2006 17:18, Stephen Clark wrote: > Hi Simon, > > Charles is looking for info on how to upgrade remote systems, which he > does not have physical access > to. The document you reference does not have that info. If you have a remote (serial) console set up, then that document works just fine. If you don't have that, then I'm not sure that upgrade is possible[1] - sshd was one of the first daemons to fail to start when I did my upgrade so you'd be hard pressed to continue after the first reboot. -- patrick [1] well, haven't tried it, but you'd probably have to scp an sshd compiled on 5.x and I'm not sure what else before booting the 5.x kernel. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
seems there are many machines at freebsd.org network are still using 4-STABLE now. http://www.freebsd.org/internal/machines.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Canonical 4.x to 6.x upgrade docs?
Simon L. Nielsen wrote: On 2006.12.28 19:55:55 -0500, Charles Sprickman wrote: Is there any official doc on this? Perhaps I'm just not finding it? I would assume since everyone is being urged to get away from 4.x that somewhere there's a good step-by-step on how to do that. http://www.freebsd.org/releases/5.4R/migration-guide.html#UPGRADE That is the one I used (or perhaps I used it from 5.3-RELEASE, but should be the same), when I recently upgraded a system 4->5->6. The 5->6 should be pretty much like any other FreeBSD upgrade, just follow the normal documented upgrade procedure and don't skip steps. My upgrade actually turned out to be pretty painless and just work. Hi Simon, Charles is looking for info on how to upgrade remote systems, which he does not have physical access to. The document you reference does not have that info. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Canonical 4.x to 6.x upgrade docs?
On 2006.12.28 19:55:55 -0500, Charles Sprickman wrote: > Is there any official doc on this? Perhaps I'm just not finding it? I > would assume since everyone is being urged to get away from 4.x that > somewhere there's a good step-by-step on how to do that. http://www.freebsd.org/releases/5.4R/migration-guide.html#UPGRADE That is the one I used (or perhaps I used it from 5.3-RELEASE, but should be the same), when I recently upgraded a system 4->5->6. The 5->6 should be pretty much like any other FreeBSD upgrade, just follow the normal documented upgrade procedure and don't skip steps. My upgrade actually turned out to be pretty painless and just work. -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
something's up, nothing in ports will write to a /tmp/download directory, so either you or someone with root access did it. I suggest: checking /var/log/auth.log for attempted breachings run sockstat and look for processes with ports open that shouldn't have ports open. conftest cores ususally mean a ./configure was issued and parts of said configure failed, them being so far apart suggests that some work was done to the configure script to fix it. If you didn't install anything from ports at or around those periods of time, then someone was running a configure script to build something on the machine. I wouldn't be overly concerned that if you're dealing with a breach, you're dealing with anyone who is compitent, change your passwords, check auth.log for ssh connections and look at sockstat to see if any programs are running that are listening on ports (that shouldn't be) David On 12/28/06, gareth <[EMAIL PROTECTED]> wrote: hey guys, my server rebooted a few days ago, and while i was looking around for possible reasons (none came up, which's disconcerting in itself) i found this suspicious directory: $ ls -l /tmp/download total 44 drwxr-xr-x 4 root wheel512 Oct 23 16:28 Archive_Tar-1.3.1 drwxr-xr-x 3 root wheel512 Oct 23 16:28 Console_Getopt-1.2 drwxr-xr-x 3 root wheel512 Oct 23 16:28 XML_RPC-1.5.0 -rw-r--r-- 1 root wheel 15433 Jul 12 02:09 package.xml -rw-r--r-- 1 root wheel 22193 Jul 12 02:09 package2.xml the subdirs contain a bunch've .php files, and the xml files are info about version updates of PEAR'S "XML-RPC for PHP". they're owned by root (only i have the passwd) so it wasn't made by a local user, and i assume it wasn't made by portupgrade or something like that? so, i've got no idea how that dir got there, i'm guessing via some web exploit that i still need to look into, and /tmp is mounted 'exec' for some legit processes to function, can't remember which, so it's possible they were able to upload something and run it. chkrootkit which i've only just installed seems clear. anyway, i'm trying to figure out when this happened to have something to go on, and i don't understand the stat command, for example: $ stat /tmp/download/package2.xml 60 49356 -rw-r--r-- 1 root wheel 198776 22193 "Dec 28 04:03:50 2006" "Jul 12 02:09:14 2006" "Oct 23 16:28:28 2006" "Jul 12 02:09:14 2006" 4096 44 0 /tmp/download/package2.xml taking hints from 'stat -x' and 'stat -s' i gather this means: access time = Dec 28 04:03:50 2006 modify time = Jul 12 02:09:14 2006 change time = Oct 23 16:28:28 2006 birth time = Jul 12 02:09:14 2006 now how much of these dates are local or carried over from the source system, since my system was created at 08:00 on 21 Oct 2006 (ie. the Jul dates don't make sense)? (also what's the difference between modify and change time?) essentially is there a way i can tell when the files were put there? this's the directory's info too: $ stat /tmp/download 60 49346 drwxr-xr-x 5 root wheel 196642 512 "Dec 29 00:53:16 2006" "Oct 23 16:28:28 2006" "Oct 23 16:28:28 2006" "Oct 23 16:28:28 2006" 4096 4 0 /tmp/download ps. out've interest: this's the only suspicious thing in the logs i could find: Oct 23 00:31:42 lordcow kernel: pid 48464 (conftest), uid 0: exited on signal 12 (core dumped) Oct 23 01:19:26 lordcow kernel: pid 17512 (conftest), uid 0: exited on signal 12 (core dumped) though from google it seems it could be an innocent apache thing. also around the 23rd or 24th of Oct i started taking md5sums of all the files in the bin and lib directories, and they haven't changed without my knowledge since then. course that doesn't help if the breach was in the 2 odd days before this and after the system was created. also, snort hasn't reported anything overly suspicious, and all packages are kept up to date. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
does growfs actually work on -stable?
I tried to grow a 600GB filesystem to 1TB and growfs barfed complaining about a negative block number - this was a raid array (highpoint) that looks like one drive (da0) to the system. Does growfs actually work - google searches were not much help ... John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
gareth wrote: > Oct 23 00:31:42 lordcow kernel: pid 48464 (conftest), uid 0: exited on signal > 12 (core dumped) > Oct 23 01:19:26 lordcow kernel: pid 17512 (conftest), uid 0: exited on signal > 12 (core dumped) These are from autoconf testing various capabilities of the system to do with signal handling -- nothing to be worried about. > hey guys, my server rebooted a few days ago, and while i was > looking around for possible reasons (none came up, which's > disconcerting in itself) i found this suspicious directory: > > $ ls -l /tmp/download > total 44 > drwxr-xr-x 4 root wheel512 Oct 23 16:28 Archive_Tar-1.3.1 > drwxr-xr-x 3 root wheel512 Oct 23 16:28 Console_Getopt-1.2 > drwxr-xr-x 3 root wheel512 Oct 23 16:28 XML_RPC-1.5.0 > -rw-r--r-- 1 root wheel 15433 Jul 12 02:09 package.xml > -rw-r--r-- 1 root wheel 22193 Jul 12 02:09 package2.xml > > > the subdirs contain a bunch've .php files, and the xml files > are info about version updates of PEAR'S "XML-RPC for PHP". > they're owned by root (only i have the passwd) so it wasn't > made by a local user, and i assume it wasn't made by portupgrade > or something like that? Are you running a web server as root on this machine? This illustrates why that is such a bad idea... If you aren't running a web server, but only using PHP as a command line tool, then have you been doing any work with such things as IDEs or other large toolsets? They often have the capability to download and install extra bits at a mouseclick. Generally if you have a compromise in a PHP based webserver, you'll see the compromised machine used as a spam-bot or similar. Check the contents of your mail spool. Use tcpdump / wireshark to monitor the traffic to and from the machine to look for suspicious activity. If you've got the permissions right, then the attackers will not be able to write to the hard drive through compromising the webserver, which means that a stop and restart of Apache will thwart their nefarious plans, at least until they can recompromise your server. Generally that's about 5 -- 15 minutes, as all that sort of stuff is pretty automated nowadays. The best defense against all of this sort of stuff is to be fully patched and up to date with all your installed software. PHP is a nightmare security wise -- the whole language tends to steer developers into doing sloppy and insecure things by default. Well known, big projects like phpMyAdmin or Horde will generally code stuff pretty tightly, but the rest often need a severe beating with the clue stick. Even the well-managed projects will have their problems, and in fact one of the measures of a well-managed project is how promptly they deal with security problems and how open they are about revealing such things. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: acquiring duplicate lock when mounting nullfs
On 12/29/06, Ulrich Spoerlein <[EMAIL PROTECTED]> wrote: It is similar to LOR #083, but not quite the same acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2036 It seems the issue is known: http://lists.freebsd.org/pipermail/freebsd-amd64/2006-March/007824.html Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 timeout problem - again
On Thursday 28 December 2006 21:52, you wrote:
> check this message:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031216.html
>
> run "/usr/src/tools/tools/net80211/wlandebug/wlandebug -i ath0 power" and
> see if one of the hosts on your wlan has powersaving turned on.
>
> "stops forever" was not one of my symptoms though, so your issue may be
> different...
>
thank's for your answer
powersaving is not the issue here because it's off
But I saw histories about this and even if powersaving issue "was the issue in
that case(really?)" I think this is wierd in any way because if ONE station
with powersaving on could set the AP in DoS ... man ... if really true this
is kind of lame excuse or kind of driver weakness which both would be
inacceptable, and, if it does NOT wake up if in sleep state ... no further
comment, but a driver weakness right?
wether powersaving is on or not on the station/client is a local setting to
this station and must not influence any remote computer in any way, imagine,
you turn on your powersavings and the complete internet goes down on your
request hihihihi :)
but then, like my case, on the AP or better ath in ap mode, even IF
powersaving is ON it might stop working for any related reason but firstable
NOT WHILE TX/RX and secondable if idle it must return soon THIS computer
wants to transmit any kind of traffic again
last but not least powersaving might shut the power down but must return when
necessary - if not - there is a driver problem.
João
> On Thu, 28 Dec 2006, JoaoBR wrote:
> > I need some help here, this is not a single case, I get this on a several
> > machines, this is releng_6 , recent, but old problem getting ugly
> >
> >
> > first I get this kind of events in messages, independent if it is client
> > mode or hostap or adhoc
> >
> > Dec 28 16:50:53 ap1-cds kernel: ath0: discard oversize frame (ether type
> > 5e4 flags 3 len 1522 > max 1514)
> > Dec 28 16:51:01 ap1-cds kernel: ath0: discard oversize frame (ether type
> > 5e4 flags 3 len 1522 > max 1514)
> > Dec 28 16:58:16 ap1-cds kernel: ath0: device timeout
> > ... timeout event repeats
> >
> > I really do not know what this event means (ether type 5e4), for my
> > understandings it is vague in the source, so I am lost here
> >
> > {
> > I get continously:
> >
> > kernel: ath0: link state changed to DOWN
> > kernel: ath0: link state changed to UP
> >
> > when WL client but it recovers when the AP comes back to normal
> > so wl-cli mode is not the issue
> > }
> >
> >
> > but when the machine is running hostap the link state up/down events do
> > not come up but transmission is interrupted, or better, goes slow and
> > stops then - and stops forever until cold reboot, no chance to get this
> > card back, not even unload ath and reload the driver (that was a try but
> > I use it compiled into the kernel)
> > this is not related to any WEP settings or any rate, this problem is
> > coming up with either rate-sample or rate_onoe
> >
> >
> > this is not related to the "tx stopped" problem (OACTIVE) and it is not
> > related to any [TX|RX]BUF value (whatever it is set to)
> >
> > this problem is not a single case and not hardware related, here I mean
> > MB, CPU, memory but is related in a certain way to the ath drv - same
> > machine, but wi0 (prism card) and it does NOT happen this way
> >
> >
> > I am with this problem since 6.0 and would be glad if somebody could
> > convince Mr. Sam L. to attend this since it is a serious issue - any
> > FreeBSD releng_6 has this problem but releng_5 does not
> >
> > depending on the amount of traffic I get this any hour ( when 2-3Mbit/s
> > or more) or several times a day (when 1-2Mbit/s)
> >
> > it get worse when I have more then one ath card installed
> >
> >
> > ath stats:
> >
> > 70777 data frames received
> > 71551 data frames transmit
> > 420 tx frames with an alternate rate
> > 10821 long on-chip tx retries
> > 260 tx failed 'cuz too many retries
> > 11M current transmit rate
> > 10489 tx management frames
> > 1 tx frames discarded prior to association
> > 786 tx frames with no ack marked
> > 80516 tx frames with short preamble
> > 54395 rx failed 'cuz of bad CRC
> > 146438 rx failed 'cuz of PHY err
> >145013 CCK timing
> >1425 CCK restart
> > 5295 beacons transmitted
> > 19 periodic calibrations
> > 42 rssi of last ack
> > 31 avg recv rssi
> > -98 rx noise floor
> > 572 cabq frames transmitted
> > 11 cabq xmit overflowed beacon interval
> > 1525 switched default/rx antenna
> > Antenna profile:
> > [1] tx41285 rx4
> >
> >
> > ifconfig
> >
> > ath0: flags=8943 mtu 1500
> >ether 00:13:46:8b:f1:86
> >media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b
> >status: associated
> >ssid omegasul channel 1 (2412) bssid 00:13:46:8b:f1:86
> >authmode OPEN privacy ON deftxkey 1
> >wepkey 1:40-bit
> >wepkey 2:40-bit
> >wepkey 3:40-bit
> >wepkey 4:40-bi
Canonical 4.x to 6.x upgrade docs?
Hi all, I'm about to hit a number of machines with 6.2-RC2 since we're nearing the release. Many of course are remote, so shuffling CDs around and the like is not practical. I've not been able to find anything in the handbook or FAQ about the process, and Google is returning very few interesting results. This thread contains a few links to rse's procedure: http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/c4c9ccb11b3bfb6b/02a2ffbee370c813 Is there any official doc on this? Perhaps I'm just not finding it? I would assume since everyone is being urged to get away from 4.x that somewhere there's a good step-by-step on how to do that. Thanks, Charles ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
acquiring duplicate lock when mounting nullfs
Hi, this is on a RELENG_6 while mounting /usr/src and /usr/obj via nullfs and doing 'make installkernel installworld' It is similar to LOR #083, but not quite the same acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2036 KDB: stack backtrace: kdb_backtrace(0,ff,c09816d0,c09816d0,c0907904,...) at kdb_backtrace+0x29 witness_checkorder(c30d56dc,9,c089bd90,7f4) at witness_checkorder+0x578 _mtx_lock_flags(c30d56dc,0,c089bd90,7f4,c218d830,...) at _mtx_lock_flags+0x78 vrefcnt(c30d5660) at vrefcnt+0x1d null_checkvp(c2a8daa0,c08894b8,215) at null_checkvp+0x56 null_lock(cd689a80) at null_lock+0x62 VOP_LOCK_APV(c0900480,cd689a80) at VOP_LOCK_APV+0x87 vn_lock(c2a8daa0,1002,c27a3180,c2a8daa0,c31bbc2c,...) at vn_lock+0xa8 nullfs_root(c246d7c8,2,cd689af8,c27a3180,0,8,0,c09beca0,0,c089b632,3dd) at nullfs_root+0x26 vfs_domount(c27a3180,c261c550,c28f7100,0,c239eb10,c09707e0,0,c089b632,2a3) at vfs_domount+0x91d vfs_donmount(c27a3180,0,c2a12e80,c2a12e80,0,...) at vfs_donmount+0x2ef nmount(c27a3180,cd689d04) at nmount+0x8b syscall(3b,3b,3b,bfbfe424,bfbfec7c,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280ba4d7, esp = 0xbfbfe3ac, ebp = 0xbfbfec28 --- Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: burncd 'blank' not terminating ?
Peter Jeremy wrote: On Mon, 2006-Dec-25 16:55:54 +0100, O. Hartmann wrote: burncd had some nice advantages over cdrecord: it came from the BSD tree, it had capabilities for burning DVD+RW images. Disadvantage was the limitation to ATA interface. I see the latter as a disadvantage of cdrecord: It only works on SCSI drives (or via atapicam) and uses an obscure device naming approach. I am also more comfortable making /dev/acd0 mode 0666 than doing the same to /dev/pass0 Did you know that ATAPI is actually just the SCSI command set that is merely encapsulated into the IDE wire protocol? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 timeout problem - again
check this message:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031216.html
run "/usr/src/tools/tools/net80211/wlandebug/wlandebug -i ath0 power" and
see if one of the hosts on your wlan has powersaving turned on.
"stops forever" was not one of my symptoms though, so your issue may be
different...
On Thu, 28 Dec 2006, JoaoBR wrote:
I need some help here, this is not a single case, I get this on a several
machines, this is releng_6 , recent, but old problem getting ugly
first I get this kind of events in messages, independent if it is client mode
or hostap or adhoc
Dec 28 16:50:53 ap1-cds kernel: ath0: discard oversize frame (ether type 5e4
flags 3 len 1522 > max 1514)
Dec 28 16:51:01 ap1-cds kernel: ath0: discard oversize frame (ether type 5e4
flags 3 len 1522 > max 1514)
Dec 28 16:58:16 ap1-cds kernel: ath0: device timeout
... timeout event repeats
I really do not know what this event means (ether type 5e4), for my
understandings it is vague in the source, so I am lost here
{
I get continously:
kernel: ath0: link state changed to DOWN
kernel: ath0: link state changed to UP
when WL client but it recovers when the AP comes back to normal
so wl-cli mode is not the issue
}
but when the machine is running hostap the link state up/down events do not
come up but transmission is interrupted, or better, goes slow and stops
then - and stops forever until cold reboot, no chance to get this card back,
not even unload ath and reload the driver (that was a try but I use it
compiled into the kernel)
this is not related to any WEP settings or any rate, this problem is coming up
with either rate-sample or rate_onoe
this is not related to the "tx stopped" problem (OACTIVE) and it is not
related to any [TX|RX]BUF value (whatever it is set to)
this problem is not a single case and not hardware related, here I mean MB,
CPU, memory but is related in a certain way to the ath drv - same machine,
but wi0 (prism card) and it does NOT happen this way
I am with this problem since 6.0 and would be glad if somebody could convince
Mr. Sam L. to attend this since it is a serious issue - any FreeBSD releng_6
has this problem but releng_5 does not
depending on the amount of traffic I get this any hour ( when 2-3Mbit/s or
more) or several times a day (when 1-2Mbit/s)
it get worse when I have more then one ath card installed
ath stats:
70777 data frames received
71551 data frames transmit
420 tx frames with an alternate rate
10821 long on-chip tx retries
260 tx failed 'cuz too many retries
11M current transmit rate
10489 tx management frames
1 tx frames discarded prior to association
786 tx frames with no ack marked
80516 tx frames with short preamble
54395 rx failed 'cuz of bad CRC
146438 rx failed 'cuz of PHY err
145013 CCK timing
1425 CCK restart
5295 beacons transmitted
19 periodic calibrations
42 rssi of last ack
31 avg recv rssi
-98 rx noise floor
572 cabq frames transmitted
11 cabq xmit overflowed beacon interval
1525 switched default/rx antenna
Antenna profile:
[1] tx41285 rx4
ifconfig
ath0: flags=8943 mtu 1500
ether 00:13:46:8b:f1:86
media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b
status: associated
ssid omegasul channel 1 (2412) bssid 00:13:46:8b:f1:86
authmode OPEN privacy ON deftxkey 1
wepkey 1:40-bit
wepkey 2:40-bit
wepkey 3:40-bit
wepkey 4:40-bit powersavemode OFF powersavesleep 100 txpowmax 36
txpower 63 rtsthreshold 2346 mcastrate 1 fragthreshold 2346 bmiss 7
-pureg protmode CTS -wme burst ssid HIDE -apbridge dtimperiod 1
bintval 100
--
thank's
João
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
