Re: pledge idea
On Thu, Oct 29, 2015 at 06:39:58PM +0100, Peter J. Philipp wrote: > Hi Reyk, > > deraadt already told me there was a patch for this already. Yes it > would be more cycles for stdio I see that. > > Thanks for your effort in making me see this. > > -peter > > > $ time obj/sleep 0.01 > > 0m00.01s real 0m00.00s user 0m00.01s system > > > > Are you trying to solve an issue? Hi, I just want to revisit this because I couldn't believe it. I turned on system accounting and rebooted my test box. Here is what I found the following programs were run this many times: 23 sh 10 ntpd 9 smtpd 7 domainname 6 id 6 getty 6 getcap 6 basename I'm gonna stop here. Some of these programs were not pledged yet in my sources (-current from last week). So I did the tedious work of adding up the cycles of pledge/strcmp on sh binary and then gave the bsearch idea a guessed average of 6 rounds per lookup. What I came up with was that pledge/strcmp has 120 cycles where bsearch had 60 cycles. Multiplied by 23 times would give pledge/strcmp 2760 cycles and bsearch 1380 cycles. /bin/sh is probably always going to be the most used in any system, well it is at startup. Another comparison was for getty: pledge/strcmp 420 cycles bsearch = 216 cycles getcap had stdio and rpath which is 3 cycles, here it wins against bsearch which has 12 cycles. I do understand that most little programs such as basename have only stdio in pledge and thus will save cycles but when you average it all out by occurences there might be a case for using bsearch? I know it was just halloween but I'm still creeped out by this. -peter
pledge idea
Hi deraadt,
I know you know I don't code well, but in order to show you what's on my
mind I had to write code, I took the bsearch() from the ieee80211 code, so
perhaps there is a better way (like always) perhaps to unify the function
between these two areas.
The reason I did this is to save on cpu cycles when you look at X amount
of processes all pledging...one time'd process won't show much difference.
below's diff:
-peter
? pledge.diff
Index: kern/kern_pledge.c
===
RCS file: /cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.90
diff -u -p -u -r1.90 kern_pledge.c
--- kern/kern_pledge.c 28 Oct 2015 17:38:52 - 1.90
+++ kern/kern_pledge.c 29 Oct 2015 16:23:04 -
@@ -58,6 +58,32 @@
int canonpath(const char *input, char *buf, size_t bufsize);
int substrcmp(const char *p1, size_t s1, const char *p2, size_t s2);
+int pledge_cmp(const void *pi, const void *ph);
+
+/* taken from net80211/ieee80211_regdomain.c */
+const void *pledge_bsearch(const void *, const void *, size_t, size_t,
+int (*)(const void *, const void *));
+
+const void *
+pledge_bsearch(const void *key, const void *base0, size_t nmemb, size_t size,
+int (*compar)(const void *, const void *))
+{
+const char *base = base0;
+int lim, cmp;
+const void *p;
+
+for (lim = nmemb; lim != 0; lim >>= 1) {
+p = base + (lim >> 1) * size;
+cmp = (*compar)(key, p);
+if (cmp == 0)
+return ((const void *)p);
+if (cmp > 0) { /* key > p: move right */
+base = (const char *)p + size;
+lim--;
+} /* else move left */
+}
+return (NULL);
+}
const u_int pledge_syscalls[SYS_MAXSYSCALL] = {
[SYS_exit] = 0x,
@@ -256,40 +282,42 @@ const u_int pledge_syscalls[SYS_MAXSYSCA
[SYS_swapctl] = PLEDGE_VMINFO, /* XXX should limit to "get" operations
*/
};
-static const struct {
+/* MUST be sorted! */
+static const struct PR {
char *name;
int flags;
} pledgereq[] = {
- { "stdio", PLEDGE_STDIO },
- { "rpath", PLEDGE_RPATH },
- { "wpath", PLEDGE_WPATH },
- { "tmppath",PLEDGE_TMPPATH },
- { "inet", PLEDGE_INET },
- { "unix", PLEDGE_UNIX },
+ { "abort", 0 },/* XXX reserve for later */
+ { "cpath", PLEDGE_CPATH },
{ "dns",PLEDGE_DNS },
+ { "exec", PLEDGE_EXEC },
+ { "fattr", PLEDGE_FATTR },
+ { "flock", PLEDGE_FLOCK },
{ "getpw", PLEDGE_GETPW },
- { "sendfd", PLEDGE_SENDFD },
- { "recvfd", PLEDGE_RECVFD },
- { "ioctl", PLEDGE_IOCTL },
{ "id", PLEDGE_ID },
- { "route", PLEDGE_ROUTE },
+ { "inet", PLEDGE_INET },
+ { "ioctl", PLEDGE_IOCTL },
{ "mcast", PLEDGE_MCAST },
- { "tty",PLEDGE_TTY },
{ "proc", PLEDGE_PROC },
- { "exec", PLEDGE_EXEC },
- { "cpath", PLEDGE_CPATH },
- { "fattr", PLEDGE_FATTR },
{ "prot_exec", PLEDGE_PROTEXEC },
- { "flock", PLEDGE_FLOCK },
{ "ps", PLEDGE_PS },
- { "vminfo", PLEDGE_VMINFO },
+ { "recvfd", PLEDGE_RECVFD },
+ { "route", PLEDGE_ROUTE },
+ { "rpath", PLEDGE_RPATH },
+ { "sendfd", PLEDGE_SENDFD },
{ "settime",PLEDGE_SETTIME },
- { "abort", 0 },/* XXX reserve for later */
+ { "stdio", PLEDGE_STDIO },
+ { "tmppath",PLEDGE_TMPPATH },
+ { "tty",PLEDGE_TTY },
+ { "unix", PLEDGE_UNIX },
+ { "vminfo", PLEDGE_VMINFO },
+ { "wpath", PLEDGE_WPATH },
};
int
sys_pledge(struct proc *p, void *v, register_t *retval)
{
+ struct PR *pr = NULL;
struct sys_pledge_args /* {
syscallarg(const char *)request;
syscallarg(const char **)paths;
@@ -300,7 +328,7 @@ sys_pledge(struct proc *p, void *v, regi
if (SCARG(uap, request)) {
size_t rbuflen;
char *rbuf, *rp, *pn;
- int f, i;
+ int f;
rbuf = malloc(MAXPATHLEN, M_TEMP, M_WAITOK);
error = copyinstr(SCARG(uap, request), rbuf, MAXPATHLEN,
@@ -321,16 +349,15 @@ sys_pledge(struct proc *p, void *v, regi
*pn++ = '\0';
}
- for (f = i = 0; i <
Re: pledge idea
On 10/29/15 18:51, Reyk Floeter wrote:
> On Thu, Oct 29, 2015 at 04:32:25PM +, Peter J. Philipp wrote:
>> Hi deraadt,
>>
>> I know you know I don't code well, but in order to show you what's on my
>> mind I had to write code, I took the bsearch() from the ieee80211 code, so
>> perhaps there is a better way (like always) perhaps to unify the function
>> between these two areas.
>>
>> The reason I did this is to save on cpu cycles when you look at X amount
>> of processes all pledging...one time'd process won't show much difference.
>>
> I'm not deraadt, but -
>
> smart but have you considered that this is not worth the effort?
> pledge() is only called once or twice during a process' lifetime -
> start, pledge, run - the linear search on such a short list is still
> relatively fast, and the entries are even sorted in the order of
> relevance. By convention "stdio" always comes first. So what is the
> impact without your diff of pledge in src/bin/sleep/sleep.c:
>
> if (pledge("stdio", NULL) == -1)
> err(1, "pledge");
Hi Reyk,
deraadt already told me there was a patch for this already. Yes it
would be more cycles for stdio I see that.
Thanks for your effort in making me see this.
-peter
> $ time obj/sleep 0.01
> 0m00.01s real 0m00.00s user 0m00.01s system
>
> Are you trying to solve an issue?
>
> Reyk
>
>> below's diff:
>>
>> -peter
>>
>>
>> ? pledge.diff
>> Index: kern/kern_pledge.c
>> ===
>> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
>> retrieving revision 1.90
>> diff -u -p -u -r1.90 kern_pledge.c
>> --- kern/kern_pledge.c 28 Oct 2015 17:38:52 - 1.90
>> +++ kern/kern_pledge.c 29 Oct 2015 16:23:04 -
>> @@ -58,6 +58,32 @@
>>
>> int canonpath(const char *input, char *buf, size_t bufsize);
>> int substrcmp(const char *p1, size_t s1, const char *p2, size_t s2);
>> +int pledge_cmp(const void *pi, const void *ph);
>> +
>> +/* taken from net80211/ieee80211_regdomain.c */
>> +const void *pledge_bsearch(const void *, const void *, size_t, size_t,
>> +int (*)(const void *, const void *));
>> +
>> +const void *
>> +pledge_bsearch(const void *key, const void *base0, size_t nmemb, size_t
>> size,
>> +int (*compar)(const void *, const void *))
>> +{
>> +const char *base = base0;
>> +int lim, cmp;
>> +const void *p;
>> +
>> +for (lim = nmemb; lim != 0; lim >>= 1) {
>> +p = base + (lim >> 1) * size;
>> +cmp = (*compar)(key, p);
>> +if (cmp == 0)
>> +return ((const void *)p);
>> +if (cmp > 0) { /* key > p: move right */
>> +base = (const char *)p + size;
>> +lim--;
>> +} /* else move left */
>> +}
>> +return (NULL);
>> +}
>>
>> const u_int pledge_syscalls[SYS_MAXSYSCALL] = {
>> [SYS_exit] = 0x,
>> @@ -256,40 +282,42 @@ const u_int pledge_syscalls[SYS_MAXSYSCA
>> [SYS_swapctl] = PLEDGE_VMINFO, /* XXX should limit to "get" operations
>> */
>> };
>>
>> -static const struct {
>> +/* MUST be sorted! */
>> +static const struct PR {
>> char *name;
>> int flags;
>> } pledgereq[] = {
>> -{ "stdio", PLEDGE_STDIO },
>> -{ "rpath", PLEDGE_RPATH },
>> -{ "wpath", PLEDGE_WPATH },
>> -{ "tmppath",PLEDGE_TMPPATH },
>> -{ "inet", PLEDGE_INET },
>> -{ "unix", PLEDGE_UNIX },
>> +{ "abort", 0 },/* XXX reserve for later */
>> +{ "cpath", PLEDGE_CPATH },
>> { "dns",PLEDGE_DNS },
>> +{ "exec", PLEDGE_EXEC },
>> +{ "fattr", PLEDGE_FATTR },
>> +{ "flock", PLEDGE_FLOCK },
>> { "getpw", PLEDGE_GETPW },
>> -{ "sendfd", PLEDGE_SENDFD },
>> -{ "recvfd", PLEDGE_RECVFD },
>> -{ "ioctl", PLEDGE_IOCTL },
>> { "id", PLEDGE_ID },
>> -{ "route", PLEDGE_ROUTE },
&
Re: autoinstall(8): using multiple set sources?
Am 08.08.2015 01:26 schrieb Alexander Hall: Try adding Set name(s) = done Here, like you would manually do (albeit likely implicit by just pressing enter). Bit counterintuitive at first, but works! Thanks a bunch.
autoinstall(8): using multiple set sources?
While heavy playing with autoinstall(8), I came across that I cannot make it happen to install the usual sets from CD/ISO and additional ones like site58.tgz from a webserver. install.conf snips: root disk = wd0 Use (W)hole disk = W Location of sets = cd Set name(s) = all Location of sets = http HTTP Server = 192.168.2.101 Server directory = / Set = all site58.tgz = yes The problem is the way the answers are popped; if I ctrl-c the installer after the first set selection, both 'Set' and 'Set name(s)' are already removed from /ai.conf. The site58.tgz will be shown as available, but wont be selected. Actually one will see that 'all' is being used twice on the first selection - and that comes from: select_sets() for resp in $resp; do Cannot provide a diff to deal with it.. only idea I had so far is including the install-method into the 'ask' for sets.
an XOR improvement of 1%
Hi,
I have made a patch against 5.7 that improves the speed of xor for amd64
by 1% (timed on a seperate userland program). I tested the userland
program against an i386 and a amd64 host, didn't have access to any other
architectures.
If a hardcore developer thinks this is worth it ... feel free to include
something similar to my patch. The modes this affects is the CTR and the
XTS AES modes, the latter being tested by me on my amd64 host with a encrypted
sparse file:
sd1 at scsibus3 targ 1 lun 0: OPENBSD, SR CRYPTO, 005 SCSI2 0/direct fixed
sd1: 1023MB, 512 bytes/sector, 2096561 sectors
It worked so the function must be working. I have attached my patch for
review inline. It goes against /sys/crypto/xform.c
-peter
--- xform.c.origMon Jun 8 09:29:27 2015
+++ xform.c Mon Jun 8 09:34:14 2015
@@ -106,6 +106,8 @@
u_int32_t deflate_decompress(u_int8_t *, u_int32_t, u_int8_t **);
u_int32_t lzs_dummy(u_int8_t *, u_int32_t, u_int8_t **);
+void xorfunc(u_int8_t *, u_int8_t *, int);
+
#define AESCTR_NONCESIZE 4
#define AESCTR_IVSIZE 8
#define AESCTR_BLOCKSIZE 16
@@ -499,8 +501,11 @@
if (++ctx-ac_block[i]) /* continue on overflow */
break;
rijndaelEncrypt(ctx-ac_ek, ctx-ac_nr, ctx-ac_block, keystream);
+#if 0
for (i = 0; i AESCTR_BLOCKSIZE; i++)
data[i] ^= keystream[i];
+#endif
+ xorfunc(data, keystream, AESCTR_BLOCKSIZE);
explicit_bzero(keystream, sizeof(keystream));
}
@@ -557,8 +562,11 @@
else
rijndael_decrypt(ctx-key1, block, data);
+#if 0
for (i = 0; i AES_XTS_BLOCKSIZE; i++)
data[i] ^= ctx-tweak[i];
+#endif
+ xorfunc(data, ctx-tweak, AES_XTS_BLOCKSIZE);
/* Exponentiate tweak */
carry_in = 0;
@@ -676,4 +684,27 @@
{
*out = NULL;
return (0);
+}
+
+void
+xorfunc(u_int8_t *output, u_int8_t *input, int len)
+{
+int i;
+#if __amd64__
+u_int8_t *i0, *i1, *i2, *i3;
+u_int8_t *o0, *o1, *o2, *o3;
+
+for (i = 0; i len; i += 4) {
+i0 = (u_int8_t *)input[0 + i]; i1=(u_int8_t *)input[1 + i];
+i2 = (u_int8_t *)input[2 + i]; i3=(u_int8_t *)input[3 + i];
+o0 = (u_int8_t *)output[0 + i]; o1=(u_int8_t *)output[1 + i];
+o2 = (u_int8_t *)output[2 + i]; o3=(u_int8_t *)output[3 + i];
+
+*o0 ^= *i0; *o1 ^= *i1; *o2 ^= *i2; *o3 ^= *i3;
+}
+#else
+for (i = 0; i len; i++) {
+output[i] ^= input[i];
+}
+#endif
}
Re: autoinstall(8) tweaks
Am 15.04.2015 01:20 schrieb Ryan McBride: On other systems where I don't know how the data will grow, I typically configure them with something close to the auto layout, but a smaller /home, and leave the remaining disk empty. When I get a feel for what the data usage is in /var/daemon or /home or /usr/local, I can expand /home or create a new partition and migrate the data. Wouldnt that be just the point? Keep the auto-layout in big mode as it is but do not assign all remains to /home but only x/% GB and leave the remains of the disk unallocated. + default secure splitted mountpoints untouched + no need to fuzz with the installer + less burden on post install by shrinking/redoing /home to gather space for /var/foobar or whatever + speeds the install-time on large disks ;-) - new heuristics for xGB /home needed 2ct or less.
Re: autoinstall(8) tweaks
Am 07.04.2015 16:55 schrieb Kirill Bychkov:
disklabel = D\na b\n\n4g\n\na a\n\n\n\n/\np\nq\n
Oh, please yes. I know that this will be PITA around (non)escaping and
all,
but the default labelling just isnt cutting it.
+ _mode=$(sed -E '/^ *filename
(.*\/)?auto_(install|upgrade);$/!d;s//\2/;q' $_lf)
+ _path=$(sed -E '/^ *filename (.*\/)[^/]+;$/!d;s//\1/;q' $_lf)
hostname based auto_{install,upgrade}.conf would be just too handy
(tweaking into that via
madness symlinking already).
Sorry for hijacking that answer, deleted the previous mail just to
early.
--pb
Re: use mallocarray in kern
Sorry to break the threading, but I already expunged the original message.. Re: http://marc.info/?l=openbsd-techm=140529530814733w=2 The second and third hunk should use mallocarray() instead of malloc() in my eyes. sizeof(Elf_Phdr) as type just doesnt make sense to me. Hope not everyone is on the plane right now. --double-p
Re: iked + isakmpd on the same machine
Am 22.04.2014 17:28 schrieb Mike Belopuhov: more like it's not supported and is not supposed to work. not supposed as in 'not wanted'? it's like running nginx and apache at the same time but Quite frankly: I'm doing that in some locations ;-) worse since there are kernel tentacles involved as well (as you might have figured out already) that will likely That's somehow the main problem, the two daemons are not trying to share the pfkey2 ioctls outcome. So, I can wait til iked supports ikev1, too. Using a different machine will be quite painful at the moment. Rock+hard place. prevent you from doing that on the same box but different ip addresses. Nevertheless I'd say that a Listen-on style directive for iked would a useful thing[tm], e.g. to default the srcid to that. Cheers.
iked + isakmpd on the same machine
It happened! A remote peer *requires* IKEv2 - and I've to do that on a machine running isakmpd with somewhat 25+ IKEv1 peers. First hurdle: I cannot bind iked to a certain (carp) IP-address. Mad workaround: start isakmpd (with Listen-on) first. Second hurdle: iked loads its SAs and eventually does this by creating a new empty SADB, effectivly killing all the SAs isakmpd loaded into the kernel before? Is there a diff sleeping out there for tackling the first hurdle? For the second one, I've to refrain from testing this in live further more. First to reconstruct my Frankenstein-Lab. Cheers for any thoughts beside mad, bro? :-)
Re: 5.5 and dual-boot
Le 07/03/2014 12:02 PM, Bob Beck a écrit : actually more painful than having to boot windows is to always have something handy to boot the snap from in order to dd the bootblock off in case you forget to do it before rebooting, or you're fucked. Hi Bob, Yeah and hopefully, with a recent post on undeadly, I managed to have an USB install media. More easy than going all around the company hunting for an external USB drive. :) Regards. Jean-Philippe -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. For all your IT requirements visit: http://www.transtec.co.uk
Re: 5.5 and dual-boot
Le 07/03/2014 12:13 PM, Theo de Raadt a écrit : actually more painful than having to boot windows is to always have something handy to boot the snap from in order to dd the bootblock off in case you forget to do it before rebooting, or you're fucked. The new installboot was enabled around a month ago. The issue is only being talked about now. Apparently... this dual-boot issue is only seen now, indicating that these people don't upgrade very often, or participate in the test cycles leading up to release. Hi Theo, In fact I sent an email on bugs@ on 04/02/2014 (subject was installboot and ERR M). First, it was suspected a problem because of using an old bsd.rd instead of the one provided with the snapshot. This is after some tests in the next weeks that I found the culprit (openbsd.pbr). Moreover as boot(8) continued to be changed, I wanted to be sure before posting. Regards. Jean-Philippe. -- Ce message a été vérifié par MailScanner pour des virus ou des polluriels et rien de suspect n'a été trouvé. For all your IT requirements visit: http://www.transtec.co.uk
Re: Routing issues
Am 17.02.2014 09:22 schrieb Alex Mathiasen: Thank you! This solved my problem. Cheers.. found the hard way the other day. There should really be some dmesg when state-tables overflow. This silent dropping is wasting time in debugging such situations. Sorry for talk instead of diff :-}
Re: Routing issues
Am 17.02.2014 12:22 schrieb Stuart Henderson: Writing messages that show up in dmesg is not cheap, particularly on systems with serial console. Well, ok. How about pflog?
Re: Routing issues
Am 17.02.2014 13:11 schrieb Henning Brauer: how do you emit such a maessage in pcap? as payload with a dummy packet header? (N!!) pf is taking action without telling anyone - and that's not nice. There *are* other log() entries in pf.c already so I wonder how the initial comment about 'slow via serial console' would qualify. some blocked because of resource exhaustion reason for pflog_packet? Just sayin...
Re: Request for Funding our Electricity
Am 17.01.2014 22:14 schrieb Kevin Lyda: That's a bug to be filed against an emulator. And it's easier to do that *now* when the older hardware is around to test for bug compatibility. And how do you do that when the hardware has gone? And I must admit the resistance to this is weird. This all ends in places like NetBSD where cross-compiling is good enough. Just to find out that a native build didnt work any longer. Stop dreaming in emulators.
Re: Request for Funding our Electricity
On 01/14/14 21:56, Theo de Raadt wrote: Hi, Anyone want to suggest we hold a bake sale? I just donated a little bit. Looking for roughly 10 dozen like minded people. I'm not suggesting a bake sale but one thing I noticed with the freebsdfoundation.org's website, that I think works out good, is that they have a donation meter on how much was put in the hat. I think something like this would benefit OpenBSD too. Just there would need to be someone able to make such a meter on a website. Also showing how much came from private donations vs. corporate donations would be interesting to see. Cheers, -peter
-DDEBUG misses DUMP_REGS on amd64 libsa
Hi,
from: sys/arch/amd64/stand/libsa/cmd_i386.c:
#ifdef DEBUG
int
Xregs(void)
{
DUMP_REGS;
return 0;
}
#endif
which is undeclared.
i386 has one in sys/arch/i386/stand/libsa/debug_md.h
--pb
urtwn(4) patch
Hi,
I previously sent out a patch for this device support here:
Linkname: 'USB Wireless Micro Adapter IWL 4000 support' - MARC
URL: http://marc.info/?l=openbsd-techm=135342591418924w=2
Now I've looked at the usbdevs file a little closer and finally replaced
my PJPUK device with something a little more proper, here is patch:
Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 if_urtwn.c
--- if_urtwn.c 15 Apr 2013 09:23:01 - 1.25
+++ if_urtwn.c 11 May 2013 21:36:59 -
@@ -83,6 +83,7 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CE_2 },
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_F7D2102 },
+ { USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU_4 },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU },
{ USB_VENDOR_CHICONY, USB_PRODUCT_CHICONY_RTL8188CUS_1 },
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.598
diff -u -p -u -r1.598 usbdevs
--- usbdevs 7 Mar 2013 23:39:14 - 1.598
+++ usbdevs 11 May 2013 21:39:19 -
@@ -1120,6 +1120,7 @@ product BELKIN RTL8188CU 0x1102 RTL8188C
product BELKIN F5U120 0x1203 F5U120-PC Hub
product BELKIN RTL8192CU 0x2102 RTL8192CU
product BELKIN F7D2102 0x2103 F7D2102
+product BELKIN RTL8192CU_4 0x21f2 RTL8192CU
product BELKIN ZD1211B 0x4050 ZD1211B
product BELKIN F5D5055 0x5055 F5D5055
product BELKIN F5D7050 0x7050 F5D7050 54g USB Network Adapter
The particular device doesn't always attach right, as you can see from this
grep from my kernel dmesg:
urtwn0 at uhub0 port 2 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 2 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 2 Belkin Components PJPUK rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 2 Belkin Components RTL8192CU rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
urtwn0 at uhub0 port 2 Belkin Components RTL8192CU rev 2.00/2.00 addr 2
urtwn0: could not set configuration no
urtwn0 detached
urtwn0 at uhub0 port 1 Realtek Belkin Wireless Adapter rev 2.00/2.00 addr 2
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c
it sometimes (1 in 3 attempts) bails with could not set configuration no
I looked at it a little closer and think it's probably in the usb device
driver code that it determines this.
-peter
Re: write(2) man page
reflum, On Sun, 2013-02-24 at 09:12 +0530, Sachidananda wrote: Also, for the record, it's open that seeks to the end. You can open a file with O_APPEND and seek back to the beginning, and write will not seek to the end again. My observation is, if I open(2) the file with O_APPEND it seeks to the end. And I lseek back to the beginning and write(2) to it, write does seek back to the end and write the data at the end. From POSIX: If the O_APPEND flag of the file status flags is set, the file offset shall be set to the end of the file prior to each write and no intervening file modification operation shall occur between changing the file offset and the write operation. (http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html) As of my understanding this is to allow race condition free appending to files such as log files so no data is lost. because of the fact that write can return a 'short write' data may be interleaved somehow but no data is lost. (Example of such a case: two processes/threads using the same logfile to log errors. something happens and both write down an error message at the same time. O_APPEND ensures no data is lost here.) Hope that helped! :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
USB Wireless Micro Adapter IWL 4000 support
First off I'd like to say that today luck was with me. Big time. I went to
a local store (saturn.de) to buy a wireless usb adapter and picked one out
that I thought was supported. I did not take my netbook with me so I didn't
know if it would work or not. So when I got home it was detected as ugen0...
damn. So then I compared the USB Vendor in a list and made an educated guess
that this is a urtwn(4) device and hacked the support into the kernel and
rebooted. Then I prayed and it did configure and attach! success then I
did a ifconfig urtwn scan and it worked, success and then I read the manpage
on how to configure wireless as I've never done it on OpenBSD since 2002.
Anyhow the driver specification needs a better name I called it PJPUK for
my initials and unknown. But I can give you information about the box what
I bought: This is a ISY (simply connected) USB Wireless Micro Adapter,
IWL 4000 and claimed to be a (N300 standard). Thank you Damien Bergamini
for this driver!
Here is some relevant information:
ifconfig urtwn0
urtwn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr ec:1a:59:0d:fa:1c
priority: 4
groups: wlan egress
media: IEEE802.11 autoselect (OFDM54 mode 11g)
status: active
ieee80211: nwid AREA27 chan 11 bssid 24:65:11:68:a1:43 196dB wpakey
CENSORED wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher
tkip
inet6 fe80::ee1a:59ff:fe0d:fa1c%urtwn0 prefixlen 64 scopeid 0x4
inet 192.168.178.36 netmask 0xff00 broadcast 192.168.178.255
usbdevs -v
Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), ATI(0x1002),
rev 1.00
port 1 addr 2: high speed, power 500 mA, config 1, Belkin Wireless
Adapter(0x21f2), Realtek(0x050d), rev 2.00, iSerialNumber 00e04c01
port 2 powered
port 3 powered
port 4 powered
port 5 powered
Controller /dev/usb1:
...
The diff against a -current snapshot from last week:
Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.23
diff -u -r1.23 if_urtwn.c
--- if_urtwn.c 17 Sep 2012 15:14:14 - 1.23
+++ if_urtwn.c 20 Nov 2012 15:11:56 -
@@ -83,6 +83,7 @@
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CE_2 },
{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_F7D2102 },
+ { USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_PJPUK },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU },
{ USB_VENDOR_CHICONY, USB_PRODUCT_CHICONY_RTL8188CUS_1 },
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.591
diff -u -r1.591 usbdevs
--- usbdevs 14 Nov 2012 16:53:49 - 1.591
+++ usbdevs 20 Nov 2012 15:11:59 -
@@ -1118,6 +1118,7 @@
product BELKIN F5U120 0x1203 F5U120-PC Hub
product BELKIN RTL8192CU 0x2102 RTL8192CU
product BELKIN F7D2102 0x2103 F7D2102
+product BELKIN PJPUK 0x21f2 PJPUK
product BELKIN ZD1211B 0x4050 ZD1211B
product BELKIN F5D5055 0x5055 F5D5055
product BELKIN F5D7050 0x7050 F5D7050 54g USB Network Adapter
and last but not least a dmesg:
OpenBSD 5.2-current (SATURN) #1: Tue Nov 20 15:57:38 CET 2012
p...@saturn.centroid.eu:/usr/src/sys/arch/amd64/compile/SATURN
RTC BIOS diagnostic error 80clock_battery
real mem = 4003721216 (3818MB)
avail mem = 3874660352 (3695MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe3e70 (51 entries)
bios0: vendor Acer version V1.08 date 12/06/2011
bios0: Acer AO722
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG BOOT SLIC SSDT SSDT
acpi0: wakeup devices SPB2(S4) GEC_(S4) USB0(S3) USB4(S3) P2P_(S5)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD C-60 APU with Radeon(tm) HD Graphics, 998.31 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD C-60 APU with Radeon(tm) HD Graphics, 997.51 MHz
cpu1:
Re: USB Wireless Micro Adapter IWL 4000 support
On Tue, Nov 20, 2012 at 04:33:27PM +0100, Peter J. Philipp wrote: urtwn0 at uhub0 port 1 Realtek Belkin Wireless Adapter rev 2.00/2.00 addr 2 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c Hrmm, sometimes it does not detect right. I had to cold boot my netbook last for it to detect, the dmesg has also changed: urtwn0 at uhub0 port 1 Belkin Components PJPUK rev 2.00/2.00 addr 2 urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R, address ec:1a:59:0d:fa:1c For the fact that it works is amazing to me. However not perfectly, and that skillset is beyond me, but I thought I'd let you know. -peter
tftpd patch
Hi, I have the weird scenario when I try to tftp a file from a remote tftpd that's also openbsd that my pf doesn't keep a state open. This is something I need to fix, however I found this in the logs on the remote tftpd and it's misleading: Jun 28 14:03:21 hostname tftpd[2506]: recv: Connection refused It first boggled my mind what it's trying to recv and then it came to me... the write error message is delayed because of the ICMP port unreachable travel time at which point the descriptor is already blocking in read I guess. So I have changed it to this: Jun 28 14:03:21 hostname tftpd[2506]: sendfile: Connection refused which to me is a lot more explanatory on what it fails on. sendfile is the function not the syscall. I'd rather see send in there than recv. Here is the patch: Index: tftpd.c === RCS file: /cvs/src/libexec/tftpd/tftpd.c,v retrieving revision 1.63 diff -u -r1.63 tftpd.c --- tftpd.c 27 Oct 2009 23:59:32 - 1.63 +++ tftpd.c 28 Jun 2012 18:00:29 - @@ -669,7 +669,10 @@ error = 1; if (errno == EINTR) continue; - syslog(LOG_ERR, recv: %m); + if (errno == ECONNREFUSED) + syslog(LOG_ERR, sendfile: %m); + else + syslog(LOG_ERR, recv: %m); goto abort; } ap-th_opcode = ntohs((u_short)ap-th_opcode); If you think kittens will die because of this patch then don't commit it but otherwise I'm just trying to make sense of this better. Cheers, -peter
Re: ip6(4) manpage update
On Mon, Jun 18, 2012 at 08:06:06AM +0100, Jason McIntyre wrote: the blank line above should be a .Pp. also this diff adds trailing whitespace at eol in a few places. please remove it. except for that, i'm fine with this diff, if some developer wants to take it. jmc Awesome! Well here is my attempt three then. Index: ip6.4 === RCS file: /cvs/src/share/man/man4/ip6.4,v retrieving revision 1.25 diff -u -r1.25 ip6.4 --- ip6.4 8 Sep 2011 16:43:56 - 1.25 +++ ip6.4 18 Jun 2012 08:06:35 - @@ -237,7 +237,7 @@ .It Dv IPV6_PORTRANGE_LOW Use a low, reserved range (600\-1023). .El -.It Dv IPV6_PKTINFO Fa int * +.It Dv IPV6_RECVPKTINFO Fa int * Get or set whether additional information about subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -250,7 +250,10 @@ unsigned intipi6_ifindex; /* send/recv if index */ }; .Ed -.It Dv IPV6_HOPLIMIT Fa int * +.Pp +Turning this option on will result in this socket getting cmsg data of +type IPV6_PKTINFO. +.It Dv IPV6_RECVHOPLIMIT Fa int * Get or set whether the hop limit header field from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -258,6 +261,8 @@ The value is stored as an .Vt int in the ancillary data returned. +Turning this option on will result in this socket getting cmsg data of +type IPV6_HOPLIMIT. .\ .It Dv IPV6_NEXTHOP Fa int * .\ Get or set whether the address of the next hop for subsequent .\ packets will be provided as ancillary data along with the payload in @@ -269,7 +274,7 @@ .\ structure in the ancillary data returned. .\ .Pp .\ This option requires superuser privileges. -.It Dv IPV6_HOPOPTS Fa int * +.It Dv IPV6_RECVHOPOPTS Fa int * Get or set whether the hop-by-hop options from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -289,7 +294,9 @@ routine and family of routines may be used to manipulate this data. .Pp This option requires superuser privileges. -.It Dv IPV6_DSTOPTS Fa int * +Turning this option on will result in this socket getting cmsg data of +type IPV6_HOPOPTS. +.It Dv IPV6_RECVDSTOPTS Fa int * Get or set whether the destination options from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -309,6 +316,8 @@ routine and family of routines may be used to manipulate this data. .Pp This option requires superuser privileges. +Turning this option on will result in this socket getting cmsg data of +type IPV6_DSTOPTS. .It Dv IPV6_TCLASS Fa int * Get or set the value of the traffic class field used for outgoing datagrams on this socket. @@ -321,7 +330,7 @@ calls. The header field is stored as a single value of type .Vt int . -.It Dv IPV6_RTHDR Fa int * +.It Dv IPV6_RECVRTHDR Fa int * Get or set whether the routing header from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -343,6 +352,8 @@ routine and family of routines may be used to manipulate this data. .Pp This option requires superuser privileges. +Turning this option on will result in this socket getting cmsg data of +type IPV6_RTHDR. .It Dv IPV6_PKTOPTIONS Fa struct cmsghdr * Get or set all header options and extension headers at one time on the last packet sent or received on the socket. @@ -413,11 +424,11 @@ .El .Pp The -.Dv IPV6_PKTINFO , -.\ .Dv IPV6_NEXTHOP , -.Dv IPV6_HOPLIMIT , -.Dv IPV6_HOPOPTS , -.Dv IPV6_DSTOPTS , +.Dv IPV6_RECVPKTINFO , +.\ .Dv IPV6_RECVNEXTHOP , +.Dv IPV6_RECVHOPLIMIT , +.Dv IPV6_RECVHOPOPTS , +.Dv IPV6_RECVDSTOPTS , and .Dv IPV6_RTHDR options will return ancillary data along with payload contents in subsequent @@ -429,7 +440,7 @@ and .Va cmsg_type set to respective option name value (e.g., -.Dv IPV6_HOPTLIMIT ) . +.Dv IPV6_HOPLIMIT ) . These options may also be used directly as ancillary .Va cmsg_type values in @@ -455,7 +466,7 @@ can be set by the .Dv IPV6_MULTICAST_IF socket option, through the -.Dv IPV6_PKTINFO +.Dv IPV6_RECVPKTINFO option, and through the .Va sin6_scope_id field of the socket address passed to the @@ -590,7 +601,7 @@ * returned along with the payload. */ optval = 1; -if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, optval, +if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, optval, sizeof(optval)) == -1) err(1, setsockopt); @@ -685,6 +696,15 @@ .%A B. Fenner .%A A. Rudoff .%T UNIX Network Programming, third edition +.Re +.Rs +.%A W. Stevens +.%A M. Thomas +.%A E. Nordmark +.%A T. Jinmei +.%T Advanced Sockets Application Program Interface (API) for IPv6 +.%R RFC 3542 +.%D May 2003 .Re .Sh STANDARDS Most of the socket options are defined in RFC 2292 or RFC 2553.
Re: ip6(4) manpage update
On Sat, Jun 16, 2012 at 07:17:16PM -0700, Philip Guenther wrote: You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS, IPV6_DSTOPTS, and IPV6_RTHDR. The RECV part was added to them in RFC3542. Yep. In addition, the text should be clarified to indicate that turning on IPV6_RECV* will result in the process getting cmsg data of type IPV6_*. E.g., IPV6_RECVHOPLIMIT turns on receiving of IPV6_HOPLIMIT cmsg data. Peter, do you want to take a stab at that part too? (There's also a typo in the current page: s/HOPTLIMIT/HOPLIMIT/) Philip Guenther Sure I'll take a stab at it but its very difficult I found (I was also distracted by freeing a bird from the attic). Here goes: -peter Index: ip6.4 === RCS file: /cvs/src/share/man/man4/ip6.4,v retrieving revision 1.25 diff -u -r1.25 ip6.4 --- ip6.4 8 Sep 2011 16:43:56 - 1.25 +++ ip6.4 17 Jun 2012 10:45:19 - @@ -237,7 +237,7 @@ .It Dv IPV6_PORTRANGE_LOW Use a low, reserved range (600\-1023). .El -.It Dv IPV6_PKTINFO Fa int * +.It Dv IPV6_RECVPKTINFO Fa int * Get or set whether additional information about subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -250,14 +250,19 @@ unsigned intipi6_ifindex; /* send/recv if index */ }; .Ed -.It Dv IPV6_HOPLIMIT Fa int * + +Turning this option on will result in this process getting cmsg data of +type IPV6_PKTINFO. +.It Dv IPV6_RECVHOPLIMIT Fa int * Get or set whether the hop limit header field from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 -calls. +calls. The value is stored as an .Vt int in the ancillary data returned. +Turning this option on will result in this process getting cmsg data of +type IPV6_HOPLIMIT. .\ .It Dv IPV6_NEXTHOP Fa int * .\ Get or set whether the address of the next hop for subsequent .\ packets will be provided as ancillary data along with the payload in @@ -269,7 +274,7 @@ .\ structure in the ancillary data returned. .\ .Pp .\ This option requires superuser privileges. -.It Dv IPV6_HOPOPTS Fa int * +.It Dv IPV6_RECVHOPOPTS Fa int * Get or set whether the hop-by-hop options from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -288,8 +293,10 @@ .Fn inet6_option_space routine and family of routines may be used to manipulate this data. .Pp -This option requires superuser privileges. -.It Dv IPV6_DSTOPTS Fa int * +This option requires superuser privileges. +Turning this option on will result in this process getting cmsg data of +type IPV6_HOPOPTS. +.It Dv IPV6_RECVDSTOPTS Fa int * Get or set whether the destination options from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -309,6 +316,8 @@ routine and family of routines may be used to manipulate this data. .Pp This option requires superuser privileges. +Turning this option on will result in this process getting cmsg data of +type IPV6_DSTOPTS. .It Dv IPV6_TCLASS Fa int * Get or set the value of the traffic class field used for outgoing datagrams on this socket. @@ -321,7 +330,7 @@ calls. The header field is stored as a single value of type .Vt int . -.It Dv IPV6_RTHDR Fa int * +.It Dv IPV6_RECVRTHDR Fa int * Get or set whether the routing header from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -343,6 +352,8 @@ routine and family of routines may be used to manipulate this data. .Pp This option requires superuser privileges. +Turning this option on will result in this process getting cmsg data of +type IPV6_RTHDR. .It Dv IPV6_PKTOPTIONS Fa struct cmsghdr * Get or set all header options and extension headers at one time on the last packet sent or received on the socket. @@ -413,11 +424,11 @@ .El .Pp The -.Dv IPV6_PKTINFO , -.\ .Dv IPV6_NEXTHOP , -.Dv IPV6_HOPLIMIT , -.Dv IPV6_HOPOPTS , -.Dv IPV6_DSTOPTS , +.Dv IPV6_RECVPKTINFO , +.\ .Dv IPV6_RECVNEXTHOP , +.Dv IPV6_RECVHOPLIMIT , +.Dv IPV6_RECVHOPOPTS , +.Dv IPV6_RECVDSTOPTS , and .Dv IPV6_RTHDR options will return ancillary data along with payload contents in subsequent @@ -429,7 +440,7 @@ and .Va cmsg_type set to respective option name value (e.g., -.Dv IPV6_HOPTLIMIT ) . +.Dv IPV6_HOPLIMIT ) . These options may also be used directly as ancillary .Va cmsg_type values in @@ -455,7 +466,7 @@ can be set by the .Dv IPV6_MULTICAST_IF socket option, through the -.Dv IPV6_PKTINFO +.Dv IPV6_RECVPKTINFO option, and through the .Va sin6_scope_id field of the socket address passed to the @@ -590,7 +601,7 @@ * returned along with the payload. */ optval = 1; -if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, optval, +if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, optval, sizeof(optval)) == -1) err(1,
Re: ip6(4) manpage update
On Sun, Jun 17, 2012 at 12:49:08PM +0200, Peter J. Philipp wrote: On Sat, Jun 16, 2012 at 07:17:16PM -0700, Philip Guenther wrote: You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS, IPV6_DSTOPTS, and IPV6_RTHDR. The RECV part was added to them in RFC3542. Yep. In addition, the text should be clarified to indicate that turning on IPV6_RECV* will result in the process getting cmsg data of type IPV6_*. E.g., IPV6_RECVHOPLIMIT turns on receiving of IPV6_HOPLIMIT cmsg data. Peter, do you want to take a stab at that part too? (There's also a typo in the current page: s/HOPTLIMIT/HOPLIMIT/) Philip Guenther Sure I'll take a stab at it but its very difficult I found (I was also distracted by freeing a bird from the attic). Here goes: attempt two.. process was the wrong word, I substituted it with socket. -peter Index: ip6.4 === RCS file: /cvs/src/share/man/man4/ip6.4,v retrieving revision 1.25 diff -u -r1.25 ip6.4 --- ip6.4 8 Sep 2011 16:43:56 - 1.25 +++ ip6.4 17 Jun 2012 10:45:19 - @@ -237,7 +237,7 @@ .It Dv IPV6_PORTRANGE_LOW Use a low, reserved range (600\-1023). .El -.It Dv IPV6_PKTINFO Fa int * +.It Dv IPV6_RECVPKTINFO Fa int * Get or set whether additional information about subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -250,14 +250,19 @@ unsigned intipi6_ifindex; /* send/recv if index */ }; .Ed -.It Dv IPV6_HOPLIMIT Fa int * + +Turning this option on will result in this socket getting cmsg data of +type IPV6_PKTINFO. +.It Dv IPV6_RECVHOPLIMIT Fa int * Get or set whether the hop limit header field from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 -calls. +calls. The value is stored as an .Vt int in the ancillary data returned. +Turning this option on will result in this socket getting cmsg data of +type IPV6_HOPLIMIT. .\ .It Dv IPV6_NEXTHOP Fa int * .\ Get or set whether the address of the next hop for subsequent .\ packets will be provided as ancillary data along with the payload in @@ -269,7 +274,7 @@ .\ structure in the ancillary data returned. .\ .Pp .\ This option requires superuser privileges. -.It Dv IPV6_HOPOPTS Fa int * +.It Dv IPV6_RECVHOPOPTS Fa int * Get or set whether the hop-by-hop options from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -288,8 +293,10 @@ .Fn inet6_option_space routine and family of routines may be used to manipulate this data. .Pp -This option requires superuser privileges. -.It Dv IPV6_DSTOPTS Fa int * +This option requires superuser privileges. +Turning this option on will result in this socket getting cmsg data of +type IPV6_HOPOPTS. +.It Dv IPV6_RECVDSTOPTS Fa int * Get or set whether the destination options from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -309,6 +316,8 @@ routine and family of routines may be used to manipulate this data. .Pp This option requires superuser privileges. +Turning this option on will result in this socket getting cmsg data of +type IPV6_DSTOPTS. .It Dv IPV6_TCLASS Fa int * Get or set the value of the traffic class field used for outgoing datagrams on this socket. @@ -321,7 +330,7 @@ calls. The header field is stored as a single value of type .Vt int . -.It Dv IPV6_RTHDR Fa int * +.It Dv IPV6_RECVRTHDR Fa int * Get or set whether the routing header from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -343,6 +352,8 @@ routine and family of routines may be used to manipulate this data. .Pp This option requires superuser privileges. +Turning this option on will result in this socket getting cmsg data of +type IPV6_RTHDR. .It Dv IPV6_PKTOPTIONS Fa struct cmsghdr * Get or set all header options and extension headers at one time on the last packet sent or received on the socket. @@ -413,11 +424,11 @@ .El .Pp The -.Dv IPV6_PKTINFO , -.\ .Dv IPV6_NEXTHOP , -.Dv IPV6_HOPLIMIT , -.Dv IPV6_HOPOPTS , -.Dv IPV6_DSTOPTS , +.Dv IPV6_RECVPKTINFO , +.\ .Dv IPV6_RECVNEXTHOP , +.Dv IPV6_RECVHOPLIMIT , +.Dv IPV6_RECVHOPOPTS , +.Dv IPV6_RECVDSTOPTS , and .Dv IPV6_RTHDR options will return ancillary data along with payload contents in subsequent @@ -429,7 +440,7 @@ and .Va cmsg_type set to respective option name value (e.g., -.Dv IPV6_HOPTLIMIT ) . +.Dv IPV6_HOPLIMIT ) . These options may also be used directly as ancillary .Va cmsg_type values in @@ -455,7 +466,7 @@ can be set by the .Dv IPV6_MULTICAST_IF socket option, through the -.Dv IPV6_PKTINFO +.Dv IPV6_RECVPKTINFO option, and through the .Va sin6_scope_id field of the socket address passed to the @@ -590,7 +601,7 @@ * returned along with the payload. */ optval = 1
ip6(4) manpage update
Hi, I just got through a thread in misc@, http://marc.info/?l=openbsd-miscm=133934252713974w=2 and it seems like the sample code in ip6(4) is wrong. I've made adjustments but it doesn't look as nice anymore, perhaps someone can look over it? These changes will really help someone first time trying the sample code, I think. Credit should be given to Simon Perreault, I just did what he suggested. -peter patch below (against 5.1): Index: ip6.4 === RCS file: /cvs/src/share/man/man4/ip6.4,v retrieving revision 1.25 diff -u -r1.25 ip6.4 --- ip6.4 8 Sep 2011 16:43:56 - 1.25 +++ ip6.4 11 Jun 2012 19:26:44 - @@ -251,6 +251,7 @@ }; .Ed .It Dv IPV6_HOPLIMIT Fa int * +.It Dv IPV6_RECVHOPLIMIT Fa int * Get or set whether the hop limit header field from subsequent packets will be provided as ancillary data along with the payload in subsequent .Xr recvmsg 2 @@ -590,7 +591,7 @@ * returned along with the payload. */ optval = 1; -if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, optval, +if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, optval, sizeof(optval)) == -1) err(1, setsockopt); @@ -685,6 +686,15 @@ .%A B. Fenner .%A A. Rudoff .%T UNIX Network Programming, third edition +.Re +.Rs +.%A W. Stevens +.%A M. Thomas +.%A E. Nordmark +.%A T. Jinmei +.%T Advanced Sockets Application Program Interface (API) for IPv6 +.%R RFC 3542 +.%D May 2003 .Re .Sh STANDARDS Most of the socket options are defined in RFC 2292 or RFC 2553.
path correction
This probably saw some debate in the past, which I did not see. On my IRC channel it is concensus that the path given out is dangerous. -peter Index: dot.profile === RCS file: /cvs/src/etc/skel/dot.profile,v retrieving revision 1.4 diff -u -r1.4 dot.profile --- dot.profile 16 Feb 2005 06:56:57 - 1.4 +++ dot.profile 13 Apr 2012 15:05:11 - @@ -2,5 +2,5 @@ # # sh/ksh initialization -PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. +PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:$HOME/bin:. export PATH HOME TERM
Re: path correction
On Fri, Apr 13, 2012 at 05:08:32PM +0200, Peter J. Philipp wrote: This probably saw some debate in the past, which I did not see. On my IRC channel it is concensus that the path given out is dangerous. I'd like to retract this patch. I lied. Yes I told a lie. Danger talking or discussing about this patch will make friends foes. Just leave it as it is, it's been so for 11 years anyhow. -peter
smtpd.conf.5 match reality
Thanks to kdump I was able to figure this one out before reading the source.
-peter
? smtpd.conf.5.patch
Index: smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
retrieving revision 1.45
diff -u -r1.45 smtpd.conf.5
--- smtpd.conf.53 Oct 2011 17:57:43 - 1.45
+++ smtpd.conf.522 Nov 2011 17:57:56 -
@@ -417,7 +417,7 @@
The configuration file would look like this:
.Bd -literal -offset indent
listen on lo0
-listen on bnx0 tls certificate mail.example.com.crt enable auth
+listen on bnx0 tls certificate mail.example.com enable auth
map aliases { source db /etc/mail/aliases.db }
accept for local deliver to mda /path/to/mda -f -
accept from all for domain example.org deliver to mda /path/to/mda -f -
Anyone interested in writing a driver for this?
Hi, I have a USB device called a USB FM transmitter from Keene Electronics. It looks like this when I plug it in. uaudio0 at uhub1 port 1 configuration 1 interface 0 HOLTEK B-LINK USB Audio rev 1.10/1.00 addr 3 uaudio0: audio rev 1.00, 2 mixer controls audio1 at uaudio0 uhidev0 at uhub1 port 1 configuration 1 interface 2 HOLTEK B-LINK USB Audio rev 1.10/1.00 addr 3 uhidev0: no report descriptor Basically there is two USB hids to this device, one is a standard audio device that acts like a sound card and transmits on FM. The second part controls it, sets its frequency and other things such as US/Europe FM stepping, TX gain etc. The driver for the audio exists as you can see. The second part is partially done by kenchy who did an incredible amount of reverse engineering of this device and wrote a libUSB program to set frequency and turns it on. https://github.com/kenchy/keene-usb-audio But the device has a few more knobs that I would love to see in a driver, such as TX gain and US/Europe settings, basically everything that the Windows XP driver does. Is anyone who is knowledged in writing a USB driver interested in writing a driver for this? I'd send you this device free of charge as it's collecting dust over here. There was a USB extension cable in the package which I have misplaced other than that there is a mini CDROM and the device itself. Kenchy has no license on his libusb program so its info can easily be used to make a BSD licensed driver out of this. Let me know in private email if you're interested. -peter
Re: Anyone interested in writing a driver for this?
On Thu, Jul 07, 2011 at 07:45:48PM +0200, Peter J. Philipp wrote: Hi, I have a USB device called a USB FM transmitter from Keene Electronics. It looks like this when I plug it in. I've found someone to send it to. If they have no luck they said they'd take it along to the next hackathon they're attending in order to give it to someone who may also be interested. Thanks! -peter
Re: last patch, idea
On Sun, Apr 10, 2011 at 10:08:24AM -0400, Ian Darwin wrote: Having tried to do things like gzcat /var/log/wtmp.0.gz | last -f /dev/stdin before, I'd certainly find it useful and this is less intrusive than modifying last(8) so it could work with standard input. Unless you run an extermely large shop like Beck does, or have extremely tiny disks, why not just remove all the Z flags from newsyslog.conf? This has the side effect of not having to gunzip /var/log/daemon* friends. This is a good idea. I guess I don't need my patch then. I won't clean it up then either. I guess we inherited this log gzipping from 4BSD, but in those days a 300MB disk cost a month's salary. Plus another week's salary or so for the trucking charges. funny. :-) -peter
last patch, idea
Hi,
while going through my wtmp with last(1) I noticed there could be a better
way than always gunzip'ing wtmp files and then using last -f. I've made
a patch for your consideration that does the following:
a) it checks if the file is a gzipped file by looking at the wtmp's file magic
b) it writes the gzipped file to a /tmp location uncompressed so that the
normal way of operation can be done on the tmp file.
I didn't want to start the discussion empty handed whether this is a good
patch or not, so I made the patch but it needs cleanup and probably a manpage
change. Let me know if this could go in, before I do any more work.
-peter
--- last.c.orig Sat Apr 9 22:33:55 2011
+++ last.c Sat Apr 9 23:49:39 2011
@@ -45,10 +45,12 @@
#include tzfile.h
#include unistd.h
#include utmp.h
+#include zlib.h
#defineNO 0 /* false/no */
#defineYES 1 /* true/yes */
#define ATOI2(ar) ((ar)[0] - '0') * 10 + ((ar)[1] - '0'); (ar) += 2;
+#define GZIP \037\213 /* gzipped file */
static struct utmp buf[1024]; /* utmp read buffer */
@@ -74,6 +76,7 @@
static time_t snaptime = 0; /* report only at this time */
static int calculate = 0;
static int seconds = 0;
+static char*tmpdir = NULL;
voidaddarg(int, char *);
struct ttytab *addtty(char *);
@@ -85,6 +88,10 @@
voidwtmp(void);
voidcheckargs(void);
voidusage(void);
+char *create_tmp(char *);
+void cleanup_tmp(char *);
+intisgzipped(void);
+void gzcopy(void);
#define NAME_WIDTH 9
#define HOST_WIDTH 24
@@ -161,8 +168,18 @@
}
}
+ if (isgzipped()) {
+ tmpdir = create_tmp(file);
+ gzcopy();
+ file = tmpdir;
+ }
+
+
checkargs();
wtmp();
+
+ if (tmpdir != NULL)
+ cleanup_tmp(tmpdir);
exit(0);
}
@@ -624,6 +641,10 @@
snprintf(str, sizeof str, \ninterrupted %10.10s %8.8s \n,
ct, ct + 11);
write(STDOUT_FILENO, str, strlen(str));
+
+ if (tmpdir != NULL)
+ cleanup_tmp(tmpdir);
+
if (signo == SIGINT)
_exit(1);
}
@@ -637,4 +658,103 @@
usage: %s [-csT] [-d date] [-f file] [-h host]
[-n number] [-t tty] [user ...]\n, __progname);
exit(1);
+}
+
+/*
+ * create a temporary directory where a temporary file can be put in
+ */
+
+char *
+create_tmp(char *file)
+{
+ static char tmpfile[MAXPATHLEN];
+ char d0[MAXPATHLEN];
+
+ char *p;
+ char *basename;
+
+ snprintf(d0, sizeof(d0), /tmp/last.);
+ mkdtemp(d0);
+
+ basename = strrchr(file, '/');
+ snprintf(tmpfile, sizeof(tmpfile), %s/%s, d0, basename);
+ p = strrchr(tmpfile, '.');
+ *p = '\0';
+
+ return ((char *)tmpfile);
+}
+
+/*
+ * clean temporary file and directory in /tmp
+ */
+
+void
+cleanup_tmp(char *tmpfile)
+{
+ char *sep;
+
+ unlink(tmpfile);
+ sep = strrchr(tmpfile, '/');
+ *sep = '\0';
+
+ rmdir(tmpfile);
+}
+
+/*
+ * determine if a wtmp file is gzipped or not, taken from /etc/magic
+ */
+
+int
+isgzipped(void)
+{
+ char buf[2];
+ char *cmp = GZIP;
+ int fd;
+
+ if ((fd = open(file, O_RDONLY, 0)) 0) {
+ perror(open);
+ exit(1);
+ }
+
+ if (read(fd, buf, sizeof(buf)) != sizeof(buf)) {
+ perror(read);
+ exit(1);
+ }
+
+ close(fd);
+
+ if (memcmp(cmp, buf, sizeof(buf)) == 0) {
+ return (1);
+ }
+
+ return (0);
+}
+
+/*
+ * copy gzipped file to file tmpdir
+ */
+void
+gzcopy(void)
+{
+ int fd, len;
+
+ char buf[512];
+ gzFile *gzt;
+
+ fd = open(tmpdir, O_WRONLY | O_CREAT, 0600);
+ if (fd 0) {
+ perror(open);
+ exit(1);
+ }
+
+ gzt = gzopen(file, r);
+ while ((len = gzread(gzt, buf, sizeof(buf))) 0) {
+ if (write(fd, buf, len) 0) {
+ perror(write);
+ exit(1);
+ }
+ }
+
+ gzclose(gzt);
+ close(fd);
}
IP option IP_RECVTTL question
Hi,
I wrote a DNS server and I'm collecting TTL information from the remote
nameservers that query my daemon. Everything works well, when I view the
logs I see:
Feb 3 10:43:48 uranus wildcarddnsd[5705]: request on descriptor 14 interface
em0 from XXX.XXX.XXX.XX (ttl=113, region=255) for centroid.eu. type=A(1)
class=1, answering centroid.eu.
Where the TTL is logged as 113 in this example.
But occasionally I get this on OpenBSD/i386 and /amd64...
Feb 3 10:45:01 uranus wildcarddnsd[5705]: request on descriptor 14 interface
em0 from XXX.XX.XX.XX (ttl=27263547, region=255) for goldflipper.net.
type=A(1) class=1, answering goldflipper.net.
Where the TTL is a bad value. I think I'm using the code the right way after
the manpage ip(4):
If the IP_RECVTTL option is enabled on a SOCK_DGRAM or SOCK_RAW socket,
the recvmsg(2) call will return the TTL of the received datagram. The
msg_control field in the msghdr structure points to a buffer that
contains a cmsghdr structure followed by the TTL value. The cmsghdr
fields have the following values:
cmsg_len = CMSG_LEN(sizeof(struct in_addr))
cmsg_level = IPPROTO_IP
cmsg_type = IP_RECVTTL
And if I'm not mistaken the size of struct in_addr is 4.
Since sourceforge is down I can't refer you to the webcvs but they still
offer the files for download if you want to take a peak at the source code
that'd be great! http://sourceforge.net/projects/wildcarddns/files/
Here are some snippets from my source code perhaps you can spot what I'm
doing wrong?
...
if (setsockopt(udp[i], IPPROTO_IP, IP_RECVTTL, on, sizeof(on)) 0) {
...
#ifdef __FreeBSD__
u_char *ttlptr;
#elif __OpenBSD__
struct in_addr *ttlptr;
#else
int *ttlptr;
#endif
u_int32_t received_ttl;
...
#if __FreeBSD__
ttlptr = (u_char *) CMSG_DATA(cmsg);
received_ttl = (u_int)*ttlptr;
#elif __OpenBSD__
ttlptr = (struct in_addr *) CMSG_DATA(cmsg);
memcpy(received_ttl, ttlptr, sizeof(u_int32_t));
#else
ttlptr = (int *) CMSG_DATA(cmsg);
received_ttl = (u_int)*ttlptr;
#endif
...
syslog(LOG_INFO, request on descriptor %u interface \%s\ from %s (ttl=%u,
region=%d) for \%s\ type=%s class=%u, answering \%s\, so, ident[i],
address, received_ttl, aregion, question-converted_name,
get_dns_type(ntohs(question-hdr-qtype)), ntohs(question-hdr-qclass),
replystring);
...
Unfortunately this #define hell is a mess but it's the only way to get this
portable among BSD's and Linux. I'm hoping someone can tell where I'm going
wrong with this and why it's right sometimes and wrong the occasional time.
Regards,
-peter
Re: IP option IP_RECVTTL question
On Thu, Feb 03, 2011 at 01:51:47PM +0100, Otto Moerbeek wrote: cmsg_len = CMSG_LEN(sizeof(struct in_addr)) cmsg_level = IPPROTO_IP cmsg_type = IP_RECVTTL And if I'm not mistaken the size of struct in_addr is 4. This looks like a documentation error. Actually, the data length is CMSG_LEN(sizeof(u_char)), as can be seen in src/netinet/ip_input.c:1744 and the implementation of sbcreatecontrol() in src/kern/uipc_socket2.c. Try the FreeBSD code, it looks that has a goof chanche of working. If this is indeed the case, I'd like to know so I can fix the man page. -Otto Hi, At first glance it seems to be working with the FreeBSD code. On both i386 and amd64. Thanks! So it must be a documentation bug. Thanks for your help! -peter
/bsd: nd6_ns_input: duplicate IP6 address 2001:0a60:f074:0004::0001
Hi,
I got a new firewall and had to do some plumbing, and _reused_ an IPv6 address
block that was already on an interface (tun0). Everything worked still but
I got these messages on the firewall (uranus):
Jan 7 16:55:47 uranus /bsd: nd6_ns_input: duplicate IP6 address
2001:0a60:f074:0004::0001
I googled this message and it seems some other people also have this message
in their kernel.
So I started to chase this message in the kernel and it turns out the old
firewall (cordelia) was sending IPv6 Neighbour Solicitation packets with a
source address of 2001:a60:f074:4::1. Since it's IP6 address was
2001:a60:f074:4::2 I don't know how it got the ::1 until I looked at an
unused /etc/hostname.tun0 file and it was incorrectly set at
2001:a60:f074:4::1/64 too. So I was chasing why it would still send the
solicitation with both source address and destination address being
2001:a60:f074:4::1 and I got lost in the code, but I produced this patch
that may be useful?
Index: nd6_nbr.c
===
RCS file: /cvs/src/sys/netinet6/nd6_nbr.c,v
retrieving revision 1.55
diff -u -r1.55 nd6_nbr.c
--- nd6_nbr.c 8 Feb 2010 11:56:09 - 1.55
+++ nd6_nbr.c 8 Jan 2011 10:18:25 -
@@ -474,6 +475,14 @@
*/
bzero(src_sa.sin6_addr, sizeof(src_sa.sin6_addr));
}
+
+ if (IN6_ARE_ADDR_EQUAL(src_sa.sin6_addr, dst_sa.sin6_addr)) {
+ log(LOG_INFO, nd6_ns_output: source is same
+ as destination: dst=%s\n,
+ ip6_sprintf(dst_sa.sin6_addr));
+ goto bad;
+ }
+
ip6-ip6_src = src_sa.sin6_addr;
nd_ns = (struct nd_neighbor_solicit *)(ip6 + 1);
nd_ns-nd_ns_type = ND_NEIGHBOR_SOLICIT;
With this patch the packet is stopped on the misconfigured machine and doesn't
cause errors on another machine due to its misconfiguration, while hopefully
still being a nagging pain in the dmesg.
-peter
Re: smtpd w/ async DNS
On Sat, Oct 30, 2010 at 04:55:36PM +0200, Gilles Chehade wrote: Hi tech@, A new tarball with all reported issues fixed is available at: http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz smtpd now catches changes in /etc/resolv.conf and should work fine with inet6 records. I have done some stress testing here and it's been stable. asr has also been improved by eric@ who cleaned up code, fixed some bugs and added tcp support, honors the family keyword in /etc/resolv.conf. Please test fast and report issues so that we can move to the next features ;-) Gilles Hi, Is this a typo? on line 40 in asr.c #define DEFAULT_CONFlookup bind file\nameserver 127.0.0.1\n should it be lookup bind file\nnameserver 127.0.0.1\n? regards, -peter
Re: smtpd w/ async DNS
On Sat, Oct 30, 2010 at 05:28:42PM +0200, Gilles Chehade wrote: It was a typo indeed, tarball has been updated and also contains a fix for a crash experienced by todd@ when using relay via Gilles I had a look at the pack.c file where the DNS compression is being handled. It looks good to me. But I have one concern that needs to be confirmed. In function dname_expand() on lines: 54 ptr = 256 * (n ~0xc0) + data[offset + 1]; 55 if (ptr = offset) 56 return (-1); The pointer is checked against offset meaning that a compression loop can't occur. This is good. However what happens if you have a DNS reply packet with a name with two labels in it, one being a normal label of a name and the second being a compression pointer that points back to the first label, kinda like so.. [8]centroid[C0 back to 8] I'm worried it might go into an infinite loop or crash even. Perhaps it should check that it cannot go back to a label inside a dns name that is being parsed. Otherwise rockin' code! I don't understand it all but the little I do it looks really high quality! -peter
Re: cksum(1) patch
On Wed, May 13, 2009 at 10:40:13AM +0200, Otto Moerbeek wrote:
Come to think of it, why don't you just putchar(tolower(hf-name[i]))
in a loop? Saves you the calloc and error handling.
Also, don't forget to fix usage().
-Otto
Yeah, thanks. Well I got good and critical feedback and Otto's prodding was
good enough to make me rewrite this puny patch. Gone are errno, calloc() and
in is the putchar(). I stayed away from adding sthen's idea, perhaps he can do
the patch for that. Patch follows:
? cksum.1-orig
? cksum.patch
? md5.c-orig
Index: cksum.1
===
RCS file: /cvs/src/bin/md5/cksum.1,v
retrieving revision 1.19
diff -u -r1.19 cksum.1
--- cksum.1 8 Feb 2009 17:15:09 - 1.19
+++ cksum.1 13 May 2009 10:03:46 -
@@ -42,7 +42,7 @@
.Sh SYNOPSIS
.Nm cksum
.Bk -words
-.Op Fl bpqrtx
+.Op Fl blpqrtx
.Op Fl a Ar algorithms
.Op Fl c Op Ar checklist ...
.Op Fl o Ar 1 | 2
@@ -162,6 +162,8 @@
option may not be used in conjunction with more than a single
.Fl a
option.
+.It Fl l
+outputs the algorithms available and exits.
.It Fl o Ar 1 | 2
Use historic algorithms instead of the (superior) default one
(see below).
Index: md5.c
===
RCS file: /cvs/src/bin/md5/md5.c,v
retrieving revision 1.50
diff -u -r1.50 md5.c
--- md5.c 6 Sep 2008 12:01:34 - 1.50
+++ md5.c 13 May 2009 10:03:46 -
@@ -210,14 +210,14 @@
struct hash_list hl;
size_t len;
char *cp, *input_string;
- int fl, error, base64;
+ int fl, error, base64, i;
int bflag, cflag, pflag, rflag, tflag, xflag;
static const char *optstr[5] = {
bcpqrs:tx,
bcpqrs:tx,
bcpqrs:tx,
- a:bco:pqrs:tx,
+ a:bco:lpqrs:tx,
a:bco:pqrs:tx
};
@@ -315,6 +315,15 @@
if (hftmp == TAILQ_END(hl))
hash_insert(hl, hf, 0);
break;
+ case 'l':
+ for (hf = functions; hf-name != NULL; hf++) {
+ len = strlen(hf-name);
+ for (i = 0; i len; i++) {
+ putchar(tolower(hf-name[i]));
+ }
+ putchar('\n');
+ }
+ exit(0);
case 'p':
pflag = 1;
break;
Re: cksum(1) patch
On Wed, May 13, 2009 at 12:20:44PM +0200, Otto Moerbeek wrote:
You forgot to fix usage(). Also, I think it makes sense to allow -l
for sum(1) too, so that both commands that take -a also take -l.
-Otto
Eeek. Ok this will do then:
Regards,
-p
? cksum.1-orig
? cksum.patch
? md5.c-orig
Index: cksum.1
===
RCS file: /cvs/src/bin/md5/cksum.1,v
retrieving revision 1.19
diff -u -r1.19 cksum.1
--- cksum.1 8 Feb 2009 17:15:09 - 1.19
+++ cksum.1 13 May 2009 11:27:53 -
@@ -42,7 +42,7 @@
.Sh SYNOPSIS
.Nm cksum
.Bk -words
-.Op Fl bpqrtx
+.Op Fl blpqrtx
.Op Fl a Ar algorithms
.Op Fl c Op Ar checklist ...
.Op Fl o Ar 1 | 2
@@ -50,7 +50,7 @@
.Op Ar file ...
.Ek
.Nm sum
-.Op Fl bpqrtx
+.Op Fl blpqrtx
.Op Fl a Ar algorithms
.Op Fl c Op Ar checklist ...
.Op Fl o Ar 1 | 2
@@ -162,6 +162,8 @@
option may not be used in conjunction with more than a single
.Fl a
option.
+.It Fl l
+outputs the algorithms available and exits.
.It Fl o Ar 1 | 2
Use historic algorithms instead of the (superior) default one
(see below).
Index: md5.c
===
RCS file: /cvs/src/bin/md5/md5.c,v
retrieving revision 1.50
diff -u -r1.50 md5.c
--- md5.c 6 Sep 2008 12:01:34 - 1.50
+++ md5.c 13 May 2009 11:27:53 -
@@ -210,15 +210,15 @@
struct hash_list hl;
size_t len;
char *cp, *input_string;
- int fl, error, base64;
+ int fl, error, base64, i;
int bflag, cflag, pflag, rflag, tflag, xflag;
static const char *optstr[5] = {
bcpqrs:tx,
bcpqrs:tx,
bcpqrs:tx,
- a:bco:pqrs:tx,
- a:bco:pqrs:tx
+ a:bco:lpqrs:tx,
+ a:bco:lpqrs:tx
};
TAILQ_INIT(hl);
@@ -315,6 +315,15 @@
if (hftmp == TAILQ_END(hl))
hash_insert(hl, hf, 0);
break;
+ case 'l':
+ for (hf = functions; hf-name != NULL; hf++) {
+ len = strlen(hf-name);
+ for (i = 0; i len; i++) {
+ putchar(tolower(hf-name[i]));
+ }
+ putchar('\n');
+ }
+ exit(0);
case 'p':
pflag = 1;
break;
@@ -794,7 +803,7 @@
break;
case MODE_CKSUM:
case MODE_SUM:
- fprintf(stderr, usage: %s [-bpqrtx] [-a algorithms]
+ fprintf(stderr, usage: %s [-blpqrtx] [-a algorithms]
[-c [checklist ...]] [-o 1 | 2]\n
%*s [-s string] [file ...]\n,
__progname, (int)strlen(__progname), );
Re: cksum(1) patch
And I seem to remember the diff was inspired by Solaris. $ uname -a SunOS foo 5.10 Generic_127128-11 i86pc i386 i86pc $ cksum -l cksum: illegal option -- l Usage: cksum [file ...] It was inspired by digest(1) not cksum. sycorax$ uname -a SunOS sycorax 5.10 Generic_137138-09 i86pc i386 i86pc sycorax$ digest -l sha1 md5 sha256 sha384 sha512 sycorax$ Regards, -peter
