Re: bgpd crashes when fed by rpki-client (aspa_add_set: bad order of adds)

[Bastien Durel]

Le jeudi 11 mai 2023 à 16:44 +0200, Wouter Prins a écrit :
> I posted this to tech@ last week.
> As a workaround use -A in the rpki-client root crontab entry
> 
Hi,

Thanks!

I searched in misc@ but not tech@ :/

-- 
Bastien

bgpd crashes when fed by rpki-client (aspa_add_set: bad order of adds)

[Bastien Durel]

Hello,

I have an openbgpd running with only iBGP, and I run rpki-client on
this machine (the bgpd runs for LG, rpki-client generates for other
routers too).

Since the 8th of may, it crashes on reload, after rpki-client ran
Only emptying the rpki-client config file makes it start again, until
it's reloaded after rpki run again.

/etc/bgpd.conf:

AS 212834
router-id 10.126.0.39

prefix-set mynetworks {
2001:678:de8::/48
}

include "/var/db/rpki-client/openbgpd.6"

socket "/var/www/run/bgpd.rsock" restricted

deny quick from ebgp prefix-set mynetworks or-longer
allow from ibgp
deny to ibgp

network prefix-set mynetworks

group "ibgp" {
remote-as 212834
local-address 2001:678:de8:x
neighbor 2001:678:de8:y {
 descr "r1"
}
neighbor 2001:678:de8:z {
 descr "r2"
}
}


/var/db/rpki-client/openbgpd.6 is an ipv6-only view of /var/db/rpki-
client/openbgpd, generated by cron :

grep -v -E '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/[0-9]+' /var/db/rpki-client/openbgpd 
> /var/db/rpki-client/openbgpd.6


When openbgpd.6 is non-empty, the log file contains :

May 11 14:49:15 rpki bgpd[47637]: startup
May 11 14:49:15 rpki bgpd[84245]: rtr engine ready
May 11 14:49:15 rpki bgpd[17015]: route decision engine ready
May 11 14:49:15 rpki bgpd[28135]: session engine ready
May 11 14:49:16 rpki bgpd[28135]: listening on 0.0.0.0
May 11 14:49:16 rpki bgpd[28135]: listening on ::
May 11 14:49:16 rpki bgpd[28135]: SE reconfigured
May 11 14:49:16 rpki bgpd[28135]: neighbor 2001:678:de8:z (r2): state change 
None -> Idle, reason: None
May 11 14:49:16 rpki bgpd[28135]: neighbor 2001:678:de8:y (r1): state change 
None -> Idle, reason: None
May 11 14:49:16 rpki bgpd[17015]: RDE reconfigured
May 11 14:49:16 rpki bgpd[17015]: running softreconfig in
May 11 14:49:16 rpki bgpd[17015]: softreconfig in done
May 11 14:49:16 rpki bgpd[17015]: starting softreconfig out for rib Loc-RIB
May 11 14:49:16 rpki bgpd[17015]: softreconfig out done for Loc-RIB
May 11 14:49:16 rpki bgpd[17015]: RDE soft reconfiguration done
May 11 14:49:16 rpki bgpd[84245]: RTR engine reconfigured
May 11 14:49:16 rpki bgpd[17015]: fatal in RDE: aspa_add_set: bad order of adds
May 11 14:49:16 rpki bgpd[84245]: peer closed imsg connection
May 11 14:49:16 rpki bgpd[84245]: RTR: Lost connection to RDE
May 11 14:49:16 rpki bgpd[28135]: peer closed imsg connection
May 11 14:49:16 rpki bgpd[28135]: SE: Lost connection to RDE
May 11 14:49:16 rpki bgpd[28135]: peer closed imsg connection
May 11 14:49:16 rpki bgpd[28135]: SE: Lost connection to RDE control
May 11 14:49:16 rpki bgpd[47637]: peer closed imsg connection
May 11 14:49:16 rpki bgpd[47637]: main: Lost connection to RDE
May 11 14:49:16 rpki bgpd[28135]: peer closed imsg connection
May 11 14:49:16 rpki bgpd[84245]: peer closed imsg connection
May 11 14:49:16 rpki bgpd[28135]: SE: Lost connection to parent
May 11 14:49:16 rpki bgpd[47637]: kernel routing table 0 (Loc-RIB) decoupled
May 11 14:49:16 rpki bgpd[28135]: session engine exiting
May 11 14:49:16 rpki bgpd[84245]: fatal in RTR: Lost connection to parent
May 11 14:49:16 rpki bgpd[47637]: terminating

I guess the aspa_add_set: bad order of adds is the cause of the
termination...


When openbgpd.6 is empty, bgpd start correctly :

May 11 14:49:31 rpki bgpd[23169]: startup
May 11 14:49:31 rpki bgpd[82407]: route decision engine ready
May 11 14:49:31 rpki bgpd[71345]: session engine ready
May 11 14:49:31 rpki bgpd[86603]: rtr engine ready
May 11 14:49:31 rpki bgpd[71345]: listening on 0.0.0.0
May 11 14:49:31 rpki bgpd[71345]: listening on ::
May 11 14:49:31 rpki bgpd[71345]: SE reconfigured
May 11 14:49:31 rpki bgpd[71345]: neighbor 2001:678:de8:z (r2): state change 
None -> Idle, reason: None
May 11 14:49:31 rpki bgpd[71345]: neighbor 2001:678:de8:y (r1): state change 
None -> Idle, reason: None
May 11 14:49:31 rpki bgpd[86603]: RTR engine reconfigured
May 11 14:49:31 rpki bgpd[82407]: RDE reconfigured
May 11 14:49:31 rpki bgpd[82407]: running softreconfig in
May 11 14:49:31 rpki bgpd[82407]: softreconfig in done
May 11 14:49:31 rpki bgpd[82407]: starting softreconfig out for rib Loc-RIB
May 11 14:49:31 rpki bgpd[82407]: softreconfig out done for Loc-RIB
May 11 14:49:31 rpki bgpd[82407]: RDE soft reconfiguration done
May 11 14:49:32 rpki bgpd[71345]: neighbor 2001:678:de8:y (r1): state change 
Idle -> Active, reason: Start
May 11 14:49:32 rpki bgpd[71345]: neighbor 2001:678:de8:y (r1): state change 
Active -> OpenSent, reason: Connection opened
May 11 14:49:32 rpki bgpd[71345]: neighbor 2001:678:de8:y (r1): state change 
OpenSent -> OpenConfirm, reason: OPEN message received
May 11 14:49:32 rpki bgpd[71345]: neighbor 2001:678:de8:y (r1): state change 
OpenConfirm -> Established, reason: KEEPALIVE message received
May 11 14:49:32 rpki bgpd[82407]: neighbor 2001:678:de8:y (r1): sending IPv6 
unicast EOR marker
May 11 14:49:34 rpki bgpd[82407]: neighbor 2001:678:de8:y (r1): received IPv6 
unicast 

Re: Can't figure out what's taking up space on /

[Bastien Durel]

Le mercredi 04 août 2021 à 14:20 -0700, Greg Thomas a écrit :
> At some point my rsync script ran while /backup wasn't mounted or
> something.  The culprit was there.

Hello.

I've done that more than once, especially on NFS-mounted backups.

Since then, I put the mount points directories immutable (before mount)

fremen# mkdir /tmp/foo
fremen# chflags schg /tmp/foo
fremen# touch /tmp/foo/bar
touch: /tmp/foo/bar: Operation not permitted
fremen# ls -loa /tmp/foo
total 8
drwxr-xr-x   2 root  wheel  schg 512 Aug  5 11:01 .
drwxrwxrwt  14 root  wheel  -512 Aug  5 11:01 ..
fremen# mount /dev/vnd0a /tmp/foo/ 
fremen# touch /tmp/foo/bar
fremen# ls -lao /tmp/foo/  
total 8
drwxr-xr-x   2 root  wheel  - 512 Aug  5 11:10 .
drwxrwxrwt  14 root  wheel  - 512 Aug  5 11:10 ..
-rw-r--r--   1 root  wheel  -   0 Aug  5 11:10 bar

Regards,

-- 
Bastien

Re: pf ipv6 source-routing 6.9

[Bastien Durel]

Le lundi 10 mai 2021 à 22:51 +1000, David Gwynne a écrit :
> 
> 
> > On 10 May 2021, at 8:05 pm, Bastien Durel 
> > wrote:
> > 
> > Le samedi 08 mai 2021 à 12:07 +0200, Bastien Durel a écrit :
> > > Le 08/05/2021 à 11:56, Stuart Henderson a écrit :
> > > > > > Does it work if you use the syntax suggested in the upgrade
> > > > > > notes
> > > > > > for the example with "pass in on pppoe1 reply-to ..."?
> > > > > > 
> > > > > > 
> > > > > For incoming connections, I tried
> > > > > 
> > > > > pass in on pppoe0 inet6 reply-to
> > > > > fe80::520f:80ff:fe65:8800%pppoe0
> > > > > keep state
> > > > > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800
> > > > > keep
> > > > > state
> > 
> > Hello,
> > 
> > Thanks to folks of #openbsd, I found out adding an explicit route
> > to
> > fe80::520f:80ff:fe65:8800 on pppoe0 make this work.
> > Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in
> > a
> > rule referencing fe80::520f:80ff:fe65:8800
> > 
> > pf.conf:
> > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0
> > pfctl -s rules:
> > pass in on pppoe0 inet6 all flags S/SA reply-to
> > fe80::520f:80ff:fe65:8800
> > 
> > hostname.pppoe0:
> > !/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0
> > fe80::%pppoe0
> > 
> > This make pf able to route to the correct interface.
> 
> You're right, pf isn't very good at handling link-local v6 addresses.
> This is annoying now that route-to uses addresses as it's argument if
> you want to move ipv6 packets toward a host with a link local
> address.
> 
> In this situation the least worst way to cope with the problem for
> now is to use route-to (pppoe0:0). This should work because route-to
> doesn't do any local address checks on the destination address it
> resolves. Once it looks up the local address as the direction to send
> the packet, it should put it straight out pppoe0. ppp as a tunnel
> interface has no address resolution protocol, it just encapsulates
> the packet it is given and sends it on its way.
> 
> route-to also takes a destination address as an argument, not a
> gateway address. If dhcp6c sets up a route to some global address
> that you know about (I'm not sure this is a thing but it might be),
> you can use that global address as the argument to route-to and it
> will send it in the right direction.
> 

Hello.

Thanks for the hint, but (pppoe0:0) does not work :

pf.conf:266: route spec requires :peer with dynamic interface addresses

(pppoe0:peer) make pf happy, but does not route anything (ifconfig does
not show any peer on inet6)

dhcp6c does not sets any route by its own, it only returns some DNS
resolver addresses, and registers the prefixes the ISP delegates.

Regards,

-- 
Bastien

Re: pf ipv6 source-routing 6.9

[Bastien Durel]

Le samedi 08 mai 2021 à 12:07 +0200, Bastien Durel a écrit :
> Le 08/05/2021 à 11:56, Stuart Henderson a écrit :
> > > > Does it work if you use the syntax suggested in the upgrade
> > > > notes
> > > > for the example with "pass in on pppoe1 reply-to ..."?
> > > > 
> > > > 
> > > For incoming connections, I tried
> > > 
> > > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0
> > > keep state
> > > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep
> > > state

Hello,

Thanks to folks of #openbsd, I found out adding an explicit route to
fe80::520f:80ff:fe65:8800 on pppoe0 make this work.
Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a
rule referencing fe80::520f:80ff:fe65:8800

pf.conf:
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0
pfctl -s rules:
pass in on pppoe0 inet6 all flags S/SA reply-to fe80::520f:80ff:fe65:8800

hostname.pppoe0:
!/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0

This make pf able to route to the correct interface.

Regards,

-- 
Bastien

Re: pf ipv6 source-routing 6.9

[Bastien Durel]

Le 08/05/2021 à 11:56, Stuart Henderson a écrit :

Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?



For incoming connections, I tried

pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state

Those aren't exactly expected to work (I don't think pf really
handles link locals)...



that was my initial question, as the previous versions handled them 
correctly with "(ifname LLaddr)"



pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state

...but I was hoping that this would (and it might possibly be a bug
that it doesn't).



It works with IPv4, but I don't think is handled the same way IPv4 is on 
this kind of links.


my hostname.pppoe0 has :

dest 0.0.0.1
inet6 eui64
!/usr/local/sbin/dhcp6c pppoe0



none of these worked



If pf cannot handle LL anymore, I guess I'll have to downgrade to 6.8 :(

--
Bastien Durel

Re: pf ipv6 source-routing 6.9

[Bastien Durel]

Le 08/05/2021 à 10:58, Stuart Henderson a écrit :

On 2021-05-08, Bastien Durel  wrote:

Le 07/05/2021 à 22:50, Stuart Henderson a écrit :

On 2021-05-07, Bastien Durel  wrote:

Hello,

I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.

I used to route outgoing streams with :

net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table  const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to ! route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to ! route-to $ovh_v6_router


This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.



I read the upgrade note, but there is nothing about IPv6 LL addresses

As said in my previous e-mail :

I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0


Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?



For incoming connections, I tried

pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state

none of these worked

--
Bastien Durel

Re: pf ipv6 source-routing 6.9

[Bastien Durel]

Le 07/05/2021 à 22:50, Stuart Henderson a écrit :

On 2021-05-07, Bastien Durel  wrote:

Hello,

I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.

I used to route outgoing streams with :

net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table  const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to ! route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to ! route-to $ovh_v6_router


This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.



I read the upgrade note, but there is nothing about IPv6 LL addresses

As said in my previous e-mail :
> I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0

--
Bastien Durel

pf ipv6 source-routing 6.9

[Bastien Durel]

Hello,

I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.

I used to route outgoing streams with :

net2_if = pppoe0 
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table  const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to ! route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to ! route-to $ovh_v6_router

And incoming with :

pass in on $net2_if inet6 reply-to $ovh_v6_router keep state

I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0 to let pf
load its configuration file, but this does not seems to work:

Here are incoming packets :

fremen# tcpdump -nvv -i pppoe0 host 2001:41d0:8:91a::1
tcpdump: listening on pppoe0, link-type PPP_ETHER
17:50:30.401270 2001:41d0:8:91a::1 > 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0: 
icmp6: echo request (id:3a19 seq:100) [icmp6 cksum ok] (len 64, hlim 55)
17:50:31.409201 2001:41d0:8:91a::1 > 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0: 
icmp6: echo request (id:3a19 seq:101) [icmp6 cksum ok] (len 64, hlim 55)

Here are outgoing ones :

fremen# tcpdump -nvv -i wg2 host 2001:41d0:8:91a::1 
tcpdump: listening on wg2, link-type LOOP
17:51:14.753505 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0 > 2001:41d0:8:91a::1: 
icmp6: echo reply (id:3a19 seq:144) [icmp6 cksum ok] [flowlabel 0xe86a] (len 
64, hlim 63)
17:51:15.761535 2001:41d0:fe4b:ec42:240:63ff:fec9:34a0 > 2001:41d0:8:91a::1: 
icmp6: echo reply (id:3a19 seq:145) [icmp6 cksum ok] [flowlabel 0xe86a] (len 
64, hlim 63)

There is a route for 2001:41d0::/32 on wg2, that's why it takes it, but
the route-to should have forced it to exit via pppoe0, isn't it ? (wg2
is in $tun_ifs)

What's the correct syntax to make route-to works with LL addresses ?

BTW, if there's a better way of handling this source-routing problem,
I'm open to suggestions

Regards,

-- 
Bastien

Re: auto-boot

[Bastien Durel]

Le mercredi 27 janvier 2021 à 08:20 -0700, Diana Eichert a écrit :
> On Tue, Jan 26, 2021 at 5:30 AM Stuart Longland
>  wrote:
> > 
> > On 25/1/21 11:40 pm, Bastien Durel wrote:
> > > Hello,
> > > 
> > > Short-circuit pins 3-5 using my DB9 cable as Mihai Popescu
> > > said[1]
> > > worked.
> > > Alas, this setup prevent to plug-in the cable on the other side
> > > ^^
> > > 
> > > But this confirm there is an hardware problem.
> 
> The issue is the input RCV line is floating which causes spurious
> characters, a
> properly designed circuit should not have this issue.
> 
> You really should insert a high ohm valu resistor in the path between
> RCV and GND,
> this would allow you to build a serial cable that still functions.
> 
Hello again,

I bought a pair of these :

https://corrin.geekwu.org/owncloud/index.php/s/3Bci6SRDjR9gPgs

