Re: ipv6 assistance

[Sonic]

That works - I didn't realize I needed to install a package to have ipv6
work with OpenBSD.

Thank you.

ipv6 assistance

[Sonic]

Running -current on my router and finally (after years) decided to move
into using ipv6.
I added "inet6 autoconf" to hostname.em0 (also has "inet autoconf") and I
get a link local address:
=
# ifconfig em0
em0:inet6 fe80::2132:31ff:fe0b:7ea4%em0 prefixlen 64 scopeid 0x1
inet 69.31.273.6 netmask 0xfc00 broadcast 69.31.273.255
=
And an ipv6 default route:
=
Internet6:
Destination Gateway
Flags   Refs  Use   Mtu  Prio Iface
default fe80::301:5bcf:fe75:2646%em0
 UGS0   22 - 8 em0
=
Which matches the default router proposal listed by slaacctl:
=
em0:
 index:   1 running: yes temporary: yes
lladdr: 40:62:31:0b:7e:a4
 inet6: fe80::2132:31ff:fe0b:7ea4%em0
Router Advertisement from fe80::201:5cff:fe75:2646%em0
received: 2024-04-06 10:49:17; 0s ago
Cur Hop Limit:   0, M: 1, O: 1, Router Lifetime:  1800s
Default Router Preference: Medium
Reachable Time:   360ms, Retrans Timer:  1000ms
prefix: 2001:623:8016:54::/64
On-link: 0, Autonomous address-configuration: 0
vltime: 604800, pltime: 302400
prefix: 2001:623:6007:a5::/64
On-link: 0, Autonomous address-configuration: 0
vltime: 604800, pltime: 302400
prefix: 2001:623:500e:16::/64
On-link: 0, Autonomous address-configuration: 0
vltime: 604800, pltime: 302400
prefix: 2001:623:4020:a5::/64
On-link: 0, Autonomous address-configuration: 0
vltime: 604800, pltime: 302400
Default router proposals
id:1, state: PROPOSAL_CONFIGURED
router: fe80::301:5bcf:fe75:2646%em0
router lifetime:   1800
Preference: Medium
updated: 2024-04-06 10:49:17; 0s ago, timeout:   1788s
=
However, there's no other ipv6 address on the interface - I suspect an
address from one of those 2001: prefix groups needs to be assigned.
Should not dhcpleased handle this?
Most of the web posts I find deal with the pre-dhcpleased days.

I'm on Comcast (Xfinity) in the US.

Thank you,
Chris

sysupgrade fails firmware fetch

[Sonic]

Today "sysupgrade -s" failed to fetch updated firmware:
=
Verifying sets.
Fetching updated firmware.
fw_update: failed.
Cannot fetch http://firmware.openbsd.org/firmware/7.5//SHA256.sig (404
Not Found)
Upgrading.
=

Seems it's looking for a 7.5 directory (-current apparently just moved
to 7.5-beta) instead of the snapshot directory.

Re: upgrade to latest snapshot failing

[Sonic]

On Fri, Nov 17, 2023 at 2:43 PM Stuart Henderson  wrote:
>
> Try booting bsd.rd and downloading a newer snap.

The latest bsd.rd is identical to the bsd.upgrade file.
The older bsd,rd from yesterday boots fine as the system does recover
from the failed upgrade if one has physical access to it to initiate a
reboot.

Re: upgrade to latest snapshot failing

[Sonic]

On Fri, Nov 17, 2023 at 2:06 PM Stuart Henderson
 wrote:
>
> Bit old by now, boot bsd.rd and try a newer one?
>
> If that fails too: which arch?

I'm currently on #1447, amd64, from which I was running "sysupgrade -s".
Apparently boots from bsd.upgrade during the process.

upgrade to latest snapshot failing

[Sonic]

Following -current:
OpenBSD 7.4-current (GENERIC.MP) #1447: Wed Nov 15 09:56:54 MST 2023
Upgrade via "sysupgrade -s" now failing with:
init: single user shell terminated, restarting
init: single user shell terminated, restarting
init: single user shell terminated, restarting


Chris

Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header

[Sonic]

Hopefully not as dumb of a question as I suspect it might be.
Does the generic...
=
match out on $ext_if inet proto tcp from ($ext_if) set prio (3, 7)
match in  on $ext_if inet proto tcp to ($ext_if) set prio (3, 7)
=
...take advantage of this patch when using wireguard or does the match need
to be applied to the wgx interface?

Re: core dumps from latest wireguard-tools

[Sonic]

Tried this:
pkg_delete wireguard-tools
pkg_delete -a(which removes bash-5.2.15)
then
pkg_add wireguard-tools   (which also reinstalls bash-5.2.15)

And it resolved the issue on all 3 systems.

Re: core dumps from latest wireguard-tools

[Sonic]

What I find odd is that it dumps core on 3 of the 5 systems but works
fine on the other two. All systems are x64 at OpenBSD 7.3-current
(GENERIC.MP) #1216 with wireguard-tools-1.0.20210914p1v0.

On Mon, Jun 5, 2023 at 8:51 AM Stuart Henderson
 wrote:
>
> On 2023-06-05, Sonic  wrote:
> > After upgrading several systems to the latest snapshot this evening
> > most of them are causing core dumps when running wg:
> >
> > # wg
> > Segmentation fault (core dumped)
> >
> > This is with:
> > wireguard-tools-1.0.20210914p1v0
>
> wireguard-tools had a port REVISION bump, because of an ABI change
> between the kernel and userland relating to wg interfaces.
>
> But it was bumped very soon after the kernel change was committed,
> so there is a good chance that the package build was done on a
> machine which didn't have the new kernel headers, but the ports
> tree was updated to a version after the bump.
>
> Please try rebuilding from /usr/ports/net/wireguard-tools.
>
> If that now works then we need to bump the REVISION again.
>
>

core dumps from latest wireguard-tools

[Sonic]

After upgrading several systems to the latest snapshot this evening
most of them are causing core dumps when running wg:

# wg
Segmentation fault (core dumped)

This is with:
wireguard-tools-1.0.20210914p1v0

Re: alias issue with snapshot #1175

[Sonic]

Sorry for the noise. It did turn out to be that the 3rd party device
was squatting on the .45 address.
Thanks to all!

Re: alias issue with snapshot #1175

[Sonic]

On Tue, May 9, 2023 at 2:24 AM Stuart Henderson  wrote:
> The only strange thing in there that I'm seeing is
>
> inet 10.68.73.1 255.255.255.248
> ...
> !route add -inet /24 10.68.73.1
> !route add -inet /24 10.68.73.1
>
> i.e. adding a route pointing at the local machine for those various
> networks, but that's not relating to the address where you mentioned
> having the problem.

I guess it might be better to point the route to the peer. Works either way.

> Perhaps diffing ifconfig -A (or maybe netstat -rn) between the working
> and non-working state will give a clue.

I just eyeballed it and they look the same but I'll run a diff to make sure.

Was able to test another system with a /29 and had no issues leaving
out an alias and having all the other addresses work fine, but in this
case there was no 3rd party device connected to the cable modem
utilizing that unused address. Hopefully by this weekend I can do some
testing by unplugging the 3rd party device and see what transpires.
Thanks!
Chris

Re: alias issue with snapshot #1175

[Sonic]

On Tue, May 9, 2023 at 12:35 AM Navan Carson  wrote:
> Do you have names that depend on DNS in pf.conf?

No.

Re: alias issue with snapshot #1175

[Sonic]

No real difference in the output of ifconfig or netstat before and
after restarting the network after a reboot.
The .45 alias refuses to accept/pass data other than answer a ping
after booting until the network, or at least the interface (em0) that
contains the alias is restarted.
>From outside testing the ssh port I get "tcp closed" and after the
network restart "tcp open", the other 3 addresses, .41, .42, .43 all
work properly after booting.
The .44 address being used by another device and not as an alias seems
to be tripping something up, but only after boot, once the interface
is restarted all is well.
Absolutely nothing in the logs indicating any error.


On Mon, May 8, 2023 at 10:48 AM Sonic  wrote:
>
> On Mon, May 8, 2023 at 9:24 AM Stuart Henderson
>  wrote:
> > There's not enough information really. /etc/hostname.* and maybe results
> > of ifconfig -A and netstat -rn might give more clues.
>
> Here's that info - hopefully not munged beyond use.
> Note that this is after the interface has been restarted (so the .45
> is working) but everything appeared normal before (ifconfig, etc.)
> although I won't be able to verify until late tonight when I can
> reboot the system.

Re: alias issue with snapshot #1175

[Sonic]

On Mon, May 8, 2023 at 9:24 AM Stuart Henderson
 wrote:
> There's not enough information really. /etc/hostname.* and maybe results
> of ifconfig -A and netstat -rn might give more clues.

Here's that info - hopefully not munged beyond use.
Note that this is after the interface has been restarted (so the .45
is working) but everything appeared normal before (ifconfig, etc.)
although I won't be able to verify until late tonight when I can
reboot the system.
lo0: flags=8049 mtu 32768
index 5 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff00
em0: flags=8843 mtu 1500
lladdr 68:05:ca:33:9b:46
description: external network
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT 
full-duplex,master,rxpause,txpause)
status: active
inet 51.67.20.41 netmask 0xfff8 broadcast 51.67.20.47
inet 51.67.20.42 netmask 0x
inet 51.67.20.43 netmask 0x
inet 51.67.20.45 netmask 0x
em1: flags=8802 mtu 1500
lladdr 00:25:90:87:9e:75
index 2 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
em2: flags=8843 mtu 1500
lladdr 00:25:90:87:9e:74
description: internal network
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet  netmask 0xfe00 broadcast 
enc0: flags=0<>
index 4 priority 0 llprio 3
groups: enc
status: active
wg0: flags=80c3 mtu 1420
description: VPN
index 6 priority 0 llprio 3
wgport 
wgpubkey 
wgpeer 
wgpsk (present)
wgendpoint  61722
tx: 109217968, rx: 3820653136
last handshake: 96 seconds ago
wgaip /24
wgaip /24
wgaip /24
wgaip /32
wgpeer 
wgpsk (present)
wgendpoint  61723
tx: 3383156, rx: 2595500
last handshake: 30 seconds ago
wgaip /24
wgaip /24
wgaip /23
wgaip /23
wgaip /32
wgpeer 
wgpsk (present)
wgendpoint  32925
tx: 4543152, rx: 5454580
last handshake: 69 seconds ago
wgaip /24
wgaip /24
wgaip /24
wgaip /24
wgaip /32
wgpeer 
wgpsk (present)
wgendpoint  37666
tx: 21211976, rx: 3509392
last handshake: 77 seconds ago
wgaip /24
wgaip /32
groups: wg
inet 10.68.73.1 netmask 0xfff8 broadcast 10.68.73.7
pflog0: flags=141 mtu 33136
index 7 priority 0 llprio 3
groups: pflog
116 mbufs in use:
109 mbufs allocated to data
1 mbuf allocated to packet headers
6 mbufs allocated to socket names and addresses
0/40 mbuf 2048 byte clusters in use (current/peak)
107/210 mbuf 2112 byte clusters in use (current/peak)
0/8 mbuf 4096 byte clusters in use (current/peak)
0/8 mbuf 8192 byte clusters in use (current/peak)
0/0 mbuf 9216 byte clusters in use (current/peak)
0/0 mbuf 12288 byte clusters in use (current/peak)
0/0 mbuf 16384 byte clusters in use (current/peak)
0/0 mbuf 65536 byte clusters in use (current/peak)
660/676/524288 Kbytes allocated to network (current/peak/max)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


hostname.em0
Description: Binary data


hostname.em2
Description: Binary data


hostname.wg0
Description: Binary data

Re: alias issue with snapshot #1175

[Sonic]

This is repeatable every time. After a boot the .45 alias does not
pass any traffic, its ports are closed. It will answer a ping, and
shows up in "ifconfig -A" (or em0) and in netstat.
The other 3 addresses work normally.
Restarting the interface with "sh /etc/netstart em0" brings the .45
alias back to an active state.

