Re: pf: drop tcp packet when syn AND fin flags are set

2022-03-14 Thread Remi Locherer
On Mon, Mar 14, 2022 at 01:27:14AM +0100, Alexander Bluhm wrote: > On Sun, Mar 13, 2022 at 11:24:33PM +0100, Remi Locherer wrote: > > Hi, > > > > When pf processes a TCP packet with SYN and FIN flags set, it removes > > the FIN flag and continuous process

pf: drop tcp packet when syn AND fin flags are set

2022-03-13 Thread Remi Locherer
Hi, When pf processes a TCP packet with SYN and FIN flags set, it removes the FIN flag and continuous processing it. I propose we change that and let pf drop such a packet. I don't see any legit use for combining these two flags in the same packet. Henning added this comment 7 years ago: XXX

Re: ospfd/ospf6d, interfaces in log messages

2021-11-03 Thread Remi Locherer
On Tue, Nov 02, 2021 at 05:27:11PM +, Stuart Henderson wrote: > I've recently started seeing a number of flaps with ospfd/ospf6d > with invalid seq nums / "seq num mismatch, bad flags" logged. > Not quite sure what's going yet as they must be occurring on > various local switched segments on

Re: wg(4) ipv6 ospf6d

2021-08-26 Thread Remi Locherer
On Wed, Aug 25, 2021 at 10:29:36PM +0100, Stuart Henderson wrote: > On 2021/08/25 13:33, Daniel Jakots wrote: > > On Wed, 25 Aug 2021 18:02:11 +0100, Stuart Henderson > > wrote: > > > > > If I manually configure a link-local the interface is successfully > > > added. > > > > > > Anyone have an

fix ospf6d.conf example

2021-03-26 Thread Remi Locherer
Hi, danj@ noticed that our ospf6d.conf example is using multiple areas. In the man page of ospf6d we state that multi area support is not available. The daemon accepts such a config but does not do the right thing if I remember correctly. OK to change the example to use just one area? Remi

Re: ping graphical display

2021-02-20 Thread Remi Locherer
On February 19, 2021 8:56:31 PM UTC, Stuart Henderson wrote: >Canvassing opinions on having . and ! this way around. I'm using . for >response, ! for no response, which makes more sense to me but it's been >pointed out that it's the opposite of what cisco does so it might >confuse >some people.

Re: fix: ospf6d(8): wrong intra area announcement

2020-10-05 Thread Remi Locherer
On Fri, Oct 02, 2020 at 02:01:09AM +0200, Jan Klemkow wrote: > Hi, > > The new intra area db entry has to be saved into the tree before > orig_intra_area_prefix_lsas() is called. If not, the ospf6d will not > announce the new intra area db for a newly learned link from another > ospf router of

Re: rdomain.4: on removing rtables

2020-09-22 Thread Remi Locherer
On Tue, Sep 22, 2020 at 10:03:29PM +0200, Klemens Nanni wrote: > We have never been able to remove an rtable; until claudio moved them > explicitly with rtable_l2set() in if_loop.c:loop_clone_destroy(), i.e. > > revision 1.90 > date: 2020/01/08 09:09:10; author: claudio; state:

Re: rdomain.4: add netstat -R example

2020-09-22 Thread Remi Locherer
On Tue, Sep 22, 2020 at 08:54:31PM +0200, Klemens Nanni wrote: > It's handy and otherwise easily missed when reading up on routing > domains and tables; wording taken from netstat(1) as is. > > Not listing pgrep(1)'s `-T' because examples don't have to be exhaustive > and ps(1) is already

ospf(6)d: do not unlink the control socket

2020-09-16 Thread Remi Locherer
In 2018 we discussed that it is OK when ripd leaves its control socket laying around: https://marc.info/?l=openbsd-tech=154101413029926=2 When mestre@ adapted ldpd in June this year I was reminded to also adapt ospfd and ospf6d for consistent. OK? Remi Index: ospfd/control.c

Re: ospf6d: use ROUTE_FLAGFILTER

2020-09-02 Thread Remi Locherer
On Wed, Sep 02, 2020 at 03:23:28PM +1000, Jonathan Matthew wrote: > Like ospfd, ospf6d can use ROUTE_FLAGFILTER to opt out of receiving messages > relating to L2 and broadcast routes on its routing socket. We've been running > this for a week or so with no problems. > > ok? ok remi@ > >

Re: top: toggle routing tables

2020-08-25 Thread Remi Locherer
On Tue, Aug 25, 2020 at 09:34:55AM +0200, Klemens Nanni wrote: > On Mon, Aug 24, 2020 at 12:52:46AM +0200, Klemens Nanni wrote: > > Add `t' to swap the WAIT column with RTABLE (and vice versa); WAIT > > is wide enough to fit RTABLE, somewhat adds additional value to STATE > > and seems therefore

Re: top: filter by routing table

