misc/149058: ASUS WL-167g doesn't work in 8.1
>Number: 149058 >Category: misc >Synopsis: ASUS WL-167g doesn't work in 8.1 >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jul 29 08:20:09 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Alexey A Bukreev >Release:FreeBSD 8.1-RELEASE >Organization: at Home :) >Environment: FreeBSD 8.1-RELEASE #0: Wed Jul 28 20:58:59 UTC 2010 (Now I can't do uname -a) >Description: Hello! This Wi-Fi card works correctly in 6.4 & 7.3 on the same computer. Steps: 1. I installed FreeBSD 8.1-RELEASE. 2. Wrote in rc.conf: ifconfig_ural0="inet 172.30.0.11 netmask 255.255.0.0 ssid lepishome wepmode off channel 2 media OFDM/54Mbps mediaopt hostap up 3. Reboot. At this moment in 7.3 Wi-Fi card starts work correctly - as a Wi-Fi access point. In 8.1 nothing happens. 'ural0' hasn't IP-address or any settings. I wrote in console 'ifconfig ural0 172.30.0.11 netmask 255.255.0.0 up' - address and netmask successfully assigned to ural0. But LED on it doesn't blink. I wrote in console 'ifconfig ural0 ssid lepishome' and get message "ifconfig: SIOCS80211: Invalid argument" in this console and message "ural0: discard raw packet" in 1st console. "http://fixunix.com/freebsd/541408-ifconfig-siocs80211-invalid-argument.html"; didn't help me. I tried to update kernel source code and recompile kernel — the same result. There is no info about "discard raw packet" in Internet, except source codes of "head/sys/net80211/ieee80211.c". My dmesg: Jul 28 23:05:42 lepis syslogd: kernel boot file is /boot/kernel/kernel Jul 28 23:05:42 lepis kernel: Copyright (c) 1992-2010 The FreeBSD Project. Jul 28 23:05:42 lepis kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 28 23:05:42 lepis kernel: The Regents of the University of California. All rights reserved. Jul 28 23:05:42 lepis kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jul 28 23:05:42 lepis kernel: FreeBSD 8.1-RELEASE #0: Wed Jul 28 20:58:59 UTC 2010 Jul 28 23:05:42 lepis kernel: lepis@:/usr/obj/usr/src/sys/lepis i386 Jul 28 23:05:42 lepis kernel: module_register: module if_bridge already exists! Jul 28 23:05:42 lepis kernel: Module if_bridge failed to register: 17 Jul 28 23:05:42 lepis kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jul 28 23:05:42 lepis kernel: CPU: Pentium(R) Dual-Core CPU E5300 @ 2.60GHz (2621.49-MHz 686-class CPU) Jul 28 23:05:42 lepis kernel: Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Jul 28 23:05:42 lepis kernel: Features=0xbfebfbff Jul 28 23:05:42 lepis kernel: Features2=0x400e3bd Jul 28 23:05:42 lepis kernel: AMD Features=0x2010 Jul 28 23:05:42 lepis kernel: AMD Features2=0x1 Jul 28 23:05:42 lepis kernel: TSC: P-state invariant Jul 28 23:05:42 lepis kernel: real memory = 2147483648 (2048 MB) Jul 28 23:05:42 lepis kernel: avail memory = 2055565312 (1960 MB) Jul 28 23:05:42 lepis kernel: ACPI APIC Table: Jul 28 23:05:42 lepis kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jul 28 23:05:42 lepis kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Jul 28 23:05:42 lepis kernel: cpu0 (BSP): APIC ID: 0 Jul 28 23:05:42 lepis kernel: cpu1 (AP): APIC ID: 1 Jul 28 23:05:42 lepis kernel: ioapic0 irqs 0-23 on motherboard Jul 28 23:05:42 lepis kernel: kbd1 at kbdmux0 Jul 28 23:05:42 lepis kernel: acpi0: on motherboard Jul 28 23:05:42 lepis kernel: acpi0: [ITHREAD] Jul 28 23:05:42 lepis kernel: acpi0: Power Button (fixed) Jul 28 23:05:42 lepis kernel: acpi0: reservation of fed1c000, 4000 (3) failed Jul 28 23:05:42 lepis kernel: acpi0: reservation of fed2, 7 (3) failed Jul 28 23:05:42 lepis kernel: acpi0: reservation of ffc0, 30 (3) failed Jul 28 23:05:42 lepis kernel: acpi0: reservation of fec0, 1000 (3) failed Jul 28 23:05:42 lepis kernel: acpi0: reservation of fee0, 1000 (3) failed Jul 28 23:05:42 lepis kernel: acpi0: reservation of f000, 400 (3) failed Jul 28 23:05:42 lepis kernel: acpi0: reservation of 0, a (3) failed Jul 28 23:05:42 lepis kernel: acpi0: reservation of 10, 7dd0 (3) failed Jul 28 23:05:42 lepis kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jul 28 23:05:42 lepis kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jul 28 23:05:42 lepis kernel: cpu0: on acpi0 Jul 28 23:05:42 lepis kernel: ACPI Warning: Incorrect checksum in table [OEMB] - 0x27, should be 0x22 (20100331/tbutils-354) Jul 28 23:05:42 lepis kernel: cpu1: on acpi0 Jul 28 23:05:42 lepis kernel: acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Jul 28 23:05:42 lepis kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Jul 28 23:05:42 lepis kernel: pcib0: port 0xcf8-0xcff on acpi0 Jul 28 23:05:42 lepis kernel: pci0: on pcib0 Jul
misc/149059: regression in /etc/rc.subr
>Number: 149059
>Category: misc
>Synopsis: regression in /etc/rc.subr
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jul 29 09:30:07 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Petr Lampa`
>Release:STABLE-8.1
>Organization:
BUT FIT
>Environment:
FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Jul 28 15:00:35 CEST 2010
r...@xxx:/usr/src/sys/i386/compile/XXX i386
>Description:
The last change in /etc/rc.subr broke sendmail startup with
sendmail_enable="NONE". We start sendmail in our local script, after this
change, MTA daemon from /etc/rc.d/sendmail is started, too. We don't want two
sendmail daemons in one system :-( See
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.subr.diff?r1=1.88.2.10;r2=1.88.2.11;f=h
In our case $rc_pid contains pid of locally started sendmail, so this case in
run_rc_command is now false:
if [ -n "${rcvar}" -a "$rc_arg" != "rcvar" -a -z "${rc_pid}" ];
if ! checkyesno ${rcvar}; then
if [ -n "${rc_quiet}" ]; then
return 0
fi
fi
fi
The checkyesno is not executed and the script doesn't return through return 0
as it was returning before this change. I really don't understand why the test
for rc_pid was added here and the CVS comment doesn't help too much:
SVN rev 207797 on 2010-05-08 21:18:22Z by dougb
MFC r206686:
Make 'stop' work even if ${name}_enable is not set.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: conf/149059: regression in /etc/rc.subr
Synopsis: regression in /etc/rc.subr Responsible-Changed-From-To: freebsd-bugs->dougb Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 29 12:15:50 UTC 2010 Responsible-Changed-Why: Over to committer of the change in question, for evaluation. http://www.freebsd.org/cgi/query-pr.cgi?pr=149059 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: usb/149058: [ural] ASUS WL-167g doesn't work in 8.1 [regression]
Old Synopsis: ASUS WL-167g doesn't work in 8.1 New Synopsis: [ural] ASUS WL-167g doesn't work in 8.1 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 29 12:17:06 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149058 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: usb/149058: [ural] ASUS WL-167g doesn't work in 8.1 [regression]
On Thursday 29 July 2010 14:17:58 lini...@freebsd.org wrote: > Old Synopsis: ASUS WL-167g doesn't work in 8.1 > New Synopsis: [ural] ASUS WL-167g doesn't work in 8.1 [regression] > > Responsible-Changed-From-To: freebsd-bugs->freebsd-usb > Responsible-Changed-By: linimon > Responsible-Changed-When: Thu Jul 29 12:17:06 UTC 2010 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=149058 Hi, This is not an USB problem! ifconfig wlan0 create wlandev ural0 ifconfig wlan0 inet 192.168.0.1 netmask 0xff00 up --HPS ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: usb/149058: [ural] ASUS WL-167g doesn't work in 8.1 [regression]
2010/7/29 Hans Petter Selasky : > This is not an USB problem! In fact, this is a *documentation* problem: At least the part on configuring an access point is outdated, and was written before VAPs were introduced (http://www.freebsd.org/doc/handbook/network-wireless.html). It should mention create_args_IF. Regards Lucius ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/40282: commit references a PR
The following reply was made to PR bin/40282; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/40282: commit references a PR
Date: Thu, 29 Jul 2010 16:40:55 + (UTC)
Author: jilles
Date: Thu Jul 29 16:40:45 2010
New Revision: 210613
URL: http://svn.freebsd.org/changeset/base/210613
Log:
kill: Stop processing if a syntactically invalid pid is encountered.
So a command like
kill _HUP 1
now fails without sending SIGTERM to init.
The behaviour when kill(2) fails remains unchanged: processing continues.
This matches other implementations and POSIX and is useful for killing
multiple processes at once when some of them may already be gone.
PR: bin/40282
Modified:
head/bin/kill/kill.c
Modified: head/bin/kill/kill.c
==
--- head/bin/kill/kill.c Thu Jul 29 16:30:27 2010(r210612)
+++ head/bin/kill/kill.c Thu Jul 29 16:40:45 2010(r210613)
@@ -123,10 +123,9 @@ main(int argc, char *argv[])
for (errors = 0; argc; argc--, argv++) {
pid = strtol(*argv, &ep, 10);
- if (!**argv || *ep) {
- warnx("illegal process id: %s", *argv);
- errors = 1;
- } else if (kill(pid, numsig) == -1) {
+ if (!**argv || *ep)
+ errx(1, "illegal process id: %s", *argv);
+ else if (kill(pid, numsig) == -1) {
warn("%s", *argv);
errors = 1;
}
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/149012: [headers] [patch] please replace '#include ' with '#include '
Hi, I realize I made a mistake, kernel headers can't use so my change needs to be reverted in sys/ directory. I tested with make buildkernel now (in my FreeBSD chroot), and it works. Sorry! On 7/28/10, lini...@freebsd.org wrote: > Old Synopsis: [headers] [request] please replace '#include ' > with '#include ' > New Synopsis: [headers] [patch] please replace '#include ' > with '#include ' > > State-Changed-From-To: suspended->open > State-Changed-By: linimon > State-Changed-When: Thu Jul 29 01:40:45 UTC 2010 > State-Changed-Why: > patch received. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=149012 > ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: usb/149058: [ural] ASUS WL-167g doesn't work in 8.1 [regression]
On Thu, Jul 29, 2010 at 09:57:25PM +0200, Marc Fonvieille wrote: > On Thu, Jul 29, 2010 at 06:10:35PM +0200, Lucius Windschuh wrote: > > 2010/7/29 Hans Petter Selasky : > > > This is not an USB problem! > > > > In fact, this is a *documentation* problem: > > At least the part on configuring an access point is outdated, and was > > written before VAPs were introduced > > (http://www.freebsd.org/doc/handbook/network-wireless.html). > > It should mention create_args_IF. > > > > Yes the AP part is outdated but the client part is up to date and this > is the subject of the PR. So please don't blame docs when they are not > guilty :) > Well, I'm a bit wrong a part of the PR is related to APs as well. But the client part is enough explicit, I mean one can't miss the wlanX use. Anyway, I have the update of the part AP on my TODO list, it should be online soon. Let's close this PR. -- Marc ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: usb/149058: [ural] ASUS WL-167g doesn't work in 8.1 [regression]
On Thu, Jul 29, 2010 at 06:10:35PM +0200, Lucius Windschuh wrote: > 2010/7/29 Hans Petter Selasky : > > This is not an USB problem! > > In fact, this is a *documentation* problem: > At least the part on configuring an access point is outdated, and was > written before VAPs were introduced > (http://www.freebsd.org/doc/handbook/network-wireless.html). > It should mention create_args_IF. > Yes the AP part is outdated but the client part is up to date and this is the subject of the PR. So please don't blame docs when they are not guilty :) -- Marc ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/40282: [patch] kill(1) has bad error checking for command line parameters
Synopsis: [patch] kill(1) has bad error checking for command line parameters State-Changed-From-To: analyzed->closed State-Changed-By: jilles State-Changed-When: Thu Jul 29 21:06:59 UTC 2010 State-Changed-Why: Fixed in 9-current, no MFC planned. Responsible-Changed-From-To: freebsd-bugs->jilles Responsible-Changed-By: jilles Responsible-Changed-When: Thu Jul 29 21:06:59 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=40282 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/148733: a potential buffer overflow in sh(1)
The following reply was made to PR bin/148733; it has been noted by GNATS. From: Jilles Tjoelker To: bug-follo...@freebsd.org, snnn...@gmail.com Cc: Subject: Re: bin/148733: a potential buffer overflow in sh(1) Date: Thu, 29 Jul 2010 23:38:55 +0200 > [buffer overflow in sh(1) pathname generation] You are right, there is a possible heap buffer overflow here. It is rather unlikely in normal usage because the kernel does not accept pathnames longer than 1023 bytes, but still possible. -- Jilles Tjoelker ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/35717: which(1) returns wrong exit status for multiple arguments
The following reply was made to PR bin/35717; it has been noted by GNATS. From: Jilles Tjoelker To: bug-follo...@freebsd.org, wo...@freebsd.org Cc: Subject: Re: bin/35717: which(1) returns wrong exit status for multiple arguments Date: Fri, 30 Jul 2010 00:30:20 +0200 > [5.x's /usr/bin/which returns 1 if any argument is not found, instead > of only when all arguments are not found like 4.x's] The new behaviour seems consistent with what most other utilities do (if an error occurs processing an argument, processing continues with the next argument but the exit status will be non-zero). POSIX mentions this in "Consequences of Errors" in XCU 1.4 Utility Description Defaults. Following this for non-standard utilities is not a requirement but makes things more consistent. There is no standard for which(1). The closest is probably the tcsh(1) builtin which behaves like the new /usr/bin/which. There seems little reason to change. -- Jilles Tjoelker ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/145082: Patch against w(1) & uptime(1) to use 24H time by default.
Synopsis: Patch against w(1) & uptime(1) to use 24H time by default. Responsible-Changed-From-To: freebsd-standards->freebsd-bugs Responsible-Changed-By: jilles Responsible-Changed-When: Thu Jul 29 22:41:10 UTC 2010 Responsible-Changed-Why: This is not a standards compliance issue as w and uptime are not in POSIX. Regarding the patch, how does a user select 12h output? I tried LANG=en_US.ISO8859-1 w and it still gave 24h. http://www.freebsd.org/cgi/query-pr.cgi?pr=145082 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/135918: [boot0] [patch] Make BootEasy compatible with NT Drive Serial Number by default
Synopsis: [boot0] [patch] Make BootEasy compatible with NT Drive Serial Number by default Responsible-Changed-From-To: freebsd-bugs->luigi Responsible-Changed-By: arundel Responsible-Changed-When: Thu Jul 29 22:50:22 UTC 2010 Responsible-Changed-Why: Over to luigi as MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=135918 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/140752: [ata] [patch] HDD power-off procedure is not clean
The following reply was made to PR kern/140752; it has been noted by GNATS. From: Alexander Best To: bug-follo...@freebsd.org Cc: Subject: Re: kern/140752: [ata] [patch] HDD power-off procedure is not clean Date: Thu, 29 Jul 2010 23:03:14 + i'm forwarding this message i got from warren which might be helpful to anybody working on this pr in the future. cheers. alex -- Forwarded message -- From: Warren Block Date: 2010/3/6 Subject: Summary: Re: Spin down HDD after disk sync or before power off To: Oliver Fromme Cc: freebsd-hack...@freebsd.org, alexbes...@wwu.de, j...@freebsd.org Just wanted to followup with a summary before all vestiges of what I learned evaporate from my memory. My apologies for the lateness. 1. Existing FreeBSD ata-disk code does not explicitly park the hard drive heads on shutdown. So the power loss causes an emergency park, which sounds bad and is bad for the heads. 2. There are a limited number of powerup/powerdown or maybe spinup/spindown cycles for a drive. Not sure what causes the wear. 3. FreeBSD doesn't park heads at reboot, either, but that's good because of #2. 4. FreeBSD's suspend code does call STANDBY_IMMEDIATE to park heads. 5. I couldn't tell if the STANDBY_IMMEDIATE in a reboot actually spun the drive down. It may be that the hardware reset happens so quickly after the standby that it doesn't matter. Or maybe it brakes very quietly. Possibly different brands do different things. I can think of ways to check, like measuring motor current, but don't have the equipment to try that. 6. Ond?ej Majerech suggested checking NetBSD's method of spinning the drive down. I did, and they have a direct way of telling the difference between reboot and shutdown, somewhat differently from FreeBSD. 7. I actually waded hip-deep through magic C code and made a powerdown event handler for ata-disk.c. It compiled and even seemed to work, although I don't trust it. 8. Alexander Motin has an updated CAM version of the ATA system which will eventually replace the existing one. In -CURRENT, anyway. He was kind enough to look at my event handler. My understanding is that he is looking at implementing the head parking/standby mechanism in that new code. Conclusions: If you rarely power down a system with FreeBSD, it may not matter, and reboots with the existing code should not be a problem. If you power down a system from FreeBSD often, the patch in http://docs.freebsd.org/cgi/getmsg.cgi?fetch=233916+0+archive/2010/freebsd-hackers/20100131.freebsd-hackers is still the lowest-impact version, although it calls STANDBY_IMMEDIATE for both reboot and shutdown. I don't have evidence either way as to whether the standby followed by a reboot causes as much wear as a cold spinup/spindown cycle, or whether that is more of a problem than emergency head parks. -Warren Block * Rapid City, South Dakota USA ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/54784: find(1) -ls wastes space
Synopsis: find(1) -ls wastes space State-Changed-From-To: open->closed State-Changed-By: jilles State-Changed-When: Thu Jul 29 23:24:55 UTC 2010 State-Changed-Why: I don't think there is a good way to fix this. Iterating over all users with getpwent() may be very slow or may not work at all in some environments. I don't see another way to find the column widths. Buffering all output would be rather annoying as well. http://www.freebsd.org/cgi/query-pr.cgi?pr=54784 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/30424: Generalization of vipw(8) to lock pwdb while being edited by a script
The following reply was made to PR bin/30424; it has been noted by GNATS. From: Jilles Tjoelker To: bug-follo...@freebsd.org, a...@batie.org Cc: Subject: Re: bin/30424: Generalization of vipw(8) to lock pwdb while being edited by a script Date: Fri, 30 Jul 2010 01:50:55 +0200 Is there any reason you need a special option in vipw(8) to run (in effect) a different editor, when temporarily changing the EDITOR environment variable would do the same? Also, the pw(8) utility may be useful, allowing various modifications to the passwd database more easily. -- Jilles Tjoelker ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/149086: Generic multicast join failure in 8.1
>Number: 149086
>Category: misc
>Synopsis: Generic multicast join failure in 8.1
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Jul 30 00:00:09 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Hans-Werner Braun
>Release:8.1-RELEASE
>Organization:
UC San Diego
>Environment:
FreeBSD mcr.hpwren.ucsd.edu 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Thu Jul 29
09:50:21 PDT 2010 h...@mcr.hpwren.ucsd.edu:/usr/src/sys/amd64/compile/MCR
amd64
>Description:
A perl program that I used in previous FreeBSD releases does not work any more.
Specifically from tcpdump outputs it does not send the join request to the
router. The program:
#!/usr/local/bin/perl
use Socket;
$PORT=$ARGV[0];
$PATTERN=$ARGV[1];
$SERVER=$ARGV[2];
if($PORT eq ""){
printf"Syntax: mcaststream.pl port {pattern} {multicastaddress}\n";
exit;
}
if($SERVER eq ""){$SERVER="233.7.117.79";}
$|=1;
$IP_ADD_MEMBERSHIP=12;
($name, $aliases, $type, $len, $SERVERIP) = gethostbyname($SERVER);
$sockaddr = 'S n a4 x8';
socket(S, PF_INET,SOCK_DGRAM,UDP_PROTO)||die("$!");
setsockopt(S, SOL_SOCKET, SO_REUSEPORT, 1)||die("$!");
$us = pack($sockaddr, 2, $PORT, pack("C4", 0,0,0,0));
bind(S, $us)||die("$!");
setsockopt(S, 0, $IP_ADD_MEMBERSHIP, $SERVERIP."\0\0\0\0")||die("$!");
while($theiraddr=recv(S,$BUF,1024,0)){
($junk, $junk, $sourceaddr, $junk) = unpack($sockaddr, $theiraddr);
$theirip=join('.',unpack('C4', $sourceaddr));
if($BUF =~ $PATTERN){
printf"$theirip\t$BUF";
}
}
>How-To-Repeat:
The above program sends no traffic out of the Ethernet interface (specifically
the join request).
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/149087: openoffice.org-3 does not compile
>Number: 149087 >Category: misc >Synopsis: openoffice.org-3 does not compile >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 30 00:10:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Hans-Werner Braun >Release:8.1-RELEASE >Organization: UC San Diego >Environment: FreeBSD mcr.hpwren.ucsd.edu 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Thu Jul 29 09:50:21 PDT 2010 h...@mcr.hpwren.ucsd.edu:/usr/src/sys/amd64/compile/MCR amd64 >Description: openoffice.org-3 does not compile. The problem is with the diablo-jdk-1.6.0.07.02_9 part: ===> diablo-jdk-1.6.0.07.02_9 depends on shared library: z.4 - not found ===>Verifying install for z.4 in /usr/ports/misc/compat7x ===> Returning to build of diablo-jdk-1.6.0.07.02_9 Error: shared library "z.4" does not exist *** Error code 1 The only libz files I found are: /lib/libz.so.5 /usr/lib/libz.a /usr/lib/libz.so >How-To-Repeat: "make" repeats the problem >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/138131: [patch] pstat(8): pstat -t coredumps when reading from kernel crashdump
Synopsis: [patch] pstat(8): pstat -t coredumps when reading from kernel crashdump Responsible-Changed-From-To: freebsd-bugs->remko Responsible-Changed-By: arundel Responsible-Changed-When: Fri Jul 30 00:44:22 UTC 2010 Responsible-Changed-Why: Assign to remko as MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=138131 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/30424: Generalization of vipw(8) to lock pwdb while being edited by a script
The following reply was made to PR bin/30424; it has been noted by GNATS. From: Alan Batie To: Jilles Tjoelker Cc: bug-follo...@freebsd.org Subject: Re: bin/30424: Generalization of vipw(8) to lock pwdb while being edited by a script Date: Thu, 29 Jul 2010 17:39:30 -0700 This is a cryptographically signed message in MIME format. --ms070907040206060705020901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/29/10 4:50 PM, Jilles Tjoelker wrote: > Is there any reason you need a special option in vipw(8) to run (in > effect) a different editor, when temporarily changing the EDITOR > environment variable would do the same? >=20 > Also, the pw(8) utility may be useful, allowing various modifications t= o > the passwd database more easily. Those would have been (and, yes, were available) useful alternatives 9 years ago ;-) The EDITOR hack makes me nervous for gettings args and stdin to the script, though I'm pretty sure they would work; pw is probably the "right" solution to the problem I was solving, though it's inefficient: I was (actually, still am --- that script is still in use) reading in the password file, making several updates to it in memory, then writing it back out. We're talking numbers you can count on fingers and toes though, so efficiency really isn't a factor in this case, though it's conceivable. Well, I'm not sure an application where it would be a factor *is* conceivable, and any setup that large would probably be using a db backend of some sort, but still, that's the sort of operation where pw_lock is useful, and it's trivial to support. --ms070907040206060705020901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPWjCC BMwwggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOCAYQwggGAMBIG A1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDMtMjA0 OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAkoCKG IGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+Iqyz cqpVMA0GCSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESf D0b3+qD+0x0Yo9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Pr v4NZmP1m3umGMpqSKTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFQTCCBCmgAwIB AgIPZR7Dm053Hoy1FoqJb2XkMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh IChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkxMDE0MDAw MDAwWhcNMTAxMDE0MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxhbiBCYXRpZTEdMBsGCSqGSIb3 DQEJARYOYWxhbkBiYXRpZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7 8gzcDFCbvznGCu/DLzUtIZrR0YsZbAIqzyh6EjE6FvH05JK/SRJ5zM32p/brZF99KINpKyoq ctYELJuqMRCdJrdCZai9uO0VGCWnZcYH338o5bh/QE6LZ16tj4R9UjdByK/SHeCUxNHxXmHX A+O9k3hZZXq61WG91a8XKkPgAMuYyQ02AgUIXDc28PjEPGOi2ialvgl9prpNUd3VOGbH601v 98wFhY5Lk+N747WPHwvj/vv+5AZ/qwbNNRRRmLnUtMFKq7htmCAlsV5fFeNJk6t4/q0c9+nu srd2mO1VkT9XB3TXsOVxzDRDR2axP8+hrYIZ3OMykEazWAwjU2NfAgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDV
Re: bin/145082: Patch against w(1) & uptime(1) to use 24H time by default.
The following reply was made to PR bin/145082; it has been noted by GNATS. From: jhell To: bug-follo...@freebsd.org, jh...@dataix.net Cc: Subject: Re: bin/145082: Patch against w(1) & uptime(1) to use 24H time by default. Date: Thu, 29 Jul 2010 20:57:23 -0400 That is part of the problem, I tried to select 24h output and was unsuccessful at doing so. Then I patched up everything I could find to just use 24h time to match the rest of the system since at the time I was looking into it, it was not or did not seem possible to just change a environment variable or other things. --=20 =A0jhell ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/149087: editors/openoffice.org-3 does not compile
Old Synopsis: openoffice.org-3 does not compile New Synopsis: editors/openoffice.org-3 does not compile Responsible-Changed-From-To: freebsd-bugs->openoffice Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 30 01:29:38 UTC 2010 Responsible-Changed-Why: Fix synopsis and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=149087 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/149086: [multicast] Generic multicast join failure in 8.1
Old Synopsis: Generic multicast join failure in 8.1 New Synopsis: [multicast] Generic multicast join failure in 8.1 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 30 01:35:20 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149086 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/54784: find(1) -ls wastes space
On Thu, 29 Jul 2010 jil...@freebsd.org wrote:
Synopsis: find(1) -ls wastes space
State-Changed-From-To: open->closed
State-Changed-By: jilles
State-Changed-When: Thu Jul 29 23:24:55 UTC 2010
State-Changed-Why:
I don't think there is a good way to fix this.
Iterating over all users with getpwent() may be very slow or may not work
at all in some environments.
I don't see another way to find the column widths. Buffering all output
would be rather annoying as well.
It certainly gives unreadable output. And didn't someone want to bloat
UT_NAMESIZE to 256 or so, so that only users with 400-column terminals
could read the output?
Related bugs:
- find(1) claims that the format is identical to that produced by ls -dgils.
Actually, the formats differ greatly in whitespace -- the latter produces
readable output. ls -Rdigls has the same problem as find -ls. ls has
variable column widths for many of the fields including ids. I think it
doesn't calculate the maximum in advance, but keeps using the previous
maximum.
- UT_LINESIZE and no longer exist, but:
- the not-unused header says that MAXLOGNAME should be
UT_LINESIZE+1 refers to for this.
- the not-unused header says that L_cuserid is UT_LINESIZE + 1
and refers to for this.
- there are some style bugs in these dead comments.
- ut_user[] in struct utmpx has size 32 bytes (max name length 31?), but
MAXLOGNAME is still 17.
- find -ls still uses MAXLOGNAME, so its format hasn't been properly
bloated.
- there are related formatting problems for printing the inode number.
find -ls uses the fixed format %6lu and a bogus cast to u_long to
ensure breakage if ino_t is larger than u_long. ls uses the variable
format %*lu. %6lu was more than enough when inodes were 16-bit
and/or file systems were small, but hasn't been enough for many
years. It messes up the alignment of the columns if there is a
mixture of large and small inode numbers, and you almost might as
well print ids using %s and accept the misalignment from this too.
- find -ls has many other printf format errors and format-printf errors:
% void
% printlong(char *name, char *accpath, struct stat *sb)
% {
% char modep[15];
%
% (void)printf("%6lu %8"PRId64" ", (u_long) sb->st_ino, sb->st_blocks);
- format-printf errors:
- PRI* shouldn't exist, but is used
- space after cast
- printf format errors:
- PRI* cannot be used here (without bogusly casting st_blocks to match it).
st_blocks has type blkcnt_t, which might differ from int64_t. blkcnt_t
is actually still int64_t, and it would not be unreasonable to depend
on this implementation to avoid using the PRI* mistake, but not to use it.
% (void)strmode(sb->st_mode, modep);
% (void)printf("%s %3u %-*s %-*s ", modep, sb->st_nlink, MAXLOGNAME - 1,
% user_from_uid(sb->st_uid, 0), MAXLOGNAME - 1,
% group_from_gid(sb->st_gid, 0));
Minor problems with fixed-width format for st_nlink (st_nlink can be as much
as 32767, and when it is >= 1000 it is misformatted).
Honest chumminess with the implementation for st_nlink. nlink_t happens to be
uint16_t so it promotes to u_int.
This still uses MAXLOGNAME. Since MAXLOGNAME is not even the maximum,
misaligned comumns result if ut_user[] is actually used. Here instead
of using %s format to get misalignment often or the current format to
get misalignment sometimes, we should probably use a debloated non-maximum
like 8 to get misalignment sometimes.
%
% if (S_ISCHR(sb->st_mode) || S_ISBLK(sb->st_mode))
% (void)printf("%3d, %3d ", major(sb->st_rdev),
% minor(sb->st_rdev));
The fixed width of 3 for device numbers will mostly work now, but it
used to cause lots of misalignment in ls output due to sparse encodings
in 32-bit minor numbers.
% else
% (void)printf("%8"PRId64" ", sb->st_size);
This use of PRI* is not even not wrong, as above.
% printtime(sb->st_mtime);
I fear finding too many format errors to look at the sub-functions.
% (void)printf("%s", name);
% if (S_ISLNK(sb->st_mode))
% printlink(accpath);
% (void)putchar('\n');
% }
ls doesn't use the PRI* mistake, but it uses the humanize_number() mistake
and associated bogus casts and printf format errors. E.g., in printsize(),
for the scientificized case it blindly casts the size (which is an off_t)
to int64_t to match humanize_number()'s broken API, and in the decimal
case it uses %*jd format with 2 errors (first it bogusly casts the field
width (which has the bogus type size_t) to the bogus type u_int (the '*'
takes an int), and then it doesn't cast the size to intmax_t to match %jd.
ls uses a sub-function for printing device numbers to reduce the
problems with large and negative device numbers. The find -ls output
is much futher from having the same format as ls -digls in this cases.
Perhaps similarly in cases involving extensions like likeACLs. Certainly
simil