On Sun, May 7, 2023 at 8:43 PM Sonic  wrote:
>
> After doing a "sh /etc/netstart em0" that alias is back up and
> working. The problem occurs after boot.
>
> On Sun, May 7, 2023 at 7:23 PM Sonic  wrote:
> >
> > Hello,
> >
> > Upgrade a system to the latest snapshot - 1175 - and am seeing a
> > problem with an alias address.
> > The outside IP is part of a /29 (not actual addresses) :
> > inet 51.67.20.41 netmask 0xfff8 broadcast 51.67.20.47
> > inet 51.67.20.42 netmask 0x
> > inet 51.67.20.43 netmask 0x
> > inet 51.67.20.45 netmask 0x
> > The address 51.67.20.44 is used by another device connected to the
> > same cable modem.
> > All was working well until the upgrade and now the alias 51.67.20.45
> > will answer a ping but shows ports that should be open as closed, and
> > traffic does not pass.
> > The other 3 addresses (main and aliases) continue to work normally.
> >
> > Thanks for any assistance.
> > Chris

Re: alias issue with snapshot #1175

[Sonic]

After doing a "sh /etc/netstart em0" that alias is back up and
working. The problem occurs after boot.

On Sun, May 7, 2023 at 7:23 PM Sonic  wrote:
>
> Hello,
>
> Upgrade a system to the latest snapshot - 1175 - and am seeing a
> problem with an alias address.
> The outside IP is part of a /29 (not actual addresses) :
> inet 51.67.20.41 netmask 0xfff8 broadcast 51.67.20.47
> inet 51.67.20.42 netmask 0x
> inet 51.67.20.43 netmask 0x
> inet 51.67.20.45 netmask 0x
> The address 51.67.20.44 is used by another device connected to the
> same cable modem.
> All was working well until the upgrade and now the alias 51.67.20.45
> will answer a ping but shows ports that should be open as closed, and
> traffic does not pass.
> The other 3 addresses (main and aliases) continue to work normally.
>
> Thanks for any assistance.
> Chris

alias issue with snapshot #1175

[Sonic]

Hello,

Upgrade a system to the latest snapshot - 1175 - and am seeing a
problem with an alias address.
The outside IP is part of a /29 (not actual addresses) :
inet 51.67.20.41 netmask 0xfff8 broadcast 51.67.20.47
inet 51.67.20.42 netmask 0x
inet 51.67.20.43 netmask 0x
inet 51.67.20.45 netmask 0x
The address 51.67.20.44 is used by another device connected to the
same cable modem.
All was working well until the upgrade and now the alias 51.67.20.45
will answer a ping but shows ports that should be open as closed, and
traffic does not pass.
The other 3 addresses (main and aliases) continue to work normally.

Thanks for any assistance.
Chris

Re: Problem with WireGuard on OpenBSD 7.3

[Sonic]

On Thu, May 4, 2023 at 9:45 AM Janne Johansson  wrote:

> Apart from that, you either use /usr/local/bin/wg(-quick) to set up
> your wireguard interface OR hostname.wg0 not calling one from the
> other.


Thanks for that. Seems every website I've found uses calling
/usr/local/bin/wg from the hostname.wg file. And I've been running it
like this since Wireguard was put in the kernel. However, I decided to
try hostname.wg only and it works a treat. As an added benefit the
wireguard-tools package is not even needed.

Chris

udp port 0

[Sonic]

I'm seeing the following in my pf logs:
==
Sep 15 14:08:49.593449 rule def/(short) pass in on em2:
172.26.20.137.60866 > 172.26.62.1.0: udp 0
Sep 15 14:08:49.809690 rule def/(short) pass in on em2:
172.26.20.137.65148 > 172.26.62.1.0: udp 0
Sep 15 14:09:29.149953 rule def/(short) pass in on em2:
172.26.20.137.49665 > 172.26.62.1.0: udp 0
Sep 15 14:09:29.365757 rule def/(short) pass in on em2:
172.26.20.137.49667 > 172.26.62.1.0: udp 0
Sep 15 14:43:17.717680 rule def/(short) pass in on em2:
172.26.20.137.61884 > 172.26.62.1.0: udp 0
Sep 15 14:43:17.931856 rule def/(short) pass in on em2:
172.26.20.137.61885 > 172.26.62.1.0: udp 0
Sep 15 14:43:47.698013 rule def/(short) pass in on em2:
172.26.20.137.59967 > 172.26.62.1.0: udp 0
Sep 15 14:43:47.911210 rule def/(short) pass in on em2:
172.26.20.137.59968 > 172.26.62.1.0: udp 0
Sep 15 15:09:13.403486 rule def/(short) pass in on em2:
172.26.20.137.49665 > 172.26.62.1.0: udp 0
Sep 15 15:09:13.614937 rule def/(short) pass in on em2:
172.26.20.137.49667 > 172.26.62.1.0: udp 0
Sep 15 15:09:55.807086 rule def/(short) pass in on em2:
172.26.20.137.57674 > 172.26.62.1.0: udp 0
Sep 15 15:09:56.022708 rule def/(short) pass in on em2:
172.26.20.137.57675 > 172.26.62.1.0: udp 0
===
The 172.26.20.x subnet is internal and forwarded by a switch to the
default gateway of the OpenBSD router at address 172.26.62.1.
This one system, the only one, regularly attempts these connections to
udp port 0.
Any ideas about why this would occur?

Thank you,
Chris

Re: Modern RFC3442 (Classless DHCP Static Routes)

[Sonic]

On Tue, May 10, 2022 at 4:23 AM  wrote:

> most
> other OSes ship with "broken" RFC3442 support in this fashion.  Cisco
> doesn't, but Mac, Ubuntu, Windows, and Android do. Color me suprised to
> find out this wrinkle of RFC3442.

Note that the test is using the Openbsd isc-dhcp-server-4.4.3 package.
A test with a Windows 10 system: if option 3 is different from the
default route in option 121 than Windows 10 installs both as default
routes.
A test with a Debian system works differently in that it ignores
option 3 if option 121 sends a default route, but installs the option
3 route if a default route is not provided by option 121.

According to this paragraph of RFC3442: "If the DHCP server returns
both a Classless Static Routes option and a Router option, the DHCP
client MUST ignore the Router option." I'm not even sure Debian
strictly follows how that reads to me, which is that option 3 should
be totally ignored even if option 121 does not include a default
route.

However the RFC then goes on to place the onus on the DHCP Server administrator:
"DHCP Server Administrator Responsibilities

   Many clients may not implement the Classless Static Routes option.
   DHCP server administrators should therefore configure their DHCP
   servers to send both a Router option and a Classless Static Routes
   option, and should specify the default router(s) both in the Router
   option and in the Classless Static Routes option.

   When a DHCP client requests the Classless Static Routes option and
   also requests either or both of the Router option and the Static
   Routes option, and the DHCP server is sending Classless Static Routes
   options to that client, the server SHOULD NOT include the Router or
   Static Routes options."

Basically the first paragraph of the two directly above seems to work
fine for cases where the default route is the same for both option 3
and option 121, but if one desires a different default route in both
options then some client configs may break if paragraph two is not
heeded.
Which seems to indicate that it's the admins responsibility to
configure the server so that it does send option 3 to a client that
requests option 121, which seems at odds with the first paragraph and
seems like something the dhcp server itself should handle instead of
the dhcp server admin. Using class matching it would be fairly
straightforward to set up proper pools for the various systems.
However, that feature is one that's sorely missing (to my knowledge
anyway) in the Openbsd base dhcp server.

Re: Modern RFC3442 (Classless DHCP Static Routes)

[Sonic]

Dealing with broken clients can be handled with separate groups or
even "deny booting;" instead of breaking the dhcp server.

Re: Modern RFC3442 (Classless DHCP Static Routes)

[Sonic]

On Mon, May 9, 2022 at 6:03 AM Stuart Henderson
 wrote:
> On 2022-05-09, Stuart Henderson  wrote:
>
> ...so the correct configuration is clear: list both a 0.0.0.0/0
> classless route and "option routers", and it should work for all
> cases.

Yes. The server sends both, the clients that handle option 121 use its
data and ignore option 3, the clients that do not handle option 121
ignore it and use the data in option 3 (which may offer a different
default route).

Re: Modern RFC3442 (Classless DHCP Static Routes)

[Sonic]

On Fri, May 6, 2022 at 7:18 AM Florian Obser  wrote:
> Also, dhcpd(8) does not even hand out option 3 when option 121 is
> configured.

That doesn't seem like correct behavior (the ISC version certainly
offers both). Both options should be sent if configured, it's up to
the client to properly handle this.
Clients that are rfc3442 compliant will install the option 121 routes,
clients that are not rfc3442 compliant will ignore option 121 and
install the gateway supplied by option 3. If dhcpd doesn't hand out
option 3 when option 121 is configured then clients that are not
rfc3442 compliant will not receive a gateway address.

Re: dhcp issues

[Sonic]

On Sun, Jul 18, 2021 at 3:55 PM Stuart Henderson  wrote:
>
> The bits that can't be handled are the more per-interface things ("fetch
> an address but ignore dns or the default route on interface X however do
> fetch them from interface Y", or "my ISP won't give me a lease without
> providing a client-id"). Sometimes people are just doing that because
> they can and they could do things differently; other times it's because
> they need to and in the current state dhcpleased isn't suitable for
> them.

I notice that dhcpleased and resolvd are started by default, is there
any reason to run them on a system with only static interfaces?

Re: dhcp issues

[Sonic]

On Sat, Jul 17, 2021 at 11:20 AM Theo de Raadt  wrote:
>
> Instead, we are focusing on 99% of the use cases.

I hardly think that wanting to override your ISP's name servers is
outside of the 99% use cases. Of course it wouldn't be the first time
I am wrong.

> You might want to look into using unwind(8) instead of unbound(8),
> because resolv(8) treats it as highest priority.

On Sat, Jul 17, 2021 at 5:13 PM Stuart Henderson  wrote:
> > The workaround I found is resolvd_flags=NO in rc.conf.local
> > eliminating the prepending of the ISP nameservers.
>
> That's one workaround. Another is to run unwind with an explicit
> configuration directing traffic to your local resolver.

The more I read about unwind the more I like it but it just doesn't
seem like the right option in this particular case (but sure for
anything that's mobile), this being a stable firewall system and
needing the features that unbound, which I've been using on many
systems (both Linux and OpenBSD since before it was in base),
provides.
Although I don't have a static IP to the world, the DHCP assigned IP
changes less than once a year, static enough for my use.
The dhclient supersede worked well for years, hopefully the
resolvd_flags=NO will as well.
Yes, starting unwind also works, but using unwind to talk to unbound
which is already running and can already be queried on it's own seems
a bit overkill (a resolving DNS server to query another resolving DNS
server on the same system?). Basically my unbound instance is the only
DNS server useful for this firewall's tasks, so any kind of auto
switching has no problem to solve. And I'm sure in the future I will
need to eat these words :-)
Thanks!
Chris

Re: dhcp issues

[Sonic]

On Fri, Jul 16, 2021 at 10:35 PM Theo de Raadt  wrote:
> We are moving from a model where dhclient on 1 interface believes it is
> MASTER of /etc/resolv.conf and a bunch of system aspects, and the
> userbase is familiar with a pile of hacky control knobs in
> dhclient.conf.
>
> Towards a model where multiple interfaces + unwind can advertise their
> DNS resolution abilities to resolvd, which then sorts the offers and
> maintains a configuration.

On the surface this sounds good.

> Anyways I'll let other people you didn't show your config to explain how
> you are probably using pf incorrectly on interfaces configured with
> dynamic addressing.

Ah yes, my bad, had a line without the parens around the dhcp
interface reference.
This issue is resolved.
Oddly enough it never affected many previous snapshots which used
dhcpcd in place of dhcpleased.

The issue with resolved is still a bit perplexing as if I allow it to
run it insists on prepending my ISP nameservers to the resolv.conf
file which breaks the system.
Before the change:

# Generated by em0 dhclient
search example.com
nameserver 127.0.0.1
lookup file bind
family inet4

# $OpenBSD: dhclient.conf,v 1.2 2017/10/16 23:43:41 krw Exp $
supersede domain-name "example.com";
supersede domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, routers;
require subnet-mask, routers;


After the change with dhcpleased and resolvd:

