Re: ksh: bug with quoted parameter expansion
On Wed, Jan 24, 2018 at 04:15:24PM +0100, m...@josuah.net wrote:
> I found a bug in ksh's parameter expansion on an edge case:
>
> true $(true "${USER#'"'}")
>
> /home/sh[4]: no closing quote
>
> The problem seems to occurs when all of these conditions are present:
>
> 1. On ${var#pattern} or ${var%pattern} parameter expansion
> 2. When the pattern contains a singly quoted double quote: '"'
> 3. While expansion occurs withing $(...), (but not `...`)
> 4. While the expansion is quoted: "${var#pattern}".
>
> true can be replaced by other commands or var=...
> if '"' gets replaced by \", the issue disappear
>
> The bin/ksh/lex.c seems to use a big switch+goto table with one label
> per grammar context. Maybe by jumping from context to context in a
> specific pattern like above is producing the issue.
>
> I did try to figure out where, but I lack time for now.
>
> I hope the problem does not come from my way to test it and that it
> have not been fixed.
>
> $ uname -a # also tested with /bin/ksh
> OpenBSD t470s 6.2 GENERIC.MP#134 amd64
>
> $ cvs co bin/ksh/; cd bin/ksh; make
> [...]
>
> $ ./ksh ~/sh
> /home/sh[4]: no closing quote
For the record, probably related to this:
$ pwd
/usr/src/bin/ksh
$ sed -n 474,479p lex.c
case SCSPAREN: /* $( .. ) */
/* todo: deal with $(...) quoting properly
* kludge to partly fake quoting inside $(..): doesn't
* really work because nested $(..) or ${..} inside
* double quotes aren't dealt with.
*/
Re: tcpdump(8) USB support
On 25/01/18(Thu) 14:55, Bryan Steele wrote:
> On Thu, Jan 25, 2018 at 07:00:43PM +0100, Martin Pieuchot wrote:
> > Diff below adds support for dumping USB transfers via bpf(4), including
> > the tcpdump(8) bits.
> >
> > I'd like special review of the new bpf_tap(9) function I'm introducing:
> > - is there a way to pass the header as a different buffer?
> > - is _bpf_tap() the best way to share code with bpf_mtap(9)?
> >
> > Concerning the kernel/userland interface, in looked at the existing
> > DLT_USB*, namely:
> > - DLT_USB_FREEBSD (a.k.a DLT_USB)
> > - DLT_USB_LINUX
> > - DLT_USB_LINUX_MMAPPED
> > - DLT_USBPCAP
> > - DLT_USB_DARWIN
> >
> > I decided to follow DLT_USBPCAP which is the most generic one beside
> > being originated from Windows. Wireshark has some support for it
> > (currently untested) so it is a nice fit.
> > The current implementation is small and I'd like to continue developing
> > it in tree.
> >
> > Here's an excerpt of what's happening when plugging a USB key:
> >
> > # tcpdump -xXi usb0
> > tcpdump: listening on usb0, link-type USBPCAP
> > [...]
> > 18:56:26.261293 bus 0 > addr 5: ep0 ctrl 0
> >
> > 18:56:26.261409 bus 0 < addr 5: ep0 ctrl 20
> >: 1403 5300 6c00 6900 6d00 2000 4c00 6900 ..S.l.i.m. .L.i.
> >0010: 6e00 6500n.e.
> >
> > 18:56:26.261418 bus 0 > addr 5: ep0 ctrl 0
> >
> > 18:56:26.261547 bus 0 < addr 5: ep0 ctrl 2
> >: 2203 ".
> >
> > 18:56:26.261552 bus 0 > addr 5: ep0 ctrl 0
> >
> > 18:56:26.261746 bus 0 < addr 5: ep0 ctrl 34
> >: 2203 3000 3700 3100 3000 3500 3900 3600 ".0.7.1.0.5.9.6.
> >0010: 3100 4100 3400 3800 4400 3600 4100 3900 1.A.4.8.D.6.A.9.
> >0020: 3500 5.
> >
> > 18:56:26.261761 bus 0 > addr 5: ep2 bulk 31
> >: 5553 4243 4c00 0600 USBCL...
> >0010: 00...
> >
> > Ok to put it in tree?
>
>
> This looks really cool, hopefully might be useful for diagnosing the
> constantly reattaching issues I've been seeing with USB mouses..
>
> Looks like you forgot to add print-usbpcap.c for tcpdump.
Indeed, full diff below.
Index: sys/net/bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.166
diff -u -p -r1.166 bpf.c
--- sys/net/bpf.c 24 Jan 2018 00:25:17 - 1.166
+++ sys/net/bpf.c 25 Jan 2018 14:02:58 -
@@ -1226,35 +1226,24 @@ bpf_mcopy(const void *src_arg, void *dst
}
}
-/*
- * like bpf_mtap, but copy fn can be given. used by various bpf_mtap*
- */
int
-_bpf_mtap(caddr_t arg, const struct mbuf *m, u_int direction,
-void (*cpfn)(const void *, void *, size_t))
+_bpf_tap(caddr_t arg, u_char *pkt, size_t pktlen, u_int direction,
+void (*cpfn)(const void *, void *, size_t), int mfilter)
{
struct bpf_if *bp = (struct bpf_if *)arg;
struct srp_ref sr;
struct bpf_d *d;
- size_t pktlen, slen;
- const struct mbuf *m0;
+ size_t slen;
struct timeval tv;
int gottime = 0;
int drop = 0;
- if (m == NULL)
+ if (pkt == NULL)
return (0);
- if (cpfn == NULL)
- cpfn = bpf_mcopy;
-
if (bp == NULL)
return (0);
- pktlen = 0;
- for (m0 = m; m0 != NULL; m0 = m0->m_next)
- pktlen += m0->m_len;
-
SRPL_FOREACH(d, &sr, &bp->bif_dlist, bd_next) {
atomic_inc_long(&d->bd_rcount);
@@ -1268,7 +1257,11 @@ _bpf_mtap(caddr_t arg, const struct mbuf
bf = srp_enter(&bsr, &d->bd_rfilter);
if (bf != NULL)
fcode = bf->bf_insns;
- slen = bpf_mfilter(fcode, m, pktlen);
+ if (mfilter) {
+ const struct mbuf *m = (const struct mbuf *)pkt;
+ slen = bpf_mfilter(fcode, m, pktlen);
+ } else
+ slen = bpf_filter(fcode, pkt, pktlen, pktlen);
srp_leave(&bsr);
}
@@ -1277,8 +1270,7 @@ _bpf_mtap(caddr_t arg, const struct mbuf
microtime(&tv);
mtx_enter(&d->bd_mtx);
- bpf_catchpacket(d, (u_char *)m, pktlen, slen, cpfn,
- &tv);
+ bpf_catchpacket(d, pkt, pktlen, slen, cpfn, &tv);
mtx_leave(&d->bd_mtx);
if (d->bd_fildrop)
@@ -1290,6 +1282,35 @@ _bpf_mtap(caddr_t arg, const struct mbuf
return (drop);
}
+int
+bpf_tap(caddr_t arg, u_char *pkt, size_t pktlen, u_int direction)
+{
+
sleep(1): support longer naps
Hi,
This increases the range for sleep(1) from 100 million seconds up to
9223372036854775807.
POSIX.1-2001 added a stipulation (which POSIX.1-2008 retains) that sleep(1)
support inputs of at least 2147483647 seconds. This patch fulfills that
requirement and brings us into alignment with POSIX.1-2008, which we already
claim anyway.
FreeBSD supports up to INT_MAX and no further. GNU sleep keeps seconds
in a double, so they too ought to support at least this minimum... but
they do something weird that I haven't quite figured out yet, so I'm
actually not sure what they support.
But anyway I don't see a reason to cap user input (as FreeBSD does) at the
positive 32-bit limit when we already carefully parse up to the limit of
time_t and check for overflow. If the end user wants to sleep that long,
we can just let them. I have a subsequent patch that tells the user that
their input is too large in the event of overflow. Currently we just exit
with EINVAL and say nothing, which is both unusual and unhelpful.
Using a loop to extend the input range of the utility seems a bit unclean,
but this case alone certainly doesn't warrant extending the input range for
nanosleep(2).
I'm not sure whether the larger range is actually an extension to the
standard, and if so whether we need to mention it in the manpage, but
I've included a diff here anyway just in case. If you have ideas about
the wording I'd love to hear them.
Thoughts? ok?
--
Scott Cheloha
Index: bin/sleep/sleep.1
===
RCS file: /cvs/src/bin/sleep/sleep.1,v
retrieving revision 1.22
diff -u -p -r1.22 sleep.1
--- bin/sleep/sleep.1 16 Aug 2016 18:51:25 - 1.22
+++ bin/sleep/sleep.1 26 Jan 2018 03:22:08 -
@@ -108,8 +108,10 @@ utility is compliant with the
.St -p1003.1-2008
specification.
.Pp
-The handling of fractional arguments is provided as an extension to that
-specification.
+The handling of fractional arguments and the support for values of
+.Ar seconds
+greater than 2147483647
+are extensions to that specification.
.Sh HISTORY
A
.Nm
Index: bin/sleep/sleep.c
===
RCS file: /cvs/src/bin/sleep/sleep.c,v
retrieving revision 1.24
diff -u -p -r1.24 sleep.c
--- bin/sleep/sleep.c 11 Oct 2015 20:17:49 - 1.24
+++ bin/sleep/sleep.c 26 Jan 2018 03:22:08 -
@@ -102,12 +102,24 @@ main(int argc, char *argv[])
}
}
- rqtp.tv_sec = secs;
- rqtp.tv_nsec = nsecs;
-
- if ((secs > 0) || (nsecs > 0))
+ while (secs > 0 || nsecs > 0) {
+ /*
+* nanosleep(2) supports a maximum of 100 million
+* seconds, so we break the nap up into multiple
+* calls if we have more than that.
+*/
+ if (secs > 1) {
+ rqtp.tv_sec = 1;
+ rqtp.tv_nsec = 0;
+ } else {
+ rqtp.tv_sec = secs;
+ rqtp.tv_nsec = nsecs;
+ }
if (nanosleep(&rqtp, NULL))
err(1, NULL);
+ secs -= rqtp.tv_sec;
+ nsecs -= rqtp.tv_nsec;
+ }
return (0);
}
efiboot: fix TFTP reading of 0-size files
Fix TFTP reading of zero-size files in efiboot:
The AllocatePages EFI call returns an error when the allocation
size is 0. Skip allocating memory and actually transferring the
file when it is empty.
Properly return the number of unread bytes so that a read() of n
bytes does not return n if no bytes were read.
While here, disallow lseek() beyond the TFTP file buffer for SEEK_CUR
as we already do for SEEK_SET.
Tested on aarch64. Can somebody test this on amd64?
OK?
Index: arch/amd64/stand/efiboot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/conf.c,v
retrieving revision 1.12
diff -u -p -r1.12 conf.c
--- arch/amd64/stand/efiboot/conf.c 25 Nov 2017 19:02:07 - 1.12
+++ arch/amd64/stand/efiboot/conf.c 25 Jan 2018 22:39:37 -
@@ -39,7 +39,7 @@
#include "efidev.h"
#include "efipxe.h"
-const char version[] = "3.36";
+const char version[] = "3.37";
#ifdef EFI_DEBUG
intdebug = 0;
Index: arch/amd64/stand/efiboot/efipxe.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efipxe.c,v
retrieving revision 1.2
diff -u -p -r1.2 efipxe.c
--- arch/amd64/stand/efiboot/efipxe.c 21 Jan 2018 21:37:01 - 1.2
+++ arch/amd64/stand/efiboot/efipxe.c 25 Jan 2018 22:46:15 -
@@ -143,6 +143,9 @@ tftp_open(char *path, struct open_file *
}
tftpfile->inbufsize = size;
+ if (tftpfile->inbufsize == 0)
+ goto out;
+
status = EFI_CALL(BS->AllocatePages, AllocateAnyPages, EfiLoaderData,
EFI_SIZE_TO_PAGES(tftpfile->inbufsize), &addr);
if (status != EFI_SUCCESS) {
@@ -157,7 +160,7 @@ tftp_open(char *path, struct open_file *
free(tftpfile, sizeof(*tftpfile));
return ENXIO;
}
-
+out:
f->f_fsdata = tftpfile;
return 0;
}
@@ -167,8 +170,9 @@ tftp_close(struct open_file *f)
{
struct tftp_handle *tftpfile = f->f_fsdata;
- EFI_CALL(BS->FreePages, (paddr_t)tftpfile->inbuf,
- EFI_SIZE_TO_PAGES(tftpfile->inbufsize));
+ if (tftpfile->inbuf != NULL)
+ EFI_CALL(BS->FreePages, (paddr_t)tftpfile->inbuf,
+ EFI_SIZE_TO_PAGES(tftpfile->inbufsize));
free(tftpfile, sizeof(*tftpfile));
return 0;
}
@@ -184,15 +188,11 @@ tftp_read(struct open_file *f, void *add
else
toread = size;
- if (toread == 0) {
- if (resid != NULL)
- *resid = 0;
- return (0);
+ if (toread != 0) {
+ memcpy(addr, tftpfile->inbuf + tftpfile->inbufoff, toread);
+ tftpfile->inbufoff += toread;
}
- memcpy(addr, tftpfile->inbuf + tftpfile->inbufoff, toread);
- tftpfile->inbufoff += toread;
-
if (resid != NULL)
*resid = size - toread;
return 0;
@@ -211,7 +211,8 @@ tftp_seek(struct open_file *f, off_t off
switch(where) {
case SEEK_CUR:
- if (tftpfile->inbufoff + offset < 0) {
+ if (tftpfile->inbufoff + offset < 0 ||
+ tftpfile->inbufoff + offset > tftpfile->inbufsize) {
errno = EOFFSET;
break;
}
Index: arch/arm64/stand/efiboot/conf.c
===
RCS file: /cvs/src/sys/arch/arm64/stand/efiboot/conf.c,v
retrieving revision 1.10
diff -u -p -r1.10 conf.c
--- arch/arm64/stand/efiboot/conf.c 21 Jan 2018 21:35:34 - 1.10
+++ arch/arm64/stand/efiboot/conf.c 25 Jan 2018 20:42:46 -
@@ -36,7 +36,7 @@
#include "efidev.h"
#include "efipxe.h"
-const char version[] = "0.9";
+const char version[] = "0.10";
intdebug = 0;
struct fs_ops file_system[] = {
Index: arch/arm64/stand/efiboot/efipxe.c
===
RCS file: /cvs/src/sys/arch/arm64/stand/efiboot/efipxe.c,v
retrieving revision 1.1
diff -u -p -r1.1 efipxe.c
--- arch/arm64/stand/efiboot/efipxe.c 21 Jan 2018 21:35:34 - 1.1
+++ arch/arm64/stand/efiboot/efipxe.c 25 Jan 2018 22:45:08 -
@@ -139,6 +139,9 @@ tftp_open(char *path, struct open_file *
}
tftpfile->inbufsize = size;
+ if (tftpfile->inbufsize == 0)
+ goto out;
+
status = EFI_CALL(BS->AllocatePages, AllocateAnyPages, EfiLoaderData,
EFI_SIZE_TO_PAGES(tftpfile->inbufsize), &addr);
if (status != EFI_SUCCESS) {
@@ -153,7 +156,7 @@ tftp_open(char *path, struct open_file *
free(tftpfile, sizeof(*tftpfile));
return ENXIO;
}
-
+out:
f->f_fsdata = tftpfile;
return 0;
}
@@ -163,8 +166,9 @@ tftp_close(struct open_file *f)
{
struct tftp_handle *tftpfile = f->f_fsdata;
- EFI_CALL(BS->FreePages, (paddr_t)tftpfile->inbuf,
- EFI_SIZE_T
Re: tftpd: transfer size for random.seed
On Thu, Jan 25 2018, Christian Weisgerber wrote: > tftpd needs to handle the transfer size option when faking up > /etc/random.seed. > > Without this, clients that query the size receive 0 as response, > preventing efiboot from loading random.seed. > > ok? Looks correct, ok jca@ > Index: tftpd.c > === > RCS file: /cvs/src/usr.sbin/tftpd/tftpd.c,v > retrieving revision 1.40 > diff -u -p -r1.40 tftpd.c > --- tftpd.c 7 Nov 2017 14:15:38 - 1.40 > +++ tftpd.c 25 Jan 2018 12:49:39 - > @@ -973,6 +973,8 @@ validate_access(struct tftp_client *clie > > buf = client->buf + sizeof(client->buf) - 512; > arc4random_buf(buf, 512); > + if (options != NULL && options[OPT_TSIZE].o_request) > + options[OPT_TSIZE].o_reply = 512; > client->file = fmemopen(buf, 512, "r"); > if (client->file == NULL) > return (errno + 100); -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: tcpdump(8) USB support
On Thu, Jan 25, 2018 at 07:00:43PM +0100, Martin Pieuchot wrote:
> Diff below adds support for dumping USB transfers via bpf(4), including
> the tcpdump(8) bits.
>
> I'd like special review of the new bpf_tap(9) function I'm introducing:
> - is there a way to pass the header as a different buffer?
> - is _bpf_tap() the best way to share code with bpf_mtap(9)?
>
> Concerning the kernel/userland interface, in looked at the existing
> DLT_USB*, namely:
> - DLT_USB_FREEBSD (a.k.a DLT_USB)
> - DLT_USB_LINUX
> - DLT_USB_LINUX_MMAPPED
> - DLT_USBPCAP
> - DLT_USB_DARWIN
>
> I decided to follow DLT_USBPCAP which is the most generic one beside
> being originated from Windows. Wireshark has some support for it
> (currently untested) so it is a nice fit.
> The current implementation is small and I'd like to continue developing
> it in tree.
>
> Here's an excerpt of what's happening when plugging a USB key:
>
> # tcpdump -xXi usb0
> tcpdump: listening on usb0, link-type USBPCAP
> [...]
> 18:56:26.261293 bus 0 > addr 5: ep0 ctrl 0
>
> 18:56:26.261409 bus 0 < addr 5: ep0 ctrl 20
>: 1403 5300 6c00 6900 6d00 2000 4c00 6900 ..S.l.i.m. .L.i.
>0010: 6e00 6500n.e.
>
> 18:56:26.261418 bus 0 > addr 5: ep0 ctrl 0
>
> 18:56:26.261547 bus 0 < addr 5: ep0 ctrl 2
>: 2203 ".
>
> 18:56:26.261552 bus 0 > addr 5: ep0 ctrl 0
>
> 18:56:26.261746 bus 0 < addr 5: ep0 ctrl 34
>: 2203 3000 3700 3100 3000 3500 3900 3600 ".0.7.1.0.5.9.6.
>0010: 3100 4100 3400 3800 4400 3600 4100 3900 1.A.4.8.D.6.A.9.
>0020: 3500 5.
>
> 18:56:26.261761 bus 0 > addr 5: ep2 bulk 31
>: 5553 4243 4c00 0600 USBCL...
>0010: 00...
>
> Ok to put it in tree?
This looks really cool, hopefully might be useful for diagnosing the
constantly reattaching issues I've been seeing with USB mouses..
Looks like you forgot to add print-usbpcap.c for tcpdump.
-Bryan.
> Index: sys/net/bpf.c
> ===
> RCS file: /cvs/src/sys/net/bpf.c,v
> retrieving revision 1.166
> diff -u -p -r1.166 bpf.c
> --- sys/net/bpf.c 24 Jan 2018 00:25:17 - 1.166
> +++ sys/net/bpf.c 25 Jan 2018 14:02:58 -
> @@ -1226,35 +1226,24 @@ bpf_mcopy(const void *src_arg, void *dst
> }
> }
>
> -/*
> - * like bpf_mtap, but copy fn can be given. used by various bpf_mtap*
> - */
> int
> -_bpf_mtap(caddr_t arg, const struct mbuf *m, u_int direction,
> -void (*cpfn)(const void *, void *, size_t))
> +_bpf_tap(caddr_t arg, u_char *pkt, size_t pktlen, u_int direction,
> +void (*cpfn)(const void *, void *, size_t), int mfilter)
> {
> struct bpf_if *bp = (struct bpf_if *)arg;
> struct srp_ref sr;
> struct bpf_d *d;
> - size_t pktlen, slen;
> - const struct mbuf *m0;
> + size_t slen;
> struct timeval tv;
> int gottime = 0;
> int drop = 0;
>
> - if (m == NULL)
> + if (pkt == NULL)
> return (0);
>
> - if (cpfn == NULL)
> - cpfn = bpf_mcopy;
> -
> if (bp == NULL)
> return (0);
>
> - pktlen = 0;
> - for (m0 = m; m0 != NULL; m0 = m0->m_next)
> - pktlen += m0->m_len;
> -
> SRPL_FOREACH(d, &sr, &bp->bif_dlist, bd_next) {
> atomic_inc_long(&d->bd_rcount);
>
> @@ -1268,7 +1257,11 @@ _bpf_mtap(caddr_t arg, const struct mbuf
> bf = srp_enter(&bsr, &d->bd_rfilter);
> if (bf != NULL)
> fcode = bf->bf_insns;
> - slen = bpf_mfilter(fcode, m, pktlen);
> + if (mfilter) {
> + const struct mbuf *m = (const struct mbuf *)pkt;
> + slen = bpf_mfilter(fcode, m, pktlen);
> + } else
> + slen = bpf_filter(fcode, pkt, pktlen, pktlen);
> srp_leave(&bsr);
> }
>
> @@ -1277,8 +1270,7 @@ _bpf_mtap(caddr_t arg, const struct mbuf
> microtime(&tv);
>
> mtx_enter(&d->bd_mtx);
> - bpf_catchpacket(d, (u_char *)m, pktlen, slen, cpfn,
> - &tv);
> + bpf_catchpacket(d, pkt, pktlen, slen, cpfn, &tv);
> mtx_leave(&d->bd_mtx);
>
> if (d->bd_fildrop)
> @@ -1290,6 +1282,35 @@ _bpf_mtap(caddr_t arg, const struct mbuf
> return (drop);
> }
>
> +int
> +bpf_tap(caddr_t arg, u_char *pkt, size_t pktlen, u_int direction)
> +{
> + return _bpf_tap(arg, pkt, pktlen, direction, bcopy, 0);
> +}
> +
> +/*
> + * like bpf_mtap,
tcpdump(8) USB support
Diff below adds support for dumping USB transfers via bpf(4), including
the tcpdump(8) bits.
I'd like special review of the new bpf_tap(9) function I'm introducing:
- is there a way to pass the header as a different buffer?
- is _bpf_tap() the best way to share code with bpf_mtap(9)?
Concerning the kernel/userland interface, in looked at the existing
DLT_USB*, namely:
- DLT_USB_FREEBSD (a.k.a DLT_USB)
- DLT_USB_LINUX
- DLT_USB_LINUX_MMAPPED
- DLT_USBPCAP
- DLT_USB_DARWIN
I decided to follow DLT_USBPCAP which is the most generic one beside
being originated from Windows. Wireshark has some support for it
(currently untested) so it is a nice fit.
The current implementation is small and I'd like to continue developing
it in tree.
Here's an excerpt of what's happening when plugging a USB key:
# tcpdump -xXi usb0
tcpdump: listening on usb0, link-type USBPCAP
[...]
18:56:26.261293 bus 0 > addr 5: ep0 ctrl 0
18:56:26.261409 bus 0 < addr 5: ep0 ctrl 20
: 1403 5300 6c00 6900 6d00 2000 4c00 6900 ..S.l.i.m. .L.i.
0010: 6e00 6500n.e.
18:56:26.261418 bus 0 > addr 5: ep0 ctrl 0
18:56:26.261547 bus 0 < addr 5: ep0 ctrl 2
: 2203 ".
18:56:26.261552 bus 0 > addr 5: ep0 ctrl 0
18:56:26.261746 bus 0 < addr 5: ep0 ctrl 34
: 2203 3000 3700 3100 3000 3500 3900 3600 ".0.7.1.0.5.9.6.
0010: 3100 4100 3400 3800 4400 3600 4100 3900 1.A.4.8.D.6.A.9.
0020: 3500 5.
18:56:26.261761 bus 0 > addr 5: ep2 bulk 31
: 5553 4243 4c00 0600 USBCL...
0010: 00...
Ok to put it in tree?
Index: sys/net/bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.166
diff -u -p -r1.166 bpf.c
--- sys/net/bpf.c 24 Jan 2018 00:25:17 - 1.166
+++ sys/net/bpf.c 25 Jan 2018 14:02:58 -
@@ -1226,35 +1226,24 @@ bpf_mcopy(const void *src_arg, void *dst
}
}
-/*
- * like bpf_mtap, but copy fn can be given. used by various bpf_mtap*
- */
int
-_bpf_mtap(caddr_t arg, const struct mbuf *m, u_int direction,
-void (*cpfn)(const void *, void *, size_t))
+_bpf_tap(caddr_t arg, u_char *pkt, size_t pktlen, u_int direction,
+void (*cpfn)(const void *, void *, size_t), int mfilter)
{
struct bpf_if *bp = (struct bpf_if *)arg;
struct srp_ref sr;
struct bpf_d *d;
- size_t pktlen, slen;
- const struct mbuf *m0;
+ size_t slen;
struct timeval tv;
int gottime = 0;
int drop = 0;
- if (m == NULL)
+ if (pkt == NULL)
return (0);
- if (cpfn == NULL)
- cpfn = bpf_mcopy;
-
if (bp == NULL)
return (0);
- pktlen = 0;
- for (m0 = m; m0 != NULL; m0 = m0->m_next)
- pktlen += m0->m_len;
-
SRPL_FOREACH(d, &sr, &bp->bif_dlist, bd_next) {
atomic_inc_long(&d->bd_rcount);
@@ -1268,7 +1257,11 @@ _bpf_mtap(caddr_t arg, const struct mbuf
bf = srp_enter(&bsr, &d->bd_rfilter);
if (bf != NULL)
fcode = bf->bf_insns;
- slen = bpf_mfilter(fcode, m, pktlen);
+ if (mfilter) {
+ const struct mbuf *m = (const struct mbuf *)pkt;
+ slen = bpf_mfilter(fcode, m, pktlen);
+ } else
+ slen = bpf_filter(fcode, pkt, pktlen, pktlen);
srp_leave(&bsr);
}
@@ -1277,8 +1270,7 @@ _bpf_mtap(caddr_t arg, const struct mbuf
microtime(&tv);
mtx_enter(&d->bd_mtx);
- bpf_catchpacket(d, (u_char *)m, pktlen, slen, cpfn,
- &tv);
+ bpf_catchpacket(d, pkt, pktlen, slen, cpfn, &tv);
mtx_leave(&d->bd_mtx);
if (d->bd_fildrop)
@@ -1290,6 +1282,35 @@ _bpf_mtap(caddr_t arg, const struct mbuf
return (drop);
}
+int
+bpf_tap(caddr_t arg, u_char *pkt, size_t pktlen, u_int direction)
+{
+ return _bpf_tap(arg, pkt, pktlen, direction, bcopy, 0);
+}
+
+/*
+ * like bpf_mtap, but copy fn can be given. used by various bpf_mtap*
+ */
+int
+_bpf_mtap(caddr_t arg, const struct mbuf *m, u_int direction,
+void (*cpfn)(const void *, void *, size_t))
+{
+ const struct mbuf *m0;
+ size_t pktlen;
+
+ if (m == NULL)
+ return (0);
+
+ if (cpfn == NULL)
+ cpfn = bpf_mcopy;
+
+ pktlen = 0;
+ for (m0 = m; m0 != NULL; m0 = m0->m_next)
+
tftpd: transfer size for random.seed
tftpd needs to handle the transfer size option when faking up /etc/random.seed. Without this, clients that query the size receive 0 as response, preventing efiboot from loading random.seed. ok? Index: tftpd.c === RCS file: /cvs/src/usr.sbin/tftpd/tftpd.c,v retrieving revision 1.40 diff -u -p -r1.40 tftpd.c --- tftpd.c 7 Nov 2017 14:15:38 - 1.40 +++ tftpd.c 25 Jan 2018 12:49:39 - @@ -973,6 +973,8 @@ validate_access(struct tftp_client *clie buf = client->buf + sizeof(client->buf) - 512; arc4random_buf(buf, 512); + if (options != NULL && options[OPT_TSIZE].o_request) + options[OPT_TSIZE].o_reply = 512; client->file = fmemopen(buf, 512, "r"); if (client->file == NULL) return (errno + 100); -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: carp_ourether() tweak
On 24/01/18(Wed) 09:30, Alexander Bluhm wrote:
> On Mon, Jan 22, 2018 at 11:58:30AM +0100, Martin Pieuchot wrote:
> > Check if `if_carp' is empty inside carp_ourether() instead of outside.
> >
> > ok?
>
> Maybe I am confused by the ! and && but I think this diff changes the
> logic.
You're right. The current logic is broken since the last refactoring.
It should read "if it's not my MAC nor the one of my carp(4) children".
Diff below corrects that in a way that should prevent future refactoring
to break it again.
ok?
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.301
diff -u -p -r1.301 if_bridge.c
--- net/if_bridge.c 10 Jan 2018 23:50:39 - 1.301
+++ net/if_bridge.c 25 Jan 2018 14:27:43 -
@@ -997,6 +997,25 @@ bridgeintr_frame(struct bridge_softc *sc
}
/*
+ * Return 1 if `ena' belongs to `ifl', 0 otherwise.
+ */
+int
+bridge_ourether(struct bridge_iflist *ifl, uint8_t *ena)
+{
+ struct arpcom *ac = (struct arpcom *)ifl->ifp;
+
+ if (bcmp(ac->ac_enaddr, ena, ETHER_ADDR_LEN) == 0)
+ return (1);
+
+#if NCARP > 0
+ if (carp_ourether(ifl->ifp, ena))
+ return (1);
+#endif
+
+ return (0);
+}
+
+/*
* Receive input from an interface. Queue the packet for bridging if its
* not for us, and schedule an interrupt.
*/
@@ -1022,7 +1041,6 @@ bridge_process(struct ifnet *ifp, struct
struct bridge_iflist *ifl;
struct bridge_iflist *srcifl;
struct ether_header *eh;
- struct arpcom *ac;
struct mbuf *mc;
ifl = (struct bridge_iflist *)ifp->if_bridgeport;
@@ -1105,13 +1123,7 @@ bridge_process(struct ifnet *ifp, struct
TAILQ_FOREACH(ifl, &sc->sc_iflist, next) {
if (ifl->ifp->if_type != IFT_ETHER)
continue;
- ac = (struct arpcom *)ifl->ifp;
- if (bcmp(ac->ac_enaddr, eh->ether_dhost, ETHER_ADDR_LEN) == 0
-#if NCARP > 0
- || (!SRPL_EMPTY_LOCKED(&ifl->ifp->if_carp) &&
- !carp_ourether(ifl->ifp, eh->ether_dhost))
-#endif
- ) {
+ if (bridge_ourether(ifl, eh->ether_dhost)) {
if (srcifl->bif_flags & IFBIF_LEARNING)
bridge_rtupdate(sc,
(struct ether_addr *)&eh->ether_shost,
@@ -1129,12 +1141,7 @@ bridge_process(struct ifnet *ifp, struct
bridge_ifinput(ifl->ifp, m);
return;
}
- if (bcmp(ac->ac_enaddr, eh->ether_shost, ETHER_ADDR_LEN) == 0
-#if NCARP > 0
- || (!SRPL_EMPTY_LOCKED(&ifl->ifp->if_carp) &&
- !carp_ourether(ifl->ifp, eh->ether_shost))
-#endif
- ) {
+ if (bridge_ourether(ifl, eh->ether_shost)) {
m_freem(m);
return;
}
Index: netinet/ip_carp.c
===
RCS file: /cvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.327
diff -u -p -r1.327 ip_carp.c
--- netinet/ip_carp.c 12 Jan 2018 23:47:24 - 1.327
+++ netinet/ip_carp.c 25 Jan 2018 14:18:44 -
@@ -1339,12 +1348,15 @@ carp_iamatch(struct ifnet *ifp)
int
carp_ourether(struct ifnet *ifp, u_int8_t *ena)
{
- struct srpl *cif;
+ struct srpl *cif = &ifp->if_carp;
struct carp_softc *vh;
KERNEL_ASSERT_LOCKED(); /* touching if_carp + carp_vhosts */
+
+ if (SRPL_EMPTY_LOCKED(cif))
+ return (0);
+
KASSERT(ifp->if_type == IFT_ETHER);
- cif = &ifp->if_carp;
SRPL_FOREACH_LOCKED(vh, cif, sc_list) {
struct carp_vhost_entry *vhe;
Re: Kernel Panic on 6.2 amd64 when run0 RT3070 based device is attached during boot
Finally catch kernel panic in the middle of run adapter work. A bit different panics from time to time: Starting stack trace... panic() at panic+0x11b splassert_fail(80218000,100,81180127) at splassert_fail+0x67 if_down*8021800) at if_down+0x39 if_downall() at if_downall+0x51 boot(104) at boot+0x76 reboot(81610bae) at reboot+0x4b panic() at panic+0x123 fataldouble fault in supervisor mode trap type 13 code 0 rip 812b54c0 cs rflags 10292 cr2 800032dbdf98 cpl 9 rsp 800032dbdfa8 panic: trap type 13, code=0, pc=812b54c0 Faulted in tracebasck, aborting... splassert: if_down: want 1 have 256 panic: spl assertion failure in if_down Faulted in traceback, aborting... splassert: if_down: want 1 have 256 ... The second 'variant' of panic screen is below: splassert_fail(80218000,100,811f6277) at splassert_fail+0x67 if_down(80218000) at if_down+0x39 if_downall() at if_downall+0x51 boot(104) at boot+0x76 reboot(81607b56) at reboot+0x4b panic() at panic+0x123 splassert_fail(f80218000,100,811f6277) at splassert_fail+0x67 if_down(80218000) at if_down+0x39 if_downall() at if_downall +0x51 boot(104) at boot+0x76 reboot(81607b56) at reboot+0x4b panic() at panic+0x123 splassert_fail(ff01dc95c720,100,811f6277) at splassert_fail+0x67 sblock(ff01dc95c638,0,ff0017f86600) at sblock+0x6a sosend(ff01d8562bf0,800032ea2d70,70, 800032ea2d90,ff01dc95c638,9abf43b1530 sendit(800032ea2d70,800032e87838,800032e87840,800032e87750,0) at sendit sys_sendmsg(800032e878d0,1c0,800032ea2d70) at sys_sendmsg+0x13f syscall() at syscall+0x270 --- syscall (number 28) --- end of kernel end trace frame: 0x7f7e24a0, count: 40 0x1372a3caf59a: End of stack trace. splassert: if_down want 1 have 256 panic: spl assertion failure in if_down Starting stack trace... panic () at ... On 1/21/2018 10:38 AM, Denis wrote: > Last tests shows that 6.2amd64 system goes reboot in a random manner > with run0 driver is loaded. Reboots mainly caused when data is > transferred other run0 device but absolutely sporadically. No dmesg > messages provided with these reboots. > > It has been tested on two different laptops with the same configuration > as in dmesg listed before. Different USB ports has been used for test. > > I've changed usb cable length, RT3070 based cards from different > manufacturers, but behavior is the same. > > Hope this helps to improve the run0 driver. > > Thanks > > On 1/18/2018 12:23 PM, Denis wrote: >> Hi All, >> >> From time to time I receive Kernel Panic on OpenBSD 6.2 amd64 when run0 >> driver for RT3070 based device is attached to the Lenovo X220 laptop >> during boot. >> It appears just after file system is mounted. Next boot I receive that >> file system was not properly unmounted. >> But after FS checking is completed the same run0 device usually works as >> expected. >> >> The same thing when I connected RT3070 device to the fully booted >> OpenBSD6.2 amd64. Three times out of ten I got kernel panic issue. >> >> I have tested two RT3070 adapters on other systems. Both works smoothly. >> But on 6.2 amd64 each of them produces panic issue with the same >> probability. >> >> I can implement any patches and test it if necessary to make it work. >> >> The boot time kernel trap (if you need a full 3000+ lines kernel panic >> message please let me know) and self explanatory dmesg are shown below: >> >> panic() at panic+0x123 >> _rw_exit_write(8139e3be) at _rw_exit_write+0x6e >> pf_purge(800032d81590) at pf_purge+0x148 >> taskq_thread(0) at taskq_thread+0x67 >> end trace frame: 0x0, count: 91 >> End of stack trace. >> splassert: if_down: want 1 have 256 >> panic: spl assertion failure in if_down >> Starting stack trace... >> panic() at panic+0x11b >> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67 >> if_down(80218000) at if_down+0x39 >> if_downall() at if_downall+0x51 >> boot(104) at boot+0x76 >> reboot(815b79ce) at reboot+0x4b >> panic() at panic+0x123 >> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67 >> if_down(80218000) at if_down+0x39 >> if_downall() at if_downall+0x51 >> boot(104) at boot+0x76 >> reboot(815b79ce) at reboot+0x4b >> panic() at panic+0x123 >> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67 >> if_down(80218000) at if_down+0x39 >> if_downall() at if_downall+0x51 >> boot(104) at boot+0x76 >> reboot(815b79ce) at reboot+0x4b >> panic() at panic+0x123 >> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67 >> if_down(80218000) at if_down+0x39 >> if_downall() at if_downall+0x51 >> boot(104) at boot+0x76 >> reboot(815b79ce) at reboot+0x4b >> panic() at panic+0x123 >> splassert_fail(80218000,100,810b9707) at splassert_fail+0x67 >> if_down(80218000)
