date:20170418

vi unused variables

2017-04-18 Thread Michael W. Bombardieri

Hi,

Some unused variables in vi were identified by gcc 4.9.4.

- Michael


Index: common/recover.c
===
RCS file: /cvs/src/usr.bin/vi/common/recover.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 recover.c
--- common/recover.c29 Jun 2016 20:38:39 -  1.25
+++ common/recover.c19 Apr 2017 02:45:32 -
@@ -313,7 +313,6 @@ static int
 rcv_mailfile(SCR *sp, int issync, char *cp_path)
 {
EXF *ep;
-   GS *gp;
struct passwd *pw;
size_t len;
time_t now;
@@ -323,7 +322,6 @@ rcv_mailfile(SCR *sp, int issync, char *
char *t1, *t2, *t3;
char host[HOST_NAME_MAX+1];
 
-   gp = sp->gp;
if ((pw = getpwuid(uid = getuid())) == NULL) {
msgq(sp, M_ERR,
"Information on user id %u not found", uid);
Index: ex/ex_bang.c
===
RCS file: /cvs/src/usr.bin/vi/ex/ex_bang.c,v
retrieving revision 1.11
diff -u -p -u -r1.11 ex_bang.c
--- ex/ex_bang.c18 Apr 2017 01:45:35 -  1.11
+++ ex/ex_bang.c19 Apr 2017 02:45:32 -
@@ -52,7 +52,6 @@ ex_bang(SCR *sp, EXCMD *cmdp)
EX_PRIVATE *exp;
MARK rm;
recno_t lno;
-   int rval;
const char *msg;
 
ap = cmdp->argv[0];
@@ -145,7 +144,7 @@ ex_bang(SCR *sp, EXCMD *cmdp)
ftype = FILTER_RBANG;
}
}
-   rval = ex_filter(sp, cmdp,
+   (void)ex_filter(sp, cmdp,
>addr1, >addr2, , ap->bp, ftype);
 
/*
Index: ex/ex_global.c
===
RCS file: /cvs/src/usr.bin/vi/ex/ex_global.c,v
retrieving revision 1.17
diff -u -p -u -r1.17 ex_global.c
--- ex/ex_global.c  27 May 2016 09:18:12 -  1.17
+++ ex/ex_global.c  19 Apr 2017 02:45:32 -
@@ -67,7 +67,6 @@ ex_g_setup(SCR *sp, EXCMD *cmdp, enum wh
RANGE *rp;
busy_t btype;
recno_t start, end;
-   regex_t *re;
regmatch_t match[1];
size_t len;
int cnt, delim, eval;
@@ -146,7 +145,6 @@ usage:  ex_emsg(sp, cmdp->cmd->usage, EX
 */
sp->searchdir = FORWARD;
}
-   re = >re_c;
 
/* The global commands always set the previous context mark. */
abs_mark.lno = sp->lno;
Index: vi/vs_split.c
===
RCS file: /cvs/src/usr.bin/vi/vi/vs_split.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 vs_split.c
--- vi/vs_split.c   27 May 2016 09:18:12 -  1.16
+++ vi/vs_split.c   19 Apr 2017 02:45:32 -
@@ -458,11 +458,8 @@ vs_swap(SCR *sp, SCR **nspp, char *name)
 int
 vs_resize(SCR *sp, long count, adj_t adj)
 {
-   GS *gp;
SCR *g, *s;
size_t g_off, s_off;
-
-   gp = sp->gp;
 
/*
 * Figure out which screens will grow, which will shrink, and

use strtonum to parse the argument to -j in make

2017-04-18 Thread David Gwynne

i cant remember why i was looking at this, but strtoll annoys me.

ok?

Index: main.c
===
RCS file: /cvs/src/usr.bin/make/main.c,v
retrieving revision 1.119
diff -u -p -r1.119 main.c
--- main.c  4 Jan 2016 10:59:23 -   1.119
+++ main.c  19 Apr 2017 01:39:22 -
@@ -310,14 +310,14 @@ MainParseArgs(int argc, char **argv)
Lst_AtEnd(, optarg);
break;
case 'j': {
-  char *endptr;
+   const char *errstr;
 
forceJobs = true;
-   maxJobs = strtol(optarg, , 0);
-   if (endptr == optarg) {
+   maxJobs = strtonum(optarg, 1, INT_MAX, );
+   if (errstr != NULL) {
fprintf(stderr,
-   "make: illegal argument to -j option -- 
%s -- not a number\n",
-   optarg);
+   "make: illegal argument to -j option"
+   " -- %s -- %s\n", optarg, errstr);
usage();
}
record_option(c, optarg);

Re: cksum not working with both -a and -C flags together

2017-04-18 Thread Craig Skinner

On 2017-03-28 Tue 11:56 AM |, Todd C. Miller wrote:
> On Tue, 28 Mar 2017 09:33:53 -0600, "Todd C. Miller" wrote:
> 
> > It seems to me that in -C mode it should really process all the
> > checksums that match the specified file(s), but the documentation
> > does not actually specify what the behavior is in this case.
> 
> Here's a diff that accomplishes that.
> 

Yep:


$ cksum -b -a cksum,MD5,RMD160,SHA1,SHA256 -h /tmp/bsd.digest /bsd
$ cksum -C /tmp/bsd.digest /bsd
(CKSUM) /bsd: OK
(MD5) /bsd: OK
(RMD160) /bsd: OK
(SHA1) /bsd: OK
(SHA256) /bsd: OK

# Scramble line order:
$ vi /tmp/bsd.digest
$ cksum -C /tmp/bsd.digest /bsd
(MD5) /bsd: OK
(SHA256) /bsd: OK
(CKSUM) /bsd: OK
(SHA1) /bsd: OK
(RMD160) /bsd: OK

# Only SHA* digests, a bad MD5 digest & some junk:
$ mv /tmp/bsd.digest /tmp/bsd.digest~
$ fgrep SHA /tmp/bsd.digest~ > /tmp/bsd.digest
$ print 'MD5 (/bsd) = I-no-thinky-so-fail-me==' >> /tmp/bsd.digest
$ print 'JUNK (/bsd) = road-killed-dead-beef==' >> /tmp/bsd.digest
$ cksum -C /tmp/bsd.digest /bsd
(SHA256) /bsd: OK
(SHA1) /bsd: OK
(MD5) /bsd: FAILED
print $?
1

# Reorder check list, making valid digests last:
$ sort -o /tmp/bsd.digest /tmp/bsd.digest
$ cksum -C /tmp/bsd.digest /bsd
(MD5) /bsd: FAILED
(SHA1) /bsd: OK
(SHA256) /bsd: OK
$ print $?
1

Re: switch base tools from /dev/bpf0 to /dev/bpf

2017-04-18 Thread Theo de Raadt

Good enough for me.

> Now that /dev/bpf has been around for two releases, it should be safe to
> move the base tools to /dev/bpf. No need to worry about the upgrade path
> anymore.
> 
> Ok?
> 
> natano
> 
> 
> Index: lib/libpcap/pcap-bpf.c
> ===
> RCS file: /cvs/src/lib/libpcap/pcap-bpf.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 pcap-bpf.c
> --- lib/libpcap/pcap-bpf.c8 May 2016 08:20:50 -   1.34
> +++ lib/libpcap/pcap-bpf.c18 Apr 2017 18:29:27 -
> @@ -216,9 +216,9 @@ bpf_open(pcap_t *p)
>  {
>   int fd;
>  
> - fd = open("/dev/bpf0", O_RDWR);
> + fd = open("/dev/bpf", O_RDWR);
>   if (fd == -1 && errno == EACCES)
> - fd = open("/dev/bpf0", O_RDONLY);
> + fd = open("/dev/bpf", O_RDONLY);
>  
>   if (fd == -1) {
>   if (errno == EACCES)
> Index: sbin/dhclient/bpf.c
> ===
> RCS file: /cvs/src/sbin/dhclient/bpf.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 bpf.c
> --- sbin/dhclient/bpf.c   18 Apr 2017 13:59:09 -  1.49
> +++ sbin/dhclient/bpf.c   18 Apr 2017 18:30:47 -
> @@ -78,13 +78,13 @@ if_register_bpf(struct interface_info *i
>   struct ifreq ifr;
>   int sock;
>  
> - if ((sock = open("/dev/bpf0", O_RDWR | O_CLOEXEC)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR | O_CLOEXEC)) == -1)
>   fatal("Can't open bpf");
>  
>   /* Set the BPF device to point at this interface. */
>   strlcpy(ifr.ifr_name, ifi->name, IFNAMSIZ);
>   if (ioctl(sock, BIOCSETIF, ) < 0)
> - fatal("Can't attach interface %s to /dev/bpf0", ifi->name);
> + fatal("Can't attach interface %s to /dev/bpf", ifi->name);
>  
>   return (sock);
>  }
> Index: usr.sbin/arp/arp.c
> ===
> RCS file: /cvs/src/usr.sbin/arp/arp.c,v
> retrieving revision 1.78
> diff -u -p -r1.78 arp.c
> --- usr.sbin/arp/arp.c15 Apr 2017 11:50:24 -  1.78
> +++ usr.sbin/arp/arp.c18 Apr 2017 18:31:21 -
> @@ -821,7 +821,7 @@ wake(const char *ether_addr, const char 
>   char*pname = NULL;
>   int  bpf;
>  
> - if ((bpf = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((bpf = open("/dev/bpf", O_RDWR)) == -1)
>   err(1, "Failed to bind to bpf");
>  
>   if (iface == NULL) {
> Index: usr.sbin/dhcpd/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcpd/bpf.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 bpf.c
> --- usr.sbin/dhcpd/bpf.c  18 Apr 2017 13:59:09 -  1.18
> +++ usr.sbin/dhcpd/bpf.c  18 Apr 2017 18:31:37 -
> @@ -77,7 +77,7 @@ if_register_bpf(struct interface_info *i
>  {
>   int sock;
>  
> - if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR)) == -1)
>   fatal("Can't open bpf device");
>  
>   /* Set the BPF device to point at this interface. */
> Index: usr.sbin/dhcrelay/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay/bpf.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 bpf.c
> --- usr.sbin/dhcrelay/bpf.c   5 Apr 2017 14:40:56 -   1.18
> +++ usr.sbin/dhcrelay/bpf.c   18 Apr 2017 18:31:56 -
> @@ -72,7 +72,7 @@ if_register_bpf(struct interface_info *i
>   int sock;
>  
>   /* Open the BPF device */
> - if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR)) == -1)
>   fatal("Can't open bpf device");
>  
>   /* Set the BPF device to point at this interface. */
> Index: usr.sbin/dhcrelay6/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay6/bpf.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 bpf.c
> --- usr.sbin/dhcrelay6/bpf.c  17 Mar 2017 14:45:16 -  1.1
> +++ usr.sbin/dhcrelay6/bpf.c  18 Apr 2017 18:33:58 -
> @@ -75,7 +75,7 @@ if_register_bpf(struct interface_info *i
>   int sock;
>  
>   /* Open the BPF device */
> - if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR)) == -1)
>   fatal("Can't open bpf device");
>  
>   /* Set the BPF device to point at this interface. */
> Index: usr.sbin/hostapd/hostapd.c
> ===
> RCS file: /cvs/src/usr.sbin/hostapd/hostapd.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 hostapd.c
> --- usr.sbin/hostapd/hostapd.c28 May 2016 07:00:18 -  1.37
> +++ usr.sbin/hostapd/hostapd.c18 Apr 2017 18:32:14 -
> @@ -173,7 +173,7 @@ hostapd_bpf_open(u_int flags)
>   int fd = -1;
>   struct bpf_version bpv;
>  
> - if ((fd = open("/dev/bpf0", flags)) == -1) {
> +

touch: remove obsolete time specification

2017-04-18 Thread Marco van Hulten

The patch below removes a feature from touch(1) that is probably in more
situations undesired than desired.

When an 8 or 10 digit time format is specified as the first argument,
and it has at least two arguments in total, it is interpreted as a time
formatting instead of a file name.  This feature/form is obsolete in the
current version of POSIX 1003.1.

When I first saw the behaviour, I thought it was a bug, but the code,
the man page and the standard explain it.  Removing the feature could
break old scripts or habits.  However, I found the behaviour quite
unexpected, and the standard says it is obsolete.

 - Marco


Index: touch.1
===
RCS file: /cvs/src/usr.bin/touch/touch.1,v
retrieving revision 1.35
diff -u -p -r1.35 touch.1
--- touch.1 25 Sep 2015 17:02:57 -  1.35
+++ touch.1 17 Apr 2017 19:14:12 -
@@ -164,18 +164,6 @@ The
 utility is compliant with the
 .St -p1003.1-2008
 specification.
-.Pp
-The obsolescent form of
-.Nm touch ,
-where a time format is specified as the first argument, is supported.
-When no
-.Fl d , r ,
-or
-.Fl t
-option is specified, there are at least two arguments, and the first
-argument is a string of digits either eight or ten characters in length,
-the first argument is interpreted as a time specification of the form
-.Dq mmddHHMM[yy] .
 .Sh HISTORY
 A
 .Nm
Index: touch.c
===
RCS file: /cvs/src/usr.bin/touch/touch.c,v
retrieving revision 1.25
diff -u -p -r1.25 touch.c
--- touch.c 9 Oct 2015 01:37:09 -   1.25
+++ touch.c 17 Apr 2017 19:14:12 -
@@ -99,20 +99,7 @@ main(int argc, char *argv[])
if (aflag == 0 && mflag == 0)
aflag = mflag = 1;
 
-   /*
-* If no -r or -t flag, at least two operands, the first of which
-* is an 8 or 10 digit number, use the obsolete time specification.
-*/
-   if (!timeset && argc > 1) {
-   (void)strtol(argv[0], , 10);
-   len = p - argv[0];
-   if (*p == '\0' && (len == 8 || len == 10)) {
-   timeset = 1;
-   stime_arg2(*argv++, len == 10, ts);
-   }
-   }
-
-   /* Otherwise use the current time of day. */
+   /* By default use the current time of day. */
if (!timeset)
ts[0].tv_nsec = ts[1].tv_nsec = UTIME_NOW;

Re: switch base tools from /dev/bpf0 to /dev/bpf

2017-04-18 Thread Alexander Bluhm

On Tue, Apr 18, 2017 at 10:20:03PM +0200, Martin Natano wrote:
> Now that /dev/bpf has been around for two releases, it should be safe to
> move the base tools to /dev/bpf. No need to worry about the upgrade path
> anymore.
> 
> Ok?

OK bluhm@

> 
> natano
> 
> 
> Index: lib/libpcap/pcap-bpf.c
> ===
> RCS file: /cvs/src/lib/libpcap/pcap-bpf.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 pcap-bpf.c
> --- lib/libpcap/pcap-bpf.c8 May 2016 08:20:50 -   1.34
> +++ lib/libpcap/pcap-bpf.c18 Apr 2017 18:29:27 -
> @@ -216,9 +216,9 @@ bpf_open(pcap_t *p)
>  {
>   int fd;
>  
> - fd = open("/dev/bpf0", O_RDWR);
> + fd = open("/dev/bpf", O_RDWR);
>   if (fd == -1 && errno == EACCES)
> - fd = open("/dev/bpf0", O_RDONLY);
> + fd = open("/dev/bpf", O_RDONLY);
>  
>   if (fd == -1) {
>   if (errno == EACCES)
> Index: sbin/dhclient/bpf.c
> ===
> RCS file: /cvs/src/sbin/dhclient/bpf.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 bpf.c
> --- sbin/dhclient/bpf.c   18 Apr 2017 13:59:09 -  1.49
> +++ sbin/dhclient/bpf.c   18 Apr 2017 18:30:47 -
> @@ -78,13 +78,13 @@ if_register_bpf(struct interface_info *i
>   struct ifreq ifr;
>   int sock;
>  
> - if ((sock = open("/dev/bpf0", O_RDWR | O_CLOEXEC)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR | O_CLOEXEC)) == -1)
>   fatal("Can't open bpf");
>  
>   /* Set the BPF device to point at this interface. */
>   strlcpy(ifr.ifr_name, ifi->name, IFNAMSIZ);
>   if (ioctl(sock, BIOCSETIF, ) < 0)
> - fatal("Can't attach interface %s to /dev/bpf0", ifi->name);
> + fatal("Can't attach interface %s to /dev/bpf", ifi->name);
>  
>   return (sock);
>  }
> Index: usr.sbin/arp/arp.c
> ===
> RCS file: /cvs/src/usr.sbin/arp/arp.c,v
> retrieving revision 1.78
> diff -u -p -r1.78 arp.c
> --- usr.sbin/arp/arp.c15 Apr 2017 11:50:24 -  1.78
> +++ usr.sbin/arp/arp.c18 Apr 2017 18:31:21 -
> @@ -821,7 +821,7 @@ wake(const char *ether_addr, const char 
>   char*pname = NULL;
>   int  bpf;
>  
> - if ((bpf = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((bpf = open("/dev/bpf", O_RDWR)) == -1)
>   err(1, "Failed to bind to bpf");
>  
>   if (iface == NULL) {
> Index: usr.sbin/dhcpd/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcpd/bpf.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 bpf.c
> --- usr.sbin/dhcpd/bpf.c  18 Apr 2017 13:59:09 -  1.18
> +++ usr.sbin/dhcpd/bpf.c  18 Apr 2017 18:31:37 -
> @@ -77,7 +77,7 @@ if_register_bpf(struct interface_info *i
>  {
>   int sock;
>  
> - if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR)) == -1)
>   fatal("Can't open bpf device");
>  
>   /* Set the BPF device to point at this interface. */
> Index: usr.sbin/dhcrelay/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay/bpf.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 bpf.c
> --- usr.sbin/dhcrelay/bpf.c   5 Apr 2017 14:40:56 -   1.18
> +++ usr.sbin/dhcrelay/bpf.c   18 Apr 2017 18:31:56 -
> @@ -72,7 +72,7 @@ if_register_bpf(struct interface_info *i
>   int sock;
>  
>   /* Open the BPF device */
> - if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR)) == -1)
>   fatal("Can't open bpf device");
>  
>   /* Set the BPF device to point at this interface. */
> Index: usr.sbin/dhcrelay6/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay6/bpf.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 bpf.c
> --- usr.sbin/dhcrelay6/bpf.c  17 Mar 2017 14:45:16 -  1.1
> +++ usr.sbin/dhcrelay6/bpf.c  18 Apr 2017 18:33:58 -
> @@ -75,7 +75,7 @@ if_register_bpf(struct interface_info *i
>   int sock;
>  
>   /* Open the BPF device */
> - if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
> + if ((sock = open("/dev/bpf", O_RDWR)) == -1)
>   fatal("Can't open bpf device");
>  
>   /* Set the BPF device to point at this interface. */
> Index: usr.sbin/hostapd/hostapd.c
> ===
> RCS file: /cvs/src/usr.sbin/hostapd/hostapd.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 hostapd.c
> --- usr.sbin/hostapd/hostapd.c28 May 2016 07:00:18 -  1.37
> +++ usr.sbin/hostapd/hostapd.c18 Apr 2017 18:32:14 -
> @@ -173,7 +173,7 @@ hostapd_bpf_open(u_int flags)
>   int fd = -1;
>   struct bpf_version bpv;
>  
> -

Re: httpd ranges are not liked by freshclam

2017-04-18 Thread trondd

On Tue, April 18, 2017 3:46 pm, Reyk Floeter wrote:
>
>> Am 18.04.2017 um 20:53 schrieb trondd :
>>
>> I have an OpenBSD httpd(8) web server hosting security/clamav main.cvd
>> and
>> daily.cvd files.  Upon upgrading to 6.1, freshclam can no longer
>> successfully fetch the cvd files.
>>
>> Freshclam does a request for the first 512 bytes of the files to check
>> the
>> dates in their header.  Then pulls the rest of the file if needed.  It
>> looks like it pulls the *whole* file again.  It doesn't pick up where it
>> left off.
>>
>> With httpd from 6.0, fully patched, this was working fine.  Whith 6.1,
>> freshclam would request the 512 chunk, then timeout with "nonblock_recv:
>> recv timing out (30 secs)".
>>
>> Knowing there were a couple of changes to ranges in httpd, I started
>> rolling things back.  I took out the pipelining fix:
>> http://marc.info/?l=openbsd-cvs=148607400902939=2
>>
>> Which didn't help.  Then I also took out the range rewrite:
>> http://marc.info/?l=openbsd-cvs=148587359420912=2
>>
>> And bingo.  Freshclam happily pulled it's now much out of date daily
>> database. :)
>>
>> I don't know if freshclam is doing something wacky here or if it's
>> httpd.
>> It does return the requested byte range, and I was able to pull a range
>> with curl as well.  I don't know another test case for this off hand.
>>
>
> Do you have any more details like request/response HTTP headers with old
> and new code?
>
> Reyk
>

Yes.  Hopefully these attach properly.  Only have access to web mail from
here so scream at me if all you get is garbage and I can resend properly
later.

ASCII output from the tcpdump showing success and failure cases.  I have
the full binary pcaps if needed.  Comparing quickly, I see 6.1 sends the
Partial Content response header in a seperate packet from the content. 
Previous code didn't do that.

Tim.Apr 18 14:46:43.193474 00:50:56:a2:e3:59 00:50:56:53:53:06 0800 74: 
172.25.87.253.36732 > 172.25.87.91.80: S [tcp sum ok] 3129109532:3129109532(0) 
win 29200  (DF) (ttl 64, 
id 24030, len 60)
.PVSS..PV..Y..E..<].@.@..R..W...W[.|.P..l...r.12.
..1.
Apr 18 14:46:43.375068 00:50:56:53:53:06 00:50:56:a2:e3:59 0800 78: 
172.25.87.91.80 > 172.25.87.253.36732: S [tcp sum ok] 4257186703:4257186703(0) 
ack 3129109533 win 16384  (ttl 64, id 51915, len 64)
.PV..Y.PVSS...E..@@..a..W[..W..P.|..l...@..6.
..C...1.
Apr 18 14:46:43.375489 00:50:56:a2:e3:59 00:50:56:53:53:06 0800 66: 
172.25.87.253.36732 > 172.25.87.91.80: . [tcp sum ok] 1:1(0) ack 1 win 229 
 (DF) (ttl 64, id 24031, len 52)
.PVSS..PV..Y..E..4].@.@..Y..W...W[.|.P..l..8.
..2...C.
Apr 18 14:46:43.375506 00:50:56:a2:e3:59 00:50:56:53:53:06 0800 285: 
172.25.87.253.36732 > 172.25.87.91.80: P [tcp sum ok] 1:220(219) ack 1 win 229 
 (DF) (ttl 64, id 24032, len 271)
.PVSS..PV..Y..E...].@.@..}..W...W[.|.P..l.wy.
..2...C.GET /main.cld HTTP/1.0
Host: obsd-build.llan.ll.mit.edu
User-Agent: ClamAV/0.99.2 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
Connection: close
Range: bytes=0-511
If-Modified-Since: Wed, 16 Mar 2016 23:17:06 GMT


Apr 18 14:46:43.376135 00:50:56:53:53:06 00:50:56:a2:e3:59 0800 644: 
172.25.87.91.80 > 172.25.87.253.36732: P [bad tcp cksum 9f4! -> d979] 
1:579(578) ack 220 win 271  (ttl 64, 
id 54869, len 630)
.PV..Y.PVSS...E..v.U..@.W[..W..P.|..l.  ..
..C...2.HTTP/1.0 404 Not Found
Date: Tue, 18 Apr 2017 18:46:43 GMT
Server: OpenBSD httpd
Connection: close
Content-Type: text/html
Content-Length: 427





404 Not Found



404 Not Found

OpenBSD httpd



Apr 18 14:46:43.376185 00:50:56:53:53:06 00:50:56:a2:e3:59 0800 66: 
172.25.87.91.80 > 172.25.87.253.36732: F [bad tcp cksum 7b2! -> 14f0] 
579:579(0) ack 220 win 271  (ttl 64, 
id 45714, len 52)
.PV..Y.PVSS...E..4@.W[..W..P.|..l
..C...2.
Apr 18 14:46:43.376729 00:50:56:a2:e3:59 00:50:56:53:53:06 0800 66: 
172.25.87.253.36732 > 172.25.87.91.80: . [tcp sum ok] 220:220(0) ack 579 win 
238  (DF) (ttl 64, id 24033, len 52)
.PVSS..PV..Y..E..4].@.@..W..W...W[.|.P..l
..2...C.
Apr 18 14:46:43.376738 00:50:56:a2:e3:59 00:50:56:53:53:06 0800 66: 
172.25.87.253.36732 > 172.25.87.91.80: F [tcp sum ok] 220:220(0) ack 580 win 
238  (DF) (ttl 64, id 24034, len 52)
.PVSS..PV..Y..E..4].@.@..V..W...W[.|.P..l
..2...C.
Apr 18 14:46:43.376743 00:50:56:a2:e3:59 00:50:56:53:53:06 0800 74: 
172.25.87.253.36734 > 172.25.87.91.80: S [tcp sum ok] 183614203:183614203(0) 
win 29200  (DF) (ttl 64, 
id 34901, len 60)

switch base tools from /dev/bpf0 to /dev/bpf

2017-04-18 Thread Martin Natano

Now that /dev/bpf has been around for two releases, it should be safe to
move the base tools to /dev/bpf. No need to worry about the upgrade path
anymore.

Ok?

natano


Index: lib/libpcap/pcap-bpf.c
===
RCS file: /cvs/src/lib/libpcap/pcap-bpf.c,v
retrieving revision 1.34
diff -u -p -r1.34 pcap-bpf.c
--- lib/libpcap/pcap-bpf.c  8 May 2016 08:20:50 -   1.34
+++ lib/libpcap/pcap-bpf.c  18 Apr 2017 18:29:27 -
@@ -216,9 +216,9 @@ bpf_open(pcap_t *p)
 {
int fd;
 
-   fd = open("/dev/bpf0", O_RDWR);
+   fd = open("/dev/bpf", O_RDWR);
if (fd == -1 && errno == EACCES)
-   fd = open("/dev/bpf0", O_RDONLY);
+   fd = open("/dev/bpf", O_RDONLY);
 
if (fd == -1) {
if (errno == EACCES)
Index: sbin/dhclient/bpf.c
===
RCS file: /cvs/src/sbin/dhclient/bpf.c,v
retrieving revision 1.49
diff -u -p -r1.49 bpf.c
--- sbin/dhclient/bpf.c 18 Apr 2017 13:59:09 -  1.49
+++ sbin/dhclient/bpf.c 18 Apr 2017 18:30:47 -
@@ -78,13 +78,13 @@ if_register_bpf(struct interface_info *i
struct ifreq ifr;
int sock;
 
-   if ((sock = open("/dev/bpf0", O_RDWR | O_CLOEXEC)) == -1)
+   if ((sock = open("/dev/bpf", O_RDWR | O_CLOEXEC)) == -1)
fatal("Can't open bpf");
 
/* Set the BPF device to point at this interface. */
strlcpy(ifr.ifr_name, ifi->name, IFNAMSIZ);
if (ioctl(sock, BIOCSETIF, ) < 0)
-   fatal("Can't attach interface %s to /dev/bpf0", ifi->name);
+   fatal("Can't attach interface %s to /dev/bpf", ifi->name);
 
return (sock);
 }
Index: usr.sbin/arp/arp.c
===
RCS file: /cvs/src/usr.sbin/arp/arp.c,v
retrieving revision 1.78
diff -u -p -r1.78 arp.c
--- usr.sbin/arp/arp.c  15 Apr 2017 11:50:24 -  1.78
+++ usr.sbin/arp/arp.c  18 Apr 2017 18:31:21 -
@@ -821,7 +821,7 @@ wake(const char *ether_addr, const char 
char*pname = NULL;
int  bpf;
 
-   if ((bpf = open("/dev/bpf0", O_RDWR)) == -1)
+   if ((bpf = open("/dev/bpf", O_RDWR)) == -1)
err(1, "Failed to bind to bpf");
 
if (iface == NULL) {
Index: usr.sbin/dhcpd/bpf.c
===
RCS file: /cvs/src/usr.sbin/dhcpd/bpf.c,v
retrieving revision 1.18
diff -u -p -r1.18 bpf.c
--- usr.sbin/dhcpd/bpf.c18 Apr 2017 13:59:09 -  1.18
+++ usr.sbin/dhcpd/bpf.c18 Apr 2017 18:31:37 -
@@ -77,7 +77,7 @@ if_register_bpf(struct interface_info *i
 {
int sock;
 
-   if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
+   if ((sock = open("/dev/bpf", O_RDWR)) == -1)
fatal("Can't open bpf device");
 
/* Set the BPF device to point at this interface. */
Index: usr.sbin/dhcrelay/bpf.c
===
RCS file: /cvs/src/usr.sbin/dhcrelay/bpf.c,v
retrieving revision 1.18
diff -u -p -r1.18 bpf.c
--- usr.sbin/dhcrelay/bpf.c 5 Apr 2017 14:40:56 -   1.18
+++ usr.sbin/dhcrelay/bpf.c 18 Apr 2017 18:31:56 -
@@ -72,7 +72,7 @@ if_register_bpf(struct interface_info *i
int sock;
 
/* Open the BPF device */
-   if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
+   if ((sock = open("/dev/bpf", O_RDWR)) == -1)
fatal("Can't open bpf device");
 
/* Set the BPF device to point at this interface. */
Index: usr.sbin/dhcrelay6/bpf.c
===
RCS file: /cvs/src/usr.sbin/dhcrelay6/bpf.c,v
retrieving revision 1.1
diff -u -p -r1.1 bpf.c
--- usr.sbin/dhcrelay6/bpf.c17 Mar 2017 14:45:16 -  1.1
+++ usr.sbin/dhcrelay6/bpf.c18 Apr 2017 18:33:58 -
@@ -75,7 +75,7 @@ if_register_bpf(struct interface_info *i
int sock;
 
/* Open the BPF device */
-   if ((sock = open("/dev/bpf0", O_RDWR)) == -1)
+   if ((sock = open("/dev/bpf", O_RDWR)) == -1)
fatal("Can't open bpf device");
 
/* Set the BPF device to point at this interface. */
Index: usr.sbin/hostapd/hostapd.c
===
RCS file: /cvs/src/usr.sbin/hostapd/hostapd.c,v
retrieving revision 1.37
diff -u -p -r1.37 hostapd.c
--- usr.sbin/hostapd/hostapd.c  28 May 2016 07:00:18 -  1.37
+++ usr.sbin/hostapd/hostapd.c  18 Apr 2017 18:32:14 -
@@ -173,7 +173,7 @@ hostapd_bpf_open(u_int flags)
int fd = -1;
struct bpf_version bpv;
 
-   if ((fd = open("/dev/bpf0", flags)) == -1) {
+   if ((fd = open("/dev/bpf", flags)) == -1) {
hostapd_fatal("unable to open BPF device: %s\n",
strerror(errno));
}
Index: usr.sbin/mopd/common/pf.c

Re: httpd ranges are not liked by freshclam

2017-04-18 Thread Reyk Floeter


> Am 18.04.2017 um 20:53 schrieb trondd :
> 
> I have an OpenBSD httpd(8) web server hosting security/clamav main.cvd and
> daily.cvd files.  Upon upgrading to 6.1, freshclam can no longer
> successfully fetch the cvd files.
> 
> Freshclam does a request for the first 512 bytes of the files to check the
> dates in their header.  Then pulls the rest of the file if needed.  It
> looks like it pulls the *whole* file again.  It doesn't pick up where it
> left off.
> 
> With httpd from 6.0, fully patched, this was working fine.  Whith 6.1,
> freshclam would request the 512 chunk, then timeout with "nonblock_recv:
> recv timing out (30 secs)".
> 
> Knowing there were a couple of changes to ranges in httpd, I started
> rolling things back.  I took out the pipelining fix:
> http://marc.info/?l=openbsd-cvs=148607400902939=2
> 
> Which didn't help.  Then I also took out the range rewrite:
> http://marc.info/?l=openbsd-cvs=148587359420912=2
> 
> And bingo.  Freshclam happily pulled it's now much out of date daily
> database. :)
> 
> I don't know if freshclam is doing something wacky here or if it's httpd. 
> It does return the requested byte range, and I was able to pull a range
> with curl as well.  I don't know another test case for this off hand.
> 

Do you have any more details like request/response HTTP headers with old and 
new code?

Reyk

httpd ranges are not liked by freshclam

2017-04-18 Thread trondd

I have an OpenBSD httpd(8) web server hosting security/clamav main.cvd and
daily.cvd files.  Upon upgrading to 6.1, freshclam can no longer
successfully fetch the cvd files.

Freshclam does a request for the first 512 bytes of the files to check the
dates in their header.  Then pulls the rest of the file if needed.  It
looks like it pulls the *whole* file again.  It doesn't pick up where it
left off.

With httpd from 6.0, fully patched, this was working fine.  Whith 6.1,
freshclam would request the 512 chunk, then timeout with "nonblock_recv:
recv timing out (30 secs)".

Knowing there were a couple of changes to ranges in httpd, I started
rolling things back.  I took out the pipelining fix:
http://marc.info/?l=openbsd-cvs=148607400902939=2

Which didn't help.  Then I also took out the range rewrite:
http://marc.info/?l=openbsd-cvs=148587359420912=2

And bingo.  Freshclam happily pulled it's now much out of date daily
database. :)

I don't know if freshclam is doing something wacky here or if it's httpd. 
It does return the requested byte range, and I was able to pull a range
with curl as well.  I don't know another test case for this off hand.

Tim.

Re: ./usr/include/g++/std removed from distrib/sets/lists/

2017-04-18 Thread Christian Weisgerber

On 2017-04-18, Sebastien Marie  wrote:

> I saw that with the split of comp lists to gcc/clang parts,
> ./usr/include/g++/std entry was removed from comp/mi, and not added
> back in comp/gcc.*.

That was on purpose.  It was also removed from etc/mtree/4.4BSD.dist.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: ./usr/include/g++/std removed from distrib/sets/lists/

2017-04-18 Thread Mark Kettenis

> Date: Tue, 18 Apr 2017 11:28:59 +0200
> From: Sebastien Marie 
> 
> Hi,
> 
> I saw that with the split of comp lists to gcc/clang parts,
> ./usr/include/g++/std entry was removed from comp/mi, and not added
> back in comp/gcc.*.
> 
> As the entry is an empty directory, it could be a volontary removal, but
> it could also be an omission.
> 
> Please note I dunno of the usage of it in base or ports.
> 
> Below is a diff to put it back in case it is important.

The removal was intentional.  There is no purpose for an empty
directory like this.

vi unused variables

use strtonum to parse the argument to -j in make

Re: cksum not working with both -a and -C flags together

Re: switch base tools from /dev/bpf0 to /dev/bpf

touch: remove obsolete time specification

Re: switch base tools from /dev/bpf0 to /dev/bpf

Re: httpd ranges are not liked by freshclam

switch base tools from /dev/bpf0 to /dev/bpf

Re: httpd ranges are not liked by freshclam

httpd ranges are not liked by freshclam

Re: ./usr/include/g++/std removed from distrib/sets/lists/

Re: ./usr/include/g++/std removed from distrib/sets/lists/

12 matches

Site Navigation

Mail list logo

Footer information