nameserver 75.75.75.75 # resolvd: em0
nameserver 75.75.76.76 # resolvd: em0
# Generated by em0 dhclient
search example.com
nameserver 127.0.0.1
lookup file bind
family inet4


I run nsd and unbound on this system, unbound listens on the loopback
and on the internal interface to serve the network, it uses stub zones
to the local nsd and to a bunch of other internal network dns servers
connected via site-to-site vpn tunnels.
My ISP's nameservers have no clue about my internal systems or the
other vpn connected internal systems that I need to resolve and there
should be someway to prevent the ISP's nameservers from being force
prepended to resolv.conf as the supersedes in dhclient.conf are
apparently ignored.
The workaround I found is resolvd_flags=NO in rc.conf.local
eliminating the prepending of the ISP nameservers.
If there's a more acceptable proper OpenBSD solution it would be
preferred but at this point I don't see what it is.

Chris

dhcp issues

[Sonic]

Having some issues after a sysupgrade to the latest snapshot (of this
writing) - OpenBSD 6.9-current (GENERIC.MP) #131.

Seems the base change to dhcpleased/resolvd has presented some issues.
Pf does not start on boot as it claims my dhcp interface has no
address, however after logging in I can load pf and almost resume
normal operations. Apparently the interface does get an IP address,
but the start of pf doesn't wait for it.
Almost, because my supersedes, etc. in /etc/dhclient.conf are
completely ignored.
The only workaround I found was to disable resolvd so I could manually
propagate /etc/resolv.conf without it being overwritten.

Re: how to use OpenBSD firewall (pf) to protect Ooma Telo VOIP phone system

[Sonic]

For starters use a separate vlan for the phones.

