headers
Daniel Dickman | 1 Oct 2008 01:10
Picon

[patch] fix a typo

Index: INSTALL.linux
===================================================================
RCS file: /cvs/src/etc/etc.i386/INSTALL.linux,v
retrieving revision 1.12
diff -u -r1.12 INSTALL.linux
--- INSTALL.linux	18 Aug 2004 08:57:33 -0000	1.12
+++ INSTALL.linux	30 Jan 2008 17:45:11 -0000
 <at>  <at>  -233,7 +233,7  <at>  <at> 
 so the granularity of disklabel partitions is 504 Kb.
 - units for size and offset can be given as sectors (default) or cylinders.

-After edition, this is what my disklabel looks like:
+After editing, this is what my disklabel looks like:
 # editing

 # using MBR partition 2: type A6 off 2201472 (0x219780) size 5798016 (0x587880)
Permalink | Reply | 0 comments |
headers
Daniel Dickman | 1 Oct 2008 05:20
Picon

[patch] sort(1) man page

I think -s is an extension to sort(1) to as per:
http://www.opengroup.org/onlinepubs/009695399/utilities/sort.html

Index: sort.1
===================================================================
RCS file: /cvs/src/usr.bin/sort/sort.1,v
retrieving revision 1.31
diff -u -r1.31 sort.1
--- sort.1      21 Aug 2007 21:22:37 -0000      1.31
+++ sort.1      28 Sep 2008 23:48:55 -0000
 <at>  <at>  -384,7 +384,7  <at>  <at> 
 specification.
 .Pp
 The flags
-.Op Fl HRTz
+.Op Fl HRsTz
 are extensions to that specification.
 .Sh HISTORY
 A
Permalink | Reply | 1 comment |
headers
Jason McIntyre | 1 Oct 2008 08:40
Picon

Re: [patch] sort(1) man page

On Wed, Oct 01, 2008 at 03:20:39AM +0000, Daniel Dickman wrote:
> I think -s is an extension to sort(1) to as per:
> http://www.opengroup.org/onlinepubs/009695399/utilities/sort.html
> 

you're right. i just committed your fix. thanks,
jmc

> Index: sort.1
> ===================================================================
> RCS file: /cvs/src/usr.bin/sort/sort.1,v
> retrieving revision 1.31
> diff -u -r1.31 sort.1
> --- sort.1      21 Aug 2007 21:22:37 -0000      1.31
> +++ sort.1      28 Sep 2008 23:48:55 -0000
>  <at>  <at>  -384,7 +384,7  <at>  <at> 
>  specification.
>  .Pp
>  The flags
> -.Op Fl HRTz
> +.Op Fl HRsTz
>  are extensions to that specification.
>  .Sh HISTORY
>  A
Permalink | Reply | 0 comments |
headers
Thomas Pfaff | 2 Oct 2008 21:32
Picon

[patch] dig(1)

Should this be sent upstream?

Index: dig.1
===================================================================
RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.1,v
retrieving revision 1.9
diff -u -p -r1.9 dig.1
--- dig.1	9 Dec 2007 13:39:42 -0000	1.9
+++ dig.1	2 Oct 2008 19:30:06 -0000
 <at>  <at>  -59,7 +59,9  <at>  <at>  Unless it is told to query a specific na
 will try each of the servers listed in
 \fI/etc/resolv.conf\fR.
 .PP
-When no command line arguments or options are given, will perform an NS query for "." (the root).
+When no command line arguments or options are given,
+\fBdig\fR
+will perform an NS query for "." (the root).
 .PP
 It is possible to set per\-user defaults for
 \fBdig\fR
Permalink | Reply | 3 comments |
headers
Stuart Henderson | 2 Oct 2008 21:47
Favicon
Gravatar

Re: [patch] dig(1)

On 2008/10/02 21:32, Thomas Pfaff wrote:
> Should this be sent upstream?

yes

> Index: dig.1
> ===================================================================
> RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.1,v
> retrieving revision 1.9
> diff -u -p -r1.9 dig.1
> --- dig.1	9 Dec 2007 13:39:42 -0000	1.9
> +++ dig.1	2 Oct 2008 19:30:06 -0000
>  <at>  <at>  -59,7 +59,9  <at>  <at>  Unless it is told to query a specific na
>  will try each of the servers listed in
>  \fI/etc/resolv.conf\fR.
>  .PP
> -When no command line arguments or options are given, will perform an NS query for "." (the root).
> +When no command line arguments or options are given,
> +\fBdig\fR
> +will perform an NS query for "." (the root).
>  .PP
>  It is possible to set per\-user defaults for
>  \fBdig\fR
Permalink | Reply | 0 comments |
headers
Jason McIntyre | 2 Oct 2008 21:55
Picon

Re: [patch] dig(1)

On Thu, Oct 02, 2008 at 09:32:34PM +0200, Thomas Pfaff wrote:
> Should this be sent upstream?
> 

yes, though you might want to check first that their current source
doesn;t address this.

jmc