and tried to put a 1kΩ resistor between pins 3 and 5, then reboot; but
the router hanged again.
I tried with pins 1-3 to make sure it was not a male/female numbering
problem, but with no more success :(

Worse : it did not boot with a wire between ports 3-5 (nor 1-5)

Is there some other wiring to do to get the plug working ? (I tried to
make it work before I plug actual cable, but maybe it's not possible ?)

Thanks,

PS: is 1kΩ enough ? I don't know if it's actually "high value"

-- 
Bastien

Re: ospf on wg(4)

[Bastien Durel]

Le 30/01/2021 à 09:22, Kapetanakis Giannis a écrit :

On 29/01/2021 23:32, Bastien Durel wrote:

Le 29/01/2021 à 17:44, Olivier Cherrier a écrit :

Hi,

I'm trying to setup OSPF on a working Wireguard VPN using 6.8 amd64
machines. This is what I get:

# ospfd -dvvv
id = "172.26.1.1"
startup
kr_init: priority filter enabled
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface wg0
if_fsm: event UP resulted in action START and changing state for
interface wg0 from DOWN to P2P
send_packet: error sending packet to 224.0.0.5 on interface wg0: Network
is unreachable
send_hello: Network is unreachable
[...]



# ifconfig wg0
wg0: flags=80c3 mtu 1420
index 23 priority 0 llprio 3
wgport 33222
wgpubkey XXX
wgpeer YYY
    wgpka 23 (sec)
    wgendpoint A.B.C.D 31502
    tx: 4317366604, rx: 382870060
    last handshake: 47 seconds ago
    wgaip 192.168.1.0/24
    wgaip 172.26.1.3/32
wgpeer WWW
    wgpka 23 (sec)
    wgendpoint E.F.G.H 15776
    tx: 609183380, rx: 1523684
    last handshake: 1 seconds ago
    wgaip 172.26.0.0/24
    wgaip 172.26.1.2/32
groups: wg
inet 172.26.1.1 netmask 0xff00 broadcast 172.26.1.255


Is it possible to use a wg(4) interface for ospfd(8)?

Thank you,
Best.


Hello.

It is possible, I use it myself. You have to allow multicast address 
on wg(4) interface(s):

225.0.0.5 for all OSPF routers
224.0.0.6 for all DR/BDR

(I use wgaip 0.0.0.0/0, so my config is not relavant for you)

Regards,


Sorry to jump in, but does this also add routes for 225.0.0.{5,6} via wg0?

If this is a case, this would be a problem for multiple interfaces.

Or maybe wg(4) handles multicast differently than normal IP

thanks

G


Hello,

IFAIK, wgaip is not routing, using wgaip 0.0.0.0/0 does not add a 
default route on interface.


Regards,

--
Bastien

Re: ospf on wg(4)

[Bastien Durel]

Le 29/01/2021 à 17:44, Olivier Cherrier a écrit :

Hi,

I'm trying to setup OSPF on a working Wireguard VPN using 6.8 amd64
machines. This is what I get:

# ospfd -dvvv
id = "172.26.1.1"
startup
kr_init: priority filter enabled
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface wg0
if_fsm: event UP resulted in action START and changing state for
interface wg0 from DOWN to P2P
send_packet: error sending packet to 224.0.0.5 on interface wg0: Network
is unreachable
send_hello: Network is unreachable
[...]



# ifconfig wg0
wg0: flags=80c3 mtu 1420
index 23 priority 0 llprio 3
wgport 33222
wgpubkey XXX
wgpeer YYY
wgpka 23 (sec)
wgendpoint A.B.C.D 31502
tx: 4317366604, rx: 382870060
last handshake: 47 seconds ago
wgaip 192.168.1.0/24
wgaip 172.26.1.3/32
wgpeer WWW
wgpka 23 (sec)
wgendpoint E.F.G.H 15776
tx: 609183380, rx: 1523684
last handshake: 1 seconds ago
wgaip 172.26.0.0/24
wgaip 172.26.1.2/32
groups: wg
inet 172.26.1.1 netmask 0xff00 broadcast 172.26.1.255


Is it possible to use a wg(4) interface for ospfd(8)?

Thank you,
Best.


Hello.

It is possible, I use it myself. You have to allow multicast address on 
wg(4) interface(s):

225.0.0.5 for all OSPF routers
224.0.0.6 for all DR/BDR

(I use wgaip 0.0.0.0/0, so my config is not relavant for you)

Regards,

--
Bastien

Re: auto-boot

[Bastien Durel]

Le vendredi 22 janvier 2021 à 23:49 +1000, Stuart Longland a écrit :
> On 21/1/21 7:48 am, Diana Eichert wrote:
> > This is not as hard as you think.  Get a couple (it is good to have
> > extras and they are pretty cheap) RJ45-DB9 adapter, the pins
> > will not be inserted in DB9 connector, therefore you can perform
> > some
> > wire surgery.  Break open the RJ45 side, cut the cables from RJ45
> > connector.
> 
> Another option is to get a DE9 serial cable and chop it in half.
> 
> The big challenge is getting hold of such a beast.  These days if you
> walk into a computer shop and mutter things about serial ports, they
> think you're talking about a place that sailors go for breakfast.
> 
Hello,

Short-circuit pins 3-5 using my DB9 cable as Mihai Popescu said[1]
worked.
Alas, this setup prevent to plug-in the cable on the other side ^^

But this confirm there is an hardware problem.

So if I understand well, I have to buy 2 of these[2], add a short-
circuit between pins in one side, and connet them with an ethernet
cable ?

Thanks,


[1] https://corrin.geekwu.org/owncloud/index.php/s/fwPmq2CbyTy5mEX

[2] 
https://www.amazon.fr/StarTech-com-Adaptateur-modulaire-RS232-RS422/dp/B6IRQA/

-- 
Bastien

Re: auto-boot

[Bastien Durel]

Le mardi 19 janvier 2021 à 14:52 -0700, Diana Eichert a écrit :
> Hello
> 
> Having spent way to many years working on serial devices it looks to
> me like either Rcv pin has noise on it because it is floating.  If I
> remember correctly you can try a resistor between rcv and ground.
> 
> diana
Hello,

Thanks for the hint, but this is -- like Stuart's -- over my reach. I
have no soldering skills or tools, and the pins are very small[1] :(

If There is no software way to solve this problem, I shall need to buy
a small HDMI screen and drop serial console ...

Thanks anyway,

[1] https://corrin.geekwu.org/owncloud/index.php/s/QZXd8WBPimCxSs6

-- 
Bastien

Re: auto-boot

[Bastien Durel]

Le samedi 16 janvier 2021 à 12:49 +0100, Marcus MERIGHI a écrit :
> bast...@durel.org (Bastien Durel), 2021.01.14 (Thu) 18:07 (CET):
> > Le jeudi 14 janvier 2021 à 16:59 +0100, Marcus MERIGHI a écrit :
> > > bast...@durel.org (Bastien Durel), 2021.01.14 (Thu) 16:05 (CET):
> > > > Le jeudi 14 janvier 2021 à 15:47 +0100, Marcus MERIGHI a
> > > > écrit :
> > > > > bast...@durel.org (Bastien Durel), 2021.01.14 (Thu) 10:20
> > > > > (CET):
> > > > > > I have a router connected via a serial port to another
> > > > > > machine
> > > > > > (which
> > > > > > is usually powered off), wich fails to boot until I connect
> > > > > > and
> > > > > > validate the boot> prompt
> > > > > > 
> > > > > > I configured my boot.conf as it follows :
> > > > > > 
> > > > > > # cat
> > > > > > /etc/boot.conf 
> > > > > > 
> > > > > > set timeout 10
> > > > > > set tty com0
> > > > > 
> > > > > I usually have 
> > > > > 
> > > > >     stty com0 115200
> > > > >     set tty com0
> > > > >     set timeout 2
> > > > > 
> > > > > and the machines boot automagically...
> > > > > 
> > > > > Marcus
> > > > > 
> > > > Actually, it looks like the automagic boot depends on the
> > > > status of
> > > > the
> > > > attached computer : when it runs, the router boots
> > > > automagically,
> > > > and
> > > > when it does not, then the boot waits until I press enter
> > > > (after
> > > > booting it, obviously)
> > > 
> > > Ah, I failed on getting what you meant!
> > > 
> > > Emitting wild guesses now... As soon as the boot> prompt receives
> > > input,
> > > it cancels the timout counter (and doesn't auto-boot). Could it
> > > be
> > > that
> > > your non-auto-booting machine receives something that looks like
> > > input
> > > to the boot> prompt? Can you test with the serial cable detached?
> > > 
> > 
> > Done that; that's very strange : the router did not auto-boot, but
> > did
> > as soon as I plugged-in the serial cable in (I left minicom running
> > on
> > the other box) (or maybe after a few seconds, I did not checked in
> > real
> > time)
> 
> so you have ruled out the second box, good!
> 
> Things I'd try... 
> 
>     - any stray empty lines in /etc/boot.conf?
>   I'm not saying these would cause any harm, but I'd try
>     - add the speed setting ("stty com0 115200")
>     - move "set timeout X" to the end
> 
> good luck! and please report back if you solve this puzzle!
> 
> Marcus
> 
Hello,

I set boot.conf to this :

# cat -e /etc/boot.conf 
stty com0 115200$
set tty com0$
set timeout 5$
# 

But the router does not boot without beeing connected to a powered-up
machine :(

-- 
Bastien

Re: auto-boot

[Bastien Durel]

Le jeudi 14 janvier 2021 à 16:59 +0100, Marcus MERIGHI a écrit :
> bast...@durel.org (Bastien Durel), 2021.01.14 (Thu) 16:05 (CET):
> > Le jeudi 14 janvier 2021 à 15:47 +0100, Marcus MERIGHI a écrit :
> > > bast...@durel.org (Bastien Durel), 2021.01.14 (Thu) 10:20 (CET):
> > > > I have a router connected via a serial port to another machine
> > > > (which
> > > > is usually powered off), wich fails to boot until I connect and
> > > > validate the boot> prompt
> > > > 
> > > > I configured my boot.conf as it follows :
> > > > 
> > > > # cat
> > > > /etc/boot.conf 
> > > > set timeout 10
> > > > set tty com0
> > > 
> > > I usually have 
> > > 
> > >     stty com0 115200
> > >     set tty com0
> > >     set timeout 2
> > > 
> > > and the machines boot automagically...
> > > 
> > > Marcus
> > > 
> > Actually, it looks like the automagic boot depends on the status of
> > the
> > attached computer : when it runs, the router boots automagically,
> > and
> > when it does not, then the boot waits until I press enter (after
> > booting it, obviously)
> 
> Ah, I failed on getting what you meant!
> 
> Emitting wild guesses now... As soon as the boot> prompt receives
> input,
> it cancels the timout counter (and doesn't auto-boot). Could it be
> that
> your non-auto-booting machine receives something that looks like
> input
> to the boot> prompt? Can you test with the serial cable detached?
> 

Done that; that's very strange : the router did not auto-boot, but did
as soon as I plugged-in the serial cable in (I left minicom running on
the other box) (or maybe after a few seconds, I did not checked in real
time)


-- 
Bastien

Re: auto-boot

[Bastien Durel]

Le jeudi 14 janvier 2021 à 15:47 +0100, Marcus MERIGHI a écrit :
> Hello, 
> 
> bast...@durel.org (Bastien Durel), 2021.01.14 (Thu) 10:20 (CET):
> > I have a router connected via a serial port to another machine
> > (which
> > is usually powered off), wich fails to boot until I connect and
> > validate the boot> prompt
> > 
> > I configured my boot.conf as it follows :
> > 
> > # cat
> > /etc/boot.conf  
> > set timeout 10
> > set tty com0
> 
> I usually have 
> 
>     stty com0 115200
>     set tty com0
>     set timeout 2
> 
> and the machines boot automagically...
> 
> Marcus
> 
Actually, it looks like the automagic boot depends on the status of the
attached computer : when it runs, the router boots automagically, and
when it does not, then the boot waits until I press enter (after
booting it, obviously)

-- 
Bastien

auto-boot

[Bastien Durel]

Hello,

I have a router connected via a serial port to another machine (which
is usually powered off), wich fails to boot until I connect and
validate the boot> prompt

I configured my boot.conf as it follows :

# cat /etc/boot.conf  
set timeout 10
set tty com0
#

Shouln't the box boot by itself after 10 seconds ?

Regards,

dmesg:

OpenBSD 6.8 (GENERIC.MP) #3: Thu Jan  7 07:35:39 MST 2021

r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4196298752 (4001MB)
avail mem = 4054081536 (3866MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ce21000 (85 entries)
bios0: vendor American Megatrends Inc. version "5.12" date 11/23/2018
bios0: Default string Default string
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT UEFI SSDT 
LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT DMAR ASF! WSMT
acpi0: wakeup devices RP09(S3) PXSX(S3) RP10(S3) PXSX(S3) RP11(S3) PXSX(S3) 
RP12(S3) PXSX(S3) RP13(S3) PXSX(S3) RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) 
RP03(S3) PXSX(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU 3865U @ 1.80GHz, 1696.62 MHz, 06-8e-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,INVPCID,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU 3865U @ 1.80GHz, 1696.06 MHz, 06-8e-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,INVPCID,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus 1 (RP01)
acpiprt10 at acpi0: bus 2 (RP02)
acpiprt11 at acpi0: bus 3 (RP03)
acpiprt12 at acpi0: bus 4 (RP04)
acpiprt13 at acpi0: bus 5 (RP05)
acpiprt14 at acpi0: bus 6 (RP06)
acpiprt15 at acpi0: bus -1 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiprt25 at acpi0: bus -1 (RP14)
acpiprt26 at acpi0: bus -1 (RP15)
acpiprt27 at acpi0: bus -1 (RP16)
acpiec0 at acpi0: not present
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"INT344B" at acpi0 not configured
acpibtn0 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
"INT33A1" at acpi0 not configured
acpibtn1 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 119 degC
acpitz1 at acpi0: critical temperature is 119 degC
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 1696 MHz: speeds: 

Re: misc panics

[Bastien Durel]

Le lundi 28 décembre 2020 à 12:34 +0200, Gregory Edigarov a écrit :
> On 12/28/20 12:18 PM, rgc wrote:
> > On Mon, Dec 28, 2020 at 10:39:56AM +0100, Otto Moerbeek wrote:
> > > On Mon, Dec 28, 2020 at 10:25:08AM +0100, Bastien Durel wrote:
> > > 
> > > > Le lundi 28 d?cembre 2020 ? 09:17 +, Stuart Henderson a
> > > > ?crit?:
> > > > > > So hardware failure confirmed :/ Do you think I can change
> > > > > > the RAM
> > > > > > or
> > > > > > it's more likely a CPU/Chipset failure ?
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > If you have multiple sticks of RAM, try removing some.
> > > > I have only one
> > > trying to reaset it is worth a try.
> > > 
> > > -Otto
> > > 
> > or doing the eraser magick
> > 
> > you clean the contacts (remove oxidation) of the RAM module (the
> > side that
> > sticks in the motherboard) by rubbing a pencil eraser on the
> > contacts of the
> > RAM module.
> > 
> in my experience, all the RAM modules nowadays comes gold plated, so
> no
> need to use eraser on them.
> just a piece of paper, to make sure there is no grease on the
> contacts
> 
Hello,

For those interested, a new memory module made the box able to run
again. (Neither cleaning or using eraser worked)

Thanks,

-- 
Bastien

Re: misc panics

[Bastien Durel]

Le lundi 28 décembre 2020 à 09:17 +, Stuart Henderson a écrit :
> > So hardware failure confirmed :/ Do you think I can change the RAM
> > or
> > it's more likely a CPU/Chipset failure ?
> > 
> > Thanks,
> > 
> 
> If you have multiple sticks of RAM, try removing some.
I have only one

-- 
Bastien

Re: misc panics

[Bastien Durel]

Le lundi 28 décembre 2020 à 09:23 +1000, Stuart Longland a écrit :
> On 28/12/20 3:56 am, Bastien Durel wrote:
> > After that I got a (maybe) endless loop of panics inducing panics
> > (I did 
> > not got the output, it was cycling fast), and after that the /bsd
> > file 
> > was left empty :
> > 
> > > > > OpenBSD/amd64 BOOT 3.52
> > > boot> NOTE: random seed is being reused.
> > > booting hd0a:/bsd: read header
> > >  failed(0). will try /bsd
> …
> > How can I figure out the cause of all these problems ?
> 
> Seems awfully strange for `/bsd` to become zero-length out-of-the-
> blue. 
>   Got a `memtest86` disk handy?
> 
> I'd be checking:
> - RAM
> - disks
> - CPU
> 
> I think from the `dmesg` the storage device is a SSD?  Could it be it
> has failed early?  Some do that, and they give practically no warning
> when they do.

SMART is OK on the disk

I ran a memtest86 test, and got thousands of errors


Test Start Time 2020-12-28 08:38:08
Elapsed Time0:01:11
Memory Range Tested 0x0 - 16F00 (5872MB)
CPU Selection Mode  Parallel (All CPUs)
ECC Polling Enabled

Lowest Error Address0x12AA18018 (4778MB)
Highest Error Address   0x12BFE7FF8 (4799MB)
Bits in Error Mask  FF00
Bits in Error   8
Max Contiguous Errors   1



Test# Tests Passed  Errors
Test 0 [Address test, walking ones, 1 CPU]  1/1 (100%)  0
Test 1 [Address test, own address, 1 CPU]   0/0 (0%)10988


Last 10 Errors
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7FF8,
Expected: 00012BFE7FF8, Actual: 10012BFE7FF8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7FE8,
Expected: 00012BFE7FE8, Actual: 04012BFE7FE8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7F58,
Expected: 00012BFE7F58, Actual: 04012BFE7F58
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7F48,
Expected: 00012BFE7F48, Actual: 08012BFE7F48
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EF8,
Expected: 00012BFE7EF8, Actual: 40012BFE7EF8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EE8,
Expected: 00012BFE7EE8, Actual: C0012BFE7EE8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EC8,
Expected: 00012BFE7EC8, Actual: 04012BFE7EC8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7E58,
Expected: 00012BFE7E58, Actual: 40012BFE7E58
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7D58,
Expected: 00012BFE7D58, Actual: 08012BFE7D58
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7D48,
Expected: 00012BFE7D48, Actual: 08012BFE7D48


So hardware failure confirmed :/ Do you think I can change the RAM or
it's more likely a CPU/Chipset failure ?

Thanks,

-- 
Bastien Durel

misc panics

[Bastien Durel]

a2f1bac75,fd800805b568,fd813843e340,804
alltraps_kern_meltdown(4,800,0,0,fd800805b568,fd813843e340) 
at alltraps_kern_melb
pmap_page_remove(fd800805b500,fd800805b500,e03d06e9ac14a5a6,fd800805b500,fd813843e34e
uvm_anfree_list(fd813843e340,8000227c35c8,9353a28319cbf425,8000227c35c8,fd813537d6806
amap_wipeout(fd813537d680,fd813537d680,f88a0e1c22e82980,8000227c3678,1,8000227c3680)7
uvm_unmap_detach(8000227c3678,1,416162009098f49d,0,fd816e493000,800022796c68)
 at uvm_unm4
uvm_map_teardown(fd816e493000,fd816e493000,5f0772d5f721764e,0,fd816e493000,fd81353e59
uvmspace_free(fd816e493000,fd816e493000,1671103de78dc753,80000f28,8185c77d,fd
uvm_exit(80000f28,80000f28,d28c4c5e6a7e09f8,80000f28,81db4744,804
reaper(800022796c68,800022796c68,0,81a74460,81a745ac,8000227c3740)
 at rec
end trace frame: 0x0, count: 246
End of stack trace.


I managed to get a working shell only by booting /bsd.sp, from which I 
re-downloaded the stock /bsd, and reverted all syspatches, but after a 
reboot I get the usual cash on boot, which induced another crash (but 
this time it was not looping)



Sun Dec 27 13:48:34 CET 2020

OpenBSD/amd64 (fremen.geekwu.org) (tty00)

login: fatal protection fault in supervisor mode
trap type 4 code 0 rip 8160f334 cs 8 rflags 10282 cr2 3091d1000 cpl a 
rsp 80003398a890
gsbase 0x800022410ff0  kgsbase 0x0
panic: trap type 4, code=0, pc=8160f334
Starting stack trace...
panic(81de58d0) at panic+0x11d
kerntrap(80003398a7e0) at kerntrap+0x114
alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
pool_do_get(821ece68,2,80003398a934) at pool_do_get+0x74
pool_get(821ece68,2) at pool_get+0x8f
pmap_enter(82185100,88053000,132836000,3,33) at pmap_enter+0xb9
uvm_pagermapin(80003398abc8,1,2) at uvm_pagermapin+0xa8
uvn_io(fd81413fccf8,80003398abc8,1,2,0) at uvn_io+0xbf
uvn_get(fd81413fccf8,67b4000,80003398ae10,80003398adc4,0,2) at 
uvn_get+0x156
uvm_fault(fd814c81d228,3091d1000,0,2) at uvm_fault+0xcb4
pageflttrap(80003398af40,3091d1000,1) at pageflttrap+0xfe
usertrap(80003398af40) at usertrap+0x16e
recall_trap() at recall_trap+0x8
end of kernel
end trace frame: 0x23ac14fc0, count: 244
End of stack trace.
syncing disks...fatal protection fault in supervisor mode
trap type 4 code 0 rip 8160f334 cs 8 rflags 10282 cr2 3091bd000 cpl 0 
rsp 8000339c47c0
gsbase 0x8210cff0  kgsbase 0x0
panic: trap type 4, code=0, pc=8160f334
Starting stack trace...
panic(81de58d0) at panic+0x11d
kerntrap(8000339c4710) at kerntrap+0x114
alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
pool_do_get(821ece68,2,8000339c4864) at pool_do_get+0x74
pool_get(821ece68,2) at pool_get+0x8f
pmap_enter(82185100,88063000,132834000,3,33) at pmap_enter+0xb9
uvm_pagermapin(8000339c4af8,1,2) at uvm_pagermapin+0xa8
uvn_io(fd81413fccf8,8000339c4af8,1,2,0) at uvn_io+0xbf
uvn_get(fd81413fccf8,67a,8000339c4d40,8000339c4cf4,0,2) at 
uvn_get+0x156
uvm_fault(fd814c81d228,3091bd000,0,2) at uvm_fault+0xcb4
pageflttrap(8000339c4e70,3091bd000,1) at pageflttrap+0xfe
usertrap(8000339c4e70) at usertrap+0x16e
recall_trap() at recall_trap+0x8
end of kernel
end trace frame: 0x205ed3430, count: 244
End of stack trace.

dump to dev 4,1 not possible
rpaenboioct: inkge.rn.e.


After that I gave up and installed a spare router.

How can I figure out the cause of all these problems ?

Thanks,

--
Bastien Durel

Re: bird make network unusable on 6.8-current

[Bastien Durel]

Le mardi 20 octobre 2020 à 12:41 +, Stuart Henderson a écrit :
> On 2020-10-20, Bastien Durel  wrote:
> > Le lundi 19 octobre 2020 à 17:17 +0100, Tom Smyth a écrit :
> > > Hi Bastien,
> > Hello
> > 
> > > can you do a
> > > route show -n |grep 10\.42
> > 
> > Boot time: 
> > 
> > default    10.42.42.1 UGS    5    5 -
> >  8 em0
> > 10.42.2/24 10.42.42.21    UGS    0    0 -
> >  8 em0
> > 10.42.42/24    10.42.42.69    UCn    3    0 -
> >  4 em0
> 
> so here you have 10.42.42/24 directly connected
> 
> > 10.42.42.1 40:62:31:01:4b:66  UHLch  1    2 -
> >  3 em0
> > 10.42.42.3 d0:50:99:18:63:82  UHLc   1    4 -
> > L   3 em0
> > 10.42.42.21    link#1 UHLch  1    2 -
> >  3 em0
> > 10.42.42.69    08:00:27:d6:6e:dd  UHLl   0    2 -
> >  1 em0
> > 10.42.42.255   10.42.42.69    UHb    0   12 -
> >  1 em0
> > 
> > After bird is started :
> > 
> > 
> > default    10.42.42.1 UGS    5    6 -
> >  8 em0
> > 10.42.2/24 10.42.42.21    UGS    0    0 -
> >  8 em0
> > 10.42.42/24    10.42.42.69    U1 0    2 -
> >     56 em0
> > 10.42.42.69    08:00:27:d6:6e:dd  UHLl   0   10 -
> >  1 em0
> > 10.42.42.255   10.42.42.69    UHb    0   14 -
> >  1 em0
> 
> and here bird has overwritten it (the "prio 56" routes are a bit of a
> clue
> that it's likely to be added by bird; it doesn't understand openbsd's
> route
> priorities and just adds with the default priority which is 56)
> 
> some way or other you'll need to stop it overriding your directly
> connected
> networks. I'm no expert in bird and when I've used it is has mostly
> not been
> handling the route table, only collecting BGP routes itself, but I
> would
> think you might be able to do that with a filter.
> 
> From the config you showed I'm not seeing anything that seems like a
> reason
> to use bird over the OSPF daemons in base; they are definitely
> preferred if
> possible because they were written with awareness of the rest of
> OpenBSD's
> network stack.
> 
> 
I tried to use bird because ospfd(8) seemed to had problems with
wireguard tunnels (but I did not test it with 6.8 yet)

Re: bird make network unusable on 6.8-current

[Bastien Durel]

Le lundi 19 octobre 2020 à 17:17 +0100, Tom Smyth a écrit :
> Hi Bastien,
Hello

> can you do a
> route show -n |grep 10\.42

Boot time: 

default10.42.42.1 UGS55 - 8 em0
10.42.2/24 10.42.42.21UGS00 - 8 em0
10.42.42/2410.42.42.69UCn30 - 4 em0
10.42.42.1 40:62:31:01:4b:66  UHLch  12 - 3 em0
10.42.42.3 d0:50:99:18:63:82  UHLc   14 - L   3 em0
10.42.42.21link#1 UHLch  12 - 3 em0
10.42.42.6908:00:27:d6:6e:dd  UHLl   02 - 1 em0
10.42.42.255   10.42.42.69UHb0   12 - 1 em0

After bird is started :


default10.42.42.1 UGS56 - 8 em0
10.42.2/24 10.42.42.21UGS00 - 8 em0
10.42.42/2410.42.42.69U1 02 -56 em0
10.42.42.6908:00:27:d6:6e:dd  UHLl   0   10 - 1 em0
10.42.42.255   10.42.42.69UHb0   14 - 1 em0


And a few seconds after :

default10.42.42.1 UGS1   28 - 8 em0
default10.42.42.1 UG100 -56 em0
10.0.42.21 10.42.42.21UGH1   00 -56 em0
10.42.0/24 10.42.42.1 UG100 -56 em0
10.42.1.56/30  10.42.42.21UG100 -56 em0
10.42.1.64/30  10.42.42.21UG100 -56 em0
10.42.1.76/30  10.42.42.21UG100 -56 em0
10.42.2/24 10.42.42.21UGS0   10 - 8 em0
10.42.2/24 10.42.42.21UG100 -56 em0
10.42.2.25410.42.42.21UGH1   0 1088 -56 em0
10.42.7.6  10.42.42.21UGH1   00 -56 em0
10.42.7.7  10.42.42.21UGH1   00 -56 em0
10.42.7.53 10.42.42.21UGH1   00 -56 em0
10.42.42/2410.42.42.69U1h   31   95 -56 em0
10.42.42.6908:00:27:d6:6e:dd  UHLl   0   19 - 1 em0
10.42.42.255   10.42.42.69UHb07 - 1 em0
10.60.77.5 10.42.42.1 UGH1   00 -56 em0
10.120/16  10.42.42.1 UG100 -56 em0
[...]

As all routes are going through 10.42.42.1 or 10.42.42.21, all my
routing table matches the grep

Im guessing here but
can you verify if BGP  or Ospf is  *Not* inserting  routes that are
more specific than your connected route on your interface

say you have 10.42.42.x/24  on your interface em0

openbsd-test# ifconfig em0 | grep -v inet6
em0:
flags=a08843 mtu 1500
lladdr 08:00:27:d6:6e:dd
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 10.42.42.69 netmask 0xff00 broadcast 10.42.42.255


and then you receive a /32 route 10.42.42.1  to point at another
address

once that route is installed your kernel wont know how to look up the
mac address of 10.42.42.1  (because it will no longer try your
physical interface)

quick workaround is put a sciatic arp entry for the ips that are
being
inserted as a morespecific route than your connected route

proper workaround filter out the more specifics If you need more
specifics (have the more specific ips on a separate network that does
not conflict with your connected routes

Hope this helps

I don't see routes to 10.42.42.1 or 10.42.42.21 (I've put full ospf
status & ospf interface outputs)

Note that ospfd(8) can run without crashing network, so I assume ospf
works correctly in the network

Regards,

-- 
Bastien
BIRD 2.0.7 ready.
ospfv2:
Interface em0 (10.42.42.0/24)
Type: broadcast
Area: 0.0.0.0 (0)
State: DROther
Priority: 1
Cost: 5
Hello timer: 10
Wait timer: 40
Dead timer: 40
Retransmit timer: 5
Designated router (ID): 10.42.42.21
Designated router (IP): 10.42.42.21
Backup designated router (ID): 10.42.42.1
Backup designated router (IP): 10.42.42.1
BIRD 2.0.7 ready.

area 0.0.0.0

router 10.42.1.78
distance 15
router 10.42.42.21 metric 10
stubnet 10.42.1.76/30 metric 10
stubnet 10.42.2.254/32 metric 10

router 10.42.42.1
distance 5
network 10.120.0.20/30 metric 12
network 10.120.0.8/30 metric 12
network 10.120.0.4/30 metric 10
network 10.120.0.0/30 metric 10
network 10.42.42.0/24 metric 1
stubnet 10.255.255.0/24 metric 10
stubnet 

Re: bird make network unusable on 6.8-current

[Bastien Durel]

Le vendredi 03 avril 2020 à 17:41 +0200, Bastien Durel a écrit :
> Hello,
> 
> As bird makes 6.6 panic, I tested it on 6.6-current. The kernel does
> not panic, but after bird runs, networking deos not work anymore.
> 
> Bird seems to work correctly, it inserts routes in the kernel as
> intended :
> 
> (before bird)
> Routing tables
> 
> Internet:
> Destination    Gateway    Flags   Refs  Use   Mtu 
> Prio Iface
> default    10.42.42.1 UG1    0    0 -   
> 56 em0  
> 224/4  127.0.0.1  URS    0   17 32768
> 8 lo0  
> 10.42.2/24 10.42.42.21    UG1    0    0 -   
> 56 em0  
> 10.42.42/24    10.42.42.69    U1h    1   51 -   
> 56 em0  
> 10.42.42.3 10.42.42.69    UGHD   1   51 - L 
> 56 em0  
> 10.42.42.69    08:00:27:d6:6e:dd  UHLhl  1   26 -
> 1 em0  
> 10.42.42.255   10.42.42.69    UHb    0   10 -
> 1 em0  
> 127/8  127.0.0.1  UGRS   0    0 32768
> 8 lo0  
> 127.0.0.1  127.0.0.1  UHhl   1    2 32768
> 1 lo0  
> 
> (with bird)
> Routing tables
> 
> Internet:
> Destination    Gateway    Flags   Refs  Use   Mtu 
> Prio Iface
> default    10.42.42.1 UGS    5   12 -
> 8 em0  
> default    10.42.42.1 UG1    0    0 -   
> 56 em0  
> 224/4  127.0.0.1  URS    0   15 32768
> 8 lo0  
> 10.0.42.21 10.42.42.21    UGH1   0    0 -   
> 56 em0  
> 10.42.0/24 10.42.42.1 UG1    0    0 -   
> 56 em0  
> 10.42.1.56/30  10.42.42.21    UG1    0    0 -   
> 56 em0  
> 10.42.1.64/30  10.42.42.21    UG1    0    0 -   
> 56 em0  
> 10.42.1.76/30  10.42.42.21    UG1    0    0 -   
> 56 em0  
> 10.42.2/24 10.42.42.21    UGS    0    4 -
> 8 em0  
> 10.42.2/24 10.42.42.21    UG1    0    0 -   
> 56 em0  
> 10.42.2.254    10.42.42.21    UGH1   0    0 -   
> 56 em0  
> 10.42.7.6  10.42.42.21    UGH1   0    0 -   
> 56 em0  
> 10.42.7.7  10.42.42.21    UGH1   0    0 -   
> 56 em0  
> [...]
> 
> Bird config is simple (stripped comments):
> router id 10.42.42.69;
> protocol device {
> }
> protocol direct {
> disabled;   # Disable by default
> ipv4;   # Connect to default IPv4 table
> ipv6;   # ... and to default IPv6 table
> }
> protocol kernel {
> ipv4 {  # Connect protocol to IPv4 table by
> channel
>   import none;  # Import to table, default is import
> all
>   export all;   # Export to protocol. default is
> export none
> };
> }
> protocol ospf v2 ospfv2 {
> rfc1583compat yes;
> tick 2;
> ipv4 {};
> area 0 {
>  interface "em0" { cost 10; };
> };
> }
> 
> But although bird adjacencies are ok, the box cannot communicate with
> others, via TCP (ssh) or ping, even on the same link :
> 
> BIRD 2.0.6 ready.
> ospfv2:
> Router ID   Pri  State  DTime   Interface  Router IP
> 10.42.42.21   1 ExStart/DR  39.261  em0   
> 10.42.42.21
> 10.42.42.1    1 ExStart/BDR 38.635  em0    10.42.42.1
> BIRD 2.0.6 ready.
> ospfv3:
> Router ID   Pri  State  DTime   Interface  Router IP
> 10.42.42.21   1 Full/DR 35.854  em0   
> fe80::225:22ff:fe1e:bb7
> 10.42.42.1    1 Full/BDR36.525  em0   
> fe80::4262:31ff:fe01:4b66
> 
> PING fe80::225:22ff:fe1e:bb7 (fe80::225:22ff:fe1e:bb7): 56 data bytes
> ping6: sendmsg: Network is unreachable
> ping: wrote fe80::225:22ff:fe1e:bb7 64 chars, ret=-1
> ping6: sendmsg: Network is unreachableping: wrote
> fe80::225:22ff:fe1e:bb7 64 chars, ret=-1
> ping6: sendmsg: Network is unreachableping: wrote
> fe80::225:22ff:fe1e:bb7 64 chars, ret=-1
> ping6: sendmsg: Network is unreachableping: wrote
> fe80::225:22ff:fe1e:bb7 64 chars, ret=-1
> 
> --- fe80::225:22ff:fe1e:bb7 ping statistics ---
> 4 packets transmitted, 0 packets received, 100.0% packet loss
> 
> 
> PING 10.42.42.1 (10.42.42.1): 56 data bytes 
> ping: sendmsg: Invalid argument
> ping: wrote 10.42.42.1 64 chars, ret=-1 
> ping: sendmsg: Invalid argument
> ping: wrote 10.42.42.1 64 chars, ret=-1 
> ping: sendmsg:

bird make network unusable on 6.6-current

[Bastien Durel]

Hello,

As bird makes 6.6 panic, I tested it on 6.6-current. The kernel does
not panic, but after bird runs, networking deos not work anymore.

Bird seems to work correctly, it inserts routes in the kernel as
intended :

(before bird)
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default10.42.42.1 UG100 -56 em0  
224/4  127.0.0.1  URS0   17 32768 8 lo0  
10.42.2/24 10.42.42.21UG100 -56 em0  
10.42.42/2410.42.42.69U1h1   51 -56 em0  
10.42.42.3 10.42.42.69UGHD   1   51 - L  56 em0  
10.42.42.6908:00:27:d6:6e:dd  UHLhl  1   26 - 1 em0  
10.42.42.255   10.42.42.69UHb0   10 - 1 em0  
127/8  127.0.0.1  UGRS   00 32768 8 lo0  
127.0.0.1  127.0.0.1  UHhl   12 32768 1 lo0  

(with bird)
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default10.42.42.1 UGS5   12 - 8 em0  
default10.42.42.1 UG100 -56 em0  
224/4  127.0.0.1  URS0   15 32768 8 lo0  
10.0.42.21 10.42.42.21UGH1   00 -56 em0  
10.42.0/24 10.42.42.1 UG100 -56 em0  
10.42.1.56/30  10.42.42.21UG100 -56 em0  
10.42.1.64/30  10.42.42.21UG100 -56 em0  
10.42.1.76/30  10.42.42.21UG100 -56 em0  
10.42.2/24 10.42.42.21UGS04 - 8 em0  
10.42.2/24 10.42.42.21UG100 -56 em0  
10.42.2.25410.42.42.21UGH1   00 -56 em0  
10.42.7.6  10.42.42.21UGH1   00 -56 em0  
10.42.7.7  10.42.42.21UGH1   00 -56 em0  
[...]

Bird config is simple (stripped comments):
router id 10.42.42.69;
protocol device {
}
protocol direct {
disabled;   # Disable by default
ipv4;   # Connect to default IPv4 table
ipv6;   # ... and to default IPv6 table
}
protocol kernel {
ipv4 {  # Connect protocol to IPv4 table by channel
  import none;  # Import to table, default is import all
  export all;   # Export to protocol. default is export none
};
}
protocol ospf v2 ospfv2 {
rfc1583compat yes;
tick 2;
ipv4 {};
area 0 {
 interface "em0" { cost 10; };
};
}

But although bird adjacencies are ok, the box cannot communicate with
others, via TCP (ssh) or ping, even on the same link :

BIRD 2.0.6 ready.
ospfv2:
Router ID   Pri  State  DTime   Interface  Router IP
10.42.42.21   1 ExStart/DR  39.261  em010.42.42.21
10.42.42.11 ExStart/BDR 38.635  em010.42.42.1
BIRD 2.0.6 ready.
ospfv3:
Router ID   Pri  State  DTime   Interface  Router IP
10.42.42.21   1 Full/DR 35.854  em0
fe80::225:22ff:fe1e:bb7
10.42.42.11 Full/BDR36.525  em0
fe80::4262:31ff:fe01:4b66

PING fe80::225:22ff:fe1e:bb7 (fe80::225:22ff:fe1e:bb7): 56 data bytes
ping6: sendmsg: Network is unreachable
ping: wrote fe80::225:22ff:fe1e:bb7 64 chars, ret=-1
ping6: sendmsg: Network is unreachableping: wrote fe80::225:22ff:fe1e:bb7 64 
chars, ret=-1
ping6: sendmsg: Network is unreachableping: wrote fe80::225:22ff:fe1e:bb7 64 
chars, ret=-1
ping6: sendmsg: Network is unreachableping: wrote fe80::225:22ff:fe1e:bb7 64 
chars, ret=-1

--- fe80::225:22ff:fe1e:bb7 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss


PING 10.42.42.1 (10.42.42.1): 56 data bytes 
ping: sendmsg: Invalid argument
ping: wrote 10.42.42.1 64 chars, ret=-1 
ping: sendmsg: Invalid argument
ping: wrote 10.42.42.1 64 chars, ret=-1 
ping: sendmsg: Invalid argument
ping: wrote 10.42.42.1 64 chars, ret=-1 
ping: sendmsg: Invalid argument
ping: wrote 10.42.42.1 64 chars, ret=-1

--- 10.42.42.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

Stopping bird does not let network recover, nor does flushing routes
(route -n flush) or restarting interface with netstart em0

I've done theses tests on various VMs, as I didn't want to upgrade my
real router to snapshot (the bug is reproductible on virtual box &
qemu-kvm, with intel pro/1000 or virtio interfaces)

here is the dmesg (with errors that may be relevant):
OpenBSD 6.6-current (GENERIC) #94: Thu Apr  2 14:10:04 MDT 2020

bird crashes kernel

[Bastien Durel]

Hello,

I tried to replace ospfd & ospf6d by bird, as they don't seem to handle
wireguard tunnels well, but soon after bird starts (or stops), I get a
panic (copied from console):

fremen# /etc/rc.d/bird stop
birduvm_fault(0xfd813f96b000, 0x18, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 81a49c6b cs 8 rflags 10206 cr2  18 cpl 0 rsp 
8000336d08c0
gsbase 0x81f44ff0  kgsbase 0x0
panic: trap type 6, code=0, pc=81a49c6b
Starting stack trace...
panic() at panic+0x11b
kerntrap(8000336d0810) at kerntrap+0x114
alltraps_kern_meltdown(6,28001,0,0,815b2dd0,18) at 
alltraps_kern_meltdown+0x7b
ml_purge(18) at ml_purge+0x1b
arp_rtrequest() at arp_rtrequest+0x180
rtm_output(814b6600,8000336d0ad0,8000336d0a28,40,0) at 
rtm_output+0x41d
route_output(fd808b525500,fd813212c090,0,0) at route_output+0x329
route_usrreq(fd813212c090,9,fd808b525500,0,0,800033566548) at 
route_usrreq+0x207
sosend(fd813212c090,0,8000336d0d28,0,0,80) at sosend+0x383
dofilewritev(800033566548,5,8000336d0d28,0,8000336d0e00) at 
dofilewritev+0xf9
sys_write(800033566548,8000336d0da0,8000336d0e00) at sys_write+0x51
syscall(8000336d0e70) at syscall+0x389
Xsyscall(6,4,1eee94104820,4,1eee9c8370d8,1eeec4584c80) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7f62c0, count: 244
End of stack trace.
syncing disks...10 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9  giving up

Here is the dmesg :

[...]
arpresolve: 10.42.42.0: route contains no arp information
arpresolve: 10.42.42.0: route contains no arp information
arpresolve: 10.42.42.0: route contains no arp information
uvm_fault(0xfd813f96b000, 0x18, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 81a49c6b cs 8 rflags 10206 cr2  18 cpl 0 rsp 
8000336d08c0
gsbase 0x81f44ff0  kgsbase 0x0
panic: trap type 6, code=0, pc=81a49c6b
Starting stack trace...
panic() at panic+0x11b
kerntrap(8000336d0810) at kerntrap+0x114
alltraps_kern_meltdown(6,28001,0,0,815b2dd0,18) at 
alltraps_kern_meltdown+0x7b
ml_purge(18) at ml_purge+0x1b
arp_rtrequest() at arp_rtrequest+0x180
rtm_output(814b6600,8000336d0ad0,8000336d0a28,40,0) at 
rtm_output+0x41d
route_output(fd808b525500,fd813212c090,0,0) at route_output+0x329
route_usrreq(fd813212c090,9,fd808b525500,0,0,800033566548) at 
route_usrreq+0x207
sosend(fd813212c090,0,8000336d0d28,0,0,80) at sosend+0x383
dofilewritev(800033566548,5,8000336d0d28,0,8000336d0e00) at 
dofilewritev+0xf9
sys_write(800033566548,8000336d0da0,8000336d0e00) at sys_write+0x51
syscall(8000336d0e70) at syscall+0x389
Xsyscall(6,4,1eee94104820,4,1eee9c8370d8,1eeec4584c80) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7f62c0, count: 244
End of stack trace.
syncing disks...presolve: 10.42.42.0: route contains no arp informat
OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020

r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4196302848 (4001MB)
avail mem = 4056403968 (3868MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ce22000 (85 entries)
bios0: vendor American Megatrends Inc. version "5.12" date 11/23/2018
bios0: Default string Default string
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT UEFI SSDT 
LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT DMAR ASF! WSMT
acpi0: wakeup devices RP09(S3) PXSX(S3) RP10(S3) PXSX(S3) RP11(S3) PXSX(S3) 
RP12(S3) PXSX(S3) RP13(S3) PXSX(S3) RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) 
RP03(S3) PXSX(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU 3855U @ 1.60GHz, 1596.83 MHz, 06-4e-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,ERMS,INVPCID,RDSEED,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU 3855U @ 1.60GHz, 1596.29 MHz, 06-4e-03
cpu1: 

Re: IPv6 problems

[Bastien Durel]

Le jeudi 22 août 2019 à 20:11 +0200, list a écrit :
> Hi,
> 
> I might be missing something right here
> 
> I have the output of "route show" attached, because I cannot paste it
> in
> here in a formatted form.
> 
> 
> This is super annoying.
> 
> Just wanna get the damn thing running.
> 
ff02::2 is a multicast address, it's not intended to be used as a route
gateway.
It's only a way to discover routers.

for example:

fremen# ping6  ff02::2%em1
PING ff02::2%em1 (ff02::2%em1): 56 data bytes
64 bytes from fe80::6366:1356:e19:f361%em1: icmp_seq=0 hlim=64 time=0.114 ms
64 bytes from fe80::225:22ff:fe1e:bb7%em1: icmp_seq=0 hlim=64 time=0.320 ms 
(DUP!)
64 bytes from fe80::6366:1356:e19:f361%em1: icmp_seq=1 hlim=64 time=0.082 ms
64 bytes from fe80::225:22ff:fe1e:bb7%em1: icmp_seq=1 hlim=64 time=0.293 ms 
(DUP!)

Here fe80::6366:1356:e19:f361 is the LL address of em1, so
fe80::225:22ff:fe1e:bb7%em1 is the router on the other side of link.

-- 
Bastien

Re: IPv6 problems

[Bastien Durel]

Le dimanche 18 août 2019 à 11:50 +0200, list a écrit :
> When I take a closer look and run tcpdump while pinging I see the
> following output: 
> (With route to fe80::1%vio added and the normal hostname.vio0)
> 
> 11:40:36.446539 fe80:: > ff02::1:ff00:1: icmp6: neighbor sol:
> who has fe80::1
> 
> This line is being repeated over and over again. I left out all the
> other traffic that is not related to my /64. 
> 
> Hm... 
> Any ideas ? 
> 
> I've got a feeling that somethings wrong with that fe80::1
> address... 
Hello,

A router may be configured to use fe80::1 LL address, but it may not
too. It's not a standard AFAIK. I never encountered one myself.
If no one responds to your neighbor sol packet, it's probably because
no router uses this address.

To discover routers in an unknown network, I use "ping6 ff02::2%vio0",
as ff02::2 is a standard multicast address for "ip6-allrouters" (as
ff02::1 is for all nodes)

-- 
Bastien

Re: rtadvd bug ?

[Bastien Durel]

Le 17/06/2018 à 22:57, Sebastian Benoit a écrit :


you have to do check

   if (rtm->rtm_flags & RTF_CONNECTED)

The priority of a connected route depends on the interface priority,
see ifconfig(8) on the priority option and wifi and carp interfaces have a
different default prio than other interfacs. So the prio is not an indicator
for the type of the route.

/Benno


/* sanity check for plen */
/* as RFC2373, prefixlen is at least 4 */
if (plen < 4 || plen > 127) {




Hello,

The patch indeed prevent including ospf6d-learned route to be advertised 
by rtadvd, as priority is 32 (RTP_OSPF).


I had to add a check on RTM_DELETE: case too, as ospf6d add (an remove) 
routes on itself, see this:


fremen# route -n show -inet6|grep ac42
2a01:e35:8aea:ac42::/642a01:e35:8aea:ac42:200:24ff:fed1:420d 
UCn12 - 4 em1
2a01:e35:8aea:ac42::/64link#2 UC 
00 -32 em1


2a01:e35:8aea:ac42:200:24ff:fed1:420d is em1 address.

without checking priority on RTM_DELETE, stopping ospf6d removes all 
prefixes ...



checking rtm_flags & RTF_CONNECTED works too, as Sebastien said.
dhcpv6-pd works regardless of the check (I run it on this router).

--
Bastien

Re: rtadvd bug ?

[Bastien Durel]

Le samedi 09 juin 2018 à 19:23 +0200, Denis Fondras a écrit :
> On Thu, Jun 07, 2018 at 04:02:34PM +0200, Bastien Durel wrote:
> > shouldn't it check the rtm_priority to be RTP_LOCAL or
> > RTP_CONNECTED ??
> > it make no sense to start advertising prefix on an interface if the
> > prefix is over a gateway.
> > 
> 
> Why RTP_LOCAL ?
> 
Because it's lower than RTP_CONNECTED and I don't know what it is. The
/* local address routes (must be the highest) */ comment makes me think
it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may
be related to interface addresses; I did not check in the kernel code
how this flag is set. (hence the question marks)

-- 
Bastien Durel

Re: rtadvd bug ?

[Bastien Durel]

Le mercredi 06 juin 2018 à 17:11 +0200, Bastien Durel a écrit :
> Le mercredi 06 juin 2018 à 13:55 +0200, Bastien Durel a écrit :
> > Hello,
> > 
> > I run rtadvd on a router, which also run ospfd (on 6.3).
> > 
[...]
> > if an ospf neighbour start advertising a new network (in my case
> > 2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel:
> > 
> > fremen# route -n show -inet6|grep ecf1
> > 2001:41d0:fe4b:ecf1::/64   fe80::225:22ff:fe1e:bb7%em1U
> > G 
> >  0  594 -32 em1
> > but rtadvd starts advertising it on the link with the said
> > neighbour.
> > 
[...]

I looked at the code, and see rtadvd monitors the routing table and add
new prefix when new route appears.
 
shouldn't it check the rtm_priority to be RTP_LOCAL or RTP_CONNECTED ??
it make no sense to start advertising prefix on an interface if the
prefix is over a gateway.

I can always put a -s in rtadvd_flags for my use case, I'd prefer a fix
;)

Thanks,

-- 
Bastien Durel

Re: rtadvd bug ?

[Bastien Durel]

Le mercredi 06 juin 2018 à 13:55 +0200, Bastien Durel a écrit :
> Hello,
> 
> I run rtadvd on a router, which also run ospfd (on 6.3).
> 
> rtadvd runs with static config (noifprefix):
> fremen# cat /etc/rtadvd.conf
> em0:\
>  :rdnss="2a01:e35:8aea:ac42::10":\
>  :dnssl="geekwu.org":\
>  :addr0="2001:41d0:fe4b:ec21::":\
>  :addr1="2a01:0e35:8aea:ac41::":\
>  :noifprefix:
> em1:\
>  :rdnss="2a01:e35:8aea:ac42::10":\
>  :dnssl="geekwu.org":\
>  :addr0="2a01:e35:8aea:ac42::":\
>  :addr1="2001:41d0:fe4b:ec42::":\
>  :noifprefix:
> em5:\
>  :rdnss="2001:41d0:fe4b:ec42::10":\
>  :dnssl="geekwu.org":\
>  :addr0="2a01:e35:8aea:ac43::":\
>  :noifprefix:
> em4:\
>  :rdnss="2001:41d0:fe4b:ec42::10":\
>  :dnssl="geekwu.org":\
>  :addr="2001:41d0:fe4b:ecff::":\
>  :noifprefix:
> 
> if an ospf neighbour start advertising a new network (in my case
> 2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel:
> 
> fremen# route -n show -inet6|grep ecf1
> 2001:41d0:fe4b:ecf1::/64   fe80::225:22ff:fe1e:bb7%em1UG 
>  0  594 -32 em1
> but rtadvd starts advertising it on the link with the said neighbour.
> 
> I get this from radvdump running on a Linux host on this link:
> #
> # radvd configuration generated by radvdump 2.17
> # based on Router Advertisement from fe80::8621:df60:6d70:8da
> # received by interface enp2s0
> #
> 
> interface enp2s0
> {
>   AdvSendAdvert on;
>   # Note: {Min,Max}RtrAdvInterval cannot be obtained with
> radvdump
>   AdvManagedFlag off;
>   AdvOtherConfigFlag off;
>   AdvReachableTime 0;
>   AdvRetransTimer 0;
>   AdvCurHopLimit 64;
>   AdvDefaultLifetime 1800;
>   AdvHomeAgentFlag off;
>   AdvDefaultPreference medium;
>   AdvSourceLLAddress on;
> 
>   prefix 2a01:e35:8aea:ac42::/64
>   {
>   AdvValidLifetime 2592000;
>   AdvPreferredLifetime 604800;
>   AdvOnLink on;
>   AdvAutonomous on;
>   AdvRouterAddr off;
>   }; # End of prefix definition
> 
> 
>   prefix 2001:41d0:fe4b:ec42::/64
>   {
>   AdvValidLifetime 2592000;
>   AdvPreferredLifetime 604800;
>   AdvOnLink on;
>   AdvAutonomous on;
>   AdvRouterAddr off;
>   }; # End of prefix definition
> 
> 
>   prefix 2001:41d0:fe4b:ecf1::/64
>   {
>   AdvValidLifetime 2592000;
>   AdvPreferredLifetime 604800;
>   AdvOnLink on;
>   AdvAutonomous on;
>   AdvRouterAddr off;
>   }; # End of prefix definition
> 
> 
>   RDNSS 2a01:e35:8aea:ac42::10
>   {
>   AdvRDNSSLifetime 900;
>   }; # End of RDNSS definition
> 
> 
>   DNSSL geekwu.org
>   {
>   AdvDNSSLLifetime 900;
>   }; # End of DNSSL definition
> 
> }; # End of interface definition
> 
> Why does rtadvd start advertising this prefix ?
> If I withdraw the prefix from ospf, rtadvd stops advertising it.
> 

BTW, radvd emits this log when the prefix is inserted into ospf

rtadvd[33784]: prefix 2001:41d0:fe4b:ecf1::/64 from fe80::225:22ff:fe1e:bb7 on 
em1 is not in our list

-- 
Bastien

rtadvd bug ?

[Bastien Durel]

Hello,

I run rtadvd on a router, which also run ospfd (on 6.3).

rtadvd runs with static config (noifprefix):
fremen# cat /etc/rtadvd.conf
em0:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2001:41d0:fe4b:ec21::":\
:addr1="2a01:0e35:8aea:ac41::":\
:noifprefix:
em1:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac42::":\
:addr1="2001:41d0:fe4b:ec42::":\
:noifprefix:
em5:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac43::":\
:noifprefix:
em4:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr="2001:41d0:fe4b:ecff::":\
:noifprefix:

if an ospf neighbour start advertising a new network (in my case
2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel:

fremen# route -n show -inet6|grep ecf1
2001:41d0:fe4b:ecf1::/64   fe80::225:22ff:fe1e:bb7%em1UG 0  
594 -32 em1  

but rtadvd starts advertising it on the link with the said neighbour.

I get this from radvdump running on a Linux host on this link:
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::8621:df60:6d70:8da
# received by interface enp2s0
#

interface enp2s0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;

prefix 2a01:e35:8aea:ac42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition


prefix 2001:41d0:fe4b:ec42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition


prefix 2001:41d0:fe4b:ecf1::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition


RDNSS 2a01:e35:8aea:ac42::10
{
AdvRDNSSLifetime 900;
}; # End of RDNSS definition


DNSSL geekwu.org
{
AdvDNSSLLifetime 900;
}; # End of DNSSL definition

}; # End of interface definition

Why does rtadvd start advertising this prefix ?
If I withdraw the prefix from ospf, rtadvd stops advertising it.

Thanks,

Bastien


dmesg:
OpenBSD 6.3 (GENERIC.MP) #3: Fri May 18 00:06:26 CEST 2018

r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 497184768 (474MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.08 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 600MHz, 600.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4115 rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ohci1 at pci2 dev 2 

rtadvd bug ?

[Bastien Durel]

Hello,

I run rtadvd on a router, which also run ospfd (on 6.3).

rtadvd runs with static config (noifprefix):
fremen# cat /etc/rtadvd.conf
em0:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2001:41d0:fe4b:ec21::":\
:addr1="2a01:0e35:8aea:ac41::":\
:noifprefix:
em1:\
:rdnss="2a01:e35:8aea:ac42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac42::":\
:addr1="2001:41d0:fe4b:ec42::":\
:noifprefix:
em5:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr0="2a01:e35:8aea:ac43::":\
:noifprefix:
em4:\
:rdnss="2001:41d0:fe4b:ec42::10":\
:dnssl="geekwu.org":\
:addr="2001:41d0:fe4b:ecff::":\
:noifprefix:

if an ospf neighbour start advertising a new network (in my case
2001:41d0:fe4b:ecf1::/64), a route is inserted in the kernel:

fremen# route -n show -inet6|grep ecf1
2001:41d0:fe4b:ecf1::/64   fe80::225:22ff:fe1e:bb7%em1UG 
0  594 -32 em1

but rtadvd starts advertising it on the link with the said neighbour.

I get this from radvdump running on a Linux host on this link:
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::8621:df60:6d70:8da
# received by interface enp2s0
#

interface enp2s0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;

prefix 2a01:e35:8aea:ac42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition


prefix 2001:41d0:fe4b:ec42::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition


prefix 2001:41d0:fe4b:ecf1::/64
{
AdvValidLifetime 2592000;
AdvPreferredLifetime 604800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition


RDNSS 2a01:e35:8aea:ac42::10
{
AdvRDNSSLifetime 900;
}; # End of RDNSS definition


DNSSL geekwu.org
{
AdvDNSSLLifetime 900;
}; # End of DNSSL definition

}; # End of interface definition

Why does rtadvd start advertising this prefix ?
If I withdraw the prefix from ospf, rtadvd stops advertising it.

Thanks,

Bastien


dmesg:
OpenBSD 6.3 (GENERIC.MP) #3: Fri May 18 00:06:26 CEST 2018

r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 497184768 (474MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.08 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 600MHz, 600.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN

cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI   mpbios0: bus 64 is type ISA   ioapic0 at 
mainbus0: apid 0 pa 0xfec0, version 20, 24 pins

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4115 
rev 0x05

pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 
19, version 1.0
ohci1 at pci2 dev 2 

Re: 答复: Openbsd6.1 as firewall can access the internet but the LAN behind it cannot

[Bastien Durel]

Le jeudi 22 juin 2017 à 06:21 +, lu jian a écrit :
> # The line i put here
> pass out on fxp0 inet from 192.168.0.0/24 to any nat-to 10.198.1.150
Your egress interface is pppoe0, not fxp0

in my pf.conf, I have :
match out on pppoe0 inet from $lan nat-to (pppoe0:0)

-- 
Bastien

6.1 dhcpd

[Bastien Durel]

Hello,

Since I upgraded to 6.1, my printer does not get its IP from dhcpd
anymore.

Printer is a xerox phaser 6022.

dhcpd gets dhcp requests and reponds to it (I've show packets with
tcpdump, and here are the logs)
Apr 16 10:26:52 fremen.geekwu.org dhcpd[77052]: DHCPOFFER on 10.42.0.49 to 
9c:93:4e:4e:c2:b1 via em0
Apr 16 10:26:52 fremen.geekwu.org dhcpd[77052]: DHCPDISCOVER from 
9c:93:4e:4e:c2:b1 via em0
Apr 16 10:26:52 fremen.geekwu.org dhcpd[77052]: DHCPOFFER on 10.42.0.49 to 
9c:93:4e:4e:c2:b1 via em0
Apr 16 10:26:58 fremen.geekwu.org dhcpd[77052]: DHCPDISCOVER from 
9c:93:4e:4e:c2:b1 via em0
Apr 16 10:26:58 fremen.geekwu.org dhcpd[77052]: DHCPOFFER on 10.42.0.49 to 
9c:93:4e:4e:c2:b1 via em0
Apr 16 10:26:58 fremen.geekwu.org dhcpd[77052]: DHCPDISCOVER from 
9c:93:4e:4e:c2:b1 via em0
Apr 16 10:26:58 fremen.geekwu.org dhcpd[77052]: DHCPOFFER on 10.42.0.49 to 
9c:93:4e:4e:c2:b1 via em0

I've connected the printer to a linux laptop with dhcpd, and it got the
address it recieved from it.

Here is the openbsd tcpdump trace :
https://corrin.geekwu.org/owncloud/index.php/s/WTctL2t2muP7FFR

And here is the Linux tcpdump trace :
https://corrin.geekwu.org/owncloud/index.php/s/5d5ohkKDPzHLA83

Do you know what change may have introduce this ?

Thanks,

OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 499585024 (476MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.08 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 600MHz, 600.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4115 rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ohci1 at pci2 dev 2 function 1 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ohci2 at pci2 dev 2 function 2 "Intel EG20T USB" rev 0x02: apic 0 int 19, 
version 1.0
ehci0 at pci2 dev 2 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
"Intel EG20T USB Client" rev 0x02 at pci2 dev 2 function 4 not configured
sdhc0 at pci2 dev 4 function 0 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdhc0: SDHC 1.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
sdhc1 at pci2 dev 4 function 1 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdhc1: SDHC 1.0, 50 MHz base clock
sdmmc1 at sdhc1: 4-bit, sd high-speed, mmc high-speed
ahci0 at pci2 dev 6 function 0 "Intel EG20T AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.50026b7253081a83
sd0: 28626MB, 512 bytes/sector, 58626288 sectors, thin
ohci3 at pci2 dev 8 function 0 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ohci4 at pci2 dev 8 function 1 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ohci5 at pci2 dev 8 function 2 "Intel EG20T USB" rev 0x02: apic 0 int 16, 
version 1.0
ehci1 at pci2 dev 8 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 16
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
"Intel EG20T DMA" rev 0x00 at pci2 dev 10 function 0 not configured
puc0 at pci2 dev 10 function 1 "Intel EG20T Serial" rev 0x01: ports: 1 com
com4 at puc0 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc1 at pci2 dev 10 function 2 "Intel 

Re: OpenBSD 6.0 panic

[Bastien Durel]

Le vendredi 02 septembre 2016 à 18:25 +0200, Bastien Durel a écrit :
> Hello.
> 
> I upgraded my router to 6.0 yesterday, and now I got a panic each
> time
> I reboot it.
> 
> Here is a console log :
> 
> #
> reboot   
>  
> stopping package daemons: munin_node svscanpanic: kernel diagnostic
> assertion "ifp != NULL" failed: file "../../../../net/route.c", line
> 902
> Starting stack trace...
> panic() at panic+0x10b
> __assert() at __assert+0x25
> rtrequest_delete() at rtrequest_delete+0x206
> rtrequest() at rtrequest+0x247
> route_output() at route_output+0x4e8
> raw_usrreq() at raw_usrreq+0x217
> route_usrreq() at route_usrreq+0x6e
> sosend() at sosend+0x3c8
> dofilewritev() at dofilewritev+0x205
> sys_writev() at sys_writev+0x6d
> syscall() at syscall+0x27b
> --- syscall (number 121) ---
> end of kernel
> end trace frame: 0x4, count: 246
> 0xa46bf29a62a:
> End of stack trace.
> syncing disks... 14 12 12 12 12 12 12 12 12 12 12 12 8 8 8 8 8 8 8 8
> giving up
> 
> dumping to dev 4,1 offset 492607
> dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496
> 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479
> 47d
> 
> 
> rebooting...
> 
I saw the dmesg was missing, stripped down by dmime, so I'll include it
inline.
The panic occurs each time openvpn is shut down, not only at host
shutdown ; I guess it's related to interface removal.

My openvpn interfaces are configured in TAP mode.

booting hd0a:/bsd: 6892100+2179088+267272+0+663552
[72+726576+483179]=0xab3868
entry point at 0x1001000 [7205c766, 3404, 24448b12, 3be0a304]
 [
using 1210472 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights
reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.  http://www.OpenB
SD.org

OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.M
P
real mem = 519962624 (495MB)
avail mem = 499789824 (476MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.08 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DSR
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU @ 600MHz, 600.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DSR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4115
rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not
configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ohci1 at pci2 dev 2 function 1 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ohci2 at pci2 dev 2 function 2 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ehci0 at pci2 dev 2 function 3 "Intel EG20T USB" rev 0x02: apic 0 int
19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel EG20T USB Client" rev 0x02 at pci2 dev 2 function 4 not
configured
sdhc0 at pci2 dev 4 function 0 "Intel EG20T SDIO" rev 0x01: apic 0 int
18
sdhc0: SDHC 1.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
sdhc1 at pci2 dev 4 function 1 "Intel EG20T SDIO" rev 0x01: apic 0 int
18
sdhc1: SDHC 1.0, 50 MHz base clock
sdmmc1 at sdhc1: 4-bit, sd high-speed, mmc high-speed
ahci0 at pci2 dev 6 function 0 "Intel EG20T AHCI" rev 0x02: msi, AHCI
1.1
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0

Re: OpenBSD 6.0 panic

[Bastien Durel]

Le 02/09/2016 à 23:28, Ryan Freeman a écrit :

On Fri, Sep 02, 2016 at 06:25:15PM +0200, Bastien Durel wrote:

Hello.

I upgraded my router to 6.0 yesterday, and now I got a panic each time
I reboot it.


Hi,

Did you happen to forget to do your pkg_add -u to upgrade packages?  I
suspect it might be openvpn not updated yet throwing the error?

Cheers!
-ryan


Hello,

I did ran pkg_add -u, but there's a mess in my package database, and 
some packages was not registered


# pkg_add openvpn
quirks-2.241 signed on 2016-07-26T16:56:10Z
Collision in openvpn-2.3.11: the following files already exist
/usr/local/include/openvpn/openvpn-plugin.h from openvpn-2.3.11 
(different checksum)
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.a from 
openvpn-2.3.11 (different checksum)
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.la from 
openvpn-2.3.11 (same checksum)
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so from 
openvpn-2.3.11 (different checksum)
/usr/local/man/man8/openvpn.8 from openvpn-2.3.11 (different 
checksum)

/usr/local/sbin/openvpn from openvpn-2.3.11 (different checksum)
[...]

wide-dhcpc6 was affected too.

But upgrading it did not solved the panic (I would have been surprised 
if an application crash made the kernel panic)


--
Bastien

OpenBSD 6.0 panic

[Bastien Durel]

Hello.

I upgraded my router to 6.0 yesterday, and now I got a panic each time
I reboot it.

Here is a console log :

# reboot
stopping package daemons: munin_node svscanpanic: kernel diagnostic assertion 
"ifp != NULL" failed: file "../../../../net/route.c", line 902
Starting stack trace...
panic() at panic+0x10b
__assert() at __assert+0x25
rtrequest_delete() at rtrequest_delete+0x206
rtrequest() at rtrequest+0x247
route_output() at route_output+0x4e8
raw_usrreq() at raw_usrreq+0x217
route_usrreq() at route_usrreq+0x6e
sosend() at sosend+0x3c8
dofilewritev() at dofilewritev+0x205
sys_writev() at sys_writev+0x6d
syscall() at syscall+0x27b
--- syscall (number 121) ---
end of kernel
end trace frame: 0x4, count: 246
0xa46bf29a62a:
End of stack trace.
syncing disks... 14 12 12 12 12 12 12 12 12 12 12 12 8 8 8 8 8 8 8 8 giving up

dumping to dev 4,1 offset 492607
dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 
493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 47d


rebooting...

The svcan deamon which is to be shut down when the panic occurs
monitors a few(4) openvpn tunnels, in TAP mode, over which ospfd+ospf6d
runs. When it's stopped, the tun* interfaces is removed, I guess it's
related ?

I've attached a boot log (with dmesg).

There's a "Bad system call" in the networking start too, but I think
it's not related (and I don't know what interface produces this
message)

Thanks,

-- 
Bastien

[demime 1.01d removed an attachment of type text/x-log which had a name of 
fremen.log"; charset="UTF-8]

Re: rtadvd advertised non-local prefix

[Bastien Durel]

Le vendredi 13 mai 2016 à 17:32 +0200, Bastien Durel a écrit :
> Hello,
> 
> I have an OpenBSD router with a few interfaces, connected to a few
> other routers, sharing routes with ospf(6)d.
> 
> There's also some hosts connected to its interfaces.
> 

Hello,

As proposed by Marc Peters, I've set the prefixes in rtadvd.conf :

em1:\
:rdnss="2001:6f8:3c8:42::10":\
:dnssl="geekwu.org":\
:addr0="2001:6f8:3c8:42::":\
:addr1="2001:41d0:fe4b:ec42::":\
:noifprefix:

I've also put noifprefix ...

But each time the 2001:41d0:fe4b:ec01::/64 comes from OSPF6, it makes
its way back in the RA's

10:45:42.633224 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
168) fe80::200:24ff:fed1:420d > ff02::1: [icmp6 sum ok] ICMP6, router
advertisement, length 168
hop limit 64, Flags [none], pref medium, router lifetime 1800s,
reachable time 0s, retrans time 0s
  source link-address option (1), length 8 (1):
00:00:24:d1:42:0d
0x:   24d1 420d
  prefix info option (3), length 32 (4): 2001:6f8:3c8:42::/64,
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  06f8 03c8 0042    
  prefix info option (3), length 32 (4):
2001:41d0:fe4b:ec42::/64, Flags [onlink, auto], valid time 2592000s,
pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  41d0 fe4b ec42    
  prefix info option (3), length 32 (4):
2001:41d0:fe4b:ec01::/64, Flags [onlink, auto], valid time 2592000s,
pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  41d0 fe4b ec01    
  rdnss option (25), length 24 (3):  lifetime 900s, addr:
2001:6f8:3c8:42::10
0x:    0384 2001 06f8 03c8 0042 
0x0010:    0010
  dnssl option (31), length 24 (3):  lifetime 900s, domain(s):
geekwu.org.
0x:    0384 0667 6565 6b77 7503 6f72
0x0010:  6700  



> rtadvd.conf is really simple:
> 
> # cat /etc/rtadvd.conf
> em0:\
> :rdnss="2001:6f8:3c8:42::10":\
> :dnssl="geekwu.org":
> em1:\
> :rdnss="2001:6f8:3c8:42::10":\
> :dnssl="geekwu.org":
> em5:\
> :rdnss="2001:6f8:3c8:42::10":\
> :dnssl="geekwu.org":
> em4:\
> :rdnss="2001:6f8:3c8:42::10":\
> :dnssl="geekwu.org":
> 
> A router connected to em1 provides connectivity to the prefix
> 2001:41d0:fe4b:ec01::/64 ; so whe have this in OSPF6 RIB:
> 
> Destination  Nexthop   Path
> TypeType  CostUptime   
> 2001:41d0:fe4b:ec01::/64 fe80::225:22ff:fe1e:bb7%em1 Type 1
> ext   Network   10  00:26:13
> 
> and this in routing table :
> 
> DestinationGatewayFla
> gs   Refs  Use   Mtu  Prio Iface
> 2001:41d0:fe4b:ec01::/64   fe80::225:22ff:fe1e:bb7%em1UG 
> 00 -32 em1   
> 
> em1 have 2 inet6 address configured :
> 
> em1: flags=18843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,MPSAFE> mtu
> 1500
> lladdr 00:00:24:d1:42:0d
> description: DMZ
> [...]
> inet6 fe80::200:24ff:fed1:420d%em1 prefixlen 64 scopeid 0x2
> inet6 2001:6f8:3c8:42:200:24ff:fec6:94c8 prefixlen 64
> inet6 2001:41d0:fe4b:ec42:200:24ff:fed1:420d prefixlen 64
> 
> And the router sends RAs on this interface with *3* prefixes :
> 
> 15:23:54.878534 IP6 (hlim 255, next-header ICMPv6 (58) payload
> length: 168) fe80::200:24ff:fed1:420d > ff02::1: [icmp6 sum ok]
> ICMP6, router advertisement, length 168
>   hop limit 64, Flags [none], pref medium, router lifetime 1800s,
> reachable time 0s, retrans time 0s
>     source link-address option (1), length 8 (1):
> 00:00:24:d1:42:0d
>   0x:   24d1 420d
>     prefix info option (3), length 32 (4): 2001:6f8:3c8:42::/64,
> Flags [onlink, auto], valid time 2592000s, pref. time 604800s
>   0x:  40c0 0027 8d00 0009 3a80   2001
>   0x0010:  06f8 03c8 0042    
>     prefix info option (3), length 32 (4):
> 2001:41d0:fe4b:ec42::/64, Flags [onlink, auto], valid time 2592000s,
> pref. time 604800s
>   0x:  40c0 0027 8d00 0009 3a80   2001
>   0x0010:  41d0 fe4b ec42    
>     prefix info option (3), length 32 (4):
> 2001:41d0:fe4b:ec01::/64, Flags [onlink, auto], valid time 2592000s,
> pref. time 604800s
>   0x:  40c0 0027 8d00 0

rtadvd advertised non-local prefix

[Bastien Durel]

Hello,

I have an OpenBSD router with a few interfaces, connected to a few
other routers, sharing routes with ospf(6)d.

There's also some hosts connected to its interfaces.

rtadvd.conf is really simple:

# cat /etc/rtadvd.conf
em0:\
:rdnss="2001:6f8:3c8:42::10":\
:dnssl="geekwu.org":
em1:\
:rdnss="2001:6f8:3c8:42::10":\
:dnssl="geekwu.org":
em5:\
:rdnss="2001:6f8:3c8:42::10":\
:dnssl="geekwu.org":
em4:\
:rdnss="2001:6f8:3c8:42::10":\
:dnssl="geekwu.org":

A router connected to em1 provides connectivity to the prefix
2001:41d0:fe4b:ec01::/64 ; so whe have this in OSPF6 RIB:

Destination  Nexthop   Path TypeType  CostUptime   
2001:41d0:fe4b:ec01::/64 fe80::225:22ff:fe1e:bb7%em1 Type 1 ext   Network   10  
00:26:13

and this in routing table :

DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
2001:41d0:fe4b:ec01::/64   fe80::225:22ff:fe1e:bb7%em1UG 0  
  0 -32 em1   

em1 have 2 inet6 address configured :

em1: flags=18843 mtu 1500
lladdr 00:00:24:d1:42:0d
description: DMZ
[...]
inet6 fe80::200:24ff:fed1:420d%em1 prefixlen 64 scopeid 0x2
inet6 2001:6f8:3c8:42:200:24ff:fec6:94c8 prefixlen 64
inet6 2001:41d0:fe4b:ec42:200:24ff:fed1:420d prefixlen 64

And the router sends RAs on this interface with *3* prefixes :

15:23:54.878534 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 168) 
fe80::200:24ff:fed1:420d > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, 
length 168
hop limit 64, Flags [none], pref medium, router lifetime 1800s, 
reachable time 0s, retrans time 0s
  source link-address option (1), length 8 (1): 00:00:24:d1:42:0d
0x:   24d1 420d
  prefix info option (3), length 32 (4): 2001:6f8:3c8:42::/64, Flags 
[onlink, auto], valid time 2592000s, pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  06f8 03c8 0042    
  prefix info option (3), length 32 (4): 2001:41d0:fe4b:ec42::/64, 
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  41d0 fe4b ec42    
  prefix info option (3), length 32 (4): 2001:41d0:fe4b:ec01::/64, 
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  41d0 fe4b ec01    
  rdnss option (25), length 24 (3):  lifetime 900s, addr: 
2001:6f8:3c8:42::10
0x:    0384 2001 06f8 03c8 0042 
0x0010:    0010
  dnssl option (31), length 24 (3):  lifetime 900s, domain(s): 
geekwu.org.
0x:    0384 0667 6565 6b77 7503 6f72
0x0010:  6700  

If I disconnect the 2001:41d0:fe4b:ec01::/64 from the remote router, it
disappear from OSPF6 RIB, and from RAs too.

15:33:59.901622 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) 
fe80::200:24ff:fed1:420d > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, 
length 136
hop limit 64, Flags [none], pref medium, router lifetime 1800s, 
reachable time 0s, retrans time 0s
  source link-address option (1), length 8 (1): 00:00:24:d1:42:0d
0x:   24d1 420d
  prefix info option (3), length 32 (4): 2001:6f8:3c8:42::/64, Flags 
[onlink, auto], valid time 2592000s, pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  06f8 03c8 0042    
  prefix info option (3), length 32 (4): 2001:41d0:fe4b:ec42::/64, 
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
0x:  40c0 0027 8d00 0009 3a80   2001
0x0010:  41d0 fe4b ec42    
  rdnss option (25), length 24 (3):  lifetime 900s, addr: 
2001:6f8:3c8:42::10
0x:    0384 2001 06f8 03c8 0042 
0x0010:    0010
  dnssl option (31), length 24 (3):  lifetime 900s, domain(s): 
geekwu.org.
0x:    0384 0667 6565 6b77 7503 6f72
0x0010:  6700  

The prefix is only advertised on em1, not on the other interfaces.

Is there a way to prevent rtadvd from advertising
2001:41d0:fe4b:ec01::/64 ?

Thanks,

-- 
Bastien

Re: OpenBSD ospf6d and ECMP

[Bastien Durel]

Le mardi 01 septembre 2015 à 09:16 +, Aviolat Romain a écrit :
> more info:
> 
> I'm running OpenBSD 5.4 yet, I checked the changelogs between 
> -current and 5.4 and haven't seen improvements regarding ECMP and
> IPv6.
> 
> Maybe someone can point me in the right direction regarding my
> problem ?
> 
> Thanks for your help,
> 
> Romain

Hello,
I have a similar setup, and same problem with 5.7

Regards,

-- 
Bastien

Re: ospfd lost tunnel interface

[Bastien Durel]

Le jeudi 09 juillet 2015 à 07:57 +, Stuart Henderson a écrit :
 On 2015-07-08, Bastien Durel bast...@durel.org wrote:
  Le 08/07/2015 22:08, Claudio Jeker a écrit :
   Feature... with maybe a bug.
 Jul  8 09:04:07 ospfd[27052]: interface tun0:10.120.0.1 gone
   So openvpn is reconfiguring the interface and ospfd does not like 
   this all
   that much because of the way interface addresses are handled. A 
   simple
   ospfctl reload should fix this.
 
 IIRC OpenVPN recreates the tun interface at startup, setting persist
 -tun
 in OpenVPN config *may* help here.
 
It's already on.

  You're right, restarting openvpn triggers the interface gone ; 
  but 
  ospfctl reload isn't sufficient, I cannot (or don't know how to) 
  recover 
  without a full restart :(
 
 You can try commenting-out the interface from ospfd.conf, reload, 
 uncomment
 and reload again. But ospfd does sometimes get in a muddle with 
 interface
 additions/removals.
 
commenting  decommenting seems to work. Now I have to figure out how
I'll change my config file in a script ;)

Thanks for your answer.

-- 
Bastien

ospfd lost tunnel interface

[Bastien Durel]

Hello,

I use openvpn to connect 2 routers over 2 links. Sometimes one of these 
links crashes, then I use OSPF to remove it from routing table.
But sometimes (I saw this twice since I upgraded to 5.7, ospfd don't 
reconnect.


Here are the relevant logs:

Jul  8 09:04:05 root: Wed Jul  8 09:04:05 2015 [corrin.geekwu.org] 
Inactivity timeout (--ping-restart), restarting
Jul  8 09:04:05 root: Wed Jul  8 09:04:05 2015 
SIGUSR1[soft,ping-restart] received, process restarting
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 NOTE: the current 
--script-security setting may allow this configuration to call 
user-defined scripts
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 WARNING: normally if you 
use --mssfix and/or --fragment, you should also set --tun-mtu 1500 
(currently it is 1380)
Jul  8 09:04:07 ospfd[27052]: send_packet: error sending packet on 
interface tun0: Host is down
Jul  8 09:04:07 ospfd[27052]: send_packet: error sending packet on 
interface tun0: Host is down

Jul  8 09:04:07 ospfd[27052]: interface tun0 down
Jul  8 09:04:07 ospfd[27052]: interface tun0 down
Jul  8 09:04:07 ospf6d[19695]: send_packet: error sending packet on 
interface tun0: Host is down
Jul  8 09:04:07 ospf6d[19695]: send_packet: error sending packet on 
interface tun0: Host is down

Jul  8 09:04:07 ospf6d[19695]: interface tun0 down
Jul  8 09:04:07 ospf6d[19695]: interface tun0 down
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 OpenVPN 2.3.6 
x86_64-unknown-openbsd5.7 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Mar 
 7 2015
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 library versions: 
LibreSSL 2.1, LZO 2.08
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 NOTE: the current 
--script-security setting may allow this configuration to call 
user-defined scripts
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 Control Channel 
Authentication: using '/etc/openvpn/pfs.key' as a OpenVPN static key file
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 WARNING: normally if you 
use --mssfix and/or --fragment, you should also set --tun-mtu 1500 
(currently it is 1380)
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 TUN/TAP device tun0 
exists previously, keep at program end

Jul  8 09:04:07 ospf6d[19695]: interface tun0 up
Jul  8 09:04:07 ospf6d[19695]: interface tun0 up
Jul  8 09:04:07 ospfd[27052]: interface tun0 up
Jul  8 09:04:07 ospfd[27052]: interface tun0 up
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 TUN/TAP device /dev/tun0 
opened
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 do_ifconfig, tt-ipv6=0, 
tt-did_ifconfig_ipv6_setup=0
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 /sbin/ifconfig tun0 
10.120.0.1 netmask 255.255.255.252 mtu 1380 broadcast 10.120.0.3 link0

Jul  8 09:04:07 ospfd[27052]: interface tun0:10.120.0.1 gone
Jul  8 09:04:07 ospfd[27052]: interface tun0:10.120.0.1 gone
Jul  8 09:04:07 root: Wed Jul  8 09:04:07 2015 ./up.sh tun0 1380 1470 
10.120.0.1 255.255.255.252 init
Jul  8 09:04:08 root: Wed Jul  8 09:04:08 2015 chroot to '/var/empty' 
and cd to '/' succeeded

Jul  8 09:04:08 root: Wed Jul  8 09:04:08 2015 GID set to _isakmpd
Jul  8 09:04:08 root: Wed Jul  8 09:04:08 2015 UID set to _isakmpd
Jul  8 09:04:08 root: Wed Jul  8 09:04:08 2015 UDPv4 link local (bound): 
[AF_INET]88.162.162.72
Jul  8 09:04:08 root: Wed Jul  8 09:04:08 2015 UDPv4 link remote: 
[AF_INET]94.23.38.211:1196
Jul  8 09:04:23 root: Wed Jul  8 09:04:23 2015 [corrin.geekwu.org] Peer 
Connection Initiated with [AF_INET]94.23.38.211:1196
Jul  8 09:04:24 root: Wed Jul  8 09:04:24 2015 Initialization Sequence 
Completed


You can see ospfd loosing interface (interface tun0:10.120.0.1 gone) but 
ospf6d don't


# ospfctl sh int
Interface   AddressState  HelloTimer Linkstate  Uptimenc  ac
em5 10.0.0.254/24  DOWN   -  active 00:00:00   0   0
em4 10.255.255.254/24  DOWN   -  active 00:00:00   0   0
tun110.120.0.5/30  BCKUP  00:00:02   active 01w1d11h   1   1
tun010.120.0.1/30  DOWN   -  active 00:00:00   1   0
em1 10.42.42.1/24  BCKUP  00:00:04   active 01w1d11h   1   1
em0 10.42.0.254/24 DR 00:00:08   active 1d05h35m   0   0

# ospf6ctl sh int
Interface   Address   State  HelloTimer Linkstate 
Uptime
em5 fe80::200:24ff:fed1:73f9  DOWN   7101w3d0   active 
00:00:00
em4 fe80::200:24ff:fed1:73f8  DOWN   7101w3d0   active 
00:00:00
tun1fe80::fce1:baff:fed3:1cf0 BCKUP  00:00:02   active 
5d11h03m
tun0fe80::fce1:baff:fed1:7f67 BCKUP  00:00:01   active 
11:58:17
em1 fe80::200:24ff:fed1:420d  BCKUP  00:00:09   active 
5d11h03m
em0 fe80::200:24ff:fed1:420c  DR 00:00:09   active 
1d05h43m


Is this know bug ? a feature ? Must I run ospfd in verbose mode to 
collect more info ?


Thanks,

--
Bastien Durel

Re: ospfd lost tunnel interface

[Bastien Durel]

Le 08/07/2015 22:08, Claudio Jeker a écrit :

Feature... with maybe a bug.

Jul  8 09:04:07 ospfd[27052]: interface tun0:10.120.0.1 gone

So openvpn is reconfiguring the interface and ospfd does not like this all
that much because of the way interface addresses are handled. A simple
ospfctl reload should fix this.
You're right, restarting openvpn triggers the interface gone ; but 
ospfctl reload isn't sufficient, I cannot (or don't know how to) recover 
without a full restart :(


--
Bastien

Re: Install 5.7 : fdisk crash

[Bastien Durel]

Le jeudi 28 mai 2015 à 18:40 +0200, Otto Moerbeek a écrit :
 On Thu, May 28, 2015 at 05:33:01PM +0200, Bastien Durel wrote:
 
 [snip]
  Which speed should com0 use? (or 'done') [57600] 
  Setup a user? (enter a lower-case loginname, or 'no') [no] 
  What timezone are you in? ('?' for list) [Europe/Paris] 
  
  Available disks are: sd0.
  Which disk is the root disk? ('?' for details) [sd0] 
  Use DUIDs rather than device names in fstab? [yes] 
  Disk: sd0   geometry: 3649/255/63 [58626288 Sectors]
  Offset: 0   Signature: 0xAA55
  Starting 
  
  erase ^?, werase ^W, kill ^U, intr ^C, status ^T
  
  Welcome to the OpenBSD/amd64 5.7 installation program.
  (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? 
  
  
  If I try to restart install, I get struck at the same step.
  
  fdisk ran from console exists with code 130:
  # fdisk sd0 
  Disk: sd0   geometry: 3649/255/63 [58626288 Sectors]
  Offset: 0   Signature: 0xAA55
  Starting # 
  
  
  # echo $?
  130
  
  Is there a way to find from where the error comes ?
 
 That would mean killed by SIGINT (^C), but that doesn't make a lot
 of sense here.
 
   -Otto
 
Looks like many programs crashes this way :

# ls
.profile etc  install.sub  sbin usr 
bin  install  mnt  tmp  var 
dev  install.md   mnt2 upgrade  
#   


# echo $?   
130 

But not in any case :
# ls -l 
total 112   
-rw-r--r--  1 root  wheel   1486 Mar  8 17:06 .profile  
drwxr-xr-x  2 root  wheel512 Mar  8 17:06 bin   
drwxr-xr-x  2 root  wheel   2048 Mar  8 19:53 dev   
drwxr-xr-x  4 root  wheel512 Mar  8 19:53 etc   
-rwxr-xr-x  1 root  wheel   4490 Mar  8 17:06 install   
-rw-r--r--  1 root  wheel   2548 Mar  8 17:06 install.md
-rw-r--r--  1 root  wheel  41430 Mar  8 17:06 install.sub   
drwxr-xr-x  2 root  wheel512 Mar  8 17:06 mnt   
drwxr-xr-x  2 root  wheel512 Mar  8 17:06 mnt2  
drwxr-xr-x  2 root  wheel512 Mar  8 17:06 sbin  
drwxrwxrwt  2 root  wheel512 Mar  8 19:53 tmp   
-rwxr-xr-x  1 root  wheel926 Mar  8 17:06 upgrade   
drwxr-xr-x  6 root  wheel512 Mar  8 17:06 usr   
drwxr-xr-x  6 root  wheel512 Mar  8 17:06 var   
#   
# echo $?   
0   

tried with many baud rates, and it *may* influence *when* programs
crashes : with 115200 bauds ls outputs more data before crashing ; but
ls -l output even more and does not crash, so I can't conclude it's
output-related ...

-- 
Bastien

Install 5.7 : fdisk crash

[Bastien Durel]

Hello. I'm trying to install openbsd 5.7 on a soekris board. I've
booted on pxeboot file from 5.7/amd64, with bsd.rd from 5.7/amd64 ; but
install(8) stops on fdisk step, returning back to the start of process

I've tried i386 and got the same results

The session folows :

Intel(R) Boot Agent GE v1.3.72
Copyright (C) 1997-2010, Intel Corporation

CLIENT MAC ADDR: 00 00 24 D1 42 0C 

CLIENT IP: 10.42.42.44  MASK: 255.255.255.0  DHCP IP: 10.42.42.1   

GATEWAY IP: 10.42.42.1 
probing: pc0 com0 pxe![2.1] mem[620K 510M a20=on]  

disk: hd0+*
net: mac 00:00:24:d1:42:0c, ip 10.42.42.44, server 10.42.42.21
 OpenBSD/amd64 PXEBOOT 3.23
switching console to com0
  OpenBSD/amd64 PXEBOOT 3.23
cannot open tftp:/etc/random.seed: No such file or directory
booting tftp:/bsd.rd: 3220112+1373792+2401280+0+520192
[97+355440+231981]=0x7bca08
entry point at 0x1000160 [7205c766, 3404, 24448b12, f680a304]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights
reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.  
http://www.OpenBSD.org

OpenBSD 5.7 (RAMDISK_CD) #806: Sun Mar  8 11:08:49 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_C
D
real mem = 519962624 (495MB)
avail mem = 504487936 (481MB)
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.09 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-
CPL,VMX,E
ST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu at mainbus0: not configured
mpbios0: bus 0 is type PCI   
mpbios0: bus 64 is type ISA   
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x4115
rev 0x05
pchb1 at pci0 dev 1 function 0 Intel E600 Config rev 0x00
ppb0 at pci0 dev 23 function 0 Intel E600 PCIE rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 Intel EG20T PCIE rev 0x01
pci2 at ppb1 bus 2
Intel EG20T Packet Hub rev 0x01 at pci2 dev 0 function 0 not
configured
Intel EG20T Ethernet rev 0x02 at pci2 dev 0 function 1 not configured
Intel EG20T GPIO rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 Intel EG20T USB rev 0x02: apic 0 int
19, version 1.0
ohci1 at pci2 dev 2 function 1 Intel EG20T USB rev 0x02: apic 0 int
19, version 1.0
ohci2 at pci2 dev 2 function 2 Intel EG20T USB rev 0x02: apic 0 int
19, version 1.0
ehci0 at pci2 dev 2 function 3 Intel EG20T USB rev 0x02: apic 0 int
19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
Intel EG20T USB Client rev 0x02 at pci2 dev 2 function 4 not
configured
sdhc0 at pci2 dev 4 function 0 Intel EG20T SDIO rev 0x01: apic 0 int
18
sdmmc0 at sdhc0
sdhc1 at pci2 dev 4 function 1 Intel EG20T SDIO rev 0x01: apic 0 int
18
sdmmc1 at sdhc1
ahci0 at pci2 dev 6 function 0 Intel EG20T AHCI rev 0x02: msi, AHCI
1.1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, KINGSTON SMS200S, 600A SCSI3
0/direct fixed naa.50026b7253081a83
sd0: 28626MB, 512 bytes/sector, 58626288 sectors, thin
ohci3 at pci2 dev 8 function 0 Intel EG20T USB rev 0x02: apic 0 int
16, version 1.0
ohci4 at pci2 dev 8 function 1 Intel EG20T USB rev 0x02: apic 0 int
16, version 1.0
ohci5 at pci2 dev 8 function 2 Intel EG20T USB rev 0x02: apic 0 int
16, version 1.0
ehci1 at pci2 dev 8 function 3 Intel EG20T USB rev 0x02: apic 0 int
16
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
Intel EG20T DMA rev 0x00 at pci2 dev 10 function 0 not configured
Intel EG20T Serial rev 0x01 at pci2 dev 10 function 1 not configured
Intel EG20T Serial rev 0x00 at pci2 dev 10 function 2 not configured
Intel EG20T Serial rev 0x00 at pci2 dev 10 function 3 not configured
Intel EG20T Serial rev 0x00 at pci2 dev 10 function 4 not configured
Intel EG20T DMA rev 0x00 at pci2 dev 12 function 0 not configured
Intel EG20T SPI rev 0x00 at pci2 dev 12 function 1 not configured
Intel EG20T I2C rev 0x00 at pci2 dev 12 function 2 not configured
Intel EG20T CAN rev 0x00 at pci2 dev 12 function 3 not configured
Intel EG20T 1588 rev 0x01 at pci2 dev 12 function 4 not configured
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 Intel OHCI root hub rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 Intel OHCI root hub rev 1.00/1.00 addr 1
usb4 at ohci2: USB revision 1.0
uhub4 at usb4 Intel OHCI root hub rev 1.00/1.00 addr 1
usb5 at ohci3: USB revision 1.0
uhub5 at usb5 Intel OHCI root hub rev 1.00/1.00 addr 1
usb6 at ohci4: USB revision 1.0
uhub6 at usb6 Intel OHCI root hub rev 1.00/1.00 addr 1
usb7 at ohci5: USB 

icmp6 get dropped on gif tunnel

[Bastien Durel]

Hello.
I have an openbsd router with 2 upstreams (one pppoe (pppoe0 on sis1),
one ipoe (sis0)).

I have a sixxs(6-in-4) tunnel (gif0).
If the gif tunnel is on one of my providers (pppoe0), it works well. 

gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280
description: Sixxs
priority: 0
groups: gif egress
tunnel: inet 109.190.17.241 - 212.100.184.146
inet6 fe80::200:24ff:fecf:42ac%gif0 -  prefixlen 64 scopeid 0xc
inet6 2001:6f8:202:19c::2 - 2001:6f8:202:19c::1 prefixlen 128

the 2001:6f8:3c8::/48 subnet which is routed via this tunnel

This provider gives me native Ipv6, so the tunnel is pretty useless, and
I want to put it on the other provider, which doesn't.

But when I move it on the other provider, the tunnel basicly works (I
can ping an inside box (2001:6f8:3c8:42:xxx) from the outside), but the
router does not answer to ping, on the tunnel endpoint Ipv6
(2001:6f8:202:19c::2) nor on any other interface (in 2001:6f8:3c8::/48).

Then sixxs count it as down, and will disable it if nothing is done. I
can ping from router to remote tunnel endpoint (2001:6f8:202:19c::1),
but remote tunnel endpoint does not get any answer when it ping my
router endpoint. nor does can I ping it from outside. 

If I tcpdump gif0, I can see icmpv6 in and out. 

Does you have any clue ?

Thanks,

-- 
Bastien Durel

Re: OpenBSD as virtual guest, host machine acting as router for the guest(s) subnet(s)

[Bastien Durel]

Le mercredi 04 février 2015 à 09:27 +0100, Kirill Peskov a écrit :
 Hi All!
 
 One of my hosting providers has recently enforced the new routing
 policy for additional IP-addresses and instead of old good bridging
 mode from now on requires that all additional IPs should be routed via
 primary IP. I've already found quite a good HOWTO, but unfortunately it
 does describe how to configure Linux virtual guest on the Linux KVM
 host. My task is a bit different, I have to configure OpenBSD 5.6 guest
 on the Linux (Ubuntu) KVM host. Debian/Ubuntu HOWTO document suggests
 following configuration:

Hello.
I use this setup (kvm with routed network over primary ip, in a debian
host). Here are my setup choices :

/etc/interfaces is untouched (only eth0 and lo), ip forwarding is
activated (/proc/sys/net/ipv4/ip_forward = 1)

kvm runs with these parameters for network interface:
NET=-net nic,model=virtio -net 
tap,ifname=${NAME},script=/etc/vm/${NAME}/qemu-ifup

/etc/vm/${NAME}/qemu-ifup:
#!/bin/sh
NETWORK=60
TAP=`echo $NETWORK+1|bc`
VM=`echo $NETWORK+2|bc`
BRD=`echo $NETWORK+3|bc`
/sbin/ip link set $1 up
/sbin/ifconfig $1 10.42.1.$TAP broadcast 10.42.1.$BRD netmask 255.255.255.252 
mtu 16000
/sbin/ip route add 10.42.1.${VM}/32 via 10.42.1.$TAP dev $1

in guest, /etc/hostname.vio0:
inet 10.42.1.62 255.255.255.252
!ifconfig vio0 mtu 16000

/etc/mygate:
10.42.1.61

Regards,

-- 
Bastien Durel bast...@durel.org

5.6 Icmp6 checksum / pf

[Bastien Durel]

Hi,

I recently upgraded to 5.6, and got problems with icmpv6

I have a gif tunnel for IPv6:
[root@fremen root]# ifconfig gif0   


gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280
description: Sixxs
priority: 0
groups: gif egress
tunnel: inet 78.194.94.73 - 212.100.184.146
inet6 fe80::200:24ff:fecf:42ac%gif0 - prefixlen 64 scopeid 0x10
inet6 2001:6f8:202:19c::2 - 2001:6f8:202:19c::1 prefixlen 128

When I initiate a ping from this interface, it works as intended:

08:59:38.376107 2001:6f8:202:19c::2  2001:41d0:8:91a::1: icmp6: echo request 
(id:392e seq:0) [icmp6 cksum ok] (len 16, hlim 64)
08:59:38.410385 2001:41d0:8:91a::1  2001:6f8:202:19c::2: icmp6: echo reply 
(id:392e seq:0) [icmp6 cksum ok] (len 16, hlim 57)
08:59:39.389383 2001:6f8:202:19c::2  2001:41d0:8:91a::1: icmp6: echo request 
(id:392e seq:1) [icmp6 cksum ok] (len 16, hlim 64)
08:59:39.421397 2001:41d0:8:91a::1  2001:6f8:202:19c::2: icmp6: echo reply 
(id:392e seq:1) [icmp6 cksum ok] (len 16, hlim 57)

But when a ping from outside reached it, the echo reply is sent with a
bad (0) checksum, and the packet is dropped by te other side:

09:40:28.852102 2001:41d0:8:91a::1  2001:6f8:202:19c::2: icmp6: echo request 
(id:6c10 seq:1) [icmp6 cksum ok] (len 64, hlim 57)
09:40:28.852251 2001:6f8:202:19c::2  2001:41d0:8:91a::1: icmp6: echo reply 
(id:6c10 seq:1) [bad icmp6 cksum 0! - 2d93] (len 64, hlim 64)
09:40:29.860327 2001:41d0:8:91a::1  2001:6f8:202:19c::2: icmp6: echo request 
(id:6c10 seq:2) [icmp6 cksum ok] (len 64, hlim 57)
09:40:29.860432 2001:6f8:202:19c::2  2001:41d0:8:91a::1: icmp6: echo reply 
(id:6c10 seq:2) [bad icmp6 cksum 0! - 8a71] (len 64, hlim 64)

It works correctly with this pf rule disabled:
pass in on gif0 reply-to ( gif0 2001:6f8:202:19c::1 ) keep state

What's the correct way to handle correct return-path ?

Regards,

-- 
Bastien Durel

Re: IPv6 problem

[Bastien Durel]

Le vendredi 01 août 2014 à 16:31 +0200, Bastien Durel a écrit :
 Hello,
 
 I face a strange problem with my IPv6 connection. (one of them, actually)
 
 I got an OpenBSD router I use to connect to 2 ISPs and various internal
 networks.
 
 One of my link cannot use IPv6 from some time (as it's my backup link, I
 can't say exactly when it failed). This provider have native IPv6.
 
 here is the connected interface:
 sis1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 lladdr 00:00:24:cf:42:ad
 description: WAN2
 priority: 0
 groups: egress
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
 inet6 fe80::200:24ff:fecf:42ad%sis1 prefixlen 64 scopeid 0x2
 inet6 2001:41d0:fc8d:f200::1 prefixlen 64
 
 When I try to ping the outside world, I can see the packet leaving via
 sis1 (tcpdump -i sis1 -nvv -s 1500 ip6)
 
 15:58:41.703964 2001:41d0:fc8d:f200::1  2001:41d0:8:91a::1: icmp6: echo
 request (id:65fd seq:9) [icmp6 cksum ok] (len 16, hlim 64)
 
 (the outside world recieves it, and awnser)
 Then the provider's router sends a nsol to my router
 
 15:58:41.751487 fe80::5a98:35ff:fe1c:af06  ff02::1:ff00:1: icmp6:
 neighbor sol: who has 2001:41d0:fc8d:f200::1(src lladdr:
 58:98:35:1c:af:06) [icmp6 cksum ok] (len 32, hlim 255)
 
 it responds
 
 15:58:41.751588 fe80::200:24ff:fecf:42ad  fe80::5a98:35ff:fe1c:af06:
 icmp6: neighbor adv: tgt is 2001:41d0:fc8d:f200::1(RSO)(tgt lladdr:
 00:00:24:cf:42:ad) [bad icmp6 cksum 8c3a!] (len 32, hlim 255)
 
 then nothing happens.
 
 I had the same problem when the ISP's modem is put in bridge mode,
 except the router that sens the sollicitation is a CISCO ...
 
 Is there something I can have miss in my side ? I see there's a bad
 checksum, could this be a problem ?
 
 Here is my dmesg: (from syslog)
[...]
 
 Thanks,
 
I put a laptop on the other side of the cable to get a trace from the
router point of view, then this is the trace :
https://owncloud.geekwu.org/public.php?service=filest=2399a4db476667fdc4d5ed68422e5edc

We can see the echo request going through the interface, then the laptop
sends a Nsol, the OpenBSD box responds with Nadv, and nothing happens.
The Icmp6 checksum of the Nadv is zero, other packets comming from the
BSD box have correct checksums: I guess it's the problem ?

The laptop answers to ping from times to time; when the BSD box emits a
Nsol to get laptop's address. The Nsol have a correct checksum.

Looks like a bug, no ?

Regards,

-- 
Bastien Durel bast...@geekwu.org

Re: IPv6 problem

[Bastien Durel]

Le vendredi 01 août 2014 à 16:31 +0200, Bastien Durel a écrit :
 Hello,
 
 I face a strange problem with my IPv6 connection. (one of them, actually)
 
 I got an OpenBSD router I use to connect to 2 ISPs and various internal
 networks.
 
 One of my link cannot use IPv6 from some time (as it's my backup link, I
 can't say exactly when it failed). This provider have native IPv6.
 
 here is the connected interface:
 sis1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 lladdr 00:00:24:cf:42:ad
 description: WAN2
 priority: 0
 groups: egress
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
 inet6 fe80::200:24ff:fecf:42ad%sis1 prefixlen 64 scopeid 0x2
 inet6 2001:41d0:fc8d:f200::1 prefixlen 64
 
 When I try to ping the outside world, I can see the packet leaving via
 sis1 (tcpdump -i sis1 -nvv -s 1500 ip6)
 
 15:58:41.703964 2001:41d0:fc8d:f200::1  2001:41d0:8:91a::1: icmp6: echo
 request (id:65fd seq:9) [icmp6 cksum ok] (len 16, hlim 64)
 
 (the outside world recieves it, and awnser)
 Then the provider's router sends a nsol to my router
 
 15:58:41.751487 fe80::5a98:35ff:fe1c:af06  ff02::1:ff00:1: icmp6:
 neighbor sol: who has 2001:41d0:fc8d:f200::1(src lladdr:
 58:98:35:1c:af:06) [icmp6 cksum ok] (len 32, hlim 255)
 
 it responds
 
 15:58:41.751588 fe80::200:24ff:fecf:42ad  fe80::5a98:35ff:fe1c:af06:
 icmp6: neighbor adv: tgt is 2001:41d0:fc8d:f200::1(RSO)(tgt lladdr:
 00:00:24:cf:42:ad) [bad icmp6 cksum 8c3a!] (len 32, hlim 255)
 
 then nothing happens.
 
 I had the same problem when the ISP's modem is put in bridge mode,
 except the router that sens the sollicitation is a CISCO ...
 
 Is there something I can have miss in my side ? I see there's a bad
 checksum, could this be a problem ?
 
 Here is my dmesg: (from syslog)
[...]
 
 Thanks,
 
I put a laptop on the other side of the cable to get a trace from the
router point of view, then this is the trace :
https://owncloud.geekwu.org/public.php?service=filest=2399a4db476667fdc4d5ed68422e5edc

We can see the echo request going through the interface, then the laptop
sends a Nsol, the OpenBSD box responds with Nadv, and nothing happens.
The Icmp6 checksum of the Nadv is zero, other packets comming from the
BSD box have correct checksums: I guess it's the problem ?

The laptop answers to ping from times to time; when the BSD box emits a
Nsol to get laptop's address. The Nsol have a correct checksum.

Looks like a bug, no ?

Regards,

-- 
Bastien Durel bast...@durel.org

IPv6 problem

[Bastien Durel]

 16
Jul 30 11:23:04 fremen /bsd: uhci1 at pci0 dev 29 function 1 Intel
82801DB USB rev 0x02: apic 2 int 19
Jul 30 11:23:04 fremen /bsd: uhci2 at pci0 dev 29 function 2 Intel
82801DB USB rev 0x02: apic 2 int 18
Jul 30 11:23:04 fremen /bsd: ehci0 at pci0 dev 29 function 7 Intel
82801DB USB rev 0x02: apic 2 int 23
Jul 30 11:23:04 fremen /bsd: usb0 at ehci0: USB revision 2.0
Jul 30 11:23:04 fremen /bsd: uhub0 at usb0 Intel EHCI root hub rev
2.00/1.00 addr 1
Jul 30 11:23:04 fremen /bsd: ppb0 at pci0 dev 30 function 0 Intel
82801BA Hub-to-PCI rev 0x82
Jul 30 11:23:04 fremen /bsd: pci1 at ppb0 bus 1
Jul 30 11:23:04 fremen /bsd: ppb1 at pci1 dev 0 function 0 TI PCI2250
rev 0x02
Jul 30 11:23:04 fremen /bsd: pci2 at ppb1 bus 2
Jul 30 11:23:04 fremen /bsd: sis0 at pci2 dev 0 function 0 NS DP83815
10/100 rev 0x00, DP83816A: apic 2 int 16, address 00:00:24:cf:42:ac
Jul 30 11:23:04 fremen /bsd: nsphyter0 at sis0 phy 0: DP83815 10/100
PHY, rev. 1
Jul 30 11:23:04 fremen /bsd: sis1 at pci2 dev 1 function 0 NS DP83815
10/100 rev 0x00, DP83816A: apic 2 int 17, address 00:00:24:cf:42:ad
Jul 30 11:23:04 fremen /bsd: nsphyter1 at sis1 phy 0: DP83815 10/100
PHY, rev. 1
Jul 30 11:23:04 fremen /bsd: sis2 at pci2 dev 2 function 0 NS DP83815
10/100 rev 0x00, DP83816A: apic 2 int 18, address 00:00:24:cf:42:ae
Jul 30 11:23:04 fremen /bsd: nsphyter2 at sis2 phy 0: DP83815 10/100
PHY, rev. 1
Jul 30 11:23:04 fremen /bsd: sis3 at pci2 dev 3 function 0 NS DP83815
10/100 rev 0x00, DP83816A: apic 2 int 19, address 00:00:24:cf:42:af
Jul 30 11:23:04 fremen /bsd: nsphyter3 at sis3 phy 0: DP83815 10/100
PHY, rev. 1
Jul 30 11:23:04 fremen /bsd: re0 at pci1 dev 1 function 0 Realtek
8169SC rev 0x10: RTL8169/8110SCd (0x1800), apic 2 int 17, address
00:06:4f:66:40:00
Jul 30 11:23:04 fremen /bsd: rgephy0 at re0 phy 7: RTL8169S/8110S PHY,
rev. 2
Jul 30 11:23:04 fremen /bsd: re1 at pci1 dev 2 function 0 Realtek
8169SC rev 0x10: RTL8169/8110SCd (0x1800), apic 2 int 18, address
00:06:4f:66:40:01
Jul 30 11:23:04 fremen /bsd: rgephy1 at re1 phy 7: RTL8169S/8110S PHY,
rev. 2
Jul 30 11:23:04 fremen /bsd: ral0 at pci1 dev 5 function 0 Ralink
RT2561S rev 0x00: apic 2 int 21, address 00:10:60:00:00:8c
Jul 30 11:23:04 fremen /bsd: ral0: MAC/BBP RT2661B, RF RT5225
Jul 30 11:23:04 fremen /bsd: hifn0 at pci1 dev 6 function 0 Hifn
7955/7954 rev 0x00: LZS 3DES ARC4 MD5 SHA1 RNG AES PK, 32KB dram, apic
2 int 19
Jul 30 11:23:04 fremen /bsd: ichpcib0 at pci0 dev 31 function 0 Intel
82801DB LPC rev 0x02
Jul 30 11:23:04 fremen /bsd: pciide0 at pci0 dev 31 function 1 Intel
82801DB IDE rev 0x02: DMA, channel 0 configured to compatibility,
channel 1 configured to compatibility
Jul 30 11:23:04 fremen /bsd: pciide0: channel 0 disabled (no drives)
Jul 30 11:23:04 fremen /bsd: wd0 at pciide0 channel 1 drive 0: FLASH CARD
Jul 30 11:23:04 fremen /bsd: wd0: 1-sector PIO, LBA, 1919MB, 3931200 sectors
Jul 30 11:23:04 fremen /bsd: wd0(pciide0:1:0): using PIO mode 4,
Ultra-DMA mode 4
Jul 30 11:23:04 fremen /bsd: ichiic0 at pci0 dev 31 function 3 Intel
82801DB SMBus rev 0x02: apic 2 int 17
Jul 30 11:23:04 fremen /bsd: iic0 at ichiic0
Jul 30 11:23:04 fremen /bsd: spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM
non-parity PC3200CL2.5
Jul 30 11:23:04 fremen /bsd: usb1 at uhci0: USB revision 1.0
Jul 30 11:23:04 fremen /bsd: uhub1 at usb1 Intel UHCI root hub rev
1.00/1.00 addr 1
Jul 30 11:23:04 fremen /bsd: usb2 at uhci1: USB revision 1.0
Jul 30 11:23:04 fremen /bsd: uhub2 at usb2 Intel UHCI root hub rev
1.00/1.00 addr 1
Jul 30 11:23:04 fremen /bsd: usb3 at uhci2: USB revision 1.0
Jul 30 11:23:04 fremen /bsd: uhub3 at usb3 Intel UHCI root hub rev
1.00/1.00 addr 1
Jul 30 11:23:04 fremen /bsd: isa0 at ichpcib0
Jul 30 11:23:04 fremen /bsd: isadma0 at isa0
Jul 30 11:23:04 fremen /bsd: com0 at isa0 port 0x3f8/8 irq 4: ns16550a,
16 byte fifo
Jul 30 11:23:04 fremen /bsd: com1 at isa0 port 0x2f8/8 irq 3: ns16550a,
16 byte fifo
Jul 30 11:23:04 fremen /bsd: com2 at isa0 port 0x3e8/8 irq 5: ns16550a,
16 byte fifo
Jul 30 11:23:04 fremen /bsd: com2: probed fifo depth: 15 bytes
Jul 30 11:23:04 fremen /bsd: pckbc0 at isa0 port 0x60/5
Jul 30 11:23:04 fremen /bsd: pckbd0 at pckbc0 (kbd slot)
Jul 30 11:23:04 fremen /bsd: pckbc0: using irq 1 for kbd slot
Jul 30 11:23:04 fremen /bsd: wskbd0 at pckbd0: console keyboard, using
wsdisplay0
Jul 30 11:23:04 fremen /bsd: pcppi0 at isa0 port 0x61
Jul 30 11:23:04 fremen /bsd: spkr0 at pcppi0
Jul 30 11:23:04 fremen /bsd: it0 at isa0 port 0x2e/2: IT8712F rev 7, EC
port 0x290
Jul 30 11:23:04 fremen /bsd: npx0 at isa0 port 0xf0/16: reported by
CPUID; using exception 16
Jul 30 11:23:04 fremen /bsd: vscsi0 at root
Jul 30 11:23:04 fremen /bsd: scsibus0 at vscsi0: 256 targets
Jul 30 11:23:04 fremen /bsd: softraid0 at root
Jul 30 11:23:04 fremen /bsd: scsibus1 at softraid0: 256 targets
Jul 30 11:23:04 fremen /bsd: root on rd0a swap on rd0b dump on rd0b

Thanks,

-- 
Bastien Durel

syslogd hangs on boot

[Bastien Durel]

Hello,

I use an OpenBSD box for my uplink router.
I recently added a second uplink, but if the two nics are configured  
to use dhcp, the boot process hangs on syslogd start. Booting with one  
of the two external nic cable unplugged let the process going to the  
end.


Have you any tips to debug that ? maybe my network configuration needs  
to be changed ?


Thanks,

--
Bastien

Re: KVM switch - keyboard

[Bastien Durel]

Quoting Kent Fritz fritz.k...@gmail.com:

Just a data point...one of the boxes I've tried (can't remember which
of Foxconn nt535, nt-i1250, nt-i2847) had a similar/same problem.
About 30%-50% of the time when I switched to it, no kernel messages on
the screen, no keyboard.  I found that plugging in a USB flash drive
caused both the flash drive and the keyboard to be detected -- so that
was my workaround.


Hello,

This workaround works here too. Thanks to Francois Pussault to suggest  
this first, although I did not understand first ;)



--
Bastien

KVM switch - keyboard

[Bastien Durel]

Hello,

I use a KVM switch to control various computers, including my OpenBSD
5.2 router.
If I boot with console attached to the OpenBSD computer, it works well,
I'm able to control it, login, etc.
But when I switch to another computer, then back to OpenBSD, I get
display but no keyboard. The KVM del blinks as it does not get data from
the USB interface, and no event goes to dmesg.

Is there any configuration to let it handle (dis-)connections of
keyboard ?

Thanks,

NB: CW910 is a GENERIC kernel which lives on a ramdisk

-- 
Bastien
OpenBSD 5.2 (CW910) #0: Tue Jan  8 02:48:24 MST 2013
r...@spice-3.geekwu.org:/obj/CW910
cpu0: Intel(R) Celeron(R) M processor 600MHz (GenuineIntel 686-class) 600 MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF
real mem  = 534179840 (509MB)
avail mem = 463036416 (441MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/16/08, BIOS32 rev. 0 @ 0xfaa80, SMBIOS 
rev. 2.2 @ 0xf0800 (34 entries)
bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 09/16/2008
apm0 at bios0: Power Management spec V1.2 (slowidle)
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0xdf84
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfde80/240 (13 entries)
pcibios0: PCI Exclusive IRQs: 6 9 10 11 12
pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801DBM LPC rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xd400! 0xd/0x1800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 Intel 82855GM Host rev 0x02
Intel 82855GM Memory rev 0x02 at pci0 dev 0 function 1 not configured
Intel 82855GM Config rev 0x02 at pci0 dev 0 function 3 not configured
vga1 at pci0 dev 2 function 0 Intel 82855GM Video rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xe000, size 0x800
inteldrm0 at vga1: irq 11
drm0 at inteldrm0
Intel 82855GM Video rev 0x02 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 29 function 0 Intel 82801DB USB rev 0x02: irq 11
uhci1 at pci0 dev 29 function 1 Intel 82801DB USB rev 0x02: irq 9
uhci2 at pci0 dev 29 function 2 Intel 82801DB USB rev 0x02: irq 10
ehci0 at pci0 dev 29 function 7 Intel 82801DB USB rev 0x02: irq 6
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x82
pci1 at ppb0 bus 1
fxp0 at pci1 dev 0 function 0 Intel 8255x rev 0x0c, i82550: irq 11, address 
00:02:b3:ca:2d:1e
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
re0 at pci1 dev 1 function 0 Realtek 8169SC rev 0x10: RTL8169/8110SCd 
(0x1800), irq 12, address 00:06:4f:66:40:00
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
re1 at pci1 dev 2 function 0 Realtek 8169SC rev 0x10: RTL8169/8110SCd 
(0x1800), irq 10, address 00:06:4f:66:40:01
rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 2
hifn0 at pci1 dev 6 function 0 Hifn 7955/7954 rev 0x00: LZS 3DES ARC4 MD5 
SHA1 RNG AES PK, 32KB dram, irq 9
ichpcib0 at pci0 dev 31 function 0 Intel 82801DB LPC rev 0x02: 24-bit timer 
at 3579545Hz
pciide0 at pci0 dev 31 function 1 Intel 82801DB IDE rev 0x02: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
wd0 at pciide0 channel 1 drive 0: FLASH CARD
wd0: 1-sector PIO, LBA, 1919MB, 3931200 sectors
wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4
ichiic0 at pci0 dev 31 function 3 Intel 82801DB SMBus rev 0x02: irq 12
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC3200CL2.5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
com2: probed fifo depth: 15 bytes
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
it0 at isa0 port 0x2e/2: IT8712F rev 7, EC port 0x290
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
uhub4 at uhub1 port 2 ALCOR Generic USB Hub rev 1.10/3.12 addr 2
uhidev0 at uhub4 port 1 configuration 1 interface 0 CHESEN USB Keyboard rev 
1.10/1.10 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes, country code 33
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub4 port 1 configuration 1 interface 1 CHESEN USB Keyboard rev 
1.10/1.10 addr 3
uhidev1: iclass 3/0, 3 report ids
uhid0 at uhidev1 reportid 

Re: KVM switch - keyboard

[Bastien Durel]

Quoting Francois Pussault fpussa...@contactoffice.fr:

Hi, many hardware cannot manage USB keyboards without it present at boot.
because bios or equiv doesn't enable the port so the OS (whatever it is)
cannot use it.


[...]
a solution could be to have an usb-test device connected to garantee  
usb is enable

even if kvm is on another device.

Hello,

But KVM *is* connected at boot time, as you can see here :
uhidev1 at uhub4 port 1 configuration 1 interface 1 CHESEN USB  
Keyboard rev 1.10/1.10 addr 3

It's the diconnection-reconnection which is not managed.

Regards,

--
Bastien
--
Bastien