On Mon, Jul 5, 2021 at 2:02 PM Jonathan Thornburg  wrote:
>
> Short summary:
>
> Has anyone used an OpenBSD firewall (pf) to protect an Ooma Telo VOIP
> phone system from internet attacks?  If so, how did you do it?  More
> generally, how do people protect VOIP phone systems (regardless of brand)
> from internet attacks?
>
>
> Details:
>
> My current home network topology is
>
>  +--+
>   (internet) | $ISP DSL |
>  | modem/router |
>  +--+
> ||
> ||
>+--++---+
>| OpenBSD  || Omma Telo |.. analog
>| firewall || VOIP box  |   telephones
>+--++---+
>  |  |
>   ++ |  |
>   | Wifi   |-+  +-- wired client
>   | access |(or network switch for
>   | point  | multiple wired clients)
>   ++
>
> The OpenBSD firewall's pf is setup to NAT all the outbound traffic
> and to block any incoming traffic except replies to previous outbound
> traffic.
>
> This works, but isn't as secure as I'd like, because the OpenBSD pf only
> protects our computers; the Ooma Telo VOIP box is outside the firewall
> and is only "protected" by the $ISP DSL modem/router (whose security I
> don't at all trust).  That is, I suspect that both the $ISP-provided
> DSL modem/router and the Ooma Telo VOIP box are ultimately "just" small
> embedded Linux boxes running less-than-fully-patched 10-year-old software,
> and are thus quite vulnerable to attack from the internet.
>
> So, as part of a forthcoming upgrade of the OpenBSD firewall hardware,
> I would like to move the Ooma box inside the firewall-protected network
> by switching to the following network topology:
>
>  +--+
>   (internet) | $ISP DSL |
>  | modem/router |
>  +--+
> |
> |
>+--++---+
>| OpenBSD  || Omma Telo |.. analog
>| firewall || VOIP box  |   telephones
>+--++---+
>  |  |
>   ++ |  |
>   | Wifi   |-+  +-- wired client
>   | access |(or network switch for
>   | point  | multiple wired clients)
>   ++
>
> This design would allow pf to protect the Ooma box as well as the
> local computers.
>
> The problem is that (as is pretty standard for VOIP systems) the Ooma
> Telo carries voice traffic on UDP packets, and the UDP port numbers
> can span a wide (dynamically-chosen) range, rather like ftp.  The
> Ooma documentation says it needs the following ports:
> https://support.ooma.com/home/advanced-connections-and-service-ports/
>   outgoing UDP/TCP 53, 1194, 1294
>   outgoing TCP 80, 110, 443
>   outgoing UDP 67, 123, 3480
>   incoming UDP 1 to 3
>
> So, there are the usual problems of NAT with dynamically-chosen ports.
>
> And, the range of incoming ports (1 to 3) is much broader than
> I would like to leave open to the whole world.  I can (will) try to
> restrict by IP source addresses, but Ooma offers no documentation on
> what IP addresses from their network may need to send me UDP packets
> for normal operation (notably, I don't know how incoming phone calls
> are signalled), so I will need to do some reverse engineering here
> (tcpdump to start with).  If I'm lucky the incoming UDP packets will
> always come from IP addresses to which I've previously sent outgoing
> traffic (so that the normal pf state table will grok them).
>
> In any case, IP source addresses can be forged, so relying on them
> alone gives somewhat limited security.  I don't know of an easy way
> to work around this.  Do I need a full-fledged SIP proxy somewhere
> (either on the firewall or on a separate dedicated machine)?
>
> Overall, I would rather not have to re-invent the wheel here.  What
> are other OpenBSD users doing to protect VOIP phone systems from
> incoming "nastygram" attacks?
>
> --
> -- "Jonathan Thornburg [remove color- to reply]" 
>on the west coast of Canada, eh?
>"There was of course no way of knowing whether you were being watched
> at any given moment.  How often, or on what system, the Thought Police
> plugged in on any individual wire was guesswork.  It was even conceivable
> that they watched everybody all the time."  -- George Orwell, "1984"
>

Re: help me to create hostname.wg

[Sonic]

On Fri, Oct 30, 2020 at 12:07 PM kasak  wrote:
> $ wg showconf wg0
> [Interface]
> ListenPort = 9022
>
> why the keys is not configured?

You're not root.

Re: can't install some packages on -current

[Sonic]

On Tue, Aug 4, 2020 at 4:24 PM  wrote:
> Update the installed packages first pkg_add -Uu

It's a fresh install based on -current just downloaded. First attempt
at installing packages, so no packages to upgrade.

Re: can't install some packages on -current

[Sonic]

Is there a workaround? Is it a matter of timing - waiting for the
packages to be built around the newer libraries? Or were the older
library versions left off mistakenly?

On Tue, Aug 4, 2020 at 4:20 PM Theo de Raadt  wrote:
>
> this is openbsd-current.  things change.  get used to it, or stick to
> releases.
>
> Sonic  wrote:
>
> > On a slightly older install I have the missing libraries (and the newer 
> > ones):
> > /usr/lib/libc++.so.4.0
> > /usr/lib/libc++.so.5.0
> > /usr/lib/libc++abi.so.2.1
> > /usr/lib/libc++abi.so.3.0
> > /usr/lib/libpcap.so.8.4
> > /usr/lib/libpcap.so.9.0
> >
> > On this most recent install only the newer libraries exist:
> > /usr/lib/libc++.so.5.0
> > /usr/lib/libc++abi.so.3.0
> > /usr/lib/libpcap.so.9.0
> >
> > Chris
> >
> > On Tue, Aug 4, 2020 at 4:00 PM Sonic  wrote:
> > >
> > > Fresh install of -current and I'm getting these errors when running 
> > > pkg_add:
> > >
> > > library pcap.8.4 not found
> > >  /usr/lib/libpcap.so.9.0 (system): bad major
> > > library c++.4.0 not found
> > >  /usr/lib/libc++.so.5.0 (system): bad major
> > > library c++abi.2.1 not found
> > >  /usr/lib/libc++abi.so.3.0 (system): bad major
> > >
> > > OpenBSD 6.7-current (GENERIC.MP) #3: Tue Aug  4 02:09:52 MDT 2020
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > real mem = 8573091840 (8175MB)
> > > avail mem = 8298237952 (7913MB)
> > > random: good seed from bootblocks
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
> > > bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
> > > bios0: innotek GmbH VirtualBox
> > > acpi0 at bios0: ACPI 4.0
> > > acpi0: sleep states S0 S5
> > > acpi0: tables DSDT FACP APIC SSDT
> > > acpi0: wakeup devices
> > > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > > cpu0 at mainbus0: apid 0 (boot processor)
> > > cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3510.84 MHz, 06-3a-09
> > > cpu0: 
> > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,MELTDOWN
> > > cpu0: 256KB 64b/line 8-way L2 cache
> > > cpu0: smt 0, core 0, package 0
> > > mtrr: CPU supports MTRRs but not enabled by BIOS
> > > cpu0: apic clock running at 1000MHz
> > > cpu1 at mainbus0: apid 1 (application processor)
> > > cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3510.59 MHz, 06-3a-09
> > > cpu1: 
> > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,MELTDOWN
> > > cpu1: 256KB 64b/line 8-way L2 cache
> > > cpu1: disabling user TSC (skew=269)
> > > cpu1: smt 0, core 1, package 0
> > > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
> > > acpiprt0 at acpi0: bus 0 (PCI0)
> > > acpicpu0 at acpi0: C1(@1 halt!)
> > > acpicpu1 at acpi0: C1(@1 halt!)
> > > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> > > extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
> > > extent `pciio' (0x0 - 0x), flags=0
> > >  0x1 - 0x
> > > extent `pcimem' (0x0 - 0x), flags=0
> > >  0x0 - 0xdfff
> > >  0xfec0 - 0xfec00fff
> > >  0xfee0 - 0xfee00fff
> > >  0xfffc - 0x
> > >  0x400 - 0x
> > > acpiac0 at acpi0: AC unit online
> > > acpivideo0 at acpi0: GFX0
> > > cpu0: using IvyBridge MDS workaround
> > > pci0 at mainbus0 bus 0
> > > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> > > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> > > pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
> > > channel 0 configured to compatibility, channel 1 configured to
> > > compatibility
> > > wd0 at pciide0 channel 0 drive 0: 
> > > wd0: 128-sector PIO, LBA, 16384MB, 33554432 sectors
> > > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> > > atapiscsi0 at pciide0 channel 1 drive 0

Re: can't install some packages on -current

[Sonic]

On a slightly older install I have the missing libraries (and the newer ones):
/usr/lib/libc++.so.4.0
/usr/lib/libc++.so.5.0
/usr/lib/libc++abi.so.2.1
/usr/lib/libc++abi.so.3.0
/usr/lib/libpcap.so.8.4
/usr/lib/libpcap.so.9.0

On this most recent install only the newer libraries exist:
/usr/lib/libc++.so.5.0
/usr/lib/libc++abi.so.3.0
/usr/lib/libpcap.so.9.0

Chris

On Tue, Aug 4, 2020 at 4:00 PM Sonic  wrote:
>
> Fresh install of -current and I'm getting these errors when running pkg_add:
>
> library pcap.8.4 not found
>  /usr/lib/libpcap.so.9.0 (system): bad major
> library c++.4.0 not found
>  /usr/lib/libc++.so.5.0 (system): bad major
> library c++abi.2.1 not found
>  /usr/lib/libc++abi.so.3.0 (system): bad major
>
> OpenBSD 6.7-current (GENERIC.MP) #3: Tue Aug  4 02:09:52 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8573091840 (8175MB)
> avail mem = 8298237952 (7913MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
> bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
> bios0: innotek GmbH VirtualBox
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP APIC SSDT
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3510.84 MHz, 06-3a-09
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: CPU supports MTRRs but not enabled by BIOS
> cpu0: apic clock running at 1000MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3510.59 MHz, 06-3a-09
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: disabling user TSC (skew=269)
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
> extent `pciio' (0x0 - 0x), flags=0
>  0x1 - 0x
> extent `pcimem' (0x0 - 0x), flags=0
>  0x0 - 0xdfff
>  0xfec0 - 0xfec00fff
>  0xfee0 - 0xfee00fff
>  0xfffc - 0x
>  0x400 - 0x
> acpiac0 at acpi0: AC unit online
> acpivideo0 at acpi0: GFX0
> cpu0: using IvyBridge MDS workaround
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
> channel 0 configured to compatibility, channel 1 configured to
> compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 128-sector PIO, LBA, 16384MB, 33554432 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> vga1 at pci0 dev 2 function 0 "VMware SVGA II" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 2 int 19,
> address 08:00:27:12:5a:3a
> "InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0
> not configured
> ohci0 at pci0 dev 6 function 0 "Apple Intrepid USB" rev 0x00: apic 2
> int 22, version 1.0
> piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: apic 2 int 23
> iic0 at piixpm0
> ehci0 at pci0 dev 11 function 0 "Intel 82801FB USB" rev 0x00: apic 2 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
> isa0 at pcib0
> isadma0 at isa0
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pms0 at pckbc0 (aux slot

can't install some packages on -current

[Sonic]

Fresh install of -current and I'm getting these errors when running pkg_add:

library pcap.8.4 not found
 /usr/lib/libpcap.so.9.0 (system): bad major
library c++.4.0 not found
 /usr/lib/libc++.so.5.0 (system): bad major
library c++abi.2.1 not found
 /usr/lib/libc++abi.so.3.0 (system): bad major

OpenBSD 6.7-current (GENERIC.MP) #3: Tue Aug  4 02:09:52 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8573091840 (8175MB)
avail mem = 8298237952 (7913MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3510.84 MHz, 06-3a-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3510.59 MHz, 06-3a-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ITSC,FSGSBASE,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: disabling user TSC (skew=269)
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
extent `pciio' (0x0 - 0x), flags=0
 0x1 - 0x
extent `pcimem' (0x0 - 0x), flags=0
 0x0 - 0xdfff
 0xfec0 - 0xfec00fff
 0xfee0 - 0xfee00fff
 0xfffc - 0x
 0x400 - 0x
acpiac0 at acpi0: AC unit online
acpivideo0 at acpi0: GFX0
cpu0: using IvyBridge MDS workaround
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 128-sector PIO, LBA, 16384MB, 33554432 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
vga1 at pci0 dev 2 function 0 "VMware SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 2 int 19,
address 08:00:27:12:5a:3a
"InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0
not configured
ohci0 at pci0 dev 6 function 0 "Apple Intrepid USB" rev 0x00: apic 2
int 22, version 1.0
piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: apic 2 int 23
iic0 at piixpm0
ehci0 at pci0 dev 11 function 0 "Intel 82801FB USB" rev 0x00: apic 2 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
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Apple OHCI root hub" rev
1.00/1.00 addr 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (4bf4d605bb37e507.a) swap on wd0b dump on wd0b

Ideas?

Thank you,
Chris

Re: wireguard multiple interfaces

[Sonic]

On Fri, Jul 31, 2020 at 3:15 PM  wrote:
> Use multiple interfaces, one per site to connect with. Overhead isnt really 
> present, its just routing and hashes at that point.
> (I’ve had no issues doing site to sites in this fashion, has been working 
> great for months)

I was picturing 3 wgx interfaces, one per vlan, on all systems. The
"server" (the "client" sites need access to the "server" but not to
each other) would be the only box that would have multiple peers
listed for each wgx interface. I thought this might simplify the
setup, but not really sure. Would make it easy to see the traffic
generated per vlan through the vpn.

wireguard multiple interfaces

[Sonic]

The need is for site-to-site vpns (multiple client sites to one server
site), 3 vlans each.
>From a management point of view it might be better to use 3 wireguard
interfaces on all of the routers (wg0, wg1, wg2). But I'm not sure if
that adds overhead, and if so how much.
Basically, is it better to use just one tunnel (wg0) or 3?

Thanks for any insights.

Chris

Re: IKEDv2 and alias addresses

[Sonic]

On Thu, Jun 25, 2020 at 4:10 PM Tobias Heider  wrote:
> I tried to reproduce your bug (on current) but it seems to work as intended
> for me.  It would certainly help to have a bit more info such as an iked log
> and a tcpdump of your failed handshake as well as the used openbsd version.

The passive side is a much older version. At this point Ikev1 is
working and once I update that box to current I'll most likely test
and, if successful, switch to Watchguard as rumor has it that its
performance is much better.

Thanks for your assistance!

Chris

Re: IKEDv2 and alias addresses

[Sonic]

On Sun, Jun 21, 2020 at 5:20 PM Stuart Henderson  wrote:
>
> IIRC "local" isn't enough, some packets are still sent on the bound
> 0.0.0.0, the kernel chooses the source address (based on the local
> interface address in the route to the destination) and it can be
> the wrong address for the other side.

I believe that is what I saw. The passive side received packets on the
alias address but when it sent replies they went out the main address
instead.

As I'm getting a /29 via the cable modem which has some extra ports
and in some cases my openbsd firewalls also have extra ports, so
instead of bringing all 5 addresses into one port maybe configuring a
different interface with one of the aliases as its only address could
work, but I believe it would need to be in a different rdomain. Which
may be, in the end, a more elegant solution. Is there any appreciable
overhead using domains like this?

Thanks!

Re: IKEDv2 and alias addresses

[Sonic]

On Sun, Jun 21, 2020 at 12:11 PM Patrick Wildt  wrote:
> If you want to use a specific address for a policy, you can use the
> "local" keyword to specify it.  This is part of the policy, not a global
> option.
>
> Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
> only match if the IP address match to the one specified as "local".

My config is basically:
Remote:
===
local_gw="a.b.c.164"
local_net="172.20.28.0/23"
server_gw="x.y.z.45"
server_net="172.26.62.0/23"
state="active"

ikev2 'remote_rsa' $state esp \
from $local_net to $server_net \
local $local_gw peer $server_gw \
dstid server.example.com
===
Server:
===
local_gw="x.y.z.45"
local_net="172.26.62.0/23"
remote_gw="a.b.c.164"
remote_net="172.20.28.0/23"
state="passive"

ikev2 'server_rsa' $state esp \
from $local_net to $remote_net \
local $local_gw peer $remote_gw \
srcid server.example.com
===

Both outside nets are /29's and the .164 and .45 are aliases, with
.161 and .41 being the main address. However in trouble shooting I
kept seeing information moving on the main addresses and my pf.conf
rules were configured for the alias addresses.

Being new to ikev2 setup I may have this all wrong.

Thanks!

IKEDv2 and alias addresses

[Sonic]

With IKEDv1 I was able to use alias addresses for the VPN tunnels with
a Listen-on directive in isakmpd.conf:
==
[General]
Listen-on=  1.2.3.7
==

So far my attempts with IKEDv2 have been unsuccessful at using alias
addresses. Is it possible?

Thanks!

Chris

Re: unexpected behavior

[Sonic]

Was wondering if I wanted such an interface for management purposes,
that is - unconnected during normal installed operation but accepting
dhcp assignment when connected - could it be placed in a different
domain (not r0)? This way it should be available when needed but yet
not interfere with the r0 routing table, that is /etc/mygate would be
valid and used for the interfaces in r0. Can a new routing domain work
via dhcp or must its network be defined when it is created?

Re: issue with IKEv2 setup

[Sonic]

On Wed, Jun 3, 2020 at 1:49 PM Tobias Heider  wrote:
> It does.  /etc/iked/pubkeys/fqdn/server2.domain is where the peer's public key
> should be.

The peers public key is there, the peer, as far as I can tell is
server1.domain, yet the example shows server2.domain.

issue with IKEv2 setup

[Sonic]

Following the FAQ at https://www.openbsd.org/faq/faq17.html I ran into
the following problem with the server2 example:
===
ikev2 'server2_rsa' active esp \
from 10.0.2.0/24 to 10.0.1.0/24 \
peer 192.0.2.1 \
dstid server2.domain
===

===
# iked -dv
set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/server2.domain
===

Is the above an error to be concerned with? Doesn't the system know
that its pubkey exists as /etc/iked/local.pub ?

Should /etc/iked/local.pub be copied to /etc/iked/pubkeys/fqdn/server2.domain ?

(of course I'm using the actual fqdn of the systems in question and
literally serverX.domaIn)

No such error on the server1 example, although it seems that srcid is
not checked for the pubkey as dstid is.

Chris

Re: unexpected behavior

[Sonic]

Thanks!

On Tue, Jun 2, 2020 at 10:48 AM Anders Andersson  wrote:
>
> On Tue, Jun 2, 2020 at 4:30 PM Sonic  wrote:
> >
> > Recently discovered (snapshot form May 30) having any hostname.if
> > configured for dhcp, even if unplugged and inactive, prevents the
> > default gateway defined in /etc/mygate from being set. Is this normal?
>
> "/etc/mygate is processed after all interfaces have been configured.
> If any hostname.if(5) files contain "dhcp" directives, IPv4 entries in
> /etc/mygate will be ignored.  If they contain "autoconf" directives,
> IPv6 entries will be ignored."
>
> Exactly as documented.

unexpected behavior

[Sonic]

Recently discovered (snapshot form May 30) having any hostname.if
configured for dhcp, even if unplugged and inactive, prevents the
default gateway defined in /etc/mygate from being set. Is this normal?

Re: dhcpd and unbound on a small LAN

[Sonic]

On Mon, Jan 6, 2020 at 9:35 AM Steve Litt  wrote:
> I need something like that for my situation. Two questions:
>
> 1) Does the preceding setup prevent anyone with a different mac address
> from getting 192.168.0.68?

Via dhcp, yes, it would. Unless they change their MAC address to match.
They could also manually use the same IP address.

> 2) Is there a way I can set it up so ONLY specific mac addresses can
> get a dhcp lease from my server?***  I'd like to keep the man on the
> street from getting a lease: If I don't know the person and machine
> ahead of time, I don't want them getting a lease.

See the "range" statement for the dhcp subnet, with no range only
known clients with reserved addresses will get IP addresses assigned.

Chris

Re: dhcpd and unbound on a small LAN

[Sonic]

On Mon, Jan 6, 2020 at 7:27 AM Anders Andersson  wrote:
> ...
> Every time information has to be entered twice there is room for error
> and inconsistencies, so preferably this list should be automatically
> generated from a simpler file, maybe /etc/hosts.

No need for dual entry or messing with the hosts file, unbound alone
is fine for resolving names.

> ...
> My second and more difficult issue is that I can't seem to find a way
> to feed information from the DHCP server into unbound, so that locally
> assigned hosts can be queried by their hostnames.

You have it backwards, let dhcp use the information in unbound to
assign the reserved address:
===
host alice {
  hardware ethernet 20:9e:02:f5:93:60;
  fixed-address alice.home.lan;
  option host-name "alice";
  }
===

Start unbound before dhcpd in your rc.conf.local (ex):
===
unbound_flags="-c /var/unbound/etc/unbound.conf"
dhcpd_flags="em0"
===

Make sure your resolv.conf points to unbound so that your system can
resolve the local dns names.

Chris

Re: pflog flooded with igmp queries

[Sonic]

On Thu, Jan 2, 2020 at 12:34 PM Otto Moerbeek  wrote:
> > Can't seem to find that specific info anywhere.
>
> see man pf.conf and then search for allow-opts

I see that it says they are blocked, but nothing to indicate they are
also automatically logged.

Chris

Re: pflog flooded with igmp queries

[Sonic]

On Thu, Jan 2, 2020 at 12:27 PM Sonic  wrote:
> I used:
> block proto igmp

More specifically:
  block drop quick proto igmp
as I thought "return" would simply add extra traffic to the network.

Chris

Re: pflog flooded with igmp queries

[Sonic]

On Thu, Jan 2, 2020 at 1:00 AM Sebastien Marie  wrote:
>  And by default, packets
> with ip-options are block-logged.

Can't seem to find that specific info anywhere.

> I suppose that adding an explicit rule with allow-opts should do the trick.
> depending your need (block or allow):
> block return proto igmp to 224/4 allow-opts
> or
> pass proto igmp to 224/4 allow-opts

I used:
block proto igmp

Thanks!
Chris

Re: pflog flooded with igmp queries

[Sonic]

5 "Intel 100 Series PCIE" rev 0xf1: msi
pci6 at ppb5 bus 6
em5 at pci6 dev 0 function 0 "Intel I211" rev 0x03: msi, address
40:62:31:0a:6a:12
"Intel 100 Series UART" rev 0x21 at pci0 dev 30 function 0 not configured
pcib0 at pci0 dev 31 function 0 "Intel 200 Series LPC" rev 0x21
"Intel 100 Series PMC" rev 0x21 at pci0 dev 31 function 2 not configured
ichiic0 at pci0 dev 31 function 4 "Intel 100 Series SMBus" rev 0x21: apic 2 int
16
iic2 at ichiic0
spdmem0 at iic2 addr 0x50: 8GB DDR4 SDRAM PC4-19200 SO-DIMM
isa0 at pcib0
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
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
efifb at mainbus0 not configured
uhidev0 at uhub0 port 5 configuration 1 interface 0 "Logitech USB Keyboard" rev
1.10/64.00 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd0 at ukbd0: console keyboard
uhidev1 at uhub0 port 5 configuration 1 interface 1 "Logitech USB Keyboard" rev
1.10/64.00 addr 2
uhidev1: iclass 3/0, 3 report ids
uhid0 at uhidev1 reportid 1: input=1, output=0, feature=0
uhid1 at uhidev1 reportid 2: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 3: input=3, output=0, feature=0
run0 at uhub0 port 9 configuration 1 interface 0 "Ralink 802.11 n WLAN" rev
2.00/1.01 addr 3
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address
00:25:d3:9b:fb:db
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (942874cb9f340f4f.a) swap on sd0b dump on sd0b
inteldrm0: 3840x2160, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)

On Wed, Jan 1, 2020 at 4:04 PM Sebastian Benoit  wrote:
>
> Sonic(sonicsm...@gmail.com) on 2020.01.01 12:33:30 -0500:
> > The pflogs on my firewall and on a new system I'm installing (-current
> > with pretty much a default pf.conf) are flooded with igmp query
> > entries. Neither system has a log rule for such action.
> >
> > Ex:
> > ===
> > rule 1/(match) pass in on em1: 192.168.1.20 > 224.0.0.1: igmp query [ttl 1]
> > ===
> >
> > pf.conf:
> > ===
> > #   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
> > #
> > # See pf.conf(5) and /etc/examples/pf.conf
> >
> > set skip on lo
> >
> > block return# block stateless traffic
> > pass# establish keep-state
> > ===
> >
> > Reason? Solution?
>
> show the output of
>
>   pfctl -si
>   pfctl -sr
>   dmesg

