[patch] Skip DHCP responsefile if no interface is given

2016-11-26 Thread Matthew Martin
Don't force the user to pick an interface if the responsefile is on
a disk.

- Matthew Martin


Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.932
diff -u -p -r1.932 install.sub
--- install.sub 24 Nov 2016 14:35:43 -  1.932
+++ install.sub 27 Nov 2016 05:17:01 -
@@ -529,6 +529,7 @@ get_responsefile() {
while (($# > 1)); do
ask_which "network interface" \
"should be used for the initial DHCP request" 
"$*"
+   [[ $resp == done ]] && break 2
isin "$resp" $* && _if=$resp && break
done
[[ -n $_if ]] && dhclient $_if || break



test TSC timecounter

2016-11-26 Thread Reyk Floeter
Hi,

we have figured out that the acpihpet(4) timecounter is extremely slow
on recent Intel platforms, especially on Skylake.  This diff adds the
TSC timecounter if it is an invariant TSC and the diff enables it by
default on Skylake or newer.  Non-invariant TSCs are not intended to
be supported as a timecounter source.

The TSC timecounter also helps on older pre-Skylake CPUs but the clock
frequency is not very accurate.  And the older HPETs aren't that slow.
So you will have to enable it manually there (see below).

To test it:

# sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=tsc
kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) 
dummy(-100)

Change the timecounter (you might see different values and defaults):

# sysctl kern.timecounter.hardware=tsc

Select tsc, delete /var/db/ntpd.drift and run ntpd -d in foreground.
Please watch the offsets of the peers - they should be somewhere in
the 0.x range.  Most importantly, they should not increase over time.
If ntpd doesn't manage to sync the clock (look for clock synced in
ntpctl -s all), the clock is not good enough.  If the clock syncs,
please wait until you find a value in /var/db/ntpd.drift (might take
very long) - a good value is somewhere around +/- 10.  +/- 100 might
also still be acceptable but not very precise.

Now you can also directly compare tsc with acpihpet0 with the
following microbenchmark.  It should also make a difference with
relayd etc.

$ time perl -e 'use Time::HiRes qw(gettimeofday);
for ($i = 0; $i < 100; $i++) { gettimeofday(); }'

Feel free to send me your dmesg in private (especially the cpu0 lines).

This diff includes bits and pieces from of kettenis, mikeb and me.

Reyk

Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.78
diff -u -p -u -p -r1.78 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 13 Oct 2016 19:36:25 -  1.78
+++ sys/arch/amd64/amd64/identcpu.c 26 Nov 2016 19:08:44 -
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vmm.h"
 
@@ -56,6 +57,12 @@ void cpu_check_vmm_cap(struct cpu_info *
 char cpu_model[48];
 int cpuspeed;
 
+u_int tsc_get_timecount(struct timecounter *tc);
+
+struct timecounter tsc_timecounter = {
+   tsc_get_timecount, NULL, ~0u, 0, "tsc", 0, NULL
+};
+
 int amd64_has_xcrypt;
 #ifdef CRYPTO
 int amd64_has_pclmul;
@@ -385,6 +392,7 @@ cpu_tsc_freq_ctr(struct cpu_info *ci)
u_int64_t count, last_count, msr;
 
if ((ci->ci_flags & CPUF_CONST_TSC) == 0 ||
+   (ci->ci_flags & CPUF_INVAR_TSC) ||
(cpu_perf_eax & CPUIDEAX_VERID) <= 1 ||
CPUIDEDX_NUM_FC(cpu_perf_edx) <= 1)
return (0);
@@ -420,6 +428,40 @@ u_int64_t
 cpu_tsc_freq(struct cpu_info *ci)
 {
u_int64_t last_count, count;
+   uint32_t eax, ebx, khz, dummy;
+
+   if (!strcmp(cpu_vendor, "GenuineIntel") &&
+   cpuid_level >= 0x15) {
+   eax = ebx = khz = dummy = 0;
+   CPUID(0x15, eax, ebx, khz, dummy);
+   khz /= 1000;
+   if (khz == 0) {
+   switch (ci->ci_model) {
+   case 0x4e: /* Skylake mobile */
+   case 0x5e: /* Skylake desktop */
+   case 0x8e: /* Kabylake mobile */
+   case 0x9e: /* Kabylake desktop */
+   khz = 24000; /* 24.0 Mhz */
+   break;
+   case 0x55: /* Skylake X */
+   khz = 25000; /* 25.0 Mhz */
+   break;
+   case 0x5c: /* Atom Goldmont */
+   khz = 19200; /* 19.2 Mhz */
+   break;
+   }
+   }
+   if (ebx == 0 || eax == 0)
+   count = 0;
+   else if ((count = khz * ebx / eax) != 0) {
+   /*
+* Using the CPUID-derived frequency increases
+* the quality of the TSC time counter.
+*/
+   tsc_timecounter.tc_quality = 2000;
+   return (count * 1000);
+   }
+   }
 
count = cpu_tsc_freq_ctr(ci);
if (count != 0)
@@ -432,6 +474,12 @@ cpu_tsc_freq(struct cpu_info *ci)
return ((count - last_count) * 10);
 }
 
+u_int
+tsc_get_timecount(struct timecounter *tc)
+{
+   return rdtsc();
+}
+
 void
 identifycpu(struct cpu_info *ci)
 {
@@ -513,6 +561,10 @@ identifycpu(struct cpu_info *ci)
ci->ci_flags |= CPUF_CONST_TSC;
}
}
+
+   /* Check if it's an invariant TSC */
+   if (cpu_apmi_edx & CPUIDE

cwm bind changes

2016-11-26 Thread Okan Demirmen
Hi cwm users,

In an effort to normalize all the bindings added over time, as well as those
now duplicated since many keyboard vs mouse bindings are now the same, the
below diff splits the bindings into a few categories: window, group, menu and
pointer. These new ones should match their actual function more closely now.

In addition, I've changed the 'bind' and 'mousebind' config options to
'bind-key' and 'bind-mouse', respectively. The 'unmap' option is replaced by
'unbind-key' and 'unbind-mouse'. By popular request by those who customize
everything, one can now also unbind key/mouse at once with '*', i.e.
'unbind-key *' or 'unbind-mouse *'.

Hopefully these new action names make more sense; they will allow adding some
more functions that will more closely match what they do.

Looking at the resulting conf.c or cwmrc(5) list might make it easier to 
read the proposal.

Thanks,
Okan

Index: conf.c
===
RCS file: /home/open/cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.224
diff -u -p -r1.224 conf.c
--- conf.c  15 Nov 2016 00:22:02 -  1.224
+++ conf.c  25 Nov 2016 16:35:36 -
@@ -35,7 +35,9 @@
 static const char  *conf_bind_getmask(const char *, unsigned int *);
 static void conf_cmd_remove(struct conf *, const char *);
 static void conf_unbind_key(struct conf *, struct bind_ctx *);
+static void conf_unbind_key_all(struct conf *);
 static void conf_unbind_mouse(struct conf *, struct bind_ctx *);
+static void conf_unbind_mouse_all(struct conf *);
 
 static int cursor_binds[] = {
XC_left_ptr,/* CF_NORMAL */
@@ -60,129 +62,129 @@ static const struct {
int  context;
union argargument;
 } name_to_func[] = {
-   { "lower", kbfunc_client_lower, CWM_CONTEXT_CC, {0} },
-   { "raise", kbfunc_client_raise, CWM_CONTEXT_CC, {0} },
-   { "search", kbfunc_menu_client, CWM_CONTEXT_SC, {0} },
-   { "menusearch", kbfunc_menu_cmd, CWM_CONTEXT_SC, {0} },
-   { "groupsearch", kbfunc_menu_group, CWM_CONTEXT_SC, {0} },
-   { "hide", kbfunc_client_hide, CWM_CONTEXT_CC, {0} },
-   { "cycle", kbfunc_client_cycle, CWM_CONTEXT_SC,
+   { "window-menu-label", kbfunc_menu_client_label, CWM_CONTEXT_CC, {0} },
+   { "window-lower", kbfunc_client_lower, CWM_CONTEXT_CC, {0} },
+   { "window-raise", kbfunc_client_raise, CWM_CONTEXT_CC, {0} },
+   { "window-search", kbfunc_menu_client, CWM_CONTEXT_SC, {0} },
+   { "window-hide", kbfunc_client_hide, CWM_CONTEXT_CC, {0} },
+   { "window-delete", kbfunc_client_delete, CWM_CONTEXT_CC, {0} },
+   { "window-htile", kbfunc_client_htile, CWM_CONTEXT_CC, {0} },
+   { "window-vtile", kbfunc_client_vtile, CWM_CONTEXT_CC, {0} },
+   { "window-stick", kbfunc_client_toggle_sticky, CWM_CONTEXT_CC, {0} },
+   { "window-fullscreen", kbfunc_client_toggle_fullscreen, CWM_CONTEXT_CC, 
{0} },
+   { "window-maximize", kbfunc_client_toggle_maximize, CWM_CONTEXT_CC, {0} 
},
+   { "window-vmaximize", kbfunc_client_toggle_vmaximize, CWM_CONTEXT_CC, 
{0} },
+   { "window-hmaximize", kbfunc_client_toggle_hmaximize, CWM_CONTEXT_CC, 
{0} },
+   { "window-freeze", kbfunc_client_toggle_freeze, CWM_CONTEXT_CC, {0} },
+   { "window-cycle", kbfunc_client_cycle, CWM_CONTEXT_SC,
{.i = (CWM_CYCLE_FORWARD)} },
-   { "rcycle", kbfunc_client_cycle, CWM_CONTEXT_SC,
+   { "window-rcycle", kbfunc_client_cycle, CWM_CONTEXT_SC,
{.i = (CWM_CYCLE_REVERSE)} },
-   { "label", kbfunc_menu_client_label, CWM_CONTEXT_CC, {0} },
-   { "delete", kbfunc_client_delete, CWM_CONTEXT_CC, {0} },
-   { "group1", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 1} },
-   { "group2", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 2} },
-   { "group3", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 3} },
-   { "group4", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 4} },
-   { "group5", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 5} },
-   { "group6", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 6} },
-   { "group7", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 7} },
-   { "group8", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 8} },
-   { "group9", kbfunc_group_toggle, CWM_CONTEXT_SC, {.i = 9} },
-   { "grouponly1", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 1} },
-   { "grouponly2", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 2} },
-   { "grouponly3", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 3} },
-   { "grouponly4", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 4} },
-   { "grouponly5", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 5} },
-   { "grouponly6", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 6} },
-   { "grouponly7", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 7} },
-   { "grouponly8", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 8} },
-   { "grouponly9", kbfunc_group_only, CWM_CONTEXT_SC, {.i = 

Re: UEFI install fails on Hetzner EX51

2016-11-26 Thread Jiri B
On Wed, Nov 23, 2016 at 03:29:55PM +0100, Leo Unglaub wrote:
> Hey,
> 
> On 11/23/16 15:17, Mark Kettenis wrote:
> >Right, something like that would work if you copy the OpenBSD EFI
> >bootloader into /EFI/OpenBSD/BOOTX64.EFI on the EFI system partition
> >first.
> 
> why do i have to copy the EFI file first? Does the order matter?
> 
> If yes, the correct workflow would be the following;
> 
> 1: Install OpenBSD
> 2: Start a Live-Linux image
> 3: Write the UEFI entry with efibootmgr
> 4: Reboot and hope the best :)
> 
> Or does someone have a better suggestion? What about efibootmgr, is it worth
> importing it into the OpenBSD source tree? Or do you guys want to do it
> yourself and create something like a uefictl with a clean CLI to manage UEFI
> corrcetly. I am not sure what the best way to go is here, but UEFI is not
> going away and the people using it are only going to get more and more do to
> larger discs becoming more common.
> 
> Greetings
> Leo
> 

Just a note, people could run UEFI VM inside qemu on OpenBSD. See
https://github.com/tianocore/tianocore.github.io/wiki/How-to-run-OVMF

I only installed OpenBSD inside qemu with OVMF on OpenBSD and at least
it booted fine.

j.



Re: man page fix: bioctl -d does not delete anything

2016-11-26 Thread Daniel Jakots
On Sat, 26 Nov 2016 16:40:41 +0100, Stefan Sperling 
wrote:

> I think "delete" is too strong a word and confusing in the context
> of hard disks. What really happens is that the volume is "detached"
> and can be reattached later (either manually with bioctl(8), or it
> will auto-assemble).
>
> ok?

Yes please. Because of this wording, there is a sentence in the FAQ
(last line): https://www.openbsd.org/faq/faq14.html#softraidCrypto
 
> Index: bioctl.8
> ===
> RCS file: /cvs/src/sbin/bioctl/bioctl.8,v
> retrieving revision 1.102
> diff -u -p -r1.102 bioctl.8
> --- bioctl.8  21 Sep 2016 17:57:33 -  1.102
> +++ bioctl.8  26 Nov 2016 15:37:06 -
> @@ -231,7 +231,7 @@ be provided via
>  RAID 5 requires at least three devices
>  and the CRYPTO discipline requires exactly one.
>  .It Fl d
> -Delete volume specified by device.
> +Detach volume specified by device.
>  .It Fl k Ar keydisk
>  Use special device
>  .Ar keydisk
> @@ -308,7 +308,7 @@ This can be done with the following comm
>  # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
>  .Ed
>  .Pp
> -Deleting a softraid volume requires the exact volume name.
> +Detaching a softraid volume requires the exact volume name.
>  For example:
>  .Bd -literal -offset 3n
>  # bioctl -d sd2
> 



man page fix: bioctl -d does not delete anything

2016-11-26 Thread Stefan Sperling
I think "delete" is too strong a word and confusing in the context
of hard disks. What really happens is that the volume is "detached"
and can be reattached later (either manually with bioctl(8), or it
will auto-assemble).

ok?

Index: bioctl.8
===
RCS file: /cvs/src/sbin/bioctl/bioctl.8,v
retrieving revision 1.102
diff -u -p -r1.102 bioctl.8
--- bioctl.821 Sep 2016 17:57:33 -  1.102
+++ bioctl.826 Nov 2016 15:37:06 -
@@ -231,7 +231,7 @@ be provided via
 RAID 5 requires at least three devices
 and the CRYPTO discipline requires exactly one.
 .It Fl d
-Delete volume specified by device.
+Detach volume specified by device.
 .It Fl k Ar keydisk
 Use special device
 .Ar keydisk
@@ -308,7 +308,7 @@ This can be done with the following comm
 # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
 .Ed
 .Pp
-Deleting a softraid volume requires the exact volume name.
+Detaching a softraid volume requires the exact volume name.
 For example:
 .Bd -literal -offset 3n
 # bioctl -d sd2



Re: ospfd - handling mtu changes

2016-11-26 Thread Remi Locherer
On Sat, Nov 26, 2016 at 09:39:40AM +0100, Jeremie Courreges-Anglas wrote:
> Remi Locherer  writes:
> 
> > Hi,
> >
> > I ran into problems with mtu sizes on interfaces (gif in my case) and
> > ospfd. mtu was not the same on both sites so adjacency could not be
> > formed. The mtu mismatch is also logged by ospfd.
> >
> > Just changing the MTU with ifconfig is not enough in such a case. I did
> > not want to restart ospfd since that produces an outage. What I did:
> >
> > * ifconfig gif1 down
> > * vi /etc/ospfd.conf -> remove gif1
> > * ospfctl reload
> > * ifconfig gif1 mtu 1380 up
> > * vi /etc/ospfd.conf -> add gif1
> > * ospfctl reload
> >
> > To make this a bit easier I propose the below two patches.
> >
> > The first displays the mtu currently known by ospd with ospfctl. Eg:
> >
> > -
> > remi@mistral:~% doas /usr/src/usr.sbin/ospfctl/obj/ospfctl sho int iwm0
> >
> > Interface iwm0, line protocol is UP
> >   Internet address 172.18.35.224/24, Area 0.0.0.0
> >   Linkstate active, MTU 1500
> > 
> >   Router ID 10.10.10.1, network type BROADCAST, cost: 10
> >   Transmit delay is 1 sec(s), state DR, priority 1
> >   Designated Router (ID) 10.10.10.1, interface address 172.18.35.224
> >   Backup Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
> >   Timer intervals configured, hello 10, dead 40, wait 40, retransmit 5
> > Hello timer due in 00:00:06+345msec
> > Uptime 00:00:44
> >   Neighbor count is 0, adjacent neighbor count is 0
> > -
> 
> Makes sense.
> 
> >
> > The second patch allows ospfd to learn about a changed mtu value (or other
> > interface configs) with a "ospfctl reload".
> >
> > Would it be better if an mtu change generates a route message that is
> > picked up by ospfd the same way as other changes to interfaces configs?
> 
> I think so.  Does the diff below work for you?
> 

Yes this works. With that I can just fix the mtu without reloading ospfd.
Nice!

> 
> Index: sys/net/if.c
> ===
> RCS file: /d/cvs/src/sys/net/if.c,v
> retrieving revision 1.462
> diff -u -p -r1.462 if.c
> --- sys/net/if.c  21 Nov 2016 09:09:06 -  1.462
> +++ sys/net/if.c  26 Nov 2016 08:26:08 -
> @@ -1886,6 +1886,8 @@ ifioctl(struct socket *so, u_long cmd, c
>   if (ifp->if_ioctl == NULL)
>   return (EOPNOTSUPP);
>   error = (*ifp->if_ioctl)(ifp, cmd, data);
> + if (!error)
> + rt_ifmsg(ifp);
>   break;
>  
>   case SIOCSIFPHYADDR:
> Index: usr.sbin/ospfctl/ospfctl.c
> ===
> RCS file: /d/cvs/src/usr.sbin/ospfctl/ospfctl.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 ospfctl.c
> --- usr.sbin/ospfctl/ospfctl.c3 Dec 2015 11:42:14 -   1.63
> +++ usr.sbin/ospfctl/ospfctl.c26 Nov 2016 08:23:52 -
> @@ -434,8 +434,9 @@ show_interface_detail_msg(struct imsg *i
>   inet_ntoa(iface->addr),
>   mask2prefixlen(iface->mask.s_addr));
>   printf("Area %s\n", inet_ntoa(iface->area));
> - printf("  Linkstate %s\n",
> + printf("  Linkstate %s,",
>   get_linkstate(iface->if_type, iface->linkstate));
> + printf(" MTU %d\n", iface->mtu);
>   printf("  Router ID %s, network type %s, cost: %d\n",
>   inet_ntoa(iface->rtr_id),
>   if_type_name(iface->type), iface->metric);
> Index: usr.sbin/ospfd/ospfe.c
> ===
> RCS file: /d/cvs/src/usr.sbin/ospfd/ospfe.c,v
> retrieving revision 1.96
> diff -u -p -r1.96 ospfe.c
> --- usr.sbin/ospfd/ospfe.c3 Sep 2016 10:22:57 -   1.96
> +++ usr.sbin/ospfd/ospfe.c26 Nov 2016 08:30:34 -
> @@ -318,6 +318,7 @@ ospfe_dispatch_main(int fd, short event,
>   iface->flags = kif->flags;
>   iface->linkstate =
>   kif->link_state;
> + iface->mtu = kif->mtu;
>  
>   if (link_ok) {
>   if_fsm(iface,
> 
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: ospfd - handling mtu changes

2016-11-26 Thread Jeremie Courreges-Anglas
Remi Locherer  writes:

> Hi,
>
> I ran into problems with mtu sizes on interfaces (gif in my case) and
> ospfd. mtu was not the same on both sites so adjacency could not be
> formed. The mtu mismatch is also logged by ospfd.
>
> Just changing the MTU with ifconfig is not enough in such a case. I did
> not want to restart ospfd since that produces an outage. What I did:
>
> * ifconfig gif1 down
> * vi /etc/ospfd.conf -> remove gif1
> * ospfctl reload
> * ifconfig gif1 mtu 1380 up
> * vi /etc/ospfd.conf -> add gif1
> * ospfctl reload
>
> To make this a bit easier I propose the below two patches.
>
> The first displays the mtu currently known by ospd with ospfctl. Eg:
>
> -
> remi@mistral:~% doas /usr/src/usr.sbin/ospfctl/obj/ospfctl sho int iwm0
>
> Interface iwm0, line protocol is UP
>   Internet address 172.18.35.224/24, Area 0.0.0.0
>   Linkstate active, MTU 1500
> 
>   Router ID 10.10.10.1, network type BROADCAST, cost: 10
>   Transmit delay is 1 sec(s), state DR, priority 1
>   Designated Router (ID) 10.10.10.1, interface address 172.18.35.224
>   Backup Designated Router (ID) 0.0.0.0, interface address 0.0.0.0
>   Timer intervals configured, hello 10, dead 40, wait 40, retransmit 5
> Hello timer due in 00:00:06+345msec
> Uptime 00:00:44
>   Neighbor count is 0, adjacent neighbor count is 0
> -

Makes sense.

>
> The second patch allows ospfd to learn about a changed mtu value (or other
> interface configs) with a "ospfctl reload".
>
> Would it be better if an mtu change generates a route message that is
> picked up by ospfd the same way as other changes to interfaces configs?

I think so.  Does the diff below work for you?


Index: sys/net/if.c
===
RCS file: /d/cvs/src/sys/net/if.c,v
retrieving revision 1.462
diff -u -p -r1.462 if.c
--- sys/net/if.c21 Nov 2016 09:09:06 -  1.462
+++ sys/net/if.c26 Nov 2016 08:26:08 -
@@ -1886,6 +1886,8 @@ ifioctl(struct socket *so, u_long cmd, c
if (ifp->if_ioctl == NULL)
return (EOPNOTSUPP);
error = (*ifp->if_ioctl)(ifp, cmd, data);
+   if (!error)
+   rt_ifmsg(ifp);
break;
 
case SIOCSIFPHYADDR:
Index: usr.sbin/ospfctl/ospfctl.c
===
RCS file: /d/cvs/src/usr.sbin/ospfctl/ospfctl.c,v
retrieving revision 1.63
diff -u -p -r1.63 ospfctl.c
--- usr.sbin/ospfctl/ospfctl.c  3 Dec 2015 11:42:14 -   1.63
+++ usr.sbin/ospfctl/ospfctl.c  26 Nov 2016 08:23:52 -
@@ -434,8 +434,9 @@ show_interface_detail_msg(struct imsg *i
inet_ntoa(iface->addr),
mask2prefixlen(iface->mask.s_addr));
printf("Area %s\n", inet_ntoa(iface->area));
-   printf("  Linkstate %s\n",
+   printf("  Linkstate %s,",
get_linkstate(iface->if_type, iface->linkstate));
+   printf(" MTU %d\n", iface->mtu);
printf("  Router ID %s, network type %s, cost: %d\n",
inet_ntoa(iface->rtr_id),
if_type_name(iface->type), iface->metric);
Index: usr.sbin/ospfd/ospfe.c
===
RCS file: /d/cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.96
diff -u -p -r1.96 ospfe.c
--- usr.sbin/ospfd/ospfe.c  3 Sep 2016 10:22:57 -   1.96
+++ usr.sbin/ospfd/ospfe.c  26 Nov 2016 08:30:34 -
@@ -318,6 +318,7 @@ ospfe_dispatch_main(int fd, short event,
iface->flags = kif->flags;
iface->linkstate =
kif->link_state;
+   iface->mtu = kif->mtu;
 
if (link_ok) {
if_fsm(iface,


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE