Re: trunk(4) shouldn't need to play with a port's if_type

2019-06-11 Thread sven falempin
Some interfaces are marked as busy ( promiscuitous ?) so they can’t be
added in two bridges for example, this could be extended and make things
more consistent?

Just my two cents

On Tue, Jun 11, 2019 at 8:27 PM David Gwynne  wrote:

> I get that trunk ports should not be able to be added to bridges or have
> carp interfaces hanging off them, but I think the value of making the
> if_type immutable outweighs this usability feature. Especially when you
> consider that you can have an interface that is already a member of a
> bridge (or have the other things on it) and then add it to trunk, and the
> system thinks that it is fine.
>
> It gets more confusing when you think about whether things like vlan or
> bpe are "service delimiting" or not, and how they're supposed to interact
> with trunk. If trunk is enabled on a physical interface, should vlan be
> allowed to coexist with it? If the trunk is doing LACP, you could argue no,
> but if it's doing failover or broadcast then maybe you want that to operate
> independently for different vlans and the "native" vlan on the one physical
> interface.
>
> If we ever want to support "independent" LACP trunk port operation like a
> variety of switches do now, then it makes sense to maintain IFT_ETHER too.
>
> dlg
>
> >
> > On 11 Jun 2019, at 17:32, Reyk Floeter  wrote:
> >
> > Hi,
> >
> > the initial intention was to differentiate a trunk port from a regular
> Ethernet interface.
> >
> > As long as an interface is a member of a trunk, it is not a fully
> featured Ethernet interface. The changed type prevented from using it
> elsewhere.
> >
> > I‘m not so familiar with the current network stack anymore, so maybe
> there are other ways to do it these days, but you should test that a trunk
> port cannot be attached to a bridge or carp or anything like this.
> >
> > You also forgot a comment that mentions the type as well.
> >
> > Reyk
> >
> >> Am 11.06.2019 um 08:33 schrieb David Gwynne :
> >>
> >> i think trunk(4) is the only thing left in the kernel that modifies an
> >> interfaces if_type at runtime. this diff removes that fiddling, so
> >> hopefully we can say that if_type is immutable after this.
> >>
> >> however, while this diff reads well to me, i don't actually know if it
> >> works. could someone kick the tyres for me?
> >>
> >> cheers,
> >> dlg
> >>
> >> Index: if_trunk.c
> >> ===
> >> RCS file: /cvs/src/sys/net/if_trunk.c,v
> >> retrieving revision 1.140
> >> diff -u -p -r1.140 if_trunk.c
> >> --- if_trunk.c11 May 2019 18:10:45 -1.140
> >> +++ if_trunk.c11 Jun 2019 06:31:29 -
> >> @@ -330,10 +330,7 @@ trunk_port_create(struct trunk_softc *tr
> >>   }
> >>   }
> >>
> >> -/* Change the interface type */
> >> -tp->tp_iftype = ifp->if_type;
> >> -ifp->if_type = IFT_IEEE8023ADLAG;
> >> -
> >> +/* Change the interface methods */
> >>   tp->tp_ioctl = ifp->if_ioctl;
> >>   ifp->if_ioctl = trunk_port_ioctl;
> >>
> >> @@ -422,9 +419,7 @@ trunk_port_destroy(struct trunk_port *tp
> >>   if (tr->tr_port_destroy != NULL)
> >>   (*tr->tr_port_destroy)(tp);
> >>
> >> -/* Restore interface type. */
> >> -ifp->if_type = tp->tp_iftype;
> >> -
> >> +/* Restore interface methods. */
> >>   ifp->if_ioctl = tp->tp_ioctl;
> >>   ifp->if_output = tp->tp_output;
> >>
> >> @@ -474,8 +469,7 @@ trunk_port_ioctl(struct ifnet *ifp, u_lo
> >>   int error = 0;
> >>
> >>   /* Should be checked by the caller */
> >> -if (ifp->if_type != IFT_IEEE8023ADLAG ||
> >> -(tp = trunk_port_get(NULL, ifp)) == NULL ||
> >> +if ((tp = trunk_port_get(NULL, ifp)) == NULL ||
> >>   (tr = (struct trunk_softc *)tp->tp_trunk) == NULL) {
> >>   error = EINVAL;
> >>   goto fallback;
> >> @@ -521,8 +515,7 @@ trunk_port_output(struct ifnet *ifp, str
> >>struct rtentry *rt)
> >> {
> >>   /* restrict transmission on trunk members to bpf only */
> >> -if (ifp->if_type == IFT_IEEE8023ADLAG &&
> >> -(m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
> >> +if ((m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
> >>   m_freem(m);
> >>   return (EBUSY);
> >>   }
> >> @@ -1123,10 +1116,6 @@ trunk_input(struct ifnet *ifp, struct mb
> >>   eh = mtod(m, struct ether_header *);
> >>   if (ETHER_IS_MULTICAST(eh->ether_dhost))
> >>   ifp->if_imcasts++;
> >> -
> >> -/* Should be checked by the caller */
> >> -if (ifp->if_type != IFT_IEEE8023ADLAG)
> >> -goto bad;
> >>
> >>   tp = (struct trunk_port *)cookie;
> >>   if ((tr = (struct trunk_softc *)tp->tp_trunk) == NULL)
> >>
> >
>
> --
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do


Re: trunk(4) shouldn't need to play with a port's if_type

2019-06-11 Thread David Gwynne
I get that trunk ports should not be able to be added to bridges or have carp 
interfaces hanging off them, but I think the value of making the if_type 
immutable outweighs this usability feature. Especially when you consider that 
you can have an interface that is already a member of a bridge (or have the 
other things on it) and then add it to trunk, and the system thinks that it is 
fine.

It gets more confusing when you think about whether things like vlan or bpe are 
"service delimiting" or not, and how they're supposed to interact with trunk. 
If trunk is enabled on a physical interface, should vlan be allowed to coexist 
with it? If the trunk is doing LACP, you could argue no, but if it's doing 
failover or broadcast then maybe you want that to operate independently for 
different vlans and the "native" vlan on the one physical interface.

If we ever want to support "independent" LACP trunk port operation like a 
variety of switches do now, then it makes sense to maintain IFT_ETHER too.

dlg

> 
> On 11 Jun 2019, at 17:32, Reyk Floeter  wrote:
> 
> Hi,
> 
> the initial intention was to differentiate a trunk port from a regular 
> Ethernet interface.
> 
> As long as an interface is a member of a trunk, it is not a fully featured 
> Ethernet interface. The changed type prevented from using it elsewhere.
> 
> I‘m not so familiar with the current network stack anymore, so maybe there 
> are other ways to do it these days, but you should test that a trunk port 
> cannot be attached to a bridge or carp or anything like this.
> 
> You also forgot a comment that mentions the type as well.
> 
> Reyk
> 
>> Am 11.06.2019 um 08:33 schrieb David Gwynne :
>> 
>> i think trunk(4) is the only thing left in the kernel that modifies an
>> interfaces if_type at runtime. this diff removes that fiddling, so
>> hopefully we can say that if_type is immutable after this.
>> 
>> however, while this diff reads well to me, i don't actually know if it
>> works. could someone kick the tyres for me?
>> 
>> cheers,
>> dlg
>> 
>> Index: if_trunk.c
>> ===
>> RCS file: /cvs/src/sys/net/if_trunk.c,v
>> retrieving revision 1.140
>> diff -u -p -r1.140 if_trunk.c
>> --- if_trunk.c11 May 2019 18:10:45 -1.140
>> +++ if_trunk.c11 Jun 2019 06:31:29 -
>> @@ -330,10 +330,7 @@ trunk_port_create(struct trunk_softc *tr
>>   }
>>   }
>> 
>> -/* Change the interface type */
>> -tp->tp_iftype = ifp->if_type;
>> -ifp->if_type = IFT_IEEE8023ADLAG;
>> -
>> +/* Change the interface methods */
>>   tp->tp_ioctl = ifp->if_ioctl;
>>   ifp->if_ioctl = trunk_port_ioctl;
>> 
>> @@ -422,9 +419,7 @@ trunk_port_destroy(struct trunk_port *tp
>>   if (tr->tr_port_destroy != NULL)
>>   (*tr->tr_port_destroy)(tp);
>> 
>> -/* Restore interface type. */
>> -ifp->if_type = tp->tp_iftype;
>> -
>> +/* Restore interface methods. */
>>   ifp->if_ioctl = tp->tp_ioctl;
>>   ifp->if_output = tp->tp_output;
>> 
>> @@ -474,8 +469,7 @@ trunk_port_ioctl(struct ifnet *ifp, u_lo
>>   int error = 0;
>> 
>>   /* Should be checked by the caller */
>> -if (ifp->if_type != IFT_IEEE8023ADLAG ||
>> -(tp = trunk_port_get(NULL, ifp)) == NULL ||
>> +if ((tp = trunk_port_get(NULL, ifp)) == NULL ||
>>   (tr = (struct trunk_softc *)tp->tp_trunk) == NULL) {
>>   error = EINVAL;
>>   goto fallback;
>> @@ -521,8 +515,7 @@ trunk_port_output(struct ifnet *ifp, str
>>struct rtentry *rt)
>> {
>>   /* restrict transmission on trunk members to bpf only */
>> -if (ifp->if_type == IFT_IEEE8023ADLAG &&
>> -(m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
>> +if ((m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
>>   m_freem(m);
>>   return (EBUSY);
>>   }
>> @@ -1123,10 +1116,6 @@ trunk_input(struct ifnet *ifp, struct mb
>>   eh = mtod(m, struct ether_header *);
>>   if (ETHER_IS_MULTICAST(eh->ether_dhost))
>>   ifp->if_imcasts++;
>> -
>> -/* Should be checked by the caller */
>> -if (ifp->if_type != IFT_IEEE8023ADLAG)
>> -goto bad;
>> 
>>   tp = (struct trunk_port *)cookie;
>>   if ((tr = (struct trunk_softc *)tp->tp_trunk) == NULL)
>> 
> 



drm(4), multi-threaded task queues and barriers

2019-06-11 Thread Mark Kettenis
The drm(4) codebase really needs multi-threaded task queues since the
code has taks that wait for the completion of other tasks that are
submitted to the same task queue.  Thank you Linux...

Unfortunately the code also needs to wait for the completion of
submitted tasks from other threads.  This implemented using
task_barrier(9).  But unfortunately our current implementation only
works for single-threaded task queues.

The diff below fixes this by marking the barrier task with a flag and
making sure that all threads of the task queue are syncchronized.
This achived through a TASK_BARRIER flag that simply blocks the
threads until the last unblocked thread sees the flag and executes the
task.

The diff also starts 4 threads for each workqueue that gets created by
the drm(4) layer.  The number 4 is a bit arbitrary but it is the
number of threads that Linux creates per CPU for a so-called "unbound"
workqueue which hopefully is enough to always make progress.

Please test.  If you experience a "hang" with this diff, please try to
log in to the machine remotely over ssh and send me and jsg@ the
output of "ps -AHwlk".

Thanks,

Mark


Index: dev/pci/drm/drm_linux.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
retrieving revision 1.38
diff -u -p -r1.38 drm_linux.c
--- dev/pci/drm/drm_linux.c 9 Jun 2019 12:58:30 -   1.38
+++ dev/pci/drm/drm_linux.c 11 Jun 2019 18:54:38 -
@@ -1399,15 +1399,15 @@ drm_linux_init(void)
 {
if (system_wq == NULL) {
system_wq = (struct workqueue_struct *)
-   taskq_create("drmwq", 1, IPL_HIGH, 0);
+   taskq_create("drmwq", 4, IPL_HIGH, 0);
}
if (system_unbound_wq == NULL) {
system_unbound_wq = (struct workqueue_struct *)
-   taskq_create("drmubwq", 1, IPL_HIGH, 0);
+   taskq_create("drmubwq", 4, IPL_HIGH, 0);
}
if (system_long_wq == NULL) {
system_long_wq = (struct workqueue_struct *)
-   taskq_create("drmlwq", 1, IPL_HIGH, 0);
+   taskq_create("drmlwq", 4, IPL_HIGH, 0);
}
 
if (taskletq == NULL)
Index: dev/pci/drm/i915/intel_hotplug.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_hotplug.c,v
retrieving revision 1.2
diff -u -p -r1.2 intel_hotplug.c
--- dev/pci/drm/i915/intel_hotplug.c14 Apr 2019 10:14:52 -  1.2
+++ dev/pci/drm/i915/intel_hotplug.c11 Jun 2019 18:54:38 -
@@ -619,7 +619,6 @@ void intel_hpd_init_work(struct drm_i915
INIT_WORK(_priv->hotplug.hotplug_work, i915_hotplug_work_func);
INIT_WORK(_priv->hotplug.dig_port_work, i915_digport_work_func);
INIT_WORK(_priv->hotplug.poll_init_work, i915_hpd_poll_init_work);
-   dev_priv->hotplug.poll_init_work.tq = systq;
INIT_DELAYED_WORK(_priv->hotplug.reenable_work,
  intel_hpd_irq_storm_reenable_work);
 }
Index: kern/kern_task.c
===
RCS file: /cvs/src/sys/kern/kern_task.c,v
retrieving revision 1.25
diff -u -p -r1.25 kern_task.c
--- kern/kern_task.c28 Apr 2019 04:20:40 -  1.25
+++ kern/kern_task.c11 Jun 2019 18:54:39 -
@@ -43,6 +43,7 @@ struct taskq {
TQ_S_DESTROYED
}tq_state;
unsigned int tq_running;
+   unsigned int tq_barrier;
unsigned int tq_nthreads;
unsigned int tq_flags;
const char  *tq_name;
@@ -59,6 +60,7 @@ static const char taskq_sys_name[] = "sy
 struct taskq taskq_sys = {
TQ_S_CREATED,
0,
+   0,
1,
0,
taskq_sys_name,
@@ -77,6 +79,7 @@ static const char taskq_sys_mp_name[] = 
 struct taskq taskq_sys_mp = {
TQ_S_CREATED,
0,
+   0,
1,
TASKQ_MPSAFE,
taskq_sys_mp_name,
@@ -122,6 +125,7 @@ taskq_create(const char *name, unsigned 
 
tq->tq_state = TQ_S_CREATED;
tq->tq_running = 0;
+   tq->tq_barrier = 0;
tq->tq_nthreads = nthreads;
tq->tq_name = name;
tq->tq_flags = flags;
@@ -161,6 +165,7 @@ taskq_destroy(struct taskq *tq)
panic("unexpected %s tq state %u", tq->tq_name, tq->tq_state);
}
 
+   tq->tq_barrier = 0;
while (tq->tq_running > 0) {
wakeup(tq);
msleep(>tq_running, >tq_mtx, PWAIT, "tqdestroy", 0);
@@ -223,6 +228,7 @@ taskq_barrier(struct taskq *tq)
 
WITNESS_CHECKORDER(>tq_lock_object, LOP_NEWORDER, NULL);
 
+   SET(t.t_flags, TASK_BARRIER);
task_add(tq, );
cond_wait(, "tqbar");
 }
@@ -238,6 +244,7 @@ taskq_del_barrier(struct taskq *tq, stru
if (task_del(tq, del))
return;
 
+   SET(t.t_flags, TASK_BARRIER);

Re: mg(1) log internals to file

2019-06-11 Thread Florian Obser
On Fri, Jun 07, 2019 at 03:18:27PM +, Mark Lumsden wrote:
> This diff allows mg to log its internal status to a file. At the moment it
> only logs line information like front and back pointers in the linked list,
> how many characters are used and where the cursor is placed in the file, but
> I am finding it incredibly useful debugging mg at the moment.
> 
> Below is an example log file after opening a file with this contents:
> 
> abc
> def
> ghk
> 
> After I open the file in mg, I move forward a line (C-n), then move forward
> a character (C-f):
> 
> $ cat log/mg.log
> next-line
> > 3 3 0xc3a3557ae00 b^0xc3a592eac20 f.0xc3a592ea4a0 abc
>  3 3 0xc3a592ea4a0 b^0xc3a3557ae00 f.0xc3a592ea660 def
>  3 3 0xc3a592ea660 b^0xc3a592ea4a0 f.0xc3a307830e0 ghk
>  0 0 0xc3a307830e0 b^0xc3a592ea660 f.0xc3a592eac20 (null)
>  head 0xc3a592eac20 b^0xc3a307830e0 f.0xc3a3557ae00
> (EOB)
> 
> forward-char
>  3 3 0xc3a3557ae00 b^0xc3a592eac20 f.0xc3a592ea4a0 abc
> > 3 3 0xc3a592ea4a0 b^0xc3a3557ae00 f.0xc3a592ea660 def
>  3 3 0xc3a592ea660 b^0xc3a592ea4a0 f.0xc3a307830e0 ghk
>  0 0 0xc3a307830e0 b^0xc3a592ea660 f.0xc3a592eac20 (null)
>  head 0xc3a592eac20 b^0xc3a307830e0 f.0xc3a3557ae00
> (EOB)
> 
> The three columns of pointer addresses are (from the 'def' line):
> 
> 0xc3a592ea4a0 the lines own pointer.
> 0xc3a3557ae00 the pointer to back(b^) line
> 0xc3a592ea660 the pointer to forward(f.) line
> 
> The numbers at the start of the first four lines are l_size and l_used.
> 
> With this diff logging is not switched on by default and has to compiled
> into mg.  -DMGDEBUG has to be added to the Makefile:
> 
> CFLAGS+=-Wall -DREGEX  -DMGDEBUG
> 
> And the comment removed from:
> 
> #SRCS+=  log.c
> 
> The information logged at the moment is viewable by gdb, however, if a bug
> that I have introduced doesn't present itself for XX number of key presses,
> I can struggle to work out what has caused it in gdb, logging like this
> makes problems I have introduced much more obvious and easier to fix.
> 
> I have tried to make the ifdefs as minimal as possible. Any objections to
> this diff?
> 

I'm not fundamentally opposed to such a functionality since I have
written an ad-hoc version of this on multiple occasions.

That being said, I would prefer a version that is so non-invasive that
we can compile it in always so that it does not fall to bitrot. I'd
also like an api that allows me to log arbitrary strings in addition
to what you have written here.

It does not quite live up to OpenBSD coding standards, see inline
(ignoring that your mail client seemed to have mangled the diff).

> Mark
> 
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.bin/mg/Makefile,v
> retrieving revision 1.33
> diff -u -p -u -p -r1.33 Makefile
> --- Makefile  16 Sep 2016 17:17:40 -  1.33
> +++ Makefile  7 Jun 2019 14:42:39 -
> @@ -9,6 +9,7 @@ DPADD+=   ${LIBCURSES} ${LIBUTIL}
>  #
>  #REGEX   -- create regular expression functions.
>  #STARTUPFILE -- look for and handle initialization file.
> +#MGDEBUG -- debug mg internals to a log file.
>  #
>  CFLAGS+=-Wall -DREGEX
> 
> @@ -22,6 +23,11 @@ SRCS=  autoexec.c basic.c bell.c buffer.c
>  # More or less standalone extensions.
>  #
>  SRCS+=   cmode.c cscope.c dired.c grep.c tags.c
> +
> +#
> +# -DMGDEBUG source file.
> +#
> +#SRCS+=  log.c
> 
>  afterinstall:
>   ${INSTALL} -d -o root -g wheel ${DESTDIR}${DOCDIR}/mg
> Index: kbd.c
> ===
> RCS file: /cvs/src/usr.bin/mg/kbd.c,v
> retrieving revision 1.30
> diff -u -p -u -p -r1.30 kbd.c
> --- kbd.c 26 Sep 2015 21:51:58 -  1.30
> +++ kbd.c 7 Jun 2019 14:42:39 -
> @@ -15,6 +15,10 @@
>  #include "key.h"
>  #include "macro.h"
> 
> +#ifdef  MGDEBUG
> +#include "log.h"
> +#endif
> +
>  #define METABIT 0x80
> 
>  #define PROMPTL 80
> @@ -151,6 +155,11 @@ doin(void)
>   while ((funct = doscan(curmap, (key.k_chars[key.k_count++] =
>   getkey(TRUE)), )) == NULL)
>   /* nothing */;
> +
> +#ifdef  MGDEBUG
> + if (!mglog(funct))
> + ewprintf("Problem with logging");
> +#endif
> 
>   if (macrodef && macrocount < MAXMACRO)
>   macro[macrocount++].m_funct = funct;
> Index: log.c
> ===
> RCS file: log.c
> diff -N log.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ log.c 7 Jun 2019 14:42:39 -
> @@ -0,0 +1,121 @@
> +/*   $OpenBSD$   */
> +
> +/* + * This file is in the public domain.
> + *
> + * Author: Mark Lumsden 
> + *
> + */
> +
> +/*
> + * Record a history of an mg session for temporal debugging.
> + * Sometimes pressing a key will set the scene for a bug only visible + *
> dozens of keystrokes later. gdb has its limitations in this scenario.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Check your machdep.allowaperture setting

2019-06-11 Thread Mark Kettenis
These days most OpenBSD users should have the machdep.allowaperture
sysctl set to 0 (the default).  Having it set to seomething else poses
security risks and can actually cause problems, in particular on
systems that have multiple GPUs where one of tha GPUs is supported by
inteldrm(4) or radeondrm(4) and the other isn't.

You'll only need to set machdep.allowaperture to a non-zero value if
inteldrm(4) or radeordrm(4) doesn't attach on your machine and you
can't use efifb(4) either.



Re: pflog(4) free sizes

2019-06-11 Thread Klemens Nanni
OK kn



Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-11 Thread Gilles Chehade
On Tue, Jun 11, 2019 at 01:37:24PM +0200, Renaud Allard wrote:
> 
> 
> On 6/11/19 10:17 AM, Renaud Allard wrote:
> > 
> > Hello,
> > 
> > Here is a patch with ecdsa and rsa in %token after the domain key name
> > 
> > OK? comments?
> 
> I just made a small modification in the formatting of acme.conf man page,
> putting keytype as an arg. And also a cleaner key.h
> 
> OK?

I don't have an openbsd at hands right now to test this version of
the diff but I tested an earlier version and you took into account
my comments so ... ok by me


> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/Makefile,v
> retrieving revision 1.8
> diff -u -p -r1.8 Makefile
> --- Makefile  3 Jul 2017 22:21:47 -   1.8
> +++ Makefile  11 Jun 2019 11:35:24 -
> @@ -2,7 +2,7 @@
>  PROG=acme-client
>  SRCS=acctproc.c base64.c certproc.c chngproc.c dbg.c 
> dnsproc.c
>  SRCS+=   fileproc.c http.c jsmn.c json.c keyproc.c main.c 
> netproc.c
> -SRCS+=   parse.y revokeproc.c rsa.c util.c
> +SRCS+=   parse.y revokeproc.c key.c util.c
>  
>  MAN= acme-client.1 acme-client.conf.5
>  
> Index: acctproc.c
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 acctproc.c
> --- acctproc.c8 Jun 2019 07:52:55 -   1.14
> +++ acctproc.c11 Jun 2019 11:35:24 -
> @@ -29,7 +29,7 @@
>  #include 
>  
>  #include "extern.h"
> -#include "rsa.h"
> +#include "key.h"
>  
>  /*
>   * Converts a BIGNUM to the form used in JWK.
> @@ -352,7 +352,9 @@ acctproc(int netsock, const char *acctke
>   goto out;
>   dodbg("%s: generated RSA account key", acctkey);
>   } else {
> - if ((pkey = rsa_key_load(f, acctkey)) == NULL)
> + if ((pkey = key_load(f, acctkey)) == NULL)
> + goto out;
> + if (EVP_PKEY_type(pkey->type) != EVP_PKEY_RSA) 
>   goto out;
>   doddbg("%s: loaded RSA account key", acctkey);
>   }
> Index: acme-client.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
> retrieving revision 1.17
> diff -u -p -r1.17 acme-client.conf.5
> --- acme-client.conf.58 Jan 2019 06:46:29 -   1.17
> +++ acme-client.conf.511 Jun 2019 11:35:24 -
> @@ -109,8 +109,10 @@ Specify a list of alternative names for 
>  The common name is included automatically if this option is present,
>  but there is no automatic conversion/inclusion between "www." and
>  plain domain name forms.
> -.It Ic domain key Ar file
> +.It Ic domain key Ar file Op Ar keytype
>  The private key file for which the certificate will be obtained.
> +.Ar keytype
> +can be rsa or ecdsa. Defaults to rsa.
>  .It Ic domain certificate Ar file
>  The filename of the certificate that will be issued.
>  This is optional if
> Index: extern.h
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
> retrieving revision 1.12
> diff -u -p -r1.12 extern.h
> --- extern.h  8 Jun 2019 07:52:55 -   1.12
> +++ extern.h  11 Jun 2019 11:35:24 -
> @@ -276,6 +276,11 @@ char *json_fmt_signed(const char *, con
>  int   verbose;
>  
>  /*
> + * Should we switch to ecdsa?
> + */
> +int  ecdsa;
> +
> +/*
>   * What component is the process within (COMP__MAX for none)?
>   */
>  enum comp proccomp;
> Index: key.c
> ===
> RCS file: key.c
> diff -N key.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ key.c 11 Jun 2019 11:35:24 -
> @@ -0,0 +1,149 @@
> +/*   $Id: rsa.c,v 1.7 2018/07/28 15:25:23 tb Exp $ */
> +/*
> + * Copyright (c) 2019 Renaud Allard 
> + * Copyright (c) 2016 Kristaps Dzonsons 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "key.h"
> +
> +/*
> + * 

Re: pflog(4) free sizes

2019-06-11 Thread Martin Pieuchot
On 10/06/19(Mon) 19:04, Klemens Nanni wrote:
> On Mon, Jun 10, 2019 at 01:55:29PM -0300, Martin Pieuchot wrote:
> > ok?
> OK kn
> 
> There's another in `pflog_clone_destroy()'.

Updated diff including your suggestions.

Index: net/if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.82
diff -u -p -r1.82 if_pflog.c
--- net/if_pflog.c  10 Dec 2018 16:48:15 -  1.82
+++ net/if_pflog.c  11 Jun 2019 15:07:38 -
@@ -124,8 +124,7 @@ pflogifs_resize(size_t n)
else
p[i] = NULL;
 
-   if (pflogifs)
-   free(pflogifs, M_DEVBUF, 0);
+   free(pflogifs, M_DEVBUF, npflogifs * sizeof(*pflogifs));
pflogifs = p;
npflogifs = n;
return (0);
@@ -183,7 +182,7 @@ pflog_clone_destroy(struct ifnet *ifp)
NET_UNLOCK();
 
if_detach(ifp);
-   free(pflogif, M_DEVBUF, 0);
+   free(pflogif, M_DEVBUF, sizeof(*pflogif));
return (0);
 }
 



About transient mark mode

2019-06-11 Thread Leonid Bobrov
Hi!

If we don't have to follow what GNU Emacs is doing anyway, let's just
change behavior of {beginning,end}-of-buffer to this instead of
implementing a useless mode:

Index: basic.c
===
RCS file: /cvs/src/usr.bin/mg/basic.c,v
retrieving revision 1.48
diff -u -p -r1.48 basic.c
--- basic.c 3 Jun 2019 16:26:30 -   1.48
+++ basic.c 11 Jun 2019 15:15:15 -
@@ -124,7 +124,8 @@ forwchar(int f, int n)
 int
 gotobob(int f, int n)
 {
-   (void) setmark(f, n);
+   if (!curwp->w_markp)
+   (void) setmark(f, n);
curwp->w_dotp = bfirstlp(curbp);
curwp->w_doto = 0;
curwp->w_rflag |= WFFULL;
@@ -150,7 +151,8 @@ gotoeob(int f, int n)
int  ln;
struct line *lp;
 
-   (void) setmark(f, n);
+   if (!curwp->w_markp)
+   (void) setmark(f, n);
curwp->w_dotp = blastlp(curbp);
curwp->w_doto = llength(curwp->w_dotp);
curwp->w_dotline = curwp->w_bufp->b_lines;
Index: mg.1
===
RCS file: /cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.114
diff -u -p -r1.114 mg.1
--- mg.16 Jun 2019 18:17:34 -   1.114
+++ mg.111 Jun 2019 15:15:15 -
@@ -1,7 +1,7 @@
 .\"$OpenBSD: mg.1,v 1.114 2019/06/06 18:17:34 jmc Exp $
 .\" This file is in the public domain.
 .\"
-.Dd $Mdocdate: June 6 2019 $
+.Dd $Mdocdate: June 11 2019 $
 .Dt MG 1
 .Os
 .Sh NAME
@@ -408,6 +408,7 @@ Move cursor to the top of the buffer.
 A numeric argument
 .Va n
 will move n/10th of the way from the top.
+Set mark at previous position if mark is not set.
 .It beginning-of-line
 Move cursor to the beginning of the line.
 .It blink-and-insert
@@ -532,6 +533,7 @@ Move cursor to the end of the buffer.
 A numeric argument
 .Va n
 will move n/10th of the way from the end.
+Set mark at previous position if mark is not set.
 .It end-of-line
 Move cursor to the end of the line.
 .It enlarge-window
Index: region.c
===
RCS file: /cvs/src/usr.bin/mg/region.c,v
retrieving revision 1.37
diff -u -p -r1.37 region.c
--- region.c9 Sep 2016 06:05:51 -   1.37
+++ region.c11 Jun 2019 15:15:15 -
@@ -405,6 +405,7 @@ markbuffer(int f, int n)
 {
if (gotoeob(f,n) == FALSE)
return (FALSE);
+   (void) clearmark(f, n);
if (gotobob(f,n) == FALSE)
return (FALSE);
return (TRUE);



Re: fsync(2) and I/O errors

2019-06-11 Thread Ted Unangst
Maximilian Lorlacks wrote:
> This looks okay to me.
> 
> (plus two months ping)

oh, good news, committed two months ago. sorry, forgot to reply.

> 
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, April 16, 2019 8:19 PM, Ted Unangst  wrote:
> 
> > Oh, right, I reworded it slightly, but I think this is something we should
> > note.
> >
> > Index: fsync.2
> >
> > =
> >
> > RCS file: /home/cvs/src/lib/libc/sys/fsync.2,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 fsync.2
> > --- fsync.2 10 Sep 2015 17:55:21 - 1.14
> > +++ fsync.2 16 Apr 2019 20:18:03 -
> > @@ -66,6 +66,16 @@ and
> > .Fn fdatasync
> > should be used by programs that require a file to be in a known state,
> > for example, in building a simple transaction facility.
> > +.Pp
> > +If
> > +.Fn fsync
> > +or
> > +.Fn fdatasync
> > +fails with
> > +.Er EIO ,
> > +the state of the on-disk data may have been only partially written.
> > +To guard against potential inconsistency, future calls will continue 
> > failing
> > +until all references to the file are closed.
> > .Sh RETURN VALUES
> > .Rv -std fsync fdatasync
> > .Sh ERRORS
> 
> 



Re: fsync(2) and I/O errors

2019-06-11 Thread Maximilian Lorlacks
This looks okay to me.

(plus two months ping)

‐‐‐ Original Message ‐‐‐
On Tuesday, April 16, 2019 8:19 PM, Ted Unangst  wrote:

> Oh, right, I reworded it slightly, but I think this is something we should
> note.
>
> Index: fsync.2
>
> =
>
> RCS file: /home/cvs/src/lib/libc/sys/fsync.2,v
> retrieving revision 1.14
> diff -u -p -r1.14 fsync.2
> --- fsync.2 10 Sep 2015 17:55:21 - 1.14
> +++ fsync.2 16 Apr 2019 20:18:03 -
> @@ -66,6 +66,16 @@ and
> .Fn fdatasync
> should be used by programs that require a file to be in a known state,
> for example, in building a simple transaction facility.
> +.Pp
> +If
> +.Fn fsync
> +or
> +.Fn fdatasync
> +fails with
> +.Er EIO ,
> +the state of the on-disk data may have been only partially written.
> +To guard against potential inconsistency, future calls will continue failing
> +until all references to the file are closed.
> .Sh RETURN VALUES
> .Rv -std fsync fdatasync
> .Sh ERRORS




Re: ssh_config.5: refer consistently to HostName, not Hostname

2019-06-11 Thread Jason McIntyre
On Tue, Jun 11, 2019 at 03:11:03PM +0300, Lauri Tirkkonen wrote:
> Hi, trivial manpage diff.
> 

fixed, thanks.
jmc

> diff --git a/usr.bin/ssh/ssh_config.5 b/usr.bin/ssh/ssh_config.5
> index b8ba4022a56..1f2094cb981 100644
> --- a/usr.bin/ssh/ssh_config.5
> +++ b/usr.bin/ssh/ssh_config.5
> @@ -203,7 +203,7 @@ The criteria for the
>  .Cm host
>  keyword are matched against the target hostname, after any substitution
>  by the
> -.Cm Hostname
> +.Cm HostName
>  or
>  .Cm CanonicalizeHostname
>  options.
> 
> -- 
> Lauri Tirkkonen | lotheac @ IRCnet
> 



ssh_config.5: refer consistently to HostName, not Hostname

2019-06-11 Thread Lauri Tirkkonen
Hi, trivial manpage diff.

diff --git a/usr.bin/ssh/ssh_config.5 b/usr.bin/ssh/ssh_config.5
index b8ba4022a56..1f2094cb981 100644
--- a/usr.bin/ssh/ssh_config.5
+++ b/usr.bin/ssh/ssh_config.5
@@ -203,7 +203,7 @@ The criteria for the
 .Cm host
 keyword are matched against the target hostname, after any substitution
 by the
-.Cm Hostname
+.Cm HostName
 or
 .Cm CanonicalizeHostname
 options.

-- 
Lauri Tirkkonen | lotheac @ IRCnet



arm: cleanup cpuid assembly

2019-06-11 Thread Patrick Wildt
Hi,

in a recent discussion I was told we can throw out all the !ARMv7
architecture code and !OpenBSD and if portable needs it they can
add it back.

With this in mind we can throw out quite a bit of ifdefs.

ok?

Patrick

diff --git a/lib/libcrypto/armv4cpuid.S b/lib/libcrypto/armv4cpuid.S
index bb9abafebe5..24d2b4b2b45 100644
--- a/lib/libcrypto/armv4cpuid.S
+++ b/lib/libcrypto/armv4cpuid.S
@@ -1,19 +1,12 @@
 #include "arm_arch.h"
 
 .text
-#if defined(__thumb2__) && !defined(__APPLE__)
-.syntaxunified
-.thumb
-#else
 .code  32
-#undef __thumb2__
-#endif
 
 .align 5
 .globl OPENSSL_atomic_add
 .type  OPENSSL_atomic_add,%function
 OPENSSL_atomic_add:
-#if __ARM_ARCH__>=6
 .Ladd: ldrex   r2,[r0]
add r3,r2,r1
strex   r2,r3,[r0]
@@ -21,32 +14,8 @@ OPENSSL_atomic_add:
bne .Ladd
mov r0,r3
bx  lr
-#else
-   stmdb   sp!,{r4,r5,r6,lr}
-   ldr r2,.Lspinlock
-   adr r3,.Lspinlock
-   mov r4,r0
-   mov r5,r1
-   add r6,r3,r2@ 
-   b   .+8
-.Lspin:bl  sched_yield
-   mov r0,#-1
-   swp r0,r0,[r6]
-   cmp r0,#0
-   bne .Lspin
-
-   ldr r2,[r4]
-   add r2,r2,r5
-   str r2,[r4]
-   str r0,[r6] @ release spinlock
-   ldmia   sp!,{r4,r5,r6,lr}
-   tst lr,#1
-   moveq   pc,lr
-.word  0xe12fff1e  @ bxlr
-#endif
 .size  OPENSSL_atomic_add,.-OPENSSL_atomic_add
 
-#if __ARM_ARCH__>=7
 .arch  armv7-a
 .fpu   neon
 
@@ -61,62 +30,40 @@ _armv7_neon_probe:
 .globl _armv8_aes_probe
 .type  _armv8_aes_probe,%function
 _armv8_aes_probe:
-#if defined(__thumb2__) && !defined(__APPLE__)
-.byte  0xb0,0xff,0x00,0x03 @ aese.8q0,q0
-#else
 .byte  0x00,0x03,0xb0,0xf3 @ aese.8q0,q0
-#endif
bx  lr
 .size  _armv8_aes_probe,.-_armv8_aes_probe
 
 .globl _armv8_sha1_probe
 .type  _armv8_sha1_probe,%function
 _armv8_sha1_probe:
-#if defined(__thumb2__) && !defined(__APPLE__)
-.byte  0x00,0xef,0x40,0x0c @ sha1c.32  q0,q0,q0
-#else
 .byte  0x40,0x0c,0x00,0xf2 @ sha1c.32  q0,q0,q0
-#endif
bx  lr
 .size  _armv8_sha1_probe,.-_armv8_sha1_probe
 
 .globl _armv8_sha256_probe
 .type  _armv8_sha256_probe,%function
 _armv8_sha256_probe:
-#if defined(__thumb2__) && !defined(__APPLE__)
-.byte  0x00,0xff,0x40,0x0c @ sha256h.32q0,q0,q0
-#else
 .byte  0x40,0x0c,0x00,0xf3 @ sha256h.32q0,q0,q0
-#endif
bx  lr
 .size  _armv8_sha256_probe,.-_armv8_sha256_probe
+
 .globl _armv8_pmull_probe
 .type  _armv8_pmull_probe,%function
 _armv8_pmull_probe:
-#if defined(__thumb2__) && !defined(__APPLE__)
-.byte  0xa0,0xef,0x00,0x0e @ vmull.p64 q0,d0,d0
-#else
 .byte  0x00,0x0e,0xa0,0xf2 @ vmull.p64 q0,d0,d0
-#endif
bx  lr
 .size  _armv8_pmull_probe,.-_armv8_pmull_probe
-#endif
 
 .globl OPENSSL_wipe_cpu
 .type  OPENSSL_wipe_cpu,%function
 OPENSSL_wipe_cpu:
-#if __ARM_ARCH__>=7
ldr r0,.LOPENSSL_armcap
adr r1,.LOPENSSL_armcap
ldr r0,[r1,r0]
-#ifdef __APPLE__
-   ldr r0,[r0]
-#endif
-#endif
eor r2,r2,r2
eor r3,r3,r3
eor ip,ip,ip
-#if __ARM_ARCH__>=7
tst r0,#1
beq .Lwipe_done
veorq0, q0, q0
@@ -132,34 +79,14 @@ OPENSSL_wipe_cpu:
veorq14, q14, q14
veorq15, q15, q15
 .Lwipe_done:
-#endif
mov r0,sp
-#if __ARM_ARCH__>=5
bx  lr
-#else
-   tst lr,#1
-   moveq   pc,lr
-.word  0xe12fff1e  @ bxlr
-#endif
 .size  OPENSSL_wipe_cpu,.-OPENSSL_wipe_cpu
 
 .align 5
-#if __ARM_ARCH__>=7
 .LOPENSSL_armcap:
 .word  OPENSSL_armcap_P-.
-#endif
-#if __ARM_ARCH__>=6
 .align 5
-#else
-.Lspinlock:
-.word  atomic_add_spinlock-.Lspinlock
-.align 5
-
-.data
-.align 2
-atomic_add_spinlock:
-.word  0
-#endif
 
 .comm  OPENSSL_armcap_P,4,4
 .hiddenOPENSSL_armcap_P



Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-11 Thread Renaud Allard



On 6/11/19 10:17 AM, Renaud Allard wrote:


Hello,

Here is a patch with ecdsa and rsa in %token after the domain key name

OK? comments?


I just made a small modification in the formatting of acme.conf man 
page, putting keytype as an arg. And also a cleaner key.h


OK?
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/acme-client/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile	3 Jul 2017 22:21:47 -	1.8
+++ Makefile	11 Jun 2019 11:35:24 -
@@ -2,7 +2,7 @@
 PROG=		acme-client
 SRCS=		acctproc.c base64.c certproc.c chngproc.c dbg.c dnsproc.c
 SRCS+=		fileproc.c http.c jsmn.c json.c keyproc.c main.c netproc.c
-SRCS+=		parse.y revokeproc.c rsa.c util.c
+SRCS+=		parse.y revokeproc.c key.c util.c
 
 MAN=		acme-client.1 acme-client.conf.5
 
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.14
diff -u -p -r1.14 acctproc.c
--- acctproc.c	8 Jun 2019 07:52:55 -	1.14
+++ acctproc.c	11 Jun 2019 11:35:24 -
@@ -29,7 +29,7 @@
 #include 
 
 #include "extern.h"
-#include "rsa.h"
+#include "key.h"
 
 /*
  * Converts a BIGNUM to the form used in JWK.
@@ -352,7 +352,9 @@ acctproc(int netsock, const char *acctke
 			goto out;
 		dodbg("%s: generated RSA account key", acctkey);
 	} else {
-		if ((pkey = rsa_key_load(f, acctkey)) == NULL)
+		if ((pkey = key_load(f, acctkey)) == NULL)
+			goto out;
+		if (EVP_PKEY_type(pkey->type) != EVP_PKEY_RSA) 
 			goto out;
 		doddbg("%s: loaded RSA account key", acctkey);
 	}
Index: acme-client.conf.5
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.17
diff -u -p -r1.17 acme-client.conf.5
--- acme-client.conf.5	8 Jan 2019 06:46:29 -	1.17
+++ acme-client.conf.5	11 Jun 2019 11:35:24 -
@@ -109,8 +109,10 @@ Specify a list of alternative names for 
 The common name is included automatically if this option is present,
 but there is no automatic conversion/inclusion between "www." and
 plain domain name forms.
-.It Ic domain key Ar file
+.It Ic domain key Ar file Op Ar keytype
 The private key file for which the certificate will be obtained.
+.Ar keytype
+can be rsa or ecdsa. Defaults to rsa.
 .It Ic domain certificate Ar file
 The filename of the certificate that will be issued.
 This is optional if
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
retrieving revision 1.12
diff -u -p -r1.12 extern.h
--- extern.h	8 Jun 2019 07:52:55 -	1.12
+++ extern.h	11 Jun 2019 11:35:24 -
@@ -276,6 +276,11 @@ char		*json_fmt_signed(const char *, con
 int		 verbose;
 
 /*
+ * Should we switch to ecdsa?
+ */
+int		ecdsa;
+
+/*
  * What component is the process within (COMP__MAX for none)?
  */
 enum comp	 proccomp;
Index: key.c
===
RCS file: key.c
diff -N key.c
--- /dev/null	1 Jan 1970 00:00:00 -
+++ key.c	11 Jun 2019 11:35:24 -
@@ -0,0 +1,149 @@
+/*	$Id: rsa.c,v 1.7 2018/07/28 15:25:23 tb Exp $ */
+/*
+ * Copyright (c) 2019 Renaud Allard 
+ * Copyright (c) 2016 Kristaps Dzonsons 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "key.h"
+
+/*
+ * Default number of bits when creating a new RSA key.
+ */
+#define	KBITS 4096
+#define ECCTYPE NID_secp384r1
+
+/*
+ * Create an RSA key with the default KBITS number of bits.
+ */
+EVP_PKEY *
+rsa_key_create(FILE *f, const char *fname)
+{
+	EVP_PKEY_CTX	*ctx = NULL;
+	EVP_PKEY	*pkey = NULL;
+
+	/* First, create the context and the key. */
+
+	if ((ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL)) == NULL) {
+		warnx("EVP_PKEY_CTX_new_id");
+		goto err;
+	} else if (EVP_PKEY_keygen_init(ctx) <= 0) {
+		warnx("EVP_PKEY_keygen_init");
+		goto err;
+	} else if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, KBITS) <= 0) {
+		warnx("EVP_PKEY_set_rsa_keygen_bits");
+		goto err;
+	} else if (EVP_PKEY_keygen(ctx, ) <= 0) {
+		warnx("EVP_PKEY_keygen");
+		goto err;
+	}
+
+	/* Serialise the key to the disc. */

athn(4): Set frame's Tx duration and power

2019-06-11 Thread Stefan Sperling
Linux ath9k provides Tx time of an entire frame to hardware.
Make our athn(4) driver do the same.

ALso set registers which contain Tx power values for retried frames.

Please test.

diff 8885fdfe4213e1feed4da2ad98226517b33cdcf5 /usr/src
blob - 1890ab7d38911a4917ed03869d7cc734669506cb
file + sys/dev/ic/ar5008.c
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -1550,12 +1550,11 @@ ar5008_tx(struct athn_softc *sc, struct mbuf *m, struc
ridx[i] != ATHN_RIDX_CCK1 &&
(ic->ic_flags & IEEE80211_F_SHPREAMBLE))
series[i].hwrate |= 0x04;
-   series[i].dur = 0;
-   }
-   if (!(ds->ds_ctl1 & AR_TXC1_NO_ACK)) {
/* Compute duration for each series. */
-   for (i = 0; i < 4; i++) {
-   series[i].dur = athn_txtime(sc, IEEE80211_ACK_LEN,
+   series[i].dur = athn_txtime(sc, totlen, ridx[i], ic->ic_flags);
+   if (!(ds->ds_ctl1 & AR_TXC1_NO_ACK)) {
+   /* Account for ACK duration. */
+   series[i].dur += athn_txtime(sc, IEEE80211_ACK_LEN,
athn_rates[ridx[i]].rspridx, ic->ic_flags);
}
}
@@ -1600,6 +1599,11 @@ ar5008_tx(struct athn_softc *sc, struct mbuf *m, struc
if (ic->ic_flags & IEEE80211_F_CBW40)
ds->ds_ctl7 |= AR_TXC7_2040_0123;
 #endif
+
+   /* Set Tx power for series 1 - 3 */
+   ds->ds_ctl9 = SM(AR_TXC9_XMIT_POWER1, txpower);
+   ds->ds_ctl10 = SM(AR_TXC10_XMIT_POWER2, txpower);
+   ds->ds_ctl11 = SM(AR_TXC11_XMIT_POWER3, txpower);
 
if (ds->ds_ctl0 & (AR_TXC0_RTS_ENABLE | AR_TXC0_CTS_ENABLE)) {
uint8_t protridx, hwrate;
blob - 91349bcbee6f9a5443115c77f09fe5454f25e783
file + sys/dev/ic/ar5008reg.h
--- sys/dev/ic/ar5008reg.h
+++ sys/dev/ic/ar5008reg.h
@@ -809,6 +809,18 @@ struct ar_tx_desc {
 #define AR_TXC7_GI0123 \
(AR_TXC7_GI0 | AR_TXC7_GI1 | AR_TXC7_GI2 | AR_TXC7_GI3)
 
+/* Bits for ds_ctl9. */
+#define AR_TXC9_XMIT_POWER1_M  0x3f00
+#define AR_TXC9_XMIT_POWER1_S  24
+
+/* Bits for ds_ctl10. */
+#define AR_TXC10_XMIT_POWER2_M 0x3f00
+#define AR_TXC10_XMIT_POWER2_S 24
+
+/* Bits for ds_ctl11. */
+#define AR_TXC11_XMIT_POWER3_M 0x3f00
+#define AR_TXC11_XMIT_POWER3_S 24
+
 /* Bits for ds_status0. */
 #define AR_TXS0_RSSI_ANT0(i)   (((x) >> ((i) * 8)) & 0xff)
 #define AR_TXS0_BA_STATUS  0x4000



Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-11 Thread Renaud Allard



On 6/7/19 2:38 PM, Renaud Allard wrote:



On 6/7/19 2:28 PM, Florian Obser wrote:

On Fri, Jun 07, 2019 at 10:40:36AM +0200, Renaud Allard wrote:



On 6/6/19 10:46 AM, Renaud Allard wrote:



On 6/6/19 10:10 AM, Florian Obser wrote:


I currently don't have time to review this. I'm busy switching
acme-client to the rfc 8555 / letsencrypt v2 api. Doesn't look like
this conflicts too badly with my work, but I'd appreciate it if we
could hold this off for a bit and rebase it ontop of the v2 work.


OK, let's wait till your v2 is done. People have the patch already if
they want to try out ecdsa in the meantime.



Here is the patch after the v2 change.
I also changed ecdsa to int instead of bool as requested.



you forgot to include ecdsa.h this time around, but I found it in one
of the earlier diffs.

It is a bit silly though, just skip it, rename rsa.h to key.h and add
your ecdsa.h content there.





Hello,

Here is a patch with ecdsa and rsa in %token after the domain key name

OK? comments?
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/acme-client/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile	3 Jul 2017 22:21:47 -	1.8
+++ Makefile	11 Jun 2019 08:15:13 -
@@ -2,7 +2,7 @@
 PROG=		acme-client
 SRCS=		acctproc.c base64.c certproc.c chngproc.c dbg.c dnsproc.c
 SRCS+=		fileproc.c http.c jsmn.c json.c keyproc.c main.c netproc.c
-SRCS+=		parse.y revokeproc.c rsa.c util.c
+SRCS+=		parse.y revokeproc.c key.c util.c
 
 MAN=		acme-client.1 acme-client.conf.5
 
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.14
diff -u -p -r1.14 acctproc.c
--- acctproc.c	8 Jun 2019 07:52:55 -	1.14
+++ acctproc.c	11 Jun 2019 08:15:13 -
@@ -29,7 +29,7 @@
 #include 
 
 #include "extern.h"
-#include "rsa.h"
+#include "key.h"
 
 /*
  * Converts a BIGNUM to the form used in JWK.
@@ -352,7 +352,9 @@ acctproc(int netsock, const char *acctke
 			goto out;
 		dodbg("%s: generated RSA account key", acctkey);
 	} else {
-		if ((pkey = rsa_key_load(f, acctkey)) == NULL)
+		if ((pkey = key_load(f, acctkey)) == NULL)
+			goto out;
+		if (EVP_PKEY_type(pkey->type) != EVP_PKEY_RSA) 
 			goto out;
 		doddbg("%s: loaded RSA account key", acctkey);
 	}
Index: acme-client.conf.5
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.17
diff -u -p -r1.17 acme-client.conf.5
--- acme-client.conf.5	8 Jan 2019 06:46:29 -	1.17
+++ acme-client.conf.5	11 Jun 2019 08:15:13 -
@@ -109,8 +109,9 @@ Specify a list of alternative names for 
 The common name is included automatically if this option is present,
 but there is no automatic conversion/inclusion between "www." and
 plain domain name forms.
-.It Ic domain key Ar file
+.It Ic domain key Ar file Op Ar keytype
 The private key file for which the certificate will be obtained.
+keytype can be rsa or ecdsa. Defaults to rsa.
 .It Ic domain certificate Ar file
 The filename of the certificate that will be issued.
 This is optional if
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
retrieving revision 1.12
diff -u -p -r1.12 extern.h
--- extern.h	8 Jun 2019 07:52:55 -	1.12
+++ extern.h	11 Jun 2019 08:15:13 -
@@ -276,6 +276,11 @@ char		*json_fmt_signed(const char *, con
 int		 verbose;
 
 /*
+ * Should we switch to ecdsa?
+ */
+int		ecdsa;
+
+/*
  * What component is the process within (COMP__MAX for none)?
  */
 enum comp	 proccomp;
Index: key.c
===
RCS file: key.c
diff -N key.c
--- /dev/null	1 Jan 1970 00:00:00 -
+++ key.c	11 Jun 2019 08:15:14 -
@@ -0,0 +1,149 @@
+/*	$Id: rsa.c,v 1.7 2018/07/28 15:25:23 tb Exp $ */
+/*
+ * Copyright (c) 2019 Renaud Allard 
+ * Copyright (c) 2016 Kristaps Dzonsons 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "key.h"
+
+/*
+ * Default number of bits when creating a new RSA key.
+ */
+#define	

Re: bpf(4) free sizes

2019-06-11 Thread Alexandr Nedvedicky
Hello,

On Mon, Jun 10, 2019 at 01:53:06PM -0300, Martin Pieuchot wrote:
> `bd_bufsize' can change via the BIOCSBLEN ioctl(2) but iff the
> descriptor hasn't been linked to an interface.  Which means the
> buffers haven't been allocated yet.
> 
> ok?

reads OK to me.

regards
sashan
> 
> Index: net/bpf.c
> ===
> RCS file: /cvs/src/sys/net/bpf.c,v
> retrieving revision 1.175
> diff -u -p -r1.175 bpf.c
> --- net/bpf.c 18 May 2019 12:59:32 -  1.175
> +++ net/bpf.c 10 Jun 2019 16:42:56 -
> @@ -1579,9 +1579,9 @@ bpf_d_smr(void *smr)
>  {
>   struct bpf_d*bd = smr;
>  
> - free(bd->bd_sbuf, M_DEVBUF, 0);
> - free(bd->bd_hbuf, M_DEVBUF, 0);
> - free(bd->bd_fbuf, M_DEVBUF, 0);
> + free(bd->bd_sbuf, M_DEVBUF, bd->bd_bufsize);
> + free(bd->bd_hbuf, M_DEVBUF, bd->bd_bufsize);
> + free(bd->bd_fbuf, M_DEVBUF, bd->bd_bufsize);
>  
>   if (bd->bd_rfilter != NULL)
>   bpf_prog_smr(bd->bd_rfilter);
> 



Re: pf_state_key_link_reverse() needs atomic ops

2019-06-11 Thread Alexandr Nedvedicky
Hello,



> > > 
> > > yes that's correct. the patch above comes from my private branch [1].
> > > mpi@ pointed out in off-line email exchange the patch unlocks local 
> > > inbound
> > > packets too, which is coming bit early. However for forwarding case 
> > > things
> > > seem to work (given all the panics I could see and fix).
> > 
> > The way I understand Jono's question is: "Do we want this locking?".  If
> > we decide that a single flow will always be processed by a single CPU,
> > is this necessary?  If it isn't should we add an assert to document this
> > design decision?
> 
> That's why I was asking.  I'm not sure we want to make that guarantee, or at
> least not until we have a better idea of how rx hashing and things like tunnel
> protocols and nat interact.  Using atomics here seems like a reasonable way to
> defer that and allow progress in pf.
> 
> Are there other side-effects from pf_test() that we'll have to worry about?
> 

OK, thanks for clarification. We might hit similar assert in
pf_state_key_link_inpcb(). I have not seen a panic there, but I was not
playing with local bound traffic as there are perhaps more dragons hiding
there. 

I understand the advantage of putting same flows to same CPUs/cores. In
this case leaving pf_state_key_link_reverse() as-is makes sense. I'm sure
we can defer the decision whether take it or leave it.

> least not until we have a better idea of how rx hashing and things like tunnel
> protocols and nat interact.  Using atomics here seems like a reasonable way to

I'm not too much worried about rx hashing and tunnels. The tunnels, NAT and
rx hashing are nicely streamlined/aligned.  The way I see interaction of
tunnels with NAT is a chain of calls to pf_test(), so those calls are
serialized w.r.t. to individual packets as packets get
encapsulated/decapsulated. Let there be tun0, which 'sits' on top of em0.
Then for the outbound packet the processing looks as follows:

10.1.1.1/24 @ tun0  >   outbound packet intercepted by
by pf_test(). state either created
or matched. the state No 1 must be
something like:
10.1.1.x <-> a.b.c.d

|
|
V

tun0 encapsulates packet so it can get transported by
underlying NIC em0

|
|
V

192.168.1.1/24 @ em0>   outbound packet intercepted by
pf_test. state either created or
matched. The state No 2 must be
something like:
192.168.1.1 <-> a.b.c.d

|
|
V
packet leaves the box

There is no relation between states No 1 and No 2, PF just sees them
as two unrelated sessions. So if it comes to rx-hashing the hashing
will have to make sure the outbound packet will end up at right
CPU. As it moves from tun0 to em0. The NAT does not change things
much, it has just influence on routing decision when packet
is being forwarded. But forwarding decision is yet another action
happening on the way.

I'm more worried about policy based routing (route-to/reply-to) vs.
rx-hashing. PBR can twist things in funny manner.

thanks and
regards
sashan




Re: trunk(4) shouldn't need to play with a port's if_type

2019-06-11 Thread Reyk Floeter
Hi,

the initial intention was to differentiate a trunk port from a regular Ethernet 
interface.

As long as an interface is a member of a trunk, it is not a fully featured 
Ethernet interface. The changed type prevented from using it elsewhere.

I‘m not so familiar with the current network stack anymore, so maybe there are 
other ways to do it these days, but you should test that a trunk port cannot be 
attached to a bridge or carp or anything like this.

You also forgot a comment that mentions the type as well.

Reyk

> Am 11.06.2019 um 08:33 schrieb David Gwynne :
> 
> i think trunk(4) is the only thing left in the kernel that modifies an
> interfaces if_type at runtime. this diff removes that fiddling, so
> hopefully we can say that if_type is immutable after this.
> 
> however, while this diff reads well to me, i don't actually know if it
> works. could someone kick the tyres for me?
> 
> cheers,
> dlg
> 
> Index: if_trunk.c
> ===
> RCS file: /cvs/src/sys/net/if_trunk.c,v
> retrieving revision 1.140
> diff -u -p -r1.140 if_trunk.c
> --- if_trunk.c11 May 2019 18:10:45 -1.140
> +++ if_trunk.c11 Jun 2019 06:31:29 -
> @@ -330,10 +330,7 @@ trunk_port_create(struct trunk_softc *tr
>}
>}
> 
> -/* Change the interface type */
> -tp->tp_iftype = ifp->if_type;
> -ifp->if_type = IFT_IEEE8023ADLAG;
> -
> +/* Change the interface methods */
>tp->tp_ioctl = ifp->if_ioctl;
>ifp->if_ioctl = trunk_port_ioctl;
> 
> @@ -422,9 +419,7 @@ trunk_port_destroy(struct trunk_port *tp
>if (tr->tr_port_destroy != NULL)
>(*tr->tr_port_destroy)(tp);
> 
> -/* Restore interface type. */
> -ifp->if_type = tp->tp_iftype;
> -
> +/* Restore interface methods. */
>ifp->if_ioctl = tp->tp_ioctl;
>ifp->if_output = tp->tp_output;
> 
> @@ -474,8 +469,7 @@ trunk_port_ioctl(struct ifnet *ifp, u_lo
>int error = 0;
> 
>/* Should be checked by the caller */
> -if (ifp->if_type != IFT_IEEE8023ADLAG ||
> -(tp = trunk_port_get(NULL, ifp)) == NULL ||
> +if ((tp = trunk_port_get(NULL, ifp)) == NULL ||
>(tr = (struct trunk_softc *)tp->tp_trunk) == NULL) {
>error = EINVAL;
>goto fallback;
> @@ -521,8 +515,7 @@ trunk_port_output(struct ifnet *ifp, str
> struct rtentry *rt)
> {
>/* restrict transmission on trunk members to bpf only */
> -if (ifp->if_type == IFT_IEEE8023ADLAG &&
> -(m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
> +if ((m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
>m_freem(m);
>return (EBUSY);
>}
> @@ -1123,10 +1116,6 @@ trunk_input(struct ifnet *ifp, struct mb
>eh = mtod(m, struct ether_header *);
>if (ETHER_IS_MULTICAST(eh->ether_dhost))
>ifp->if_imcasts++;
> -
> -/* Should be checked by the caller */
> -if (ifp->if_type != IFT_IEEE8023ADLAG)
> -goto bad;
> 
>tp = (struct trunk_port *)cookie;
>if ((tr = (struct trunk_softc *)tp->tp_trunk) == NULL)
> 



Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-11 Thread Renaud Allard



On 6/7/19 2:28 PM, Florian Obser wrote:

On Fri, Jun 07, 2019 at 10:40:36AM +0200, Renaud Allard wrote:



On 6/6/19 10:46 AM, Renaud Allard wrote:



On 6/6/19 10:10 AM, Florian Obser wrote:


I currently don't have time to review this. I'm busy switching
acme-client to the rfc 8555 / letsencrypt v2 api. Doesn't look like
this conflicts too badly with my work, but I'd appreciate it if we
could hold this off for a bit and rebase it ontop of the v2 work.


OK, let's wait till your v2 is done. People have the patch already if
they want to try out ecdsa in the meantime.



Here is the patch after the v2 change.
I also changed ecdsa to int instead of bool as requested.



you forgot to include ecdsa.h this time around, but I found it in one
of the earlier diffs.

It is a bit silly though, just skip it, rename rsa.h to key.h and add
your ecdsa.h content there.



Here is a patch without the flag.
I know you told me not to strncmp the keytype, but I don't see how to 
produce an understandable error if I use tokens and without making 
repetitions in the code.




? acctproc.d
? acme-client
? base64.d
? certproc.d
? chngproc.d
? dbg.d
? dnsproc.d
? fileproc.d
? http.d
? jsmn.d
? json.d
? key.d
? keyproc.d
? main.d
? netproc.d
? parse.c
? parse.d
? revokeproc.d
? util.d
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/acme-client/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile	3 Jul 2017 22:21:47 -	1.8
+++ Makefile	11 Jun 2019 06:58:25 -
@@ -2,7 +2,7 @@
 PROG=		acme-client
 SRCS=		acctproc.c base64.c certproc.c chngproc.c dbg.c dnsproc.c
 SRCS+=		fileproc.c http.c jsmn.c json.c keyproc.c main.c netproc.c
-SRCS+=		parse.y revokeproc.c rsa.c util.c
+SRCS+=		parse.y revokeproc.c key.c util.c
 
 MAN=		acme-client.1 acme-client.conf.5
 
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.14
diff -u -p -r1.14 acctproc.c
--- acctproc.c	8 Jun 2019 07:52:55 -	1.14
+++ acctproc.c	11 Jun 2019 06:58:25 -
@@ -29,7 +29,7 @@
 #include 
 
 #include "extern.h"
-#include "rsa.h"
+#include "key.h"
 
 /*
  * Converts a BIGNUM to the form used in JWK.
@@ -352,7 +352,9 @@ acctproc(int netsock, const char *acctke
 			goto out;
 		dodbg("%s: generated RSA account key", acctkey);
 	} else {
-		if ((pkey = rsa_key_load(f, acctkey)) == NULL)
+		if ((pkey = key_load(f, acctkey)) == NULL)
+			goto out;
+		if (EVP_PKEY_type(pkey->type) != EVP_PKEY_RSA) 
 			goto out;
 		doddbg("%s: loaded RSA account key", acctkey);
 	}
Index: acme-client.conf.5
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.17
diff -u -p -r1.17 acme-client.conf.5
--- acme-client.conf.5	8 Jan 2019 06:46:29 -	1.17
+++ acme-client.conf.5	11 Jun 2019 06:58:26 -
@@ -111,6 +111,8 @@ but there is no automatic conversion/inc
 plain domain name forms.
 .It Ic domain key Ar file
 The private key file for which the certificate will be obtained.
+.It Ic domain keytype Ar type
+The type of key used for the domain. Can be RSA or ECDSA.
 .It Ic domain certificate Ar file
 The filename of the certificate that will be issued.
 This is optional if
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
retrieving revision 1.12
diff -u -p -r1.12 extern.h
--- extern.h	8 Jun 2019 07:52:55 -	1.12
+++ extern.h	11 Jun 2019 06:58:26 -
@@ -276,6 +276,11 @@ char		*json_fmt_signed(const char *, con
 int		 verbose;
 
 /*
+ * Should we switch to ecdsa?
+ */
+int		ecdsa;
+
+/*
  * What component is the process within (COMP__MAX for none)?
  */
 enum comp	 proccomp;
Index: key.c
===
RCS file: key.c
diff -N key.c
--- /dev/null	1 Jan 1970 00:00:00 -
+++ key.c	11 Jun 2019 06:58:26 -
@@ -0,0 +1,149 @@
+/*	$Id: rsa.c,v 1.7 2018/07/28 15:25:23 tb Exp $ */
+/*
+ * Copyright (c) 2019 Renaud Allard 
+ * Copyright (c) 2016 Kristaps Dzonsons 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 

trunk(4) shouldn't need to play with a port's if_type

2019-06-11 Thread David Gwynne
i think trunk(4) is the only thing left in the kernel that modifies an
interfaces if_type at runtime. this diff removes that fiddling, so
hopefully we can say that if_type is immutable after this.

however, while this diff reads well to me, i don't actually know if it
works. could someone kick the tyres for me?

cheers,
dlg

Index: if_trunk.c
===
RCS file: /cvs/src/sys/net/if_trunk.c,v
retrieving revision 1.140
diff -u -p -r1.140 if_trunk.c
--- if_trunk.c  11 May 2019 18:10:45 -  1.140
+++ if_trunk.c  11 Jun 2019 06:31:29 -
@@ -330,10 +330,7 @@ trunk_port_create(struct trunk_softc *tr
}
}
 
-   /* Change the interface type */
-   tp->tp_iftype = ifp->if_type;
-   ifp->if_type = IFT_IEEE8023ADLAG;
-
+   /* Change the interface methods */
tp->tp_ioctl = ifp->if_ioctl;
ifp->if_ioctl = trunk_port_ioctl;
 
@@ -422,9 +419,7 @@ trunk_port_destroy(struct trunk_port *tp
if (tr->tr_port_destroy != NULL)
(*tr->tr_port_destroy)(tp);
 
-   /* Restore interface type. */
-   ifp->if_type = tp->tp_iftype;
-
+   /* Restore interface methods. */
ifp->if_ioctl = tp->tp_ioctl;
ifp->if_output = tp->tp_output;
 
@@ -474,8 +469,7 @@ trunk_port_ioctl(struct ifnet *ifp, u_lo
int error = 0;
 
/* Should be checked by the caller */
-   if (ifp->if_type != IFT_IEEE8023ADLAG ||
-   (tp = trunk_port_get(NULL, ifp)) == NULL ||
+   if ((tp = trunk_port_get(NULL, ifp)) == NULL ||
(tr = (struct trunk_softc *)tp->tp_trunk) == NULL) {
error = EINVAL;
goto fallback;
@@ -521,8 +515,7 @@ trunk_port_output(struct ifnet *ifp, str
 struct rtentry *rt)
 {
/* restrict transmission on trunk members to bpf only */
-   if (ifp->if_type == IFT_IEEE8023ADLAG &&
-   (m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
+   if ((m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
m_freem(m);
return (EBUSY);
}
@@ -1123,10 +1116,6 @@ trunk_input(struct ifnet *ifp, struct mb
eh = mtod(m, struct ether_header *);
if (ETHER_IS_MULTICAST(eh->ether_dhost))
ifp->if_imcasts++;
-
-   /* Should be checked by the caller */
-   if (ifp->if_type != IFT_IEEE8023ADLAG)
-   goto bad;
 
tp = (struct trunk_port *)cookie;
if ((tr = (struct trunk_softc *)tp->tp_trunk) == NULL)