pflog flooded with igmp queries

[Sonic]

The pflogs on my firewall and on a new system I'm installing (-current
with pretty much a default pf.conf) are flooded with igmp query
entries. Neither system has a log rule for such action.

Ex:
===
rule 1/(match) pass in on em1: 192.168.1.20 > 224.0.0.1: igmp query [ttl 1]
===

pf.conf:
===
#   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo

block return# block stateless traffic
pass# establish keep-state
===

Reason? Solution?

Thanks!

Re: VPN over alias address

[Sonic]

Adding the route to other side network from the alias address does work:
route add 192.168.99.0/24 50.79.22.45

On Sun, Oct 21, 2018 at 1:58 PM Sonic  wrote:
>
> On Mon, Oct 15, 2018 at 7:17 PM Stuart Henderson  wrote:
> > The problem is _not_ that your source address is 50.79.22.41,
> > because it wouldn't work with 50.79.22.45 either, you need to be
> > using an address that is covered by the flows (say 192.168.55.1).
> >
> > Try "ping -I $source_ip $dest_ip" with various addresses as $source_ip
> > and you should see better how it works.
>
> Using your ping example - it does work from the alias address of
> 50.79.22.45 and not from the other addresses.
>
> > The usual bodge around this is to have a local address within the
> > VPN'd network on your router (which is normally the case anyway -
> > with examples above, say 192.168.55.1) and add a route to the
> > "other side" network e.g."route add 192.168.99.0/24 192.168.55.1"
> > - i.e. using your *own* address as the destination).
>
> Adding the route does not resolve the issue.
> From a totally separate remote site, with no IP aliases on the ext_if
> it works just fine. No route add necessary.
>
> Chris

Re: VPN over alias address

[Sonic]

On Mon, Oct 15, 2018 at 7:17 PM Stuart Henderson  wrote:
> The problem is _not_ that your source address is 50.79.22.41,
> because it wouldn't work with 50.79.22.45 either, you need to be
> using an address that is covered by the flows (say 192.168.55.1).
>
> Try "ping -I $source_ip $dest_ip" with various addresses as $source_ip
> and you should see better how it works.

Using your ping example - it does work from the alias address of
50.79.22.45 and not from the other addresses.

> The usual bodge around this is to have a local address within the
> VPN'd network on your router (which is normally the case anyway -
> with examples above, say 192.168.55.1) and add a route to the
> "other side" network e.g."route add 192.168.99.0/24 192.168.55.1"
> - i.e. using your *own* address as the destination).

Adding the route does not resolve the issue.
>From a totally separate remote site, with no IP aliases on the ext_if
it works just fine. No route add necessary.

Chris

Re: VPN over alias address

[Sonic]

On Mon, Oct 15, 2018 at 5:09 PM Johan Hattne  wrote:
> Not sure I’m understanding your question, but is this not 
> application-dependent?  So for an internal interface mec0 and ssh, you could,
>
>   $ ssh -B mec0 f...@example.com
>
> and for ping,
>
>   $ ping -I mec0 example.com

The addresses in question are aliases of the same interface.
For example em1 might be configured with the following addresses:
50.79.22.41
50.79.22.42
50.79.22.43
50.79.22.44
50.79.22.45
I'm using different addresses on the same interface for different things.
In this example I have the ipsec vpn listening on 50.79.22.45 and a
similar setup on the other end - the non default address is the
listening address. Internal systems are working fine between the two
subnets, but the OpenBSD firewall itself (if I ping from it, for
example) uses the default address of 50.79.22.41 instead of
50.79.22.45 when attempting to connect to the remote network and
therefore is not successful. I'm fairly certain if there's a way to
configure the firewall to send using the chosen alias address instead
of the default address it would work properly.

Thanks,

Chris

VPN over alias address

[Sonic]

Have setup a site-to-site VPN using alias addresses which works fine
for systems inside the network, however, when attempting to connect
from the routers themselves to the remote network the fact that they
use the default address on the external interface and not the chosen
alias address appears to be preventing a connection.
How does one tell the router to use the chosen outbound alias address
instead of the default address when sending to the specific remote
network?

Thanks!
Chris

Re: Equipment for OBSD based firewall

[Sonic]

How does the Edgerouter compare in performance to an Atom 2358/2558
based system?
Especially interested in firewall performance using site-to-site VPN's.

On Mon, Sep 3, 2018 at 8:01 PM Jordan Geoghegan  wrote:
>
> On 09/03/18 16:17, Bogdan Kulbida wrote:
> > Ladies and gentlemen,
> >
> > I need to build a pf OBSD firewall for a small office. What minimally
> > feasible equipment would you recommend in order to achieve this goal?
> >
> > Thank you!
> I've ran multiple office networks on octeon devices. I've found the
> Edgerouter and Edgerouter Pro to be quite performant. The Edgerouter Pro
> can easily handle a 100/100 connection or even a 250/250 connection. I
> like them because they're free of any spectre / fpu bugs as they use an
> in-order CPU. OpenBSD also supports hw accelerated IPsec on them. I've
> used them to run DHCP and DNS servers, used them heavily as jump
> hosts/proxies and also ran my unbound-adblock and pf-badhost scripts;
> with over 100,000 domains and IP/CIDR blocks being filtered while
> pushing dozens of terrabytes in network traffic through them each month,
> they've proven to be rock solid. If you have modest needs, then an
> Edgerouter lite should suffice.
>
> Keep in mind, these are just my personal opinions, and I am biased. I
> can't stand the thought of having an x86 machine exposed on the open
> internet, much less trusting it to secure and segment my network. With
> spooky management engine shenanigans and hardware bugs abound, I'm just
> not interested in putting my faith in x86 again. Too much emotion, too
> much garbage.
>
> Cheers,
> Jordan
>

Re: Unsetting a DHCP option in dhcpd.conf(5)

[Sonic]

I suspect you can use groups, set it for a group and leave it out of
another group.

On Tue, Feb 27, 2018 at 12:55 PM, Grzegorz Kowalczyk
 wrote:
> Hi,
>
> can an option be unset in a host declaration of dhcpd.conf(5)?
>
> I'm trying to set a generic "option routers A.B.C.D" option in a
> subnet block and disable it in some host blocks.
>
> I've already skimmed through dhcpd.conf(5) and dhcp-options(5) man
> pages, to no avail.
>

Re: pf integration with dhcpd

[Sonic]

On Fri, Oct 27, 2017 at 2:48 PM, Carlos Cardenas  wrote:
> On a 6.2-syspatch box, I wanted to start leveraging the pf integration dhcpd

> pfctl -t dhcpd_X -T show

Do you see the current leases in "/var/db/dhcpd.leases"? A "reserved"
address would not show up there, nor would it be placed in the leased
table. Must truly be a dynamic lease.

Re: tmpfs

[Sonic]

On Tue, Aug 2, 2016 at 3:13 PM, Theo de Raadt  wrote:
> I see you have selected only the parts of my reply which suit you.
>
> The rest of my reply clearly stated we don't have people to do the
> work you want.
>
>> I doubt I'm the only non-developer who counts on that file to help
>> me keep from going astray in so many possible ways when attempting
>> to remain -current.
>
> You count on it?  The first paragraph tells you not to count on it!
>
> Basically you have no preperation, except counting on us doing
> something we say we won't do?

Yes, I counted on it. Again my mistake. Sorry for the noise.

Re: tmpfs

[Sonic]

On Tue, Aug 2, 2016 at 9:42 AM, Theo de Raadt  wrote:
> Whoa.  You haven't read the first paragraph of current.html, let me
> include it here:
>
> Active OpenBSD development is known as the -current branch. These
> sources are frequently compiled into releases known as
> snapshots. Active development sometimes pushes aggressive changes, and
> complications can arise when building the latest code from a previous
> point in time. Some of the shortcuts for getting over these hurdles
> are explained on this page. In general, it's far better to use the
> OpenBSD upgrade procedure with a newer snapshot, as developers will
> have gone through the trouble for you already.
>
> That purpose of the page is to help people "make build" through the
> most disruptive changes.
>
> You seem to believe it is for a different purpose -- to alert about removal
> of subsystems which are not critical for building through snapshots.

Yes, and admittedly my mistake. Although I have found current.html to
be quite valuable beyond getting past "make build", so in my defense
it's an easy mistake to make.
Take the last 4 entries. for example:
2016/05/28 - iwm(4) needs new firmware
2016/06/30 - doas.conf adjustment
2016/07/13 - [packages] OpenSMTPD-extras filters removal
2016/08/01 - new mandoc.db(5) format

