Re: ThinkPad T60 x86emu panic on resume (w/patch)
Please send the dump my way.
Re: [clau...@openbsd.org: graceful restart diff]
On Sep 3, 2012, at 8:14 PM, Claudio Jeker clau...@openbsd.org wrote: I never got any negative test results back about this change. I assume that either nobody is interested or that it just works. I've been using this in semi-production with announce restart yes without issues.
Re: ThinkPad T60 x86emu panic on resume (w/patch)
Date: Wed, 5 Sep 2012 04:01:56 +0400 From: Alexander Polakov p...@sdf.org * Alexander Polakov p...@sdf.org [120903 21:41]: Now back to underlying issues: x86emu executes some code which causes parity check NMI (bit 7 set in port 0x61) to be generated, which causes drop to the debugger (I mistook it for a panic). Nobody asked me which code exactly. But I'll tell you anyway. 000C1867 56 pushsi 000C1868 BE 38 02 mov si, 0x0238 000C186B 8B 34 mov si, [si] 000C186D 8B 74 10 mov si, [si+0x10] 000C1870 83 C6 04 add si, 0x04 000C1873 FC cld 000C1874 B9 07 00 mov cx, 0x0007 000C1877 66 AD lodseax, ds:[esi] 000C1879 E8 D5 F9 call0x000C1251 000C187C 83 C3 04 add bx, 0x04 000C187F E2 F6 loop0x000C1877 000C1881 5E pop si 000C1882 C3 ret NMI ... going to debugger ... x86emu: SEGMASK: 0x0 x86emu: R_DS: 0xc000 x86emu: R_SS: 0x0 x86emu: R_CS: 0xc000 x86emu: R_ES: 0xc000 x86emu: R_FS: 0x0 x86emu: R_GS: 0x0 x86emu: R_IP: 0x1877 x86emu: R_SI: 0xe886 x86emu: R_ESI: 0xe886 x86emu: Now at 0xc1877, instruction: 0x66 Sometimes it's 0xc1878 or even 0xc187f. So, if you feel like debugging this video bios/x86 emulation mess, feel free to contact me, I can provide you with memory dump or disassembled memory dump. Hmm 0x66 is used as an instruction prefix. I believe I've seen prefix-related fixes flying by on the Xorg mailing lists. Might be worth investigating whether there are any x86emu fixes that are missing from our tree.
Re: ThinkPad T60 x86emu panic on resume (w/patch)
On Mon, Sep 10, 2012 at 12:26:09PM +0200, Mark Kettenis wrote: Date: Wed, 5 Sep 2012 04:01:56 +0400 From: Alexander Polakov p...@sdf.org * Alexander Polakov p...@sdf.org [120903 21:41]: Now back to underlying issues: x86emu executes some code which causes parity check NMI (bit 7 set in port 0x61) to be generated, which causes drop to the debugger (I mistook it for a panic). Nobody asked me which code exactly. But I'll tell you anyway. 000C1867 56 pushsi 000C1868 BE 38 02 mov si, 0x0238 000C186B 8B 34 mov si, [si] 000C186D 8B 74 10 mov si, [si+0x10] 000C1870 83 C6 04 add si, 0x04 000C1873 FC cld 000C1874 B9 07 00 mov cx, 0x0007 000C1877 66 AD lodseax, ds:[esi] 000C1879 E8 D5 F9 call0x000C1251 000C187C 83 C3 04 add bx, 0x04 000C187F E2 F6 loop0x000C1877 000C1881 5E pop si 000C1882 C3 ret NMI ... going to debugger ... x86emu: SEGMASK: 0x0 x86emu: R_DS: 0xc000 x86emu: R_SS: 0x0 x86emu: R_CS: 0xc000 x86emu: R_ES: 0xc000 x86emu: R_FS: 0x0 x86emu: R_GS: 0x0 x86emu: R_IP: 0x1877 x86emu: R_SI: 0xe886 x86emu: R_ESI: 0xe886 x86emu: Now at 0xc1877, instruction: 0x66 Sometimes it's 0xc1878 or even 0xc187f. So, if you feel like debugging this video bios/x86 emulation mess, feel free to contact me, I can provide you with memory dump or disassembled memory dump. Hmm 0x66 is used as an instruction prefix. I believe I've seen prefix-related fixes flying by on the Xorg mailing lists. Might be worth investigating whether there are any x86emu fixes that are missing from our tree. I looked at the NetBSD tree last week and I haven't spotted any. Where's the X11 tree for this?
Re: ThinkPad T60 x86emu panic on resume (w/patch)
Date: Mon, 10 Sep 2012 13:34:56 +0300 From: Paul Irofti p...@irofti.net On Mon, Sep 10, 2012 at 12:26:09PM +0200, Mark Kettenis wrote: Date: Wed, 5 Sep 2012 04:01:56 +0400 From: Alexander Polakov p...@sdf.org * Alexander Polakov p...@sdf.org [120903 21:41]: Now back to underlying issues: x86emu executes some code which causes parity check NMI (bit 7 set in port 0x61) to be generated, which causes drop to the debugger (I mistook it for a panic). Nobody asked me which code exactly. But I'll tell you anyway. 000C1867 56 pushsi 000C1868 BE 38 02 mov si, 0x0238 000C186B 8B 34 mov si, [si] 000C186D 8B 74 10 mov si, [si+0x10] 000C1870 83 C6 04 add si, 0x04 000C1873 FC cld 000C1874 B9 07 00 mov cx, 0x0007 000C1877 66 AD lodseax, ds:[esi] 000C1879 E8 D5 F9 call0x000C1251 000C187C 83 C3 04 add bx, 0x04 000C187F E2 F6 loop0x000C1877 000C1881 5E pop si 000C1882 C3 ret NMI ... going to debugger ... x86emu: SEGMASK: 0x0 x86emu: R_DS: 0xc000 x86emu: R_SS: 0x0 x86emu: R_CS: 0xc000 x86emu: R_ES: 0xc000 x86emu: R_FS: 0x0 x86emu: R_GS: 0x0 x86emu: R_IP: 0x1877 x86emu: R_SI: 0xe886 x86emu: R_ESI: 0xe886 x86emu: Now at 0xc1877, instruction: 0x66 Sometimes it's 0xc1878 or even 0xc187f. So, if you feel like debugging this video bios/x86 emulation mess, feel free to contact me, I can provide you with memory dump or disassembled memory dump. Hmm 0x66 is used as an instruction prefix. I believe I've seen prefix-related fixes flying by on the Xorg mailing lists. Might be worth investigating whether there are any x86emu fixes that are missing from our tree. I looked at the NetBSD tree last week and I haven't spotted any. Where's the X11 tree for this? We have a copy in /usr/xenocara/xserver/hw/xfree86/x86emu, and you can look at the commit log at: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/x86emu The particular change I was thinking about was: http://cgit.freedesktop.org/xorg/xserver/commit/hw/xfree86/x86emu?id=bb18f277156c08be028a6e12d8987fb1593e9168 Cheers, Mark
Re: Use ACPI to detect secondary PCI root segments on x86
Hi, first of all: Thanks for your reply! On Sat, Sep 08, 2012 at 04:04:41PM +0200, Mark Kettenis wrote: most modern x86 hardware includes more than one PCI root segement. E.g. a hardware that I have here has three PCI root segemnts with bus numbers 0, 0x7f, 0x80 and 0xff respectively. (0x7f and 0xff host the uncore devices of each processor). Well, machines with multiple host bridges have been around for a while. Some of them even pre-date ACPI. These segments are already detected by APCI but this information is not used when attaching PCI busses to the mainbus. Below is a patch that should solve the PCI bus detection problem in a robust way. I hate ACPI! It's full of lies; I don't trust it. Agreed. It is much better to detect these additional PCI busses by looking at actual hardware registers. This approach (unfortunately) means that device detection breaks with each new chipset and I hate that :-) So before we go down this path, can you investigate that? It seems the bus number for the additional Uncore devices of the Xeon E5 1600/2600 CPUs is available in config register 0x108 of device 0:5:0. Yes, I already figured that. It works and I can cook a patch if you want. The patch is not completely straight forward, tough, because the device is not just a bridge but a multi-purpose devices. But I haven't figured how to find the bus number for the second socket. Looking at the AML for this machine and determining how it detects these additional busses might provide some clues. Feel free to send me the acpidump output for this box. I will send you ACPI data in private. However, the second PCI bus is simply hardwired in DSDT, i.e. there does not seem to be code in ACPI that would try to detect its presence. I tend to believe that there is no bridge device that exposes the second PCI bus. There's a small problem though: Some of the secondary PCI segments can show up as busses behind some kind of host bridge device dowstream of pci bus 0, too. These PCI busses would be attached twice, now. Thus we keep track of attached root segemnents in the ACPI code. Yup. Since we have code to detect additional host bridges some of them may already have been attached. And it would be a good way to defend against ACPI lying to us. However, please keep the ACPI hooks out of the MI PCI code. It'd be better if you used pci_attach_hook(), which lives in arch/pci/pci_machdep.c. Ok, will do that. However, there might be a different solution: We could track attached busses (not just host bridge busses but all busses) in the pci code (or via MD code and hooks but I think that would be a generic thing) and do nothing in pciattach if a bus is discovered for the second time. With this MD code could use whatever methods it wants to detect otherwise undiscovered host bridges. Possible methods might be magic numbers, hints from ACPI or even a linear scan of all possible bus numbers. Does this sound like a possible solution? regardsChristian
BCM5719 support for bge(4)
i dont have this hardware, so i can only test that it hasnt broken
this chip:
bge0 at pci3 dev 4 function 0 Broadcom BCM5714 rev 0xa3, BCM5715 A3 (0x9003):
ivec 0x795, address 00:14:4f:a9:34:90
brgphy0 at bge0 phy 1: BCM5714 10/100/1000baseT/SX PHY, rev. 0
i need tests from any bge users willing to give it a spin to make
sure it hasnt broken support for previous chips, in particular i
need a BCM5717 test since this driver touches the conditionals
around that one a lot.
this is an intermediate diff on the way to BCM5720 support.
Index: if_bge.c
===
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.311
diff -u -p -r1.311 if_bge.c
--- if_bge.c4 Jul 2012 13:24:41 - 1.311
+++ if_bge.c10 Sep 2012 12:53:31 -
@@ -305,6 +305,7 @@ const struct pci_matchid bge_devices[] =
#define BGE_IS_5755_PLUS(sc) ((sc)-bge_flags BGE_5755_PLUS)
#define BGE_IS_5700_FAMILY(sc) ((sc)-bge_flags BGE_5700_FAMILY)
#define BGE_IS_5714_FAMILY(sc) ((sc)-bge_flags BGE_5714_FAMILY)
+#define BGE_IS_5717_PLUS(sc) ((sc)-bge_flags BGE_5717_PLUS)
#define BGE_IS_JUMBO_CAPABLE(sc) ((sc)-bge_flags BGE_JUMBO_CAPABLE)
static const struct bge_revision {
@@ -400,6 +401,7 @@ static const struct bge_revision bge_maj
{ BGE_ASICREV_BCM5906, unknown BCM5906 },
{ BGE_ASICREV_BCM57780, unknown BCM57780 },
{ BGE_ASICREV_BCM5717, unknown BCM5717 },
+ { BGE_ASICREV_BCM5719, unknown BCM5719 },
{ BGE_ASICREV_BCM57765, unknown BCM57765 },
{ 0, NULL }
@@ -1260,7 +1262,19 @@ bge_chipinit(struct bge_softc *sc)
if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5703 ||
BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5704)
dma_rw_ctl = ~BGE_PCIDMARWCTL_MINDMA;
-
+ if (BGE_IS_5717_PLUS(sc)) {
+ dma_rw_ctl = ~BGE_PCIDMARWCTL_DIS_CACHE_ALIGNMENT;
+ if (sc-bge_chipid == BGE_CHIPID_BCM57765_A0)
+ dma_rw_ctl = ~BGE_PCIDMARWCTL_CRDRDR_RDMA_MRRS_MSK;
+ /*
+* Enable HW workaround for controllers that misinterpret
+* a status tag update and leave interrupts permanently
+* disabled.
+*/
+ if (BGE_ASICREV(sc-bge_chipid) != BGE_ASICREV_BCM5717
+ BGE_ASICREV(sc-bge_chipid) != BGE_ASICREV_BCM57765)
+ dma_rw_ctl |= BGE_PCIDMARWCTL_TAGGED_STATUS_WA;
+}
pci_conf_write(pa-pa_pc, pa-pa_tag, BGE_PCI_DMA_RW_CTL, dma_rw_ctl);
/*
@@ -1318,7 +1332,7 @@ bge_blockinit(struct bge_softc *sc)
vaddr_t rcb_addr;
int i;
bge_hostaddrtaddr;
- u_int32_t val;
+ u_int32_t dmactl, val;
/*
* Initialize the memory window pointer register so that
@@ -1346,8 +1360,7 @@ bge_blockinit(struct bge_softc *sc)
/* Configure mbuf pool watermarks */
/* new Broadcom docs strongly recommend these: */
- if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5717 ||
- BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM57765) {
+ if (BGE_IS_5717_PLUS(sc)) {
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x2a);
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0xa0);
@@ -1372,8 +1385,16 @@ bge_blockinit(struct bge_softc *sc)
CSR_WRITE_4(sc, BGE_BMAN_DMA_DESCPOOL_HIWAT, 10);
/* Enable buffer manager */
- CSR_WRITE_4(sc, BGE_BMAN_MODE,
- BGE_BMANMODE_ENABLE|BGE_BMANMODE_LOMBUF_ATTN);
+ val = BGE_BMANMODE_ENABLE | BGE_BMANMODE_LOMBUF_ATTN;
+ /*
+* Change the arbitration algorithm of TXMBUF read request to
+* round-robin instead of priority based for BCM5719. When
+* TXFIFO is almost empty, RDMA will hold its request until
+* TXFIFO is not almost empty.
+*/
+ if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5719)
+ val |= BGE_BMANMODE_NO_TX_UNDERRUN;
+ CSR_WRITE_4(sc, BGE_BMAN_MODE, val);
/* Poll for buffer manager start indication */
for (i = 0; i 2000; i++) {
@@ -1408,8 +1429,7 @@ bge_blockinit(struct bge_softc *sc)
/* Initialize the standard RX ring control block */
rcb = sc-bge_rdata-bge_info.bge_std_rx_rcb;
BGE_HOSTADDR(rcb-bge_hostaddr, BGE_RING_DMA_ADDR(sc, bge_rx_std_ring));
- if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5717 ||
- BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM57765)
+ if (BGE_IS_5717_PLUS(sc))
rcb-bge_maxlen_flags = (BGE_RCB_MAXLEN_FLAGS(512, 0) |
(ETHER_MAX_DIX_LEN 2));
else if (BGE_IS_5705_PLUS(sc))
@@ -1417,7 +1437,11 @@ bge_blockinit(struct bge_softc *sc)
else
Re: BCM5719 support for bge(4)
On 2012/09/10 22:57, David Gwynne wrote: i dont have this hardware, so i can only test that it hasnt broken this chip: bge0 at pci3 dev 4 function 0 Broadcom BCM5714 rev 0xa3, BCM5715 A3 (0x9003): ivec 0x795, address 00:14:4f:a9:34:90 brgphy0 at bge0 phy 1: BCM5714 10/100/1000baseT/SX PHY, rev. 0 i need tests from any bge users willing to give it a spin to make sure it hasnt broken support for previous chips, in particular i need a BCM5717 test since this driver touches the conditionals around that one a lot. It looks like BCM57765 would also be a useful test for the conditionals. Doesn't look there are many BCM5717 around; not in dmesglog or http://www.nycbug.org/?action=dmesgd anyway, but there are a small number of 57765. I'll try and get it on some other bge's but it doesn't look like it should affect them.
usermod: lock/unlock local password
Hi.
This diff adds 2 new options to usermod(8):
-U to unlock a user's password
-Z to lock a user's password
In effect locking/unlocking the password means to add a '!' in front of
the encrypted entry in master.passwd.
Note that this disable the _password_ not the account of course (you
could still connect using ssh+key for e.g.).
That said, I have some use for it and would like to be able to have this
if at all possible.
Behavior is basically the same as Linux's usermod(8) except that I am
using -Z for locking the password (-Z is for SElinux in Linux land and
-L is used instead but we use it ourselves for the login class).
Comments?
Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.90
diff -u -r1.90 user.c
--- user.c 29 Jan 2012 08:38:54 - 1.90
+++ user.c 10 Sep 2012 15:00:21 -
@@ -100,7 +100,9 @@
F_UID = 0x0400,
F_USERNAME = 0x0800,
F_CLASS = 0x1000,
- F_SETSECGROUP = 0x4000
+ F_SETSECGROUP = 0x4000,
+ F_PWLOCK= 0x8000,
+ F_PWUNLOCK = 0x1
};
#define CONFFILE /etc/usermgmt.conf
@@ -1339,11 +1341,14 @@
struct group*grp;
const char *homedir;
charbuf[LINE_MAX];
+ charlocked_str[] = !;
+ charpw_len[PasswordLength + 1];
size_t colonc, loginc;
size_t cc;
FILE*master;
charnewdir[MaxFileNameLen];
char*colon;
+ char*pw_tmp;
int len;
int masterfd;
int ptmpfd;
@@ -1359,6 +1364,9 @@
if (!is_local(login_name, _PATH_MASTERPASSWD)) {
errx(EXIT_FAILURE, User `%s' must be a local user,
login_name);
}
+ if ((up-u_flags (F_PWLOCK | F_PWUNLOCK)) (pwp-pw_uid == 0)) {
+ errx(EXIT_FAILURE, (un)locking is not supported for `%s',
pwp-pw_name);
+ }
/* keep dir name in case we need it for '-m' */
homedir = pwp-pw_dir;
@@ -1410,6 +1418,29 @@
pwp-pw_passwd = up-u_password;
}
}
+ if (up-u_flags F_PWLOCK) {
+ if (strncmp(pwp-pw_passwd, locked_str,
sizeof(locked_str)-1) == 0) {
+warnx(user '%s' is already locked,
pwp-pw_name);
+ } else {
+ pw_tmp = malloc(strlen(pwp-pw_passwd) +
sizeof(locked_str));
+ if (pw_tmp == NULL) {
+ (void) close(ptmpfd);
+ pw_abort();
+ errx(EXIT_FAILURE, cannot allocate
memory);
+ }
+ strlcpy(pw_tmp, locked_str, sizeof(pw_len));
+ strlcat(pw_tmp, pwp-pw_passwd, sizeof(pw_len));
+ pwp-pw_passwd = pw_tmp;
+ free (pw_tmp);
+ }
+ }
+ if (up-u_flags F_PWUNLOCK) {
+ if (strncmp(pwp-pw_passwd, locked_str,
sizeof(locked_str)-1) != 0) {
+ warnx(user '%s' is not locked, pwp-pw_name);
+ } else {
+ pwp-pw_passwd += sizeof(locked_str)-1;
+ }
+ }
if (up-u_flags F_UID) {
/* check uid isn't already allocated */
if (!(up-u_flags F_DUPUID)
getpwuid((uid_t)(up-u_uid)) != NULL) {
@@ -1617,7 +1648,7 @@
[-p password] [-r low..high]\n
[-s shell] [-u uid] user\n, prog);
} else if (strcmp(prog, usermod) == 0) {
- (void) fprintf(stderr, usage: %s [-mov]
+ (void) fprintf(stderr, usage: %s [-UZmov]
[-c comment] [-d home-directory] [-e expiry-time]\n
[-f inactive-time]
[-G secondary-group[,group,...]]\n
@@ -1788,7 +1819,7 @@
free(u.u_primgrp);
u.u_primgrp = NULL;
have_new_user = 0;
- while ((c = getopt(argc, argv, G:L:S:c:d:e:f:g:l:mop:s:u:v)) != -1) {
+ while ((c = getopt(argc, argv, G:L:S:UZc:d:e:f:g:l:mop:s:u:v)) != -1)
{
switch(c) {
case 'G':
while ((u.u_groupv[u.u_groupc] = strsep(optarg, ,))
!= NULL
@@ -1814,6 +1845,12 @@
}
u.u_flags |= F_SETSECGROUP;
break;
+ case 'U':
+ u.u_flags |= F_PWUNLOCK;
+ break;
+ case 'Z':
+
PF: match dir ... tag tag; pass tagged { tag, tag } keep state
Hi list@,
is there any plans to expand 'tagged' keyword in PF into list?
Example of usage:
match in ... tag ABC
match in ... tag BCD
pass in on egress tagged { ABC, BCD }
If yes, is anyone already working on that? Any diff for testing?
Yes, I started to look at this, but it will take time for me to produce
something useful.
Regards,
Maxim
Re: Support power saving with athn(4) in host AP mode
On Aug 18 10:40:23, Mark Kettenis wrote: Finally got annoyed enough that my MacBook running OS X (don't ask) didn't work too well on my OpenBSD AP at home. The reason is the following caveat listed in the athn(4) man page: Host AP mode doesn't support power saving. Clients attempting to use power saving mode may experience significant packet loss (disabling power saving on the client will fix this). Same here. Unfortunately Steve doesn't allow you to disable power saving. So here is a diff to make athn(4) in host AP mode handle clients that use power saving. The Mac is much happier now. Further testing would be welcome. Even if you don't use clients with power saving enabled. So if you're running an athn(4) based AP, please give this a spin. This diff seems to be in the tree already, and in the snapshots, so I upgraded my i386 AP to current, and indeed, the connections from my macbook via wifi no longer die out. Thank you! Jan
Re: FTDI FT2232H
On Sun, Sep 9, 2012 at 8:32 PM, Aaron Bieber def...@gmail.com wrote: On Sat, Sep 08, 2012 at 04:47:45PM +0200, Raphael Graf wrote: This adds support for the FT2232H and FT4232H serial adapters. (FT2232H found on the BeagleBone). These devices have a 120MHz base clock for the baud rate generator and need a different encoding for the baud rate divisor. The values for ibufsize/obufsize are now taken from the endpoint descriptors. I can't be sure that this does not break anything. It would have to be tested on various devices. Testing this with my beaglebone. When I connect with minicom ( uc doesn't seem to output anything ), I can see linux booting ( YAY! ), but I am unable to type anything. I was doing something stupid. Both cu and minicom ( with hw flowcontrol disabled - Thanks Raphael ) are working perfectly . Regards Raphael
Re: usermod: lock/unlock local password
2012/9/10 Antoine Jacoutot ajacou...@bsdfrog.org
Hi.
This diff adds 2 new options to usermod(8):
-U to unlock a user's password
-Z to lock a user's password
In effect locking/unlocking the password means to add a '!' in front of
the encrypted entry in master.passwd.
Note that this disable the _password_ not the account of course (you
could still connect using ssh+key for e.g.).
That said, I have some use for it and would like to be able to have this
if at all possible.
Behavior is basically the same as Linux's usermod(8) except that I am
using -Z for locking the password (-Z is for SElinux in Linux land and
-L is used instead but we use it ourselves for the login class).
Comments?
noob remarks:
it doesnt lock it modify the password (unexpected behavior)
though every other login way (like keys) works.
Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.90
diff -u -r1.90 user.c
--- user.c 29 Jan 2012 08:38:54 - 1.90
+++ user.c 10 Sep 2012 15:00:21 -
@@ -100,7 +100,9 @@
F_UID = 0x0400,
F_USERNAME = 0x0800,
F_CLASS = 0x1000,
- F_SETSECGROUP = 0x4000
+ F_SETSECGROUP = 0x4000,
+ F_PWLOCK= 0x8000,
+ F_PWUNLOCK = 0x1
};
#define CONFFILE /etc/usermgmt.conf
@@ -1339,11 +1341,14 @@
struct group*grp;
const char *homedir;
charbuf[LINE_MAX];
+ charlocked_str[] = !;
+ charpw_len[PasswordLength + 1];
size_t colonc, loginc;
size_t cc;
FILE*master;
charnewdir[MaxFileNameLen];
char*colon;
+ char*pw_tmp;
int len;
int masterfd;
int ptmpfd;
@@ -1359,6 +1364,9 @@
if (!is_local(login_name, _PATH_MASTERPASSWD)) {
errx(EXIT_FAILURE, User `%s' must be a local user,
login_name);
}
+ if ((up-u_flags (F_PWLOCK | F_PWUNLOCK)) (pwp-pw_uid == 0))
{
+ errx(EXIT_FAILURE, (un)locking is not supported for
`%s', pwp-pw_name);
+ }
/* keep dir name in case we need it for '-m' */
homedir = pwp-pw_dir;
@@ -1410,6 +1418,29 @@
pwp-pw_passwd = up-u_password;
}
}
+ if (up-u_flags F_PWLOCK) {
+ if (strncmp(pwp-pw_passwd, locked_str,
sizeof(locked_str)-1) == 0) {
+warnx(user '%s' is already locked,
pwp-pw_name);
+ } else {
+ pw_tmp = malloc(strlen(pwp-pw_passwd) +
sizeof(locked_str));
+ if (pw_tmp == NULL) {
+ (void) close(ptmpfd);
+ pw_abort();
+ errx(EXIT_FAILURE, cannot
allocate memory);
+ }
+ strlcpy(pw_tmp, locked_str,
sizeof(pw_len));
+ strlcat(pw_tmp, pwp-pw_passwd,
sizeof(pw_len));
+ pwp-pw_passwd = pw_tmp;
+ free (pw_tmp);
+ }
+ }
+ if (up-u_flags F_PWUNLOCK) {
+ if (strncmp(pwp-pw_passwd, locked_str,
sizeof(locked_str)-1) != 0) {
+ warnx(user '%s' is not locked,
pwp-pw_name);
+ } else {
+ pwp-pw_passwd += sizeof(locked_str)-1;
+ }
+ }
if (up-u_flags F_UID) {
/* check uid isn't already allocated */
if (!(up-u_flags F_DUPUID)
getpwuid((uid_t)(up-u_uid)) != NULL) {
@@ -1617,7 +1648,7 @@
[-p password] [-r low..high]\n
[-s shell] [-u uid] user\n, prog);
} else if (strcmp(prog, usermod) == 0) {
- (void) fprintf(stderr, usage: %s [-mov]
+ (void) fprintf(stderr, usage: %s [-UZmov]
[-c comment] [-d home-directory] [-e expiry-time]\n
[-f inactive-time]
[-G secondary-group[,group,...]]\n
@@ -1788,7 +1819,7 @@
free(u.u_primgrp);
u.u_primgrp = NULL;
have_new_user = 0;
- while ((c = getopt(argc, argv, G:L:S:c:d:e:f:g:l:mop:s:u:v)) !=
-1) {
+ while ((c = getopt(argc, argv, G:L:S:UZc:d:e:f:g:l:mop:s:u:v))
!= -1) {
switch(c) {
case 'G':
while ((u.u_groupv[u.u_groupc] = strsep(optarg,
,)) != NULL
@@
Re: usermod: lock/unlock local password
On 09/10/12 15:24, sven falempin wrote: 2012/9/10 Antoine Jacoutot ajacou...@bsdfrog.org In effect locking/unlocking the password means to add a '!' in front of the encrypted entry in master.passwd. Note that this disable the _password_ not the account of course (you could still connect using ssh+key for e.g.). noob remarks: it doesnt lock it modify the password (unexpected behavior) though every other login way (like keys) works. And curiously, that's exactly what he said in his original email.. -- Scott McEachern https://www.blackstaff.ca
iostat: show read and write transfers per second
Hi,
the following patch adds a new flag to iostat(8) to show the read and
write transfers per second, similiar to the iostat view of systat(1).
Though I had a hard time formulating the man page bits. This is how it
looks like:
$ iostat -x -w1 wd0
wd0
KB/t rt/s wt/s MB/s
19.00 135 2021 39.99
21.84 155 978 24.18
22.57 62 346 8.99
Or for multiple disks:
$ iostat -x -w 1
wd0sd0sd1
KB/t rt/s wt/s MB/s KB/t rt/s wt/s MB/s KB/t rt/s wt/s MB/s
19.6215 0.12 32.1000 0.01 0.5000 0.00
0.0000 0.00 0.0000 0.00 0.0000 0.00
Together w/ CPU stats:
$ iostat -Cx -w 1 wd0
wd0 cpu
KB/t rt/s wt/s MB/s us ni sy in id
19.6115 0.12 7 0 4 0 89
0.0000 0.00 0 0 3 0 97
0.0000 0.00 0 0 3 0 97
Frank.
Index: iostat.c
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
retrieving revision 1.28
diff -u -r1.28 iostat.c
--- iostat.c26 Jun 2012 21:37:59 - 1.28
+++ iostat.c10 Sep 2012 20:33:27 -
@@ -94,6 +94,7 @@
#define SHOW_TTY 0x0002
#define SHOW_STATS_1 0x0004
#define SHOW_STATS_2 0x0008
+#define SHOW_STATS_3 0x0010
#define SHOW_TOTALS0x0080
static void cpustats(void);
@@ -115,7 +116,7 @@
int ch, hdrcnt;
struct timeval tv;
- while ((ch = getopt(argc, argv, Cc:dDIM:N:Tw:)) != -1)
+ while ((ch = getopt(argc, argv, Cc:dDIM:N:Tw:x)) != -1)
switch(ch) {
case 'c':
if ((reps = atoi(optarg)) = 0)
@@ -146,6 +147,9 @@
if ((interval = atoi(optarg)) = 0)
errx(1, interval = 0.);
break;
+ case 'x':
+ todo |= SHOW_STATS_3;
+ break;
case '?':
default:
usage();
@@ -153,7 +157,7 @@
argc -= optind;
argv += optind;
- if (!ISSET(todo, SHOW_CPU | SHOW_TTY | SHOW_STATS_1 | SHOW_STATS_2))
+ if (!ISSET(todo, SHOW_CPU | SHOW_TTY | SHOW_STATS_1 | SHOW_STATS_2 |
SHOW_STATS_3))
todo |= SHOW_CPU | SHOW_TTY | SHOW_STATS_1;
dkinit(0);
@@ -210,13 +214,18 @@
if (ISSET(todo, SHOW_STATS_1))
for (i = 0; i dk_ndrive; i++)
if (cur.dk_select[i])
- (void)printf( %14.14s , cur.dk_name[i]);
+ (void)printf( %16.16s , cur.dk_name[i]);
if (ISSET(todo, SHOW_STATS_2))
for (i = 0; i dk_ndrive; i++)
if (cur.dk_select[i])
(void)printf( %13.13s , cur.dk_name[i]);
+ if (ISSET(todo, SHOW_STATS_3))
+ for (i = 0; i dk_ndrive; i++)
+ if (cur.dk_select[i])
+ (void)printf( %21.21s , cur.dk_name[i]);
+
if (ISSET(todo, SHOW_CPU))
(void)printf(cpu);
printf(\n);
@@ -238,6 +247,11 @@
if (cur.dk_select[i]) {
(void)printf( KB xfr time );
}
+ if (ISSET(todo, SHOW_STATS_3))
+ for (i = 0; i dk_ndrive; i++)
+ if (cur.dk_select[i]) {
+ (void)printf( KB/t rt/s wt/s MB/s );
+ }
if (ISSET(todo, SHOW_CPU))
(void)printf( us ni sy in id);
printf(\n);
@@ -306,6 +320,43 @@
}
static void
+disk_stats3(double etime)
+{
+ int dn;
+ double atime, mbps;
+
+ for (dn = 0; dn dk_ndrive; ++dn) {
+ if (!cur.dk_select[dn])
+ continue;
+
+ /* average Kbytes per transfer. */
+ if (cur.dk_rxfer[dn] + cur.dk_wxfer[dn])
+ mbps = ((cur.dk_rbytes[dn] + cur.dk_wbytes[dn]) /
+ (1024.0)) / (cur.dk_rxfer[dn] + cur.dk_wxfer[dn]);
+ else
+ mbps = 0.0;
+
+ (void)printf( %5.2f, mbps);
+
+ /* average transfers per second. */
+ (void)printf( %4.0f, cur.dk_rxfer[dn] / etime);
+ (void)printf( %4.0f, cur.dk_wxfer[dn] / etime);
+
+ /* time busy in disk activity */
+ atime = (double)cur.dk_time[dn].tv_sec +
+ ((double)cur.dk_time[dn].tv_usec / (double)100);
+
+ /* Megabytes per second. */
+ if (atime != 0.0)
+ mbps = (cur.dk_rbytes[dn] + cur.dk_wbytes[dn]) /
+ (double)(1024 * 1024);
+ else
+ mbps = 0;
+ (void)printf( %5.2f , mbps / etime);
+ }
+}
+
+static void
cpustats(void)
{
int state;
@@ -324,7 +375,7 @@
usage(void)
{
(void)fprintf(stderr,
Re: Support power saving with athn(4) in host AP mode
It's working reasonably well here, but there's glitches with Android devices. After a while they either say the AP is 'out of range' or 'saved' with the non functional option to connect. That's with both an Androided ICS HP Touchpad and a Sony Ericcson Xperia Pro with latest official ICS. Sadly the net is not particularly forthcoming with whether this is ultimately an access point or Android issue. Windows works fine. I also had one complete wireless failure, but that could easily have been another issue/hardware, as I managed to pull out the power cable when fitting a video cable to check the console.. athn0 at pci0 dev 15 function 0 Atheros AR5416 rev 0x01: irq 3 athn0: MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5, address ... Cheers - this is much appreciated! Peter On 10 September 2012 19:21, Jan Stary h...@stare.cz wrote: On Aug 18 10:40:23, Mark Kettenis wrote: Finally got annoyed enough that my MacBook running OS X (don't ask) didn't work too well on my OpenBSD AP at home. The reason is the following caveat listed in the athn(4) man page: Host AP mode doesn't support power saving. Clients attempting to use power saving mode may experience significant packet loss (disabling power saving on the client will fix this). Same here. Unfortunately Steve doesn't allow you to disable power saving. So here is a diff to make athn(4) in host AP mode handle clients that use power saving. The Mac is much happier now. Further testing would be welcome. Even if you don't use clients with power saving enabled. So if you're running an athn(4) based AP, please give this a spin. This diff seems to be in the tree already, and in the snapshots, so I upgraded my i386 AP to current, and indeed, the connections from my macbook via wifi no longer die out. Thank you! Jan
Cómo Elaborar Folletos, Catálogo, Revistas, Boletines, =?
Cómo Elaborar Folletos, Catálogos, Revistas, Boletines, Prensa, Anuncios y Mucho Más... SEMINARIO ONLINE EN VIVO este 19 de Septiembre de 2012. ¡Aprenda las habilidades esenciales del diseño gráfico que harán que cada uno de los proyectos que diseñe sean visualmente más efectivos y poderosos! Ningún software en el mundo podrá lograr por si solo que sus documentos sean atractivos Si usted no cuenta con habilidades y destrezas sólidas de Comunicación y Diseño que le ayuden a desarrollar su sentido creativo e innovador para transmitir mensajes visuales claros y de gran impacto, cualquier boletín, folleto, revista o catálogo que realice parecerá opaco y ordinario. !No necesita experiencia para participar!, si usted no tiene conocimientos técnicos de diseño, pero redacta mensajes comerciales, prensa, folletos, boletines o cualquier anuncio publicitario, este seminario le interesa. Con este Seminario ONLINE en Vivo aprenda: Diversas maneras de captar y cautivar la atención de sus lectores Tip's que le ayudarán a crear diseños frescos y emocionantes Gráficos, Tipos de Letra, Fondos Todos estos elementos que le dan a su documento una personalidad ¡Simplifique! A menudo es difícil lograr que todo lo que usted necesita decir quede en el espacio asignado ¿Cómo utilizar el color para resaltar su mensaje? El color es tan poderoso que puede comunicar sin palabras Agregue impacto visual con las mejores fuentes de fotografías, ilustraciones y otras imágenes gráficas que transmitirán su mensaje perfectamente Evite la trampa de saturar sus documentos con demasiados elementos gráficos y efectos especiales. Adquiera la información completa y sin compromiso, solo responda este correo con asunto -Deseo Folleto o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 - y a la brevedad lo recibirá! ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado a: tech@openbsd.org
Fix for sftp(1) tab-complete
This is a diff that should fix a few issues I've encountered with sftp's
tab-complete, and a few others that I found in the process.
1) In makeargs: Lack of bounds checking for the argument pointer
table, causing a buffer overflow when entering too many arguments.
2)Improper handling of absolute paths when PWD is part of the completed
path.
ex:
sftp cd /usr/local
sftp ls /usr/loctab
expected result: /usr/local/
actual result: /usr/loc
3)Improper handling of filenames containing escaped globbing characters.
ex:
touch file*name
sftp ls file\*tab
expected result: file\*name
actual result: file\*ame
4) * and # aren't getting escaped.
ex:
sftp ls filetab
expected result: file\*name
actual result: file*name
The character # causes makeargs to ignore the rest of the argument.
So if you type rm important_file#2 you will end up with the
following arguments:
[0] rm
[1] important_file
ex:
sftp rm important_file#2
Removing /tmp/important_file
I haven't seen anywhere where this is documented. I added it to the
characters to escape but I don't know why this behaviour is there to
begin with.
Index: sftp.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.136
diff -u -r1.136 sftp.c
--- sftp.c 22 Jun 2012 14:36:33 - 1.136
+++ sftp.c 11 Sep 2012 00:48:37 -
@@ -968,6 +968,10 @@
state = MA_START;
i = j = 0;
for (;;) {
+ if (argc = sizeof(argv) / sizeof(*argv)){
+ error(Too many arguments.);
+ return NULL;
+ }
if (isspace(arg[i])) {
if (state == MA_UNQUOTED) {
/* Terminate current argument */
@@ -1671,7 +1675,7 @@
{
glob_t g;
char *tmp, *tmp2, ins[3];
- u_int i, hadglob, pwdlen, len, tmplen, filelen;
+ u_int i, hadglob, pwdlen, len, tmplen, filelen, cesc, isesc, isabs;
const LineInfo *lf;
/* Glob from file location */
@@ -1680,6 +1684,9 @@
else
xasprintf(tmp, %s*, file);
+ /* Check if the path is absolute. */
+ isabs = tmp[0] == '/';
+
memset(g, 0, sizeof(g));
if (remote != LOCAL) {
tmp = make_absolute(tmp, remote_path);
@@ -1714,7 +1721,7 @@
goto out;
tmp2 = complete_ambiguous(file, g.gl_pathv, g.gl_matchc);
- tmp = path_strip(tmp2, remote_path);
+ tmp = path_strip(tmp2, isabs ? NULL : remote_path);
xfree(tmp2);
if (tmp == NULL)
@@ -1723,8 +1730,24 @@
tmplen = strlen(tmp);
filelen = strlen(file);
- if (tmplen filelen) {
- tmp2 = tmp + filelen;
+ /*
+*Count the number of escaped characters in the
+*input string.
+*/
+ cesc = isesc = 0;
+ for(i = 0; i filelen; i++)
+ {
+ if (!isesc file[i] == '\\' i + 1 filelen){
+ isesc = 1;
+ cesc++;
+ }
+ else
+ isesc = 0;
+ }
+
+
+ if (tmplen (filelen - cesc)) {
+ tmp2 = tmp + filelen - cesc;
len = strlen(tmp2);
/* quote argument on way out */
for (i = 0; i len; i++) {
@@ -1738,6 +1761,8 @@
case '\t':
case '[':
case ' ':
+ case '#':
+ case '*':
if (quote == '\0' || tmp2[i] == quote) {
if (el_insertstr(el, ins) == -1)
fatal(el_insertstr