> Index: dig.1
> ===================================================================
> RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.1,v
> retrieving revision 1.9
> diff -u -p -r1.9 dig.1
> --- dig.1	9 Dec 2007 13:39:42 -0000	1.9
> +++ dig.1	2 Oct 2008 19:30:06 -0000
>  <at>  <at>  -59,7 +59,9  <at>  <at>  Unless it is told to query a specific na
>  will try each of the servers listed in
>  \fI/etc/resolv.conf\fR.
>  .PP
> -When no command line arguments or options are given, will perform an NS query for "." (the root).
> +When no command line arguments or options are given,
> +\fBdig\fR
> +will perform an NS query for "." (the root).
>  .PP
>  It is possible to set per\-user defaults for
>  \fBdig\fR
Permalink | Reply | 1 comment |
headers
Mitja Muženič | 3 Oct 2008 00:00

tcpdump print-ike.c patch

The following adds the display of the SPI field of DPD R_U_THERE{-ACK}
messages to tcpdump's IKE dissector. It came handy when I was debugging an
"INVALID SPI" error message that was caused by, well, an invalid SPI :)

I don't know of a better way to concatenate an array of 16 u_int8_t's while
keeping the formatting. Apologies if the tabs get lost somehow.

Index: print-ike.c
===================================================================
RCS file: /export/obsd/cvshome/cvs/src/usr.sbin/tcpdump/print-ike.c,v
retrieving revision 1.30
diff -u -r1.30 print-ike.c
--- print-ike.c 7 Oct 2007 16:41:05 -0000       1.30
+++ print-ike.c 1 Oct 2008 19:36:06 -0000
 <at>  <at>  -684,6 +684,11  <at>  <at> 
                else {
				seq = (u_int32_t *)&np->data[np->spi_size];
				printf("seq %u", ntohl(*seq));
+				printf(" SPI: 0x%08x%8x %08x%8x",
+					np->data[0]<<24 | np->data[1]<<16 |
np->data[2]<<8 | np->data[3],
+					np->data[4]<<24 | np->data[5]<<16 |
np->data[6]<<8 | np->data[7],
+					np->data[8]<<24 | np->data[9]<<16 |
np->data[10]<<8 | np->data[11],
+					np->data[12]<<24 | np->data[13]<<16
| np->data[14]<<8 | np->data[15]);
                }
                break;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mitja Muženič | 3 Oct 2008 00:18

isakmpd and DPD - rfc3706 compliance

RFC3706, paragraph 5.3 says this about the SPI payload of a DPD R_U_THERE
message:

"Security Parameter Index (16 octets) - SHOULD be set to the cookies of the
Initiator and Responder of the IKE SA (in that order)"

and paragraph 6.1

"Additionally, both the receiver of the R-U-THERE and the R-U-THERE-ACK
message SHOULD check the validity of the Initiator and Responder cookies
presented in the SPI field of the payload."

isakmpd does this validity check and errors out on a DPD R_U_THERE message
that does not follow the above format (in my case the SPI was composed of 2x
Initiator's cookie). Since the format of the SPI field is described as
"SHOULD be" instead of "MUST be", it arguably means that isakmpd's check is
too strict.

The following converts the check's output from error to warning and unbreaks
the DPD traffic with Stonegate VPN gateway (ver. 4.2.5) that is sending such
an unortodox yet technically legal DPD message. Without it, isakmpd does not
reply to Stonegate's DPD requests with R_U_THERE_ACK, but with NOTIFY:
INVALID SPI, and this causes the tunnel to go down when DPD expires.

Index: sbin/isakmpd/message.c
===================================================================
RCS file: /export/obsd/cvshome/cvs/src/sbin/isakmpd/message.c,v
retrieving revision 1.126
diff -u -r1.126 message.c
--- sbin/isakmpd/message.c      2 Jun 2007 01:29:11 -0000       1.126
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeremy C. Reed | 3 Oct 2008 03:00

Re: [patch] dig(1)

On Thu, 2 Oct 2008, Jason McIntyre wrote:

> yes, though you might want to check first that their current source
> doesn;t address this.

Needed it. Committed it. Thanks Thomas!
Permalink | Reply | 0 comments |
headers
Matthew Dempsky | 3 Oct 2008 04:01
Favicon

Re: isakmpd and DPD - rfc3706 compliance

On Thu, Oct 2, 2008 at 3:18 PM, Mitja Mu>enih <mitja <at> muzenic.net> wrote:
> "Additionally, both the receiver of the R-U-THERE and the R-U-THERE-ACK
> message SHOULD check the validity of the Initiator and Responder cookies
> presented in the SPI field of the payload."
>
> isakmpd does this validity check and errors out on a DPD R_U_THERE message
> that does not follow the above format (in my case the SPI was composed of 2x
> Initiator's cookie). Since the format of the SPI field is described as
> "SHOULD be" instead of "MUST be", it arguably means that isakmpd's check is
> too strict.

Why even check for validity if you're not going to throw out invalid messages?
Permalink | Reply | 1 comment |

Gmane