Certainly all useful, but which of these, if any, would hamper a "make
build"? Possibly the doas.conf, but at least it will print a warning.
Is it possible that limiting the contents to just those items that
would prevent a "make build" might be a bit too restrictive (since it
really hasn't been done in the past)? I doubt I'm the only
non-developer who counts on that file to help me keep from going
astray in so many possible ways when attempting to remain -current.

Chris

Re: tmpfs

[Sonic]

I don't know why this thread got out of hand. But, as the OP I really
had just two points. One was that, like myself, there may have been
many others using tmpfs (due to the upbeat announcement of its
inclusion). And that two, there was no indication of its removal in
the "following -current" faq, as I (apparently incorrectly) thought it
might be important if your system doesn't either successfully reboot
or successfully mount all of your file systems after installing a new
kernel, especially hampering those upgrading remotely.

tmpfs

[Sonic]

I remember a bit of fanfare when tmpfs was enabled in OpenBSD -
http://undeadly.org/cgi?action=article=20131217081921 and at the
time switched from using mfs to tmpfs. At the time it appeared that
tmpfs solved some mfs issues. It seems we've come full circle and
noticed during a perusal of the cvs list that tmpfs is now disabled in
-current. However, there seems to be no mention of that in following
-current faq at https://www.openbsd.org/faq/current.html.

internet connection issues

[Sonic]

Have a client whose Internet connection is less then reliable. It's
cable service and the cable company always claims there is nothing
wrong on their end. Of course the service is intermittent and by the
time the onsite clerk calls the ISP it's usually back up and always by
the time they get someone sent out.

The problem is ongoing - it was a problem before I took over the
account, and is still a problem even though the previous firewall has
been replaced with a shiny OpenBSD box and the previous rented cable
modem has also been replaced with a shiny new Arris model (separated
by a few months).

I discovered that when the problem occurs I (of course) cannot connect
to the firewall remotely, nor can I ping it. However I can ping the
gateway node. Which to me says the problem is between the ISP gateway
node and the cable modem. Two cable modems with the same issue lead me
to discount them as the problem, and two firewalls with the same
problem are a bit far fetched as well. Plus the OpenBSD firewall logs
no errors, either in dmesg or any other log file.

I would like to be able to provide a way to document the outage no
matter when it occurs both via some job running on the firewall and a
job running remotely - to be positive that when the Internet cannot be
seen from the firewall the problem is at the suspected gateway node
and that at the same time the remote job can verify that the gateway
node can be seen but the firewall cannot, creating logs in both
systems only during the outage times. All of this possibly under the
mistaken idea that I can actually get WOW to repair their service.

Would like some suggestions on ways to about this.

Thanks,

Chris

sendsyslog error 57

[Sonic]

Running -current (OpenBSD 6.0-beta (GENERIC.MP) #7: Wed Jun  1
10:21:47 EDT 2016) the following gets logged on every boot:

sendsyslog: dropped 3 messages, error 57

Chris

Re: ntpd tries to connect via ipv6

[Sonic]

On Tue, May 31, 2016 at 1:04 PM, Stefan Wollny  wrote:
> I asked this just last week.

Indeed! Sorry I missed it.

Thanks all!

ntpd tries to connect via ipv6

[Sonic]

Getting many such log entries:
===
May 31 08:53:34 stargate ntpd[5702]: tls connect failed:
2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host
May 31 09:08:35 stargate ntpd[15803]: tls connect failed:
2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host
May 31 09:23:36 stargate ntpd[92515]: tls connect failed:
2607:f8b0:4009:808::2004 (www.google.com): connect: No route to host
===

ntpd.conf has the line: constraints from "https://www.google.com;

System has no ipv6 addresses. Unbound is resolving DNS server with "do-ip6: no".

resolv.conf uses "nameserver 127.0.0.1" (Unbound serving on this address)

normal lookups (dig) only return the ipv4 address for www.google.com

Why does ntpd attempt to connect on an ipv6 address?

Thanks,

Chris

Re: Supermicro X11SSL-F freezes probing USB 3

[Sonic]

On Tue, Mar 29, 2016 at 5:55 PM, Stuart Henderson  wrote:
> Make sure it's set to stop redirecting after boot in BIOS, then when
> you hit the boot-loader, you should be able to 'stty com0 ' and
> 'set tty com0'.

Ahha! Who would have thought... com0 was the ticket. Thanks much!

Chris

Re: Supermicro X11SSL-F freezes probing USB 3

[Sonic]

On Tue, Mar 29, 2016 at 9:13 PM, Paul B. Henson  wrote:
> Hmm, that sounds broken. Are you sure you've got the right serial port
> and baud rate? Once you switch the boot loader to serial, it's no longer
> a matter of "forwarding", it's direct serial access as far as the
> bootloader/OS is concerned. The BIOS forwarding piece is out of the
> picture. Unless your IPMI serial port implementation is broken you've
> probably got the wrong settings.

The IPMI is part of Dell's iDRAC stuff and the only thing I've found
on the net is that iDRAC 9 is needed for proper SOL access and this
system has the previous generation - iDRAC 8. I actually had tried
both serial ports for SOL which is why I think it's just broken. It
may be the iDRAC license level as well, anything above the "basic"
level, providing a limited feature set, requires purchasing a license
key. All of my other firewalls are using Supermicro boxes and the IPMI
works just fine on them. Unfortunately the client didn't listen to my
purchase suggestions. I don't want to become an iDRAC guru, just want
to install OpenBSD without wrestling alligators :-)

Re: Supermicro X11SSL-F freezes probing USB 3

[Sonic]

On Tue, Mar 29, 2016 at 6:15 PM, Paul B. Henson  wrote:
> stty com1 115200
> set tty com1

Yes, tried that with no luck, SOL still stops forwarding. The box does
have a physical serial port, so I ordered a serial to USB adapter
cable (don't have any other systems left with serial ports) that I'm
hoping will work for the install. Once I'm installed I can probably
rely on ssh for everything. But there's always some possible problem
that it would be nice to be able to plug in a keyboard and monitor to
work with.

Chris

Re: Supermicro X11SSL-F freezes probing USB 3

[Sonic]

On Mon, Mar 28, 2016 at 9:48 PM, Paul B. Henson  wrote:
> I'm installing via an IPMI virtual serial port so the lack
> of keyboard isn't really an issue for me,

Unfortunately that option isn't available for me. The IPMI SOL on this
Dell stops forwarding the console once the system boots.

This problem was reported by another user to "bugs" back on Feb. 9th,
but I don't know if any action was ever taken.

Chris

Re: Supermicro X11SSL-F freezes probing USB 3

[Sonic]

On Mon, Mar 28, 2016 at 9:48 PM, Paul B. Henson  wrote:
> Could I trouble you to be more specific as to the duration of "long
> enough" :)? I think my patience ran out after about 15-20 minutes.

I think it was just around that - 15 or 20 minutes, but I really
didn't time it. I had given up earlier on previous attempts and then
started to research the issue assuming the system would stay "frozen"
and when I turned around it had booted. However the keyboard was dead
so the install could not continue.

> So it
> eventually boots without disabling xhci, but the USB doesn't work in the
> end anyway?

I think that xhci is disabled (one way or the other). My guess is that
attempting to load the driver eventually times out (or crashes) and
the boot process finally continues.

> I'm installing via an IPMI virtual serial port so the lack
> of keyboard isn't really an issue for me, I can live without USB but as
> the box won't be going live for a few weeks I thought I'd see if any
> devs wanted me to try anything on it before I just moved forward without
> USB support. I've got -current set up to ready to patch and compile to
> test stuff on it if I can. It would be nice to get it working for
> situations like yours where it's needed.

Agreed :-) Would love to see this working!

Chris

Re: Supermicro X11SSL-F freezes probing USB 3

[Sonic]

On Mon, Mar 28, 2016 at 2:36 PM, Sonic <sonicsm...@gmail.com> wrote:
> Exact same problem here with a Dell PowerEdge R230 and snapshot
> downloaded today.

If I wait long enough the install will finally finish booting but the
keyboard (no ps2 ports) doesn't work.

Disabling xhci via UKC on boot also kills the keyboard.

Chris

Re: Supermicro X11SSL-F freezes probing USB 3

[Sonic]

On Mon, Mar 7, 2016 at 12:48 AM, Paul B. Henson  wrote:
 xhci probe won
> xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x31: msi
 probing for usb*
 usb probe returned 1
 usb probe won
> usb0 at xhci0: USB revision 3.0
 probing for uhub*
 uhub probe returned 10
 uhub probe won
> uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
> [system freezes here]

Exact same problem here with a Dell PowerEdge R230 and snapshot
downloaded today.

Chris

Re: mongodb

[Sonic]

On Fri, Nov 22, 2013 at 5:18 PM, Chris Smith  wrote:
> Wondering if mongodb is operational with -current?

Reviving old thread. Mongodb, yes, no?

Thanks,

Chris

Re: ftp-proxy man page out of date?

[Sonic]

On Mon, Jan 4, 2016 at 1:04 PM, Jason McIntyre  wrote:
> these are dynamically inserted rules.  and they must be
> redirects.  so you don't have to change them.  divert-to
> would be incorrect.

Divert-to is the proper way to send the packets to the proxy, but the
dynamic rules that the proxy creates use rdr-to which is why the man
page may appear a bit confusing at first reading.

Re: High interrupt load using 5.8 Release GENERIC i386 on Acer Aspire 3630 laptop

[Sonic]

No clue if it's related but I recently built a new firewall with a
Supermicro SYS-5018A-MLTN4 and see an unusually high interrupt load
(none of my other systems have exhibited this issue).

load averages:  0.08,  0.12,  0.10
   firewall.example.com 14:59:42
38 processes: 37 idle, 1 on processor
   up 22 days,  1:30
CPU0 states:  0.0% user,  0.0% nice,  0.4% system, 61.1% interrupt, 38.5% idle
CPU1 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU2 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU3 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Memory: Real: 66M/467M act/tot Free: 15G Cache: 295M Swap: 0K/11G

OpenBSD 5.8-current (GENERIC.MP) #0: Sat Dec 12 18:43:09 EST 2015
   r...@firewall.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17148784640 (16354MB)