2020-08-23 Thread Remi Locherer
On Sun, Aug 23, 2020 at 10:45:14PM +0200, Klemens Nanni wrote: > On Sun, Aug 23, 2020 at 10:39:21PM +0200, Remi Locherer wrote: > > I like the feature and it works as advertised. > > > > It would be nice to have a column that displays the rtable id of > > each process

Re: top: filter by routing table

2020-08-23 Thread Remi Locherer
On Sat, Aug 22, 2020 at 05:20:56PM -0600, Todd C. Miller wrote: > This looks good to me but I've refrained from commenting simply > because I don't use rtables at all myself. Can we get some feedback > from people who actually use rtables? > > - todd > I like the feature and it works as

Re: rdomain.4: route -T takes an rtable, not rdomain

2020-07-30 Thread Remi Locherer
On Thu, Jul 30, 2020 at 04:08:01AM +0200, Klemens Nanni wrote: > Multiple rtables may exist in the default rdomain (0), that is their > corresponding rdomains/lo(4) interfaces do not have to exist. > > This demonstrates it; first, nothing but default, so route(8) fails: > > # netstat -R >

Re: ldpd engine process exits with pledge "cpath"

2020-06-20 Thread Remi Locherer
On Fri, Jun 19, 2020 at 02:43:00PM +0100, Ricardo Mestre wrote: > mea culpa, but I'd rather just remove the unlink of the socket. > > OK? Diff reads OK to me. We had the same discussion in 2018 for ripd: https://marc.info/?l=openbsd-tech=154101413029926=2 Note to self: ospfd should get the

Re: netstat -R: list rdomains with associated ifs and tables

2020-06-11 Thread Remi Locherer
On Wed, Jun 10, 2020 at 11:47:49PM +0200, Sebastian Benoit wrote: > Remi Locherer(remi.loche...@relo.ch) on 2020.06.10 22:16:36 +0200: > > On Tue, Jun 09, 2020 at 10:02:06AM +0200, Remi Locherer wrote: > > > On Tue, Jun 09, 2020 at 09:17:31AM +0200, Claudio Jeker wrote: >

Re: netstat -R: list rdomains with associated ifs and tables

2020-06-11 Thread Remi Locherer
On Wed, Jun 10, 2020 at 11:44:17PM +0100, Stuart Henderson wrote: > It's useful information, I like it. (I preferred it with the route > count, but I agree, it's hard on the system if there's a full DFZ > table). > > One thing though - > > > twister ..in/netstat$ obj/netstat -R > > Rdomain 0 >

Re: netstat -R: list rdomains with associated ifs and tables

2020-06-10 Thread Remi Locherer
On Tue, Jun 09, 2020 at 10:02:06AM +0200, Remi Locherer wrote: > On Tue, Jun 09, 2020 at 09:17:31AM +0200, Claudio Jeker wrote: > > On Tue, Jun 09, 2020 at 08:44:42AM +0200, Remi Locherer wrote: > > > On Mon, Jun 08, 2020 at 10:10:17PM +0200, Remi Locherer wrote: > > > &

Re: netstat -R: list rdomains with associated ifs and tables

2020-06-09 Thread Remi Locherer
On Tue, Jun 09, 2020 at 09:17:31AM +0200, Claudio Jeker wrote: > On Tue, Jun 09, 2020 at 08:44:42AM +0200, Remi Locherer wrote: > > On Mon, Jun 08, 2020 at 10:10:17PM +0200, Remi Locherer wrote: > > > Hi, > > > > > > to my knowledge there is no

Re: netstat -R: list rdomains with associated ifs and tables

2020-06-09 Thread Remi Locherer
On Mon, Jun 08, 2020 at 10:10:17PM +0200, Remi Locherer wrote: > Hi, > > to my knowledge there is no easy way to list all active rdomains or > routing tables. Other platforms have "show vrf" or similar commands > for an overview. > > Here is my attempt at such a

netstat -R: list rdomains with associated ifs and tables

2020-06-08 Thread Remi Locherer
Hi, to my knowledge there is no easy way to list all active rdomains or routing tables. Other platforms have "show vrf" or similar commands for an overview. Here is my attempt at such a view for OpenBSD: twister ..in/netstat$ obj/netstat -R Rdomain 0 Interfaces: lo0 iwm0 re0 enc0 pflog0

Re: ospf6d: change the way interfaces are handled

2020-06-03 Thread Remi Locherer
On Sat, May 30, 2020 at 04:37:43PM +0200, Denis Fondras wrote: > This diff updates how ospf6d(8) handles interfaces. > It is now in line with what ospfd(8) does. > > Last step before enabling reload. > > Tested against Mikrotik and Zebra implementations. > > Warning: it changes the default

Re: iked(8): AES_GCM ciphers for IKE

2020-05-20 Thread Remi Locherer
On Fri, May 15, 2020 at 01:59:35AM +0200, Tobias Heider wrote: > On Thu, May 14, 2020 at 10:47:52PM +0200, Tobias Heider wrote: > > On Thu, May 14, 2020 at 10:07:30PM +0200, Tobias Heider wrote: > > > Hi, > > > > > > currently iked(8) supports AES-GCM only for ESP. > > > The diff below adds the

