Re: ripd(8) fails on P2P links

[Chris Cappuccio]

Piotr Durlej [pi...@durlej.net] wrote:
> 
> And here is a patch:
> 

Whoops, I missed this part...And unlike mine it is correct, as there may
not be a destination configured. I think this is the right way to go.

> diff --git a/usr.sbin/ripd/packet.c b/usr.sbin/ripd/packet.c
> index 37b4a91..b956ec0 100644
> --- a/usr.sbin/ripd/packet.c
> +++ b/usr.sbin/ripd/packet.c
> @@ -232,15 +232,17 @@ find_iface(struct ripd_conf *xconf, unsigned int
> ifindex, struct in_addr src)
> 
>  /* returned interface needs to be active */
>  LIST_FOREACH(iface, >iface_list, entry) {
> -if (ifindex != 0 && ifindex == iface->ifindex &&
> -!iface->passive && (iface->addr.s_addr &
> +if (ifindex == 0 || ifindex != iface->ifindex)
> +continue;
> +
> +if (iface->passive)
> +continue;
> +
> +if ((iface->addr.s_addr &
>  iface->mask.s_addr) == (src.s_addr & iface->mask.s_addr))
> -/*
> - * XXX may fail on P2P links because src and dst don't
> - * have to share a common subnet on the otherhand
> - * checking something like this will help to support
> - * multiple networks configured on one interface.
> - */
> +return (iface);
> +
> +if (iface->dst.s_addr && iface->dst.s_addr == src.s_addr)
>  return (iface);
>  }
> 

Re: ripd(8) fails on P2P links

[Chris Cappuccio]

For P2P links, the destination address should be configured as
the peer. If so, perhaps this works?

Index: packet.c
===
RCS file: /cvs/src/usr.sbin/ripd/packet.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 packet.c
--- packet.c25 Oct 2014 03:23:49 -  1.12
+++ packet.c6 Dec 2016 01:34:09 -
@@ -233,15 +233,13 @@ find_iface(struct ripd_conf *xconf, unsi
/* returned interface needs to be active */
LIST_FOREACH(iface, >iface_list, entry) {
if (ifindex != 0 && ifindex == iface->ifindex &&
-   !iface->passive && (iface->addr.s_addr &
-   iface->mask.s_addr) == (src.s_addr & iface->mask.s_addr))
-   /*
-* XXX may fail on P2P links because src and dst don't
-* have to share a common subnet on the otherhand
-* checking something like this will help to support
-* multiple networks configured on one interface.
-*/
-   return (iface);
+   !iface->passive) {
+   if ((iface->addr.s_addr & iface->mask.s_addr) == 
+   (src.s_addr & iface->mask.s_addr))
+   return (iface);
+   if (iface->dst.s_addr == src.s_addr)
+   return (iface);
+   }
}
 
return (NULL);

ripd(8) fails on P2P links

[Piotr Durlej]

Hi,

I dislike cross-posting/repeated posting but I was advised to do so by
mpi@.

I just want to make sure my previous mail sent to bugs@ hasn't gone
unnoticed.

The problem is that ripd(8) is unable to determine the interface on
which a RIP packet was received when the source and destination
addresses of the interface do not share the same subnet.

Additionally, when ran with the -d switch, ripd(8) produces the
following error message every time a valid RIP packet is received on
the interface in question:

"recv_packet: cannot find a matching interface".

Here is an example:

Script started on Wed Nov 23 08:58:36 2016
# ifconfig gre0

gre0: flags=9011 mtu 1476
 index 5 priority 0 llprio 3
 groups: gre
 tunnel: inet 192.168.0.1 -> 192.168.0.2
 inet 192.168.1.1 --> 192.168.1.2 netmask 0x
# ripd -dv

startup
[...]
recv_packet: cannot find a matching interface
^C
[...]
terminating
# tcpdump -s1500 -vnlpi gre0

tcpdump: listening on gre0, link-type LOOP
08:59:37.627530 192.168.1.2.520 > 224.0.0.9.520: [udp sum ok]
RIPv2-resp [items 2]: {172.22.1.0/255.255.255.0}(1)
{192.168.0.0/255.255.255.0}(1) [tos 0xc0] [ttl 1] (id 47684, len 72)
^C
1 packets received by filter
0 packets dropped by kernel
# ^D


Script done on Wed Nov 23 09:00:10 2016

And here is a patch:

diff --git a/usr.sbin/ripd/packet.c b/usr.sbin/ripd/packet.c
index 37b4a91..b956ec0 100644
--- a/usr.sbin/ripd/packet.c
+++ b/usr.sbin/ripd/packet.c
@@ -232,15 +232,17 @@ find_iface(struct ripd_conf *xconf, unsigned int 
ifindex, struct in_addr src)


 /* returned interface needs to be active */
 LIST_FOREACH(iface, >iface_list, entry) {
-if (ifindex != 0 && ifindex == iface->ifindex &&
-!iface->passive && (iface->addr.s_addr &
+if (ifindex == 0 || ifindex != iface->ifindex)
+continue;
+
+if (iface->passive)
+continue;
+
+if ((iface->addr.s_addr &
 iface->mask.s_addr) == (src.s_addr & iface->mask.s_addr))
-/*
- * XXX may fail on P2P links because src and dst don't
- * have to share a common subnet on the otherhand
- * checking something like this will help to support
- * multiple networks configured on one interface.
- */
+return (iface);
+
+if (iface->dst.s_addr && iface->dst.s_addr == src.s_addr)
 return (iface);
 }

Kind regards,
Piotr

Re: cwm bind changes

[Okan Demirmen]

On Mon 2016.12.05 at 22:16 +, Stuart Henderson wrote:
> On 2016/12/05 21:38, Stuart Henderson wrote:
> > On 2016/11/26 14:57, Okan Demirmen wrote:
> > > 
> > > 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 *'.
> > 
> > This also changes some _ to -, for example
> > 
> > mousebind M-2 window_lower
> > mousebind M-3 window_resize
> > 
> > now needs to be
> > 
> > bind-mouse M-2 window-lower
> > bind-mouse M-3 window-resize
> > 
> > Had me confused for a few minutes..
> > 
> 
> here's a cheat-sheet.

Thanks; I didn't realize there'd be trouble, else I would have published
something like this along with the change (one small mistake on my part
below, fixing...).

> old   new
> 
> bind  bind-key
> mousebind bind-mouse
> bind ... unmapunbind-key ...
> mousebind ... unmap   unbind-mouse ...
> 
> lower window-lower
> window_lower  window-lower
> raise window-raise
> window_raise  window-raise
> hide  window-hide
> window_hide   window-hide
> 
> htile window-htile
> vtile window-vtile
> 
> cycle window-cycle
> rcyclewindow-rcycle
> deletewindow-delete
> searchwindow-search

oops, 'window-search' shouldn't be in here; it's below as 'menu-window'!

> label window-menu-label
> stick window-stick
> fullscreenwindow-fullscreen
> maximize  window-maximize
> vmaximize window-vmaximize
> hmaximize window-hmaximize
> freezewindow-freeze
> 
> move  window-move
> moveupwindow-move-up
> movedown  window-move-down
> moveright window-move-right
> moveleft  window-move-left
> bigmoveup window-move-up-big
> bigmovedown   window-move-down-big
> bigmoveright  window-move-right-big
> bigmoveleft   window-move-left-big
> 
> resizewindow-resize
> resizeup  window-resize-up
> resizedownwindow-resize-down
> resizeright   window-resize-right
> resizeleftwindow-resize-left
> bigresizeup   window-resize-up-big
> bigresizedown window-resize-down-big
> bigresizerightwindow-resize-right-big
> bigresizeleft window-resize-left-big
> 
> movetogroup1..9   window-movetogroup-1..9
> 
> nogroup   group-toggle-all
> group1..9 group-toggle-1..9
> grouponly1..9 group-only-1..9
> cyclegroupgroup-cycle
> rcyclegroup   group-rcycle
> cycleingroup  window-cycle-ingroup
> rcycleingroup window-rcycle-ingroup
> 
> grouptoggle   window-group
> window_grouptogglewindow-group
> 
> ptrmoveup pointer-move-up
> ptrmovedown   pointer-move-down
> ptrmoveleft   pointer-move-left
> ptrmoveright  pointer-move-right
> bigptrmoveup  pointer-move-up-big
> bigptrmovedownpointer-move-down-big
> bigptrmoveleftpointer-move-left-big
> bigptrmoveright   pointer-move-right-big
> 
> menu_cmd  menu-cmd
> menusearchmenu-cmd
> menu_groupmenu-group
> groupsearch   menu-group
> menu_unhide   menu-window
> ssh   menu-ssh
> exec  menu-exec
> exec_wm   menu-exec-wm
> 

Re: cwm bind changes

[Stuart Henderson]

On 2016/12/05 21:38, Stuart Henderson wrote:
> On 2016/11/26 14:57, Okan Demirmen wrote:
> > 
> > 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 *'.
> 
> This also changes some _ to -, for example
> 
> mousebind M-2 window_lower
> mousebind M-3 window_resize
> 
> now needs to be
> 
> bind-mouse M-2 window-lower
> bind-mouse M-3 window-resize
> 
> Had me confused for a few minutes..
> 

here's a cheat-sheet.

old new

bindbind-key
mousebind   bind-mouse
bind ... unmap  unbind-key ...
mousebind ... unmap unbind-mouse ...

lower   window-lower
window_lowerwindow-lower
raise   window-raise
window_raisewindow-raise
hidewindow-hide
window_hide window-hide

htile   window-htile
vtile   window-vtile

cycle   window-cycle
rcycle  window-rcycle
delete  window-delete
search  window-search

label   window-menu-label
stick   window-stick
fullscreen  window-fullscreen
maximizewindow-maximize
vmaximize   window-vmaximize
hmaximize   window-hmaximize
freeze  window-freeze

movewindow-move
moveup  window-move-up
movedownwindow-move-down
moveright   window-move-right
moveleftwindow-move-left
bigmoveup   window-move-up-big
bigmovedown window-move-down-big
bigmoverightwindow-move-right-big
bigmoveleft window-move-left-big

resize  window-resize
resizeupwindow-resize-up
resizedown  window-resize-down
resizeright window-resize-right
resizeleft  window-resize-left
bigresizeup window-resize-up-big
bigresizedown   window-resize-down-big
bigresizeright  window-resize-right-big
bigresizeleft   window-resize-left-big

movetogroup1..9 window-movetogroup-1..9

nogroup group-toggle-all
group1..9   group-toggle-1..9
grouponly1..9   group-only-1..9
cyclegroup  group-cycle
rcyclegroup group-rcycle
cycleingroupwindow-cycle-ingroup
rcycleingroup   window-rcycle-ingroup

grouptoggle window-group
window_grouptoggle  window-group

ptrmoveup   pointer-move-up
ptrmovedown pointer-move-down
ptrmoveleft pointer-move-left
ptrmoverightpointer-move-right
bigptrmoveuppointer-move-up-big
bigptrmovedown  pointer-move-down-big
bigptrmoveleft  pointer-move-left-big
bigptrmoveright pointer-move-right-big

menu_cmdmenu-cmd
menusearch  menu-cmd
menu_group  menu-group
groupsearch menu-group
menu_unhide menu-window
ssh menu-ssh
execmenu-exec
exec_wm menu-exec-wm

[PATCH] softraid.4 move wd(4) examples to sd(4)

[Bryan Vyhmeister]

In responding to a post on misc@, I noticed that bioctl(8) uses all sd(4)
devices in the examples sections while softraid(4) uses wd(4) devices
for the chunks. This patch updates softraid.4 to use sd(4) devices as
well. I have not used a wd(4) device in years and I think it more
confusing to use examples with wd(4) when almost everything these days
is sd(4).

Bryan


Index: share/man/man4/softraid.4
===
RCS file: /cvs/src/share/man/man4/softraid.4,v
retrieving revision 1.41
diff -u -p -r1.41 softraid.4
--- share/man/man4/softraid.4   14 Apr 2015 19:10:13 -  1.41
+++ share/man/man4/softraid.4   5 Dec 2016 21:58:55 -
@@ -121,41 +121,41 @@ An example to create a 3 chunk RAID 1 fr
 .Pp
 Initialize the partition tables of all disks:
 .Bd -literal -offset indent
-# fdisk -iy wd1
-# fdisk -iy wd2
-# fdisk -iy wd3
+# fdisk -iy sd1
+# fdisk -iy sd2
+# fdisk -iy sd3
 .Ed
 .Pp
 Now create RAID partitions on all disks:
 .Bd -literal -offset indent
-# printf "a\en\en\en\enRAID\enw\enq\en\en" | disklabel -E wd1
-# printf "a\en\en\en\enRAID\enw\enq\en\en" | disklabel -E wd2
-# printf "a\en\en\en\enRAID\enw\enq\en\en" | disklabel -E wd3
+# printf "a\en\en\en\enRAID\enw\enq\en\en" | disklabel -E sd1
+# printf "a\en\en\en\enRAID\enw\enq\en\en" | disklabel -E sd2
+# printf "a\en\en\en\enRAID\enw\enq\en\en" | disklabel -E sd3
 .Ed
 .Pp
 Assemble the RAID volume:
 .Bd -literal -offset indent
-# bioctl -c 1 -l /dev/wd1a,/dev/wd2a,/dev/wd3a softraid0
+# bioctl -c 1 -l /dev/sd1a,/dev/sd2a,/dev/sd3a softraid0
 .Ed
 .Pp
 The console will show what device was added to the system:
 .Bd -literal -offset indent
 scsibus0 at softraid0: 1 targets
-sd0 at scsibus0 targ 0 lun 0:  SCSI2
-sd0: 1MB, 0 cyl, 255 head, 63 sec, 512 bytes/sec, 3714 sec total
+sd4 at scsibus0 targ 0 lun 0:  SCSI2
+sd4: 1MB, 0 cyl, 255 head, 63 sec, 512 bytes/sec, 3714 sec total
 .Ed
 .Pp
 It is good practice to wipe the front of the disk before using it:
 .Bd -literal -offset indent
-# dd if=/dev/zero of=/dev/rsd0c bs=1m count=1
+# dd if=/dev/zero of=/dev/rsd4c bs=1m count=1
 .Ed
 .Pp
 Initialize the partition table and create a filesystem on the
 new RAID volume:
 .Bd -literal -offset indent
-# fdisk -iy sd0
-# printf "a\en\en\en\en4.2BSD\enw\enq\en\en" | disklabel -E sd0
-# newfs /dev/rsd0a
+# fdisk -iy sd4
+# printf "a\en\en\en\en4.2BSD\enw\enq\en\en" | disklabel -E sd4
+# newfs /dev/rsd4a
 .Ed
 .Pp
 The RAID volume is now ready to be used as a normal disk device.
@@ -167,7 +167,7 @@ Install
 .Xr boot 8
 on the RAID volume:
 .Bd -literal -offset indent
-# installboot sd0
+# installboot sd4
 .Ed
 .Pp
 At the

Re: cwm bind changes

[Stuart Henderson]

On 2016/11/26 14:57, Okan Demirmen wrote:
> 
> 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 *'.

This also changes some _ to -, for example

mousebind M-2 window_lower
mousebind M-3 window_resize

now needs to be

bind-mouse M-2 window-lower
bind-mouse M-3 window-resize

Had me confused for a few minutes..

Re: dhcrelay: allow it to work as part of a chain

[Jeremie Courreges-Anglas]

Patrick Wildt  writes:

> Hi,
>
> DHCP requests can be relayed through multiple relays.  There are two parts in
> the RFC that we don't oblige and thus make dhcrelay impossible to use through
> multiple relays.
>
> The BOOTREQUEST message has a gateway ip addr attribute (giaddr).  This is
> used by the DHCP server to correlate which subnet the DHCP client is connected
> to and asks information for.  It has to be only set by the first relay, since
> this is the IP from the subnet the DHCP client runs in.  Currently we ignore
> a request which already has the giaddr attribute set.  This means the dhcrelay
> will refuse to be part of a relay chain.  Instead we should continue forward-
> ing the packet and simply only update the attribute if it hasn't been set
> already.

This would makes dhcrelay behave when it's not the first relay in the
chain.  However it doesn't help when it is.

Addresses start with 192.168...

[server] <-> [relay1] <-> [relay2] <-> [client]
  1.1   1.22.1   2.23.1

Here dhcrelay on relay2 ignores replies sent by 192.168.1.1 to
192.168.3.1, because its UDP socket is bound to 192.168.3.1 but
connected to 192.168.2.2.

Do you use dhcrelay from base as the relay agent on relay2?

> The RFC specifies that on BOOTREQUEST messages, we must increase the hopcount
> if we relay a packet.  If the hopcount exceeds a value of 16, we must silently
> ignore the packet.

I must be looking at the wrong RFC.  How did you pick 16? :)

> Considering we can now actually be part of a relay chain,
> this check helps with a broken configuration where the relays are set up to
> become a loop.

> Does anyone actually use this program?

Probably not with multi-relays setups. ;)

> ok?

ok jca@

> Patrick
>
> diff --git a/usr.sbin/dhcrelay/dhcrelay.c b/usr.sbin/dhcrelay/dhcrelay.c
> index 497656b..791a3d5 100644
> --- a/usr.sbin/dhcrelay/dhcrelay.c
> +++ b/usr.sbin/dhcrelay/dhcrelay.c
> @@ -323,18 +323,21 @@ relay(struct interface_info *ip, struct dhcp_packet 
> *packet, int length,
>   return;
>   }
>  
> - /* If giaddr is set on a BOOTREQUEST, ignore it - it's already
> -been gatewayed. */
> - if (packet->giaddr.s_addr) {
> - note("ignoring BOOTREQUEST with giaddr of %s",
> - inet_ntoa(packet->giaddr));
> + if (packet->hops > 16) {
> + note("ignoring BOOTREQUEST with hop count of %d",
> + packet->hops);
>   return;
>   }
> -
> - /* Set the giaddr so the server can figure out what net it's
> -from and so that we can later forward the response to the
> -correct net. */
> - packet->giaddr = ip->primary_address;
> + packet->hops++;
> +
> + /*
> +  * Set the giaddr so the server can figure out what net it's
> +  * from and so that we can later forward the response to the
> +  * correct net.  The RFC specifies that we have to keep the
> +  * initial giaddr (in case we relay over multiple hops).
> +  */
> + if (!packet->giaddr.s_addr)
> + packet->giaddr = ip->primary_address;
>  
>   if ((length = relay_agentinfo(ip, packet, length,
>   (struct in_addr *)from.iabuf, NULL)) == -1) {
>

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

Re: ospfd - handling mtu changes

[Remi Locherer]

On Tue, Nov 29, 2016 at 12:14:40PM +0100, Jeremie Courreges-Anglas wrote:
> Remi Locherer  writes:
> 
> > 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!
> 
> Thanks for confirming.  There's one thing that bugs me when I change the
> mtu on an interface:
> 
> if_fsm: interface vether0, event UP not expected in state WAIT
> interface vether0 up
> if_fsm: interface vether0, event UP not expected in state WAIT
> interface vether0 up
> 
> "not expected" or "really, should not happen"?  Maybe this routing
> message (or the one that could be sent for SIOCSIFXFLAGS) is breaking
> some kind of assumption here?  Input welcome.

Sorry to not reply any sooner.

The message is generated by if_fsm in interface.c. I found Claudio's
drawing from the interface state machine here:
https://www.openbsd.org/papers/eurobsd2005/claudio/mgp00015.html

If the mtu is changed while OSPF is running state machine has no definition
for handling the event IF_EVT_UP. This additional patch teachs ospfd that
no action is required in this situation.

The message is now:
if_fsm: event UP resulted in action NOTHING and changing state for interface 
pair0 from DR to DR
interface pair0 up

I checked what a Brocade FastIron router does when the mtu (ip mtu) changes
after the ospf adjacency has been formed: nothing.


Index: interface.c
===
RCS file: /cvs/src/usr.sbin/ospfd/interface.c,v
retrieving revision 1.81
diff -u -p -r1.81 interface.c
--- interface.c 5 Dec 2015 12:20:13 -   1.81
+++ interface.c 5 Dec 2016 17:02:40 -
@@ -55,6 +55,8 @@ struct {
 } iface_fsm[] = {
 /* current state   event that happened action to take  resulting state 
*/
 {IF_STA_DOWN,  IF_EVT_UP,  IF_ACT_STRT,0},
+{IF_STA_WAITING,   IF_EVT_UP,  IF_ACT_NOTHING, 0},
+{IF_STA_MULTI, IF_EVT_UP,  IF_ACT_NOTHING, 0},
 {IF_STA_WAITING,   IF_EVT_BACKUP_SEEN, IF_ACT_ELECT,   0},
 {IF_STA_WAITING,   IF_EVT_WTIMER,  IF_ACT_ELECT,   0},
 {IF_STA_ANY,   IF_EVT_WTIMER,  IF_ACT_NOTHING, 0},


> 
> 
> >> 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
> >> 

Re: BFD: route get and route monitor

[Peter Hessler]

On 2016 Sep 30 (Fri) at 10:16:19 +0200 (+0200), Peter Hessler wrote:
:This diff makes route get and route monitor work.  sockaddr_bfd is so we
:can play like the other RTAX_* indexes in rti_info of route messages.
:
:OK?
:
:
:$ route -n monitor
:got message of size 128 on Wed Sep 28 21:35:32 2016
:RTM_BFD: bidirectional forwarding detection: len 128
:BFD mode async state down remotestate down laststate admindown error 0
:localdiscr 4002401056 remotediscr 0 localdiag none remotediag none
:uptime 04m46s lastuptime 00s mintx 100 minrx 1 minecho 0 multiplier 3
:
:sockaddrs: 
: 192.168.50.1 192.168.50.61
:
:$ route -n get 192.168.50.1
:   route to: 192.168.50.1
:destination: 192.168.50.1
:   mask: 255.255.255.255
:  interface: vio0
: if address: 192.168.50.61
:   priority: 4 (connected)
:  flags: 
:BFD mode async state down remotestate down laststate admindown error 0
:localdiscr 4002401056 remotediscr 0 localdiag none remotediag none
:uptime 05m13s lastuptime 00s mintx 100 minrx 1 minecho 0 multiplier 3
: use   mtuexpire
:   8 0   879 
:sockaddrs: 
:

Here is a new diff, generated against -current.  No changes to the code.

OK?


Index: sbin/route/Makefile
===
RCS file: /cvs/src/sbin/route/Makefile,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 Makefile
--- sbin/route/Makefile 19 Jul 2013 14:41:46 -  1.13
+++ sbin/route/Makefile 5 Dec 2016 10:34:48 -
@@ -4,7 +4,7 @@ PROG=   route
 MAN=   route.8
 SRCS=  route.c show.c
 
-CFLAGS+=   -Wall
+CFLAGS+=   -Wall -DBFD
 
 route.o .depend lint tags: keywords.h
 
Index: sbin/route/route.c
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.192
diff -u -p -u -p -r1.192 route.c
--- sbin/route/route.c  24 Sep 2016 19:36:49 -  1.192
+++ sbin/route/route.c  5 Dec 2016 10:34:48 -
@@ -100,6 +100,7 @@ const char *bfd_state(unsigned int);
 const char *bfd_diag(unsigned int);
 const char *bfd_calc_uptime(time_t);
 voidprint_bfdmsg(struct rt_msghdr *);
+voidprint_sabfd(struct sockaddr_bfd *);
 #endif
 const char *get_linkstate(int, int);
 voidprint_rtmsg(struct rt_msghdr *, int);
@@ -1439,6 +1440,9 @@ print_getmsg(struct rt_msghdr *rtm, int 
struct sockaddr *dst = NULL, *gate = NULL, *mask = NULL, *ifa = NULL;
struct sockaddr_dl *ifp = NULL;
struct sockaddr_rtlabel *sa_rl = NULL;
+#ifdef BFD
+   struct sockaddr_bfd *sa_bfd = NULL;
+#endif
struct sockaddr *mpls = NULL;
struct sockaddr *sa;
char *cp;
@@ -1487,6 +1491,11 @@ print_getmsg(struct rt_msghdr *rtm, int 
case RTA_LABEL:
sa_rl = (struct sockaddr_rtlabel *)sa;
break;
+#ifdef BFD
+   case RTA_BFD:
+   sa_bfd = (struct sockaddr_bfd *)sa;
+   break;
+#endif
}
ADVANCE(cp, sa);
}
@@ -1519,6 +1528,10 @@ print_getmsg(struct rt_msghdr *rtm, int 
printf("\n");
if (sa_rl != NULL)
printf("  label: %s\n", sa_rl->sr_label);
+#ifdef BFD
+   if (sa_bfd)
+   print_sabfd(sa_bfd);
+#endif
 
 #define lock(f)((rtm->rtm_rmx.rmx_locks & __CONCAT(RTV_,f)) ? 'L' : ' 
')
relative_expire = rtm->rtm_rmx.rmx_expire ?
@@ -1621,12 +1634,21 @@ void
 print_bfdmsg(struct rt_msghdr *rtm)
 {
struct bfd_msghdr *bfdm = (struct bfd_msghdr *)rtm;
+
+   printf("\n");
+   print_sabfd(>bm_sa);
+   pmsg_addrs(((char *)rtm + rtm->rtm_hdrlen), rtm->rtm_addrs);
+}
+
+void
+print_sabfd(struct sockaddr_bfd *sa_bfd)
+{
struct timeval tv;
 
gettimeofday(, NULL);
 
-   printf(" mode ");
-   switch (bfdm->bm_mode) {
+   printf("BFD mode ");
+   switch (sa_bfd->bs_mode) {
case BFD_MODE_ASYNC:
printf("async");
break;
@@ -1634,27 +1656,26 @@ print_bfdmsg(struct rt_msghdr *rtm)
printf("demand");
break;
default:
-   printf("unknown %u", bfdm->bm_mode);
+   printf("unknown %u", sa_bfd->bs_mode);
break;
}
-   printf(" state %s", bfd_state(bfdm->bm_state));
-   printf(" remotestate %s", bfd_state(bfdm->bm_remotestate));
-   printf(" laststate %s", bfd_state(bfdm->bm_laststate));
-
-   printf(" error %d", bfdm->bm_error);
-   printf(" localdiscr %u", bfdm->bm_localdiscr);
-   printf(" remotediscr %u", bfdm->bm_remotediscr);
-   printf(" localdiag %s", bfd_diag(bfdm->bm_localdiag));
-   printf(" remotediag %s", 

Re: update Mesa to 13.0.2

[Jonathan Gray]

On Mon, Dec 05, 2016 at 12:20:59PM +0100, Matthieu Herrb wrote:
> On Sun, Dec 04, 2016 at 10:45:34PM +1100, Jonathan Gray wrote:
> > cd /usr/xenocara/lib
> > ftp https://mesa.freedesktop.org/archive/13.0.2/mesa-13.0.2.tar.gz
> > tar zxf mesa-13.0.2.tar.gz
> > patch -p0 < /path/to/mesa.diff
> > 
> > sed -i 's/mesa$/mesa-13.0.2/' Makefile
> > 
> > build xenocara as normal
> > 
> 
> Seems to work for me where I tested so far. (Intel Skylake and radeon
> 3650, both amd64). 
> 
> I guess the rename to mesa-13.0.2 is only for testing.. You will
> put the new version in 'mesa' for the commit, right?

Yes, that is just to avoid cvs conflicts.

in terms of other archs, runs on i386 with x40/i915 and t42/r100 radeon,
working my way through more test machines but I don't expect any problems.

Builds on arm and the compiler bug there seems to be back in hiding
as glxgears now slowly runs over forwarding without crashing.

Re: update Mesa to 13.0.2

[Matthieu Herrb]

On Sun, Dec 04, 2016 at 10:45:34PM +1100, Jonathan Gray wrote:
> cd /usr/xenocara/lib
> ftp https://mesa.freedesktop.org/archive/13.0.2/mesa-13.0.2.tar.gz
> tar zxf mesa-13.0.2.tar.gz
> patch -p0 < /path/to/mesa.diff
> 
> sed -i 's/mesa$/mesa-13.0.2/' Makefile
> 
> build xenocara as normal
> 

Seems to work for me where I tested so far. (Intel Skylake and radeon
3650, both amd64). 

I guess the rename to mesa-13.0.2 is only for testing.. You will
put the new version in 'mesa' for the commit, right?

-- 
Matthieu Herrb


signature.asc
Description: Digital signature

Re: doas.conf(5): clarify args

[Ingo Schwarze]

Hi Ted,

Ted Unangst wrote on Sun, Dec 04, 2016 at 07:52:38PM -0500:

> i guess.

Thanks for having a look; committed.


> What does No do? I don't see any difference.

It is useful on two different levels:

 1. Semantic:
Currently, the word "..." is inside the .Ic macro.
So it means "you can repeat the previous comand here",
which means that any of the following would be valid:

args
args args
args args args

The .No takes it out of the .Ic and labels it as "no markup"
which is both customary for punctuation and also signals
"interpret this word naively rather than formally" - in this
case the intent is: Something was left out here, but we don't
say (yet) what that is.

 2. Presentational:
Currectly, the "..." is bold.
The .No uses normal font instead, which is more usual
for punctuation.

These are advanced details, though.  Don't worry if they seem a bit
arcane to you.  Just write manuals, and jmc@ and myself will
"tweak previous" occasionally.  :)

> I definitely would prefer to avoid long strings of ]].

True, that would make the synopsis harder to understand.

Yours,
  Ingo

Re: ntpd(8): use stack instead of heap

[Brent Cook]

OK bcook@

On Fri, Dec 2, 2016 at 10:29 AM, Rafael Zalamena 
wrote:

> On Sat, Oct 01, 2016 at 07:05:51PM +0200, Rafael Zalamena wrote:
> > The ntpd(8) constraint fork+exec diff changed the way the constraint
> > processes are created, but then it introduced new calloc()s to avoid
> > increasing diff size and to focus on the problem. Now that the fork+exec
> > is in, this diff make those variables to become a part of the stack.
> >
> > No functional changes, just changing variables storage location.
> >
> > ok?
>
> Ping.
>
> Updated diff to apply on the latest ntpd sources.
>
> ok?
>
> Index: usr.sbin/ntpd//constraint.c
> ===
> RCS file: /home/obsdcvs/src/usr.sbin/ntpd/constraint.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 constraint.c
> --- usr.sbin/ntpd//constraint.c 18 Oct 2016 22:05:47 -  1.34
> +++ usr.sbin/ntpd//constraint.c 2 Dec 2016 16:27:15 -
> @@ -321,8 +321,8 @@ priv_constraint_readquery(struct constra
>  void
>  priv_constraint_child(const char *pw_dir, uid_t pw_uid, gid_t pw_gid)
>  {
> -   struct constraint   *cstr;
> -   struct ntp_addr_msg *am;
> +   struct constraintcstr;
> +   struct ntp_addr_msg  am;
> uint8_t *data;
> static char  addr[NI_MAXHOST];
> struct timeval   rectv, xmttv;
> @@ -336,10 +336,6 @@ priv_constraint_child(const char *pw_dir
> if (setpriority(PRIO_PROCESS, 0, 0) == -1)
> log_warn("could not set priority");
>
> -   if ((cstr = calloc(1, sizeof(*cstr))) == NULL ||
> -   (am = calloc(1, sizeof(*am))) == NULL)
> -   fatal("%s: calloc", __func__);
> -
> /* Init TLS and load CA certs before chroot() */
> if (tls_init() == -1)
> fatalx("tls_init");
> @@ -368,9 +364,9 @@ priv_constraint_child(const char *pw_dir
> if (pledge("stdio inet", NULL) == -1)
> fatal("pledge");
>
> -   cstr->fd = CONSTRAINT_PASSFD;
> -   imsg_init(>ibuf, cstr->fd);
> -   priv_constraint_readquery(cstr, am, );
> +   cstr.fd = CONSTRAINT_PASSFD;
> +   imsg_init(, cstr.fd);
> +   priv_constraint_readquery(, , );
>
> /*
>  * Get the IP address as name and set the process title
> accordingly.
> @@ -378,8 +374,8 @@ priv_constraint_child(const char *pw_dir
>  * any DNS operation, so it is safe to be called without the dns
>  * pledge.
>  */
> -   if (getnameinfo((struct sockaddr *)>addr->ss,
> -   SA_LEN((struct sockaddr *)>addr->ss),
> +   if (getnameinfo((struct sockaddr *)>ss,
> +   SA_LEN((struct sockaddr *)>ss),
> addr, sizeof(addr), NULL, 0,
> NI_NUMERICHOST) != 0)
> fatalx("%s getnameinfo", __func__);
> @@ -398,21 +394,21 @@ priv_constraint_child(const char *pw_dir
> fatal("%s fcntl F_SETFD", __func__);
>
> /* Get remaining data from imsg in the unpriv child */
> -   if (am->namelen) {
> -   if ((cstr->addr_head.name =
> -   get_string(data, am->namelen)) == NULL)
> +   if (am.namelen) {
> +   if ((cstr.addr_head.name =
> +   get_string(data, am.namelen)) == NULL)
> fatalx("invalid IMSG_CONSTRAINT_QUERY name");
> -   data += am->namelen;
> +   data += am.namelen;
> }
> -   if (am->pathlen) {
> -   if ((cstr->addr_head.path =
> -   get_string(data, am->pathlen)) == NULL)
> +   if (am.pathlen) {
> +   if ((cstr.addr_head.path =
> +   get_string(data, am.pathlen)) == NULL)
> fatalx("invalid IMSG_CONSTRAINT_QUERY path");
> }
>
> /* Run! */
> if ((ctx = httpsdate_query(addr,
> -   CONSTRAINT_PORT, cstr->addr_head.name, cstr->addr_head.path,
> +   CONSTRAINT_PORT, cstr.addr_head.name, cstr.addr_head.path,
> conf->ca, conf->ca_len, , )) == NULL) {
> /* Abort with failure but without warning */
> exit(1);
> @@ -422,10 +418,10 @@ priv_constraint_child(const char *pw_dir
> iov[0].iov_len = sizeof(rectv);
> iov[1].iov_base = 
> iov[1].iov_len = sizeof(xmttv);
> -   imsg_composev(>ibuf,
> +   imsg_composev(,
> IMSG_CONSTRAINT_RESULT, 0, 0, -1, iov, 2);
> do {
> -   rv = imsg_flush(>ibuf);
> +   rv = imsg_flush();
> } while (rv == -1 && errno == EAGAIN);
>
> /* Tear down the TLS connection after sending the result */
>
>