avail mem = 16624930816 (15854MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4ce000 (57 entries)
bios0: vendor American Megatrends Inc. version "1.2a" date 04/14/2015
bios0: Supermicro A1SAM-2550F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT SPMI MCFG WDAT UEFI APIC BDAT HPET SSDT
HEST BERT ERST EINJ
acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.44 MHz
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP
,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-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.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP
,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
cpu2: 
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP
,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
cpu3: 
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP
,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (BR18)
acpiprt3 at acpi0: bus 3 (PEX2)
acpiprt4 at acpi0: bus -1 (BR1A)
acpiprt5 at acpi0: bus 4 (PEX3)
acpiprt6 at acpi0: bus -1 (PEX4)
acpicpu0 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2400 MHz: speeds: 2401, 2400, 2300, 2200,
2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Atom C2000 Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "ASPEED Technology AST1150 PCI" rev 0x03
pci2 at ppb1 bus 2
vga1 at pci2 dev 0 function 0 "ASPEED Technology AST2000" rev 0x30
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb2 at pci0 dev 2 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 3 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci4 at ppb3 bus 4
pchb1 at pci0 dev 14 function 0 "Intel Atom C2000 RAS" rev 0x02
"Intel Atom 

pax: pledge: Invalid argument

[Sonic]

-current not building:

./icdb.h -> ./icdb.ph
pax: pledge: Invalid argument
*** Error 1 in gnu/usr.bin/perl (Makefile.bsd-wrapper:112 'install')
*** Error 2 in gnu/usr.bin (:48 'realinstall')
*** Error 2 in gnu (:48 'realinstall')
*** Error 2 in . (:48 'realinstall')
*** Error 2 in /usr/src (Makefile:82 'build')

Re: pax: pledge: Invalid argument

[Sonic]

On Mon, Dec 7, 2015 at 2:41 PM, Theo de Raadt  wrote:
> Your mistake.

Yes, my mistake. Sorry for the noise.

Re: serious watchdog timeout issues with em driver

[Sonic]

On Fri, Nov 20, 2015 at 8:12 AM, Martin Pieuchot  wrote:
> I just committed a revert to 1.305 keeping the API changes needed for
> the driver to build.
>
> This should bring your stability back, please let us know if that's not
> the case.

The kernel/driver builds with those changes but crashes on startup
(hadn't rebuilt userland yet). Couldn't see much when it happened, I
believe it was just after starting the network, and there was some
Xsoft... error and then what I would describe as a core dump to the
console. No footprints seem to be left after a power reset and booting
into obsd.

Thanks,

Chris

Re: serious watchdog timeout issues with em driver

[Sonic]

On Fri, Nov 20, 2015 at 12:37 PM, Mark Kettenis  wrote:
> Thanks Martin.

All is fine now. System booted with no errors and no watchdog timeouts.

Thanks to all.

Chris

serious watchdog timeout issues with em driver

[Sonic]

Have serious problems for over 7 weeks now with em driver,
specifically any rev of if_em.c >  1.305. Starting with rev 1.306,
released on 2015/09/30 and continuing to -current, watchdog timeouts
rue the day. Unfortunately rev 1.305 no longer builds with -current as
it appears the patch in rev 1.309 would be necessary.

System in question is a NAT firewall, also running Unbound and DHCPD.
Timeouts occur randomly and can affect both internal and external
interfaces. But use of a bittorrent app on an internal client system
will always trigger many such timeouts:

Nov 18 12:21:17 stargate /bsd: em0: watchdog timeout -- resetting
Nov 18 12:21:17 stargate /bsd: em1: watchdog timeout -- resetting
Nov 18 12:22:34 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:22:34 stargate unbound: [12687:1] notice: remote address is
172.27.12.11 port 55181
Nov 18 12:22:36 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:22:36 stargate unbound: [12687:1] notice: remote address is
172.27.12.253 port 54266
Nov 18 12:22:36 stargate unbound: [22477:0] notice: sendto failed: No buffer
space available
Nov 18 12:22:36 stargate unbound: [22477:0] notice: remote address is
172.27.12.253 port 53257
Nov 18 12:22:37 stargate /bsd: em0: watchdog timeout -- resetting
Nov 18 12:23:42 stargate /bsd: em0: watchdog timeout -- resetting
Nov 18 12:28:11 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:28:11 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 56045
Nov 18 12:28:12 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:28:12 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 41975
Nov 18 12:28:12 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:28:12 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 48603
Nov 18 12:28:12 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:28:12 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 17834
Nov 18 12:28:13 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:28:13 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 1177
Nov 18 12:28:14 stargate unbound: [12687:1] notice: sendto failed: No buffer
space available
Nov 18 12:28:14 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 39013
Nov 18 12:28:15 stargate /bsd: em0: watchdog timeout -- resetting
Nov 18 12:29:42 stargate /bsd: em0: watchdog timeout -- resetting
Nov 18 14:00:01 stargate syslogd: restart
Nov 18 16:00:01 stargate syslogd: restart
Nov 19 12:00:01 stargate syslogd: restart
Nov 19 16:00:01 stargate syslogd: restart
Nov 19 16:08:36 stargate /bsd: em0: watchdog timeout -- resetting
Nov 19 16:10:34 stargate /bsd: em0: watchdog timeout -- resetting
Nov 19 16:15:04 stargate /bsd: em0: watchdog timeout -- resetting
Nov 19 16:19:55 stargate last message repeated 3 times

(one of the above is on the external interface em1)

The timeouts don't just shutdown net access during the reset time,
other problems occur. Many time the SSH server no longer accepts
connections so shelling into the system is not an option:

$ ssh stargate
write: Connection reset by peer


I've also had a system crash that I suspect (no proof at all and
thankfully it hasn't re-occurred, but timing is everything) was caused
by the faulty em driver:

Nov  1 22:23:55 stargate /bsd: uvm_fault(0x818f9920,
0xfff7818adf60, 0, 1) -> e
Nov  1 22:23:55 stargate /bsd: fatal page fault in supervisor mode
Nov  1 22:23:55 stargate /bsd: trap type 6 code 0 rip 81329e69
cs 8 rflags 10286 cr2  fff7818adf60 cpl 7 rsp 8000221df76
0
Nov  1 22:23:55 stargate /bsd: panic: trap type 6, code=0, pc=81329e69
Nov  1 22:23:55 stargate /bsd: Starting stack trace...
Nov  1 22:23:55 stargate /bsd: panic() at panic+0x10b
Nov  1 22:23:55 stargate /bsd: trap() at trap+0x7b8
Nov  1 22:23:55 stargate /bsd: --- trap (number 6) ---
Nov  1 22:23:55 stargate /bsd: trap() at trap+0x709
Nov  1 22:23:55 stargate /bsd: --- trap (number 4) ---
Nov  1 22:23:55 stargate /bsd: trap() at trap+0x709
Nov  1 22:23:55 stargate /bsd: --- trap (number 4) ---
Nov  1 22:23:55 stargate /bsd: bpf_filter() at bpf_filter+0x19b
Nov  1 22:23:55 stargate /bsd: _bpf_mtap() at _bpf_mtap+0xf4
Nov  1 22:23:55 stargate /bsd: bpf_mtap_ether() at bpf_mtap_ether+0x39
Nov  1 22:23:55 stargate /bsd: em_start() at em_start+0xd6
Nov  1 22:23:55 stargate /bsd: nettxintr() at nettxintr+0x52
Nov  1 22:23:55 stargate /bsd: softintr_dispatch() at softintr_dispatch+0x8b
Nov  1 22:23:55 stargate /bsd: Xsoftnet() at 

Re: em(4) watchdog timeouts

[Sonic]

On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best  wrote:
> I've done some further testing and I think I've narrowed it down to the
> "Unlocking em(4) a bit further"-patch [0].

That was the start of it for me.

When I could revert to rev 1.305 for if_em.c and rev 1.57 for if_em.h
all was fine. But the kernel no longer builds with if_em.c rev 1.305
due to:
cc1: warnings being treated as errors
../../../../dev/pci/if_em.c: In function 'em_ioctl':
../../../../dev/pci/if_em.c:674: warning: implicit declaration of function
'arp_ifinit'
*** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:937
'if_em.o')

I'm wondering if the patch that moved if_em.c from rev 1.308 to rev
1.309 could be applied to rev 1.305 and if that would the kernel to
build and work?

These timeouts are killing me.
Nov 13 08:21:11 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:47:36 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:47:36 stargate unbound: [22477:0] notice: sendto failed: No
buffer space available
Nov 13 09:47:36 stargate unbound: [22477:0] notice: remote address is
172.27.12.66 port 34281
Nov 13 09:47:36 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 34281
Nov 13 09:47:37 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:49:42 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:51:55 stargate unbound: [22477:0] notice: sendto failed: No
buffer space available
Nov 13 09:51:55 stargate unbound: [22477:0] notice: remote address is
172.27.12.66 port 57280
Nov 13 09:52:00 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:53:18 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:54:32 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:54:32 stargate unbound: [22477:0] notice: sendto failed: No
buffer space available
Nov 13 09:54:32 stargate unbound: [22477:0] notice: remote address is
172.27.12.66 port 57438
Nov 13 09:54:32 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 57438
Nov 13 09:54:35 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:55:54 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 09:58:08 stargate last message repeated 2 times
Nov 13 09:58:53 stargate /bsd: em1: watchdog timeout -- resetting
Nov 13 09:59:05 stargate ftp-proxy[18455]: #1 client command too long
or not clean
Nov 13 09:59:09 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:59:09 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 22970
Nov 13 09:59:09 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:59:09 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 60307
Nov 13 09:59:11 stargate unbound: [12687:1] notice: sendto failed: No
buffer space available
Nov 13 09:59:11 stargate unbound: [12687:1] notice: remote address is
172.27.12.66 port 41198
Nov 13 09:59:11 stargate /bsd: em0: watchdog timeout -- resetting
Nov 13 10:01:15 stargate /bsd: em0: watchdog timeout -- resetting

Chris

Re: dhcpd exiting with strange error message.

[Sonic]

On Sun, Nov 8, 2015 at 3:35 PM, Jeremy  wrote:
> No I only have one instance running.
>
> # ps aux | grep dhcp
> _dhcp 7784  0.0  0.1   756  1340 ??  Ss 9:00AM0:00.00 
> /usr/sbin/dhcpd em0

Interesting a bit that the log shows two different PID's - it changes
between 08:25:34 and 08:25:46.
=
Nov  6 08:25:34 janus dhcpd[11758]: DHCPACK on 192.168.7.36 to
b4:ae:2b:2f:b6:bf via em0
Nov  6 08:25:46 janus dhcpd[24427]: Can't open f: No such file or directory
=

Not sure of the "Can't open f:", besides the config file there's the
/var/db/dhcpd.leases file.

And I believe that the reserved address pool should be outside the
dynamic range.

Your:
host DocuCentre {
fixed-address 192.168.7.100;
}

Is inside the dynamic range:
range 192.168.7.32 192.168.7.127;

And for a little clean up you may want to place reservations in their
own group. Example:
===
subnet 192.168.7.0 netmask 255.255.255.0 {
option routers 192.168.7.1;
range 192.168.7.32 192.168.7.127;
allow-unknown-clients;
}
group {
deny unknown-clients;
default-lease-time 36;

host DocuCentre {
fixed-address 192.168.7.200;
}
}
===
Notice that with the new address the DocuCentre's IP address is
outside the dynamic lease range. Plus you give those "static" devices
longer lease times.

And for an added heads up - if you're really using the 192.168.1.0/24
subnet I highly suggest changing it, as conflicts may eventually arise
with phones, tablets, laptops, etc joining your network and creating a
temporary duplicate IP issue due to the fact that subnet, and a few
others, are the default subnets on a multitude of home routers. Had
one case where a worker would take the server offline the minute she
pulled into the parking lot as her cell phone had the same IP address
as the server when it initially connected to the wifi.

Chris

Re: em(4) watchdog timeouts

[Sonic]

On Wed, Nov 4, 2015 at 2:51 PM, Sonic <sonicsm...@gmail.com> wrote:
> Is there anything else I can provide to assist in finding a cure for this 
> issue?

Not sure this helps at all but the specific error I get is "em0:
watchdog timeout -- resetting". In this case em0 is the nic on the
internal network. I do not see the errors on the external network nic
(em1) which connects to the cable modem. The internal network nic
(em0) connects directly to an HP 2520 switch.

# dmesg |grep em1
em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:92:d4:f9
spdmem1 at iic0 addr 0x51: 2GB DDR3 SDRAM PC3-10600 SO-DIMM
# dmesg |grep em0
em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:92:d4:f8
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600 SO-DIMM
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting
em0: watchdog timeout -- resetting

Chris

Re: em(4) watchdog timeouts

[Sonic]

On Mon, Nov 2, 2015 at 11:19 PM, Sonic <sonicsm...@gmail.com> wrote:
> Sorry to report that the diff does not solve the timeout problem here.
>
> All was working fine with the if_em* versions from 2015/09/29 (I
> downgraded to this version per Stuarts post on 10-14):
> "try backing out the last commits to
> if_em.c and if_em.h ("cd /sys/dev/pci; cvs up -D 2015/09/29 if_em*") to
> see if it makes a difference."
>
> However, that version no longer compiles with -current and the
> watchdog timeouts are back (even with the diff).

Is there anything else I can provide to assist in finding a cure for this issue?
I get sporadic timeouts even under normal usage, but starting a
bittorrent on a client brings the firewall to its knees. And as all
the firewalls I manage use the em driver I cannot take a chance on
upgrading any of them to -current.

Thank you,

Chris

Re: /bsd: em0: watchdog timeout -- resetting

[Sonic]

On Mon, Oct 5, 2015 at 10:41 AM, Theo de Raadt  wrote:
>> On Sun, Oct 4, 2015 at 12:00 PM, Stuart Henderson  
>> wrote:
>> > I'm hoping it isn't this, but please try backing out the last commits to
>> > if_em.c and if_em.h ("cd /sys/dev/pci; cvs up -D 2015/09/29 if_em*") to
>> > see if it makes a difference.
>>
>> Same issue here. Reverting now and will post if problem resurfaces.
>
> The snapshots contain an uncommited diff in the same direction as that
> em commit.  Problem is unknown.  Few more days, still trying to learn
> what is amiss, and not stall out the promised advancement.

Problem has returned in -current (could no longer keep the em driver
at that revision and get a successful build).

Chris

Re: crash with -current

[Sonic]

On Mon, Nov 2, 2015 at 12:19 PM, Martin Pieuchot  wrote:
> Do you have an idea how to reproduce this crash?  Which program are you
> running that uses bpf?

Not using bpf at all (that I know of), just a straightforward firewall
- pf, dhcpd, unbound.

The nasty little "em0: watchdog timeout -- resetting", reported on
10-4-15 bug is also back - triggered by using a bittorrent client on
one of my desktops. The above reported crash happened while streaming
some Netflix. I'm inclined to suspect the em driver is hosed again.

Chris

Re: Watchdog timeouts with em on recent snapshots

[Sonic]

On Sun, Nov 1, 2015 at 12:11 PM, Gregor Best  wrote:
> I just upgraded one of my routers to todays snapshot and I'm seeing
>
> em0: watchdog timeout -- resetting

I'm seeing these again (reported on 10-4-15) after upgrading to -current.

Chris

Re: em(4) watchdog timeouts

[Sonic]

On Mon, Nov 2, 2015 at 3:29 PM, Gregor Best  wrote:
> On Mon, Nov 02, 2015 at 08:11:30PM +0100, Mark Kettenis wrote:
>> Can those that are experiencing watchdog timeouts check if the diff
>> below gets rid of them?
>> [...]

Hello,

For whatever reason I see this reply but not the original post
containing the actual patch.

Thank you,

Chris

Re: em(4) watchdog timeouts

[Sonic]

On Mon, Nov 2, 2015 at 2:11 PM, Mark Kettenis  wrote:
> Can those that are experiencing watchdog timeouts check if the diff
> below gets rid of them?

Sorry to report that the diff does not solve the timeout problem here.

All was working fine with the if_em* versions from 2015/09/29 (I
downgraded to this version per Stuarts post on 10-14):
"try backing out the last commits to
if_em.c and if_em.h ("cd /sys/dev/pci; cvs up -D 2015/09/29 if_em*") to
see if it makes a difference."

However, that version no longer compiles with -current and the
watchdog timeouts are back (even with the diff).

$ dmesg
OpenBSD 5.8-current (GENERIC.MP) #12: Mon Nov  2 20:29:08 EST 2015
   r...@stargate.grizzly.bear:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277665792 (4079MB)
avail mem = 4143894528 (3951MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f000 (19 entries)
bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
bios0: Supermicro X7SPA-HF
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4)
USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S
4) P0P5(S4) P0P6(S4) P0P7(S4) [...]
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) Atom(TM) CPU D525 @ 1.80GHz, 1800.24 MHz
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,DTES64
,MWAIT,DS-CPL,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 199MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 MHz
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,DTES64
,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 3
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 18
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 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:92:d4:f8
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:92:d4:f9
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 19
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci4 at ppb3 bus 4
vga1 at pci4 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3
0/direct fixed naa.5001517959323666
sd0: 76319MB, 512 bytes/sector, 156301488 sectors, thin
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 3 int 18
iic0 at ichiic0
lm1 at iic0 addr 0x2d: W83627DHG
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600 SO-DIMM
spdmem1 at iic0 addr 0x51: 2GB DDR3 SDRAM PC3-10600 SO-DIMM
usb2 at uhci0: USB revision 