Re: mcx(4) checksum offload

2020-05-19 Thread Remi Locherer
On Tue, May 19, 2020 at 08:48:17AM +1000, Jonathan Matthew wrote: > So far I've completely ignored offloads in the ethernet drivers I've > written, but on having a quick look at the documentation I found that > mcx(4) checksum offload is extremely easy to use, and some simple testing > suggests

Re: ospf6d: remove F_IFACE_AVAIL

2020-05-17 Thread Remi Locherer
On Sat, May 16, 2020 at 08:17:28PM +0200, Denis Fondras wrote: > This information is never used/checked. > ok remi@ > Index: kroute.c > === > RCS file: /cvs/src/usr.sbin/ospf6d/kroute.c,v > retrieving revision 1.63 > diff -u -p

Re: ospf6d: remove IMSG_IFDELETE

2020-05-16 Thread Remi Locherer
On Thu, May 14, 2020 at 08:10:55PM +0200, Denis Fondras wrote: > Following https://marc.info/?l=openbsd-tech=158946552515632=2, when > IMSG_IFADD is removed, IMSG_IFDELETE becomes useless... OK remi@ > > Index: kroute.c > === > RCS

Re: ospf6d: remove IMSG_IFADD

2020-05-16 Thread Remi Locherer
On Thu, May 14, 2020 at 04:10:42PM +0200, Denis Fondras wrote: > IMSG_IFADD is never used, wipe it. In ospfd we have IMSG_RECONF_IFACE for this. Once we start adding reload functionality we can bring that over to ospf6d. OK remi@ > > Index: ospf6d.h >

Re: tcpdump: print nhrp packets

2020-04-14 Thread Remi Locherer
On Tue, Apr 14, 2020 at 01:49:32PM +1000, David Gwynne wrote: > > > > On 13 Apr 2020, at 19:03, Remi Locherer wrote: > > > > Hi, > > > > I recently looked into NHRP (RFC 2332) and noticed that our tcpdump does > > not have a printer for

tcpdump: print nhrp packets