crash with -current

[Sonic]

Upgraded -current earlier today, and system has crashed:
=
Nov  1 22:23:55 stargate /bsd: uvm_fault(0x818f9920,
0xfff7818adf60, 0, 1) -> e
Nov  1 22:23:55 stargate /bsd: fatal page fault in supervisor mode
Nov  1 22:23:55 stargate /bsd: trap type 6 code 0 rip 81329e69
cs 8 rflags 10286 cr2  fff7818adf60 cpl 7 rsp 8000221df76
0
Nov  1 22:23:55 stargate /bsd: panic: trap type 6, code=0, pc=81329e69
Nov  1 22:23:55 stargate /bsd: Starting stack trace...
Nov  1 22:23:55 stargate /bsd: panic() at panic+0x10b
Nov  1 22:23:55 stargate /bsd: trap() at trap+0x7b8
Nov  1 22:23:55 stargate /bsd: --- trap (number 6) ---
Nov  1 22:23:55 stargate /bsd: trap() at trap+0x709
Nov  1 22:23:55 stargate /bsd: --- trap (number 4) ---
Nov  1 22:23:55 stargate /bsd: trap() at trap+0x709
Nov  1 22:23:55 stargate /bsd: --- trap (number 4) ---
Nov  1 22:23:55 stargate /bsd: bpf_filter() at bpf_filter+0x19b
Nov  1 22:23:55 stargate /bsd: _bpf_mtap() at _bpf_mtap+0xf4
Nov  1 22:23:55 stargate /bsd: bpf_mtap_ether() at bpf_mtap_ether+0x39
Nov  1 22:23:55 stargate /bsd: em_start() at em_start+0xd6
Nov  1 22:23:55 stargate /bsd: nettxintr() at nettxintr+0x52
Nov  1 22:23:55 stargate /bsd: softintr_dispatch() at softintr_dispatch+0x8b
Nov  1 22:23:55 stargate /bsd: Xsoftnet() at Xsoftnet+0x1f
Nov  1 22:23:55 stargate /bsd: --- interrupt ---
Nov  1 22:23:55 stargate /bsd: end of kernel
Nov  1 22:23:55 stargate /bsd: end trace frame: 0xff8132b494, count: 246
Nov  1 22:23:55 stargate /bsd: 0x282:
Nov  1 22:23:55 stargate /bsd: End of stack trace.
=
# dmesg
OpenBSD 5.8-current (GENERIC.MP) #8: Sun Nov  1 13:10:37 EST 2015
r...@stargate.grizzly.bear:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277665792 (4079MB)
avail mem = 4143894528 (3951MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f000 (19 entries)
bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
bios0: Supermicro X7SPA-HF
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4)
USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4)
P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) [...]
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) Atom(TM) CPU D525 @ 1.80GHz, 1800.23 MHz
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,DTES64,MWAIT,DS-CPL,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 200MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.01 MHz
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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 3
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 18
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 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:92:d4:f8
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:25:90:92:d4:f9
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 19
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 18
ehci1 

error compiling -current kernel if_em.c

[Sonic]

Hello, I'm getting this error during -current kernel compile, x64:

ci/if_em.c
cc1: warnings being treated as errors
../../../../dev/pci/if_em.c: In function 'em_ioctl':
../../../../dev/pci/if_em.c:674: warning: implicit declaration of
function 'arp_ifinit'
*** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP
(Makefile:937 'if_em.o')

Chris

Re: error compiling -current kernel if_em.c

[Sonic]

it was due to the fact that I backed out revision 1.305 that caused
annoying watchdog timeouts and loss of network connectivity with em0
earlier this month

ok now, thanks


On Sat, Oct 31, 2015 at 5:52 PM, Ossi Herrala <oherr...@gmail.com> wrote:
> On Sat, Oct 31, 2015 at 05:00:51PM -0400, Sonic wrote:
>> Hello, I'm getting this error during -current kernel compile, x64:
>>
>> ci/if_em.c
>> cc1: warnings being treated as errors
>> ../../../../dev/pci/if_em.c: In function 'em_ioctl':
>> ../../../../dev/pci/if_em.c:674: warning: implicit declaration of
>> function 'arp_ifinit'
>> *** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP
>> (Makefile:937 'if_em.o')
>>
>
> This should have been fixed in if_em.c 1.309.
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_em.c.diff?r1=1.308=1.309
>
>
> --
> Ossi Herrala

Re: syslogd: Syscall 28 (SYS_sendmsg) in 18 October (i386) snapshot

[Sonic]

On Sun, Oct 18, 2015 at 3:22 PM, Scott Vanderbilt  wrote:
> Another pledge(2) related issue, this time in syslogd.

No clue if my bug is related. Attempting to upgrade -current today and I get:
Oct 18 14:29:39 stargate /bsd: ksh(4880): syscall 131
Oct 18 14:29:46 stargate /bsd: ksh(30776): syscall 131
etc.

This is after installing the new kernel and rebooting to build
userland (it may just be an out of sync issue).
However after the reboot, I cannot login as root, I can login as a
user, but cannot "su -", although I can "su" (no dash). Also cannot
run tmux, it crashes.
I've reinstalled the old kernel to get back in sync with the userland.

Chris

Re: requesting help working around boot failures with supermicro atom board

[Sonic]

On Mon, Oct 5, 2015 at 1:18 PM, dewey.hyl...@gmail.com
 wrote:
> but their non-support of this brand-new motherboard

When the other OS's work fine is does seem to point to an OpenBSD
issue, but that's not always a reliable conclusion to arrive at.
Either way it would be nice to see it resolved.

There was a time when the problem did not exist, but it's been so long
that I have no clue any longer when the change occurred that triggered
the issue.

Chris

Re: /bsd: em0: watchdog timeout -- resetting

[Sonic]

ub6 at usb6 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb7 at uhci5: USB revision 1.0
uhub7 at usb7 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25
uhidev0 at uhub4 port 2 configuration 1 interface 0 "Winbond
Electronics Corp Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub4 port 2 configuration 1 interface 1 "Winbond
Electronics Corp Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev2 at uhub5 port 2 configuration 1 interface 0 "Logitech USB
Keyboard" rev 1.10/64.00 addr 2
uhidev2: iclass 3/1
ukbd1 at uhidev2: 8 variable keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhidev3 at uhub5 port 2 configuration 1 interface 1 "Logitech USB
Keyboard" rev 1.10/64.00 addr 2
uhidev3: iclass 3/0, 3 report ids
uhid0 at uhidev3 reportid 1: input=1, output=0, feature=0
uhid1 at uhidev3 reportid 2: input=1, output=0, feature=0
uhid2 at uhidev3 reportid 3: input=3, output=0, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (67f54d511ac3222d.a) swap on sd0b dump on sd0b

On Mon, Oct 5, 2015 at 1:50 PM, Martin Pieuchot <m...@openbsd.org> wrote:
> On 05/10/15(Mon) 10:35, Sonic wrote:
>> On Sun, Oct 4, 2015 at 12:00 PM, Stuart Henderson <s...@spacehopper.org> 
>> wrote:
>> > I'm hoping it isn't this, but please try backing out the last commits to
>> > if_em.c and if_em.h ("cd /sys/dev/pci; cvs up -D 2015/09/29 if_em*") to
>> > see if it makes a difference.
>>
>> Same issue here. Reverting now and will post if problem resurfaces.
>
> Dmesg please.

Re: /bsd: em0: watchdog timeout -- resetting

[Sonic]

On Sun, Oct 4, 2015 at 12:00 PM, Stuart Henderson  wrote:
> I'm hoping it isn't this, but please try backing out the last commits to
> if_em.c and if_em.h ("cd /sys/dev/pci; cvs up -D 2015/09/29 if_em*") to
> see if it makes a difference.

Same issue here. Reverting now and will post if problem resurfaces.

Re: /bsd: em0: watchdog timeout -- resetting

[Sonic]

On Mon, Oct 5, 2015 at 10:54 AM, Josh Grosse  wrote:
> I'm using the em(4) NIC as a vlandev, which may be a contributing factor.

Nothing special here, using OpenBSD as a simple IPV4 firewall/router,
no VLAN's etc.

Last -current update was on the 3rd (October) and it appeared to work
fine, even streaming video via HBO Now and Netflix, but when I fired
up a bittorrent client on my desktop system (Linux) this morning I
soon lost connectivity with this error. After rebooting the error
occurred once again after restarting the bittorrent client. Rebooted
again and didn't restart the bittorrent client until after I reverted
the em patches and rebooted. No issues since then.

Basically the use of of a bittorrent client on an internal systems
triggered the issue for me, and in short order.

Chris

Re: requesting help working around boot failures with supermicro atom board

[Sonic]

Any progress on this issue?

On Thu, Sep 17, 2015 at 1:26 PM, Mike Larkin  wrote:
> On Thu, Sep 17, 2015 at 12:40:12PM +, Dewey Hylton wrote:
>> Dewey Hylton  gmail.com> writes:
>>
>> >
>> > Mike Larkin  azathoth.net> writes:
>> >
>> > >
>> > > On Tue, Sep 15, 2015 at 07:16:40PM +, Dewey Hylton wrote:
>> > > > Dewey Hylton  gmail.com> writes:
>> > > >
>> > > > >
>> > > > > Mike Larkin  azathoth.net> writes:
>> > > >
>> > > > > > acpidump please.
>>
>> > motherboard: supermicro x7spe-hf-d525 rev 1.0
>> > bios: 1.2b
>> >
>> > at the end of this link is an archive containing acpidump output for all
>> > three acpi settings in the bios (1.0, 2.0, 3.0).
>> >
>> > https://goo.gl/tWGL6C
>> >
>> > i apologize for the somewhat hidden link; gmane wouldn't allow me to post
>> > the full link because it's greater than 80 characters.
>> >
>> > please let me know if i can help in any way; i honestly know nothing about
>> > acpi but am willing to learn or assist otherwise if it means understanding
>> > and potentially fixing this issue.
>>
>> i was able to export the DSDT files into something human-readable. while i
>> don't really understand much of what i'm seeing in the resulting text files,
>> diff shows that the differences between the three acpi versions are
>> nonexistent. i have no idea about the other files, of which there are 
>> several.
>>
>> Mike, does the acpidump output help at all? if not, am i simply at the point
>> where this hardware is not compatible with OpenBSD?
>>
>
> Haven't had a chance to look at it yet.
>
> -ml