2020-04-13 Thread Remi Locherer
@ +/* $OpenBSD:$ */ + +/* + * Copyright (c) 2020 Remi Locherer + * + * 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. + * + * T

Re: ospf6d: update to connected routes

2020-04-05 Thread Remi Locherer
On Wed, Apr 01, 2020 at 08:50:45PM +0200, Denis Fondras wrote: > Handle connected routes as ospfd(8) does. > > (diff to ospf6d and ospf6ctl) OK remi@ > > Index: ospf6ctl/ospf6ctl.c > === > RCS file:

Re: ospf6d: bring ospf6d closer to ospfd

2020-03-28 Thread Remi Locherer
On Sat, Mar 21, 2020 at 05:25:45PM +0100, Denis Fondras wrote: > Biggest chunk is rework of rde_asext_get()/rde_asext_put(). > Also change get_net_link() and get_rtr_link() to work like ospfd couterpart. Reads good to me and I didn't spot any issues running tests with it. One question: why "if

syslog regress and libressl

2020-03-04 Thread Remi Locherer
I noticed that some regress test fail since February 7: - run-args-server-tls-reconnect.pl - run-args-server-tls-tcp.pl - run-args-tls-cipher-null.pl (http://bluhm.genua.de/regress/results/regress-ot6.html) It is related to changes in LibreSSL. Is this intended? Should the regress tests be

Re: openssl.1: Tag command names

2020-02-17 Thread Remi Locherer
On Mon, Feb 17, 2020 at 05:19:27PM +0100, Klemens Nanni wrote: > > I'd like to commit this soon, it allows me to jump to the command I'm > looking for, e.g. ":tx509" shows me the synopsis right away. > > FWIW, some Linux distributions ship with separate manuals, e.g. x509(1SSL). > > Patch was

Re: ospf6d: rework rde_lsdb.c

2020-02-16 Thread Remi Locherer
On Sat, Feb 15, 2020 at 11:37:12AM +0100, Denis Fondras wrote: > 3 changes in rde_lsdb.c > - lsa_find_lsid() has redondant parameters > - call to lsa_self() can be simplified (== ospfd) > - update debug messages to be more suitable > ok remi@ > Index: rde.c >

Re: ospf6d: simplify lsa_snap()

2020-01-21 Thread Remi Locherer
On Wed, Jan 22, 2020 at 12:56:00AM +0100, Claudio Jeker wrote: > On Tue, Jan 21, 2020 at 03:58:58PM +0100, Remi Locherer wrote: > > On Tue, Jan 21, 2020 at 01:09:30PM +0100, Denis Fondras wrote: > > > On Tue, Jan 21, 2020 at 09:35:06AM +0100, Remi Locherer wrote: > >

Re: ospf6d: simplify lsa_snap()

2020-01-21 Thread Remi Locherer
On Tue, Jan 21, 2020 at 01:09:30PM +0100, Denis Fondras wrote: > On Tue, Jan 21, 2020 at 09:35:06AM +0100, Remi Locherer wrote: > > > @@ -235,6 +233,7 @@ lsa_check(struct rde_nbr *nbr, struct ls > > > case LSA_TYPE_NETWORK: > > > if ((len % sizeof(u_int32_

Re: ospf(6)d: allow "type p2p" globally or per area

2020-01-21 Thread Remi Locherer
On Mon, Jan 20, 2020 at 05:08:26PM +0100, Denis Fondras wrote: > On Sun, Jan 19, 2020 at 11:04:16PM +0100, Remi Locherer wrote: > > This makes the interface setting "type p2p" configurable globally or > > per area. ospf(6)d allows this for almost all interface related set

Re: ospf6d: simplify lsa_snap()

2020-01-21 Thread Remi Locherer
On Mon, Jan 20, 2020 at 05:03:34PM +0100, Denis Fondras wrote: > No need to pass peerid to lsa_snap() > > While at it, remove unused variable. ok iremi@ with a small comment below. > > Index: rde.c > === > RCS file:

ospf(6)d: allow "type p2p" globally or per area

2020-01-19 Thread Remi Locherer
This makes the interface setting "type p2p" configurable globally or per area. ospf(6)d allows this for almost all interface related settings. As a side-effect of this diff ospf(6)d -nv prints "type p2p" also for point-to-point interfaces like gif or gre. I think this is an advantage but I can

Re: ospf(6)d.conf: define interface parameters per area or globally

2020-01-12 Thread Remi Locherer
On Sun, Jan 12, 2020 at 04:18:26PM +0100, Claudio Jeker wrote: > On Sun, Jan 12, 2020 at 03:46:15PM +0100, Remi Locherer wrote: > > On Wed, Jan 08, 2020 at 01:13:45PM +0100, Denis Fondras wrote: > > > On Wed, Jan 08, 2020 at 09:14:48AM +0100, Remi Locherer wrote: > > >

Re: ospf(6)d.conf: define interface parameters per area or globally

2020-01-12 Thread Remi Locherer
On Wed, Jan 08, 2020 at 01:13:45PM +0100, Denis Fondras wrote: > On Wed, Jan 08, 2020 at 09:14:48AM +0100, Remi Locherer wrote: > > > I have a diff to allow parameters after interface or area definition. > > > Not sure if we want to do that though. > &

Re: ospf(6)d.conf: define interface parameters per area or globally

2020-01-08 Thread Remi Locherer
On Sat, Jan 04, 2020 at 11:34:45PM +0100, Denis Fondras wrote: > On Sat, Jan 04, 2020 at 11:11:36PM +0100, Remi Locherer wrote: > > Hi, > > > > interface-specific parameters can be defined globally or per area. > > But they are applied to the interfaces only if the

ospf(6)d.conf: define interface parameters per area or globally

2020-01-04 Thread Remi Locherer
Hi, interface-specific parameters can be defined globally or per area. But they are applied to the interfaces only if the interfaces are declared afterwards. Or is the GLOBAL CONFIURATION section the better place for this? I opted for the AREA section because I consider it unlikely a user adds

Re: ospf6d: sync hello.c with ospfd

2020-01-03 Thread Remi Locherer
On Thu, Jan 02, 2020 at 05:17:02PM +0100, Denis Fondras wrote: > Sync with ospfd's hello.c ok remi@ > > Index: hello.c > === > RCS file: /cvs/src/usr.sbin/ospf6d/hello.c,v > retrieving revision 1.21 > diff -u -p -r1.21 hello.c >

Re: ospf6d: sync database.c with ospfd(8)

2020-01-03 Thread Remi Locherer
On Thu, Jan 02, 2020 at 04:05:45PM +0100, Denis Fondras wrote: > This is mostly log messages sync. ok remi@ > > Index: database.c > === > RCS file: /cvs/src/usr.sbin/ospf6d/database.c,v > retrieving revision 1.18 > diff -u -p

Re: ospf6d: remove useless orig_rtr_lsa()

2020-01-02 Thread Remi Locherer
On Tue, Dec 31, 2019 at 01:47:08PM +0100, Denis Fondras wrote: > Rename orig_rtr_lsa_area() to orig_rtr_lsa() > > Now that area is part of iface, original orig_rtr_lsa() is useless. Also > verifying that area != NULL is not needed in some cases (these are leftovers > of > the previous diff). >

Re: ospf6d: refactor link state ack/req

2019-12-27 Thread Remi Locherer
On Tue, Dec 24, 2019 at 10:02:37PM +0100, Denis Fondras wrote: > Refactor link state ack/req in ospf6d so it looks closer to ospfd. ok remi@ > Index: lsack.c > === > RCS file: /cvs/src/usr.sbin/ospf6d/lsack.c,v > retrieving revision

ospf6d: type p2p

2019-12-23 Thread Remi Locherer
Hi, this brings support for interface "type p2p" to ospf6d (ospfd got it a few weeks ago). The configuration looks like this: area 0.0.0.0 { interface em0 { type p2p } } OK? Remi Index: ospf6d.conf.5

Re: ospf6d: add basic regress tests

2019-12-23 Thread Remi Locherer
On Sun, Dec 22, 2019 at 08:36:41PM +0100, Denis Fondras wrote: > Add basic regress test to ospf6d. Works for me. OK remi@ The tests also succeed when I reduce the sleep from 120 to 60. A few lines end with a space. I marked them below. Remi > > Index: ospf6d/Makefile >

Re: ospf6d: warn when a neighbor changes its source address

2019-12-23 Thread Remi Locherer
On Sun, Dec 22, 2019 at 10:32:12PM +0100, Denis Fondras wrote: > On Sun, Dec 22, 2019 at 10:06:40PM +0100, Remi Locherer wrote: > > this is similar to ospfd's hello.c rev 1.23. > > > > OK? > > > >

Re: ospf6d: add reference to area in struct iface

2019-12-22 Thread Remi Locherer
On Sun, Dec 22, 2019 at 06:35:47PM +0100, Denis Fondras wrote: > area is now part of struct iface > > Code looks cleaner and more like ospfd. ok remi@ > > Index: area.c > === > RCS file: /cvs/src/usr.sbin/ospf6d/area.c,v >

ospf6d: warn when a neighbor changes its source address

2019-12-22 Thread Remi Locherer
this is similar to ospfd's hello.c rev 1.23. OK? Remi Index: hello.c === RCS file: /cvs/src/usr.sbin/ospf6d/hello.c,v retrieving revision 1.19 diff -u -p -r1.19 hello.c --- hello.c 11 Dec 2019 21:33:56 - 1.19 +++

Re: ospf6d: scale send buffer

2019-12-22 Thread Remi Locherer
On Sun, Dec 22, 2019 at 03:27:05PM +0100, Denis Fondras wrote: > Trivial diff to scale send buffer on socket. ok remi@ > > Index: interface.c > === > RCS file: /cvs/src/usr.sbin/ospf6d/interface.c,v > retrieving revision 1.25 >

Re: ospf6d: rework priority handling

2019-12-15 Thread Remi Locherer
reads good to me (but I did not test). On Sun, Dec 15, 2019 at 09:56:15AM +0100, Denis Fondras wrote: > > Index: kroute.c > === > RCS file: /cvs/src/usr.sbin/ospf6d/kroute.c,v > retrieving revision 1.61 > diff -u -p -r1.61 kroute.c

Re: ospf6d: rework redist_list and area

2019-12-14 Thread Remi Locherer
On Sat, Dec 14, 2019 at 12:05:57PM +0100, Denis Fondras wrote: > Still working towards bringing ospf6d and ospfd closer. > > area is now part of struct iface. Makes sense to me. > redist_list is part of struct area. In ospfd the redist_list per area is only used to redistribute a default route

Re: ospf6d: refactor kernel route message handling

2019-12-11 Thread Remi Locherer
On Wed, Dec 11, 2019 at 04:38:38PM +0100, Denis Fondras wrote: > On Tue, Dec 10, 2019 at 09:51:12PM +0100, Remi Locherer wrote: > > Unfortunately redistribute does not work anymore. > > > > Indeed, simple tests are too simple... > > Here is an updated diff. ok

Re: ripd: memory leak and double free/use-after-free

2019-12-11 Thread Remi Locherer
On Wed, Dec 11, 2019 at 10:11:58AM +0100, Sebastian Benoit wrote: > Remi Locherer(remi.loche...@relo.ch) on 2019.12.10 22:39:32 +0100: > > On Tue, Dec 10, 2019 at 07:05:27PM +0100, Hiltjo Posthuma wrote: > > > Hi, > > > > > > While looking at the code of ripd:

Re: ripd: memory leak and double free/use-after-free

2019-12-10 Thread Remi Locherer
On Tue, Dec 10, 2019 at 07:05:27PM +0100, Hiltjo Posthuma wrote: > Hi, > > While looking at the code of ripd: > > I think there are (also) 2 small memleaks in a debug/error path > (IMSG_REQUEST_ADD and IMSG_RESPONSE_ADD). It breaks out before adding the > struct rip_route as an entry by the

Re: ospf6d: refactor kernel route message handling

2019-12-10 Thread Remi Locherer
On Mon, Dec 09, 2019 at 07:31:11PM +0100, Denis Fondras wrote: > Give some love to ospf6d. > > The goal is to have ospf6d looks like ospfd, this could be useful to have > changes made in one daemon from one go inside the other. > > I will do it step by step until I get to the point where

ripd: fix split-horizon simple

2019-12-08 Thread Remi Locherer
Hi, when "split-horizon simple" is used, ripd might send out messges with 0 routes in it. This is because nentries is counted up even if the route was not added to buf. Moving nentries++ up is fixing this. Below log message is an indicator for this bug: recv_response: bad packet size, interface

ripd: fix error message

2019-12-08 Thread Remi Locherer
Hi, this fixes an error message to reflect the correct function name. OK? Remi Index: message.c === RCS file: /cvs/src/usr.sbin/ripd/message.c,v retrieving revision 1.12 diff -u -p -r1.12 message.c --- message.c 25 Oct 2014

ripd: remove unused line

2019-12-08 Thread Remi Locherer
Hi, iface is not used afterwards. I think it should have been removed in revision 1.8. OK? Remi Index: ripe.c === RCS file: /cvs/src/usr.sbin/ripd/ripe.c,v retrieving revision 1.23 diff -u -p -r1.23 ripe.c --- ripe.c 4 Nov

Re: ospfd: type p2p

2019-11-17 Thread Remi Locherer
On Sat, Nov 16, 2019 at 06:58:35AM +0100, Claudio Jeker wrote: > On Fri, Nov 15, 2019 at 06:06:42PM +0100, Remi Locherer wrote: > > On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote: > > > On 25/10/2019 13:57, Remi Locherer wrote: > > > > Hi

Re: ospfd: type p2p

2019-11-15 Thread Remi Locherer
On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote: > On 25/10/2019 13:57, Remi Locherer wrote: > > Hi tech@, > > > > earlier this year I sent a diff that allowed to change an interface > > from broadcast to point-to-point. > > > > https://ma

Re: ospfd: type p2p

2019-11-04 Thread Remi Locherer
On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote: > On 25/10/2019 13:57, Remi Locherer wrote: > > Hi tech@, > > > > earlier this year I sent a diff that allowed to change an interface > > from broadcast to point-to-point. > > > > https://ma

Re: Opportunistic DoT for unwind(8)

2019-11-02 Thread Remi Locherer
On Sat, Nov 02, 2019 at 08:20:08AM +0100, Otto Moerbeek wrote: > On Fri, Nov 01, 2019 at 10:43:27PM +0100, Remi Locherer wrote: > > > On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote: > > > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote: > &g

Re: Opportunistic DoT for unwind(8)

2019-11-01 Thread Remi Locherer
On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote: > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote: > > On Fri, Nov 01, 2019 at 09:35:07PM +0100, Remi Locherer wrote: > > > On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote: > > >

Re: Opportunistic DoT for unwind(8)

2019-11-01 Thread Remi Locherer
On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote: > Hi, > > So here's a new diff that incorporates the bug fix mentioned plus > debug printf line changes suggested by Stuart. > > Please note that this is a diff on top of very recent current, i.e. > florian's work he committed today.

Re: Opportunistic DoT for unwind(8)

2019-10-30 Thread Remi Locherer
Hi Otto, On Wed, Oct 30, 2019 at 03:57:15PM +0100, Otto Moerbeek wrote: > Hi, > > I got *very* little feedback on this request for testing. > > If not enough enough testing is done, I'll either abandon the diff or > commit it as-is, introducing bugs that could have been prevented. Both > are

ospfd: type p2p

2019-10-25 Thread Remi Locherer
Hi tech@, earlier this year I sent a diff that allowed to change an interface from broadcast to point-to-point. https://marc.info/?l=openbsd-tech=156132923203704=2 It turned out that this was not sufficient. It made the adjacency come up in p2p mode (no selection of DR or BDR) but didn't set a

Re: Attach Hyper-V guest services to VMBus 4.0

2019-10-05 Thread Remi Locherer
On Sat, Oct 05, 2019 at 03:19:08PM +0200, Mike Belopuhov wrote: > > Remi Locherer writes: > > > On Tue, Oct 01, 2019 at 12:25:35AM +0200, Mike Belopuhov wrote: > >> > >> > >> Hi, > >> > >> I've got a verbal report that Hyper-V gues

Re: Attach Hyper-V guest services to VMBus 4.0

2019-10-05 Thread Remi Locherer
On Tue, Oct 01, 2019 at 12:25:35AM +0200, Mike Belopuhov wrote: > > > Hi, > > I've got a verbal report that Hyper-V guest services aren't attached > on modern Windows 10 systems so I believe we should get this one-liner > in before 6.6. > > FreeBSD revision 349856 adds another define for VMBus

Re: Attach Hyper-V guest services to VMBus 4.0

2019-10-05 Thread Remi Locherer
Hi Mike, On Tue, Oct 01, 2019 at 12:25:35AM +0200, Mike Belopuhov wrote: > > > Hi, > > I've got a verbal report that Hyper-V guest services aren't attached > on modern Windows 10 systems so I believe we should get this one-liner > in before 6.6. > > FreeBSD revision 349856 adds another define

ospfd: warn when a neighbor changes its ip address

2019-08-11 Thread Remi Locherer
I'd like to get a notification when a neighbor changes the src IP address for hello packets. Either it is a planned change or something bad happens in the network. OK? Remi Index: hello.c === RCS file:

ospfd: check dst addr for hello packets

2019-08-11 Thread Remi Locherer
When ospfd receives a hello packet it takes the src IP address and updates the address in its neighbor struct for the given router id unconditionally. In the case of broadcast interfaces this is not a problem: find_iface() checks that the src address is from the same subnet as the receiving

Re: tpmr(4): 802.1Q Two-Port MAC Relay

2019-07-30 Thread Remi Locherer
On Tue, Jul 30, 2019 at 01:36:59PM +1000, David Gwynne wrote: > a Two-Port MAC Relay is basically a cut down bridge(4). it only supports > two ports, and unconditionally relays packets between those ports > instead of doing learning or anything like that. > > i've been trying to get a redundant

ospfd: improve logging when sendig packets fail

2019-07-14 Thread Remi Locherer
Hi, I'd like to improve ospfd's logging when sending a packet fails. I got a debug output from a ospfd user which contains "send packet: error ...". I guess ospfd failed to send an ls ack. With below diff applied it would be clear which packet could not be sent and to which neighbor. OK? Remi

Re: ospfd: point-to-point on ethernet interfaces

2019-07-04 Thread Remi Locherer
ck route the BSD is announcing. Thank you for testing! Can you send me your ospfd.conf, the output from ospfd -dv and the output from tcpdump showing the ospf traffic? > On 24/06/2019 01:33, Remi Locherer wrote: > > Diff below adds to ospfd point to point support for Ethernet interfaces.

Re: ospfd: point-to-point on ethernet interfaces

2019-07-02 Thread Remi Locherer
ping On Mon, Jun 24, 2019 at 12:33:16AM +0200, Remi Locherer wrote: > Diff below adds to ospfd point to point support for Ethernet interfaces. > I successfully tested this against Junos and FastIron. > > I first made the key word in the config "point-to-point". But then I

ospfd: point-to-point on ethernet interfaces

2019-06-23 Thread Remi Locherer
Diff below adds to ospfd point to point support for Ethernet interfaces. I successfully tested this against Junos and FastIron. I first made the key word in the config "point-to-point". But then I changed to "type p2p". The later would allow for "type nbma" or "type p2mp" should we implement

ospf6d: conf_clear_redist_list

2019-06-08 Thread Remi Locherer
Clear unused redist_list the same way as in ospfd. OK? Remi Index: ospf6d.h === RCS file: /cvs/src/usr.sbin/ospf6d/ospf6d.h,v retrieving revision 1.39 diff -u -p -r1.39 ospf6d.h --- ospf6d.h29 Dec 2018 16:04:31 - 1.39

Re: ospfd: allow specifying area by number as well as id

2019-05-28 Thread Remi Locherer
Hi David, are you going to commit this? Remi On Thu, May 16, 2019 at 11:14:55PM +0200, Remi Locherer wrote: > On Thu, May 16, 2019 at 09:39:37AM +0200, Sebastian Benoit wrote: > > > > > > > > Remi Locherer(remi.loche...@relo.ch) on 2019.05.15 23:15:03 +0200: >

ospf6d: allow specifying area by number as well as id

2019-05-23 Thread Remi Locherer
Hi tech@, David sent a diff for ospfd which allows specifying an area by number as well as id. --> https://marc.info/?l=openbsd-tech=155650284619263=2 This diff does the same for ospf6d and ospf6ctl without modifying any outputs. OK? Remi Index: ospf6d/ospf6d.conf.5

Re: ospfd: allow specifying area by number as well as id

2019-05-16 Thread Remi Locherer
On Thu, May 16, 2019 at 09:39:37AM +0200, Sebastian Benoit wrote: > > > > Remi Locherer(remi.loche...@relo.ch) on 2019.05.15 23:15:03 +0200: > > On Tue, Apr 30, 2019 at 11:10:37PM +0200, Remi Locherer wrote: > > > On Mon, Apr 29, 2019 at 11:10:31AM +0100, Stuart Hende

Re: ospfd: allow specifying area by number as well as id

2019-05-15 Thread Remi Locherer
On Tue, Apr 30, 2019 at 11:10:37PM +0200, Remi Locherer wrote: > On Mon, Apr 29, 2019 at 11:10:31AM +0100, Stuart Henderson wrote: > > On 2019/04/29 11:58, Sebastian Benoit wrote: > > > David Gwynne(da...@gwynne.id.au) on 2019.04.29 19:36:51 +1000: > > > > > >

Re: ospfd: do not change router-id on reload if unspecified

2019-05-15 Thread Remi Locherer
On Wed, May 15, 2019 at 03:52:57PM +0200, Denis Fondras wrote: > When router-id is unspecified, ospfd will choose the lowest IP address of the > host. I added an area and an IP lower than the existing ones and on reload > ospfd asked me to restart and did not activate the new area. > > Why would

Re: ospfd: allow specifying area by number as well as id

2019-04-30 Thread Remi Locherer
On Mon, Apr 29, 2019 at 11:10:31AM +0100, Stuart Henderson wrote: > On 2019/04/29 11:58, Sebastian Benoit wrote: > > David Gwynne(da...@gwynne.id.au) on 2019.04.29 19:36:51 +1000: > > > > > > > > > > On 29 Apr 2019, at 4:59 pm, Remi Loc

Re: ospfd: allow specifying area by number as well as id

2019-04-29 Thread Remi Locherer
Hi David On Mon, Apr 29, 2019 at 11:53:27AM +1000, David Gwynne wrote: > it's always bothered me that i config areas on a crisco using a number, > but then have to think hard to convert that number to an address for use > in openbsd. eg, i was given area 700 in one place, which is 0.0.2.188 > as

ospf(6)d: check rdomain for depend on interfaces

2019-04-28 Thread Remi Locherer
Hi, the parser in ospf(6)d accepts depend on interfaces that are in a different rdomain. This works on startup of the daemon. But since it filters route messages based on it's rdomain it will not get notified if the depend on interface changes link state. Below diff extends the existing

Re: uslcom: new product id

2019-04-25 Thread Remi Locherer
On Wed, Apr 24, 2019 at 10:19:13PM +0100, Jason McIntyre wrote: > On Wed, Apr 24, 2019 at 11:16:18PM +0200, Remi Locherer wrote: > > On Wed, Apr 24, 2019 at 08:54:08AM +0100, Jason McIntyre wrote: > > > On Wed, Apr 24, 2019 at 08:11:42AM +0100, Stuart Henderson wrote: > >

Re: uslcom: new product id

2019-04-24 Thread Remi Locherer
On Wed, Apr 24, 2019 at 08:54:08AM +0100, Jason McIntyre wrote: > On Wed, Apr 24, 2019 at 08:11:42AM +0100, Stuart Henderson wrote: > > On 2019/04/23 23:53, Remi Locherer wrote: > > > Hi, > > > > > > with below diff the usb serial adapter built into the SRX

uslcom: new product id

2019-04-23 Thread Remi Locherer
Hi, with below diff the usb serial adapter built into the SRX 300 attaches to uslcom and can be used. uslcom0 at uhub1 port 1 configuration 1 interface 0 "Silicon Labs Juniper Networks BX Series System Console" rev 1.10/1.01 addr 10 OK? Remi Index: usbdevs

fix link id for p2p interfaces router lsa type 3 link

2019-04-22 Thread Remi Locherer
Hi, when ospfd originates LSAs for p2p interfaces it puts the interface address into the link id field where it should use the network address. The issue was reported by Mitchell Krome on tech@ and one part of the problem was fixed in rde_spf.c revision 1.77. -->

Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table

2019-04-04 Thread Remi Locherer
On Tue, Apr 02, 2019 at 07:27:07PM +1000, Mitchell Krome wrote: > On 2/04/2019 3:30 pm, Remi Locherer wrote: > > Hi Mitchell > > > > On Sat, Mar 30, 2019 at 04:10:09PM +1000, Mitchell Krome wrote: > >> I kept finding I had a lingering /30 route when I turned of

Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table

2019-04-01 Thread Remi Locherer
Hi Mitchell On Sat, Mar 30, 2019 at 04:10:09PM +1000, Mitchell Krome wrote: > I kept finding I had a lingering /30 route when I turned off one of my > test boxes. I tracked it down to ospfd sending RTM_ADD for a stub > network with the non-masked prefix. The RTM_ADD path applies the mask > inside

Re: ospfd: Warn when the router ID changes during config reload

2019-03-25 Thread Remi Locherer
On Mon, Mar 25, 2019 at 02:43:26PM +0100, Jeremie Courreges-Anglas wrote: > On Sun, Mar 24 2019, Mitchell Krome wrote: > > On 24/03/2019 7:23 am, Theo de Raadt wrote: > >> Sebastian Benoit wrote: > >> > >>> Mitchell Krome(mitchellkr...@gmail.com) on 2019.03.23 20:27:17 +1000: > Was messing

ospf(6)d: fix "redistribute X set type 2 depend on if"

2019-01-10 Thread Remi Locherer
Hi tech, in OSPFs external LSAs the type is encoded in the metric field. ospfd and ospf6d overwrite the type information when "depend on" is used and the specified interface is down (or in backup state). Below diff fixes this. The problem was reported on misc by Ior Podlesny:

ospf6d: detect and remove alien routes

2019-01-02 Thread Remi Locherer
Hi tech, ospfd detects and removes routes in the kernel routing table with priority RTP_OSPF (or the configured fib-priority) that have been inserted by another program. Below diff adds the same behaviour to ospf6d. OK? Remi Index: kroute.c

ospfd: send router lsa when removing an interface

2019-01-01 Thread Remi Locherer
Hi tech, when removing an interface from ospdf.conf and doing a reload other OSPF routers should get a router LSA update. Then they can remove the affected route. But currently this does not happen. The affected route might be used by other routers a long time after removing it from the config

  1   2   3   >