Re: Bind address for wireguard

[Janne Johansson]

Den tis 29 aug. 2023 kl 17:10 skrev Samuel Jayden :
> Is it possible to bind source address on wireguard as the source address of
> the connection?
> Thanks.

There isn't such an option now, outgoing udp will choose the interface
which currently is deemed "best" on which the destination IP can be
reached. If you search with google, you will find similar questions on
the wireguard mail list from many years ago, and similar answers.

-- 
May the most significant bit of your life be positive.

Bind address for wireguard

[Samuel Jayden]

Hello misc@,

Is it possible to bind source address on wireguard as the source address of
the connection?
Thanks.

P.S. In fact this is a feature request. It's not too suitable for work
arounds.
Yeah, someone can say "use vrf", "use route command for the destination ip
address of the wireguard's remote endpoint".
But when I use workarounds like that  I have always had other, also bigger
issues.
So simply found out that binding source address will be a life saver.

bind(2) documentation about the socklen_t parameter

[Alejandro Colomar]

Hi Ingo,

I'm modifying some Unix sockets code to add support for abstract sockets 
(in Linux only, of course), and while I (mostly) know how bind(2) works, 
I've found surprising that none of the bind(2) pages I've read 
documented at all how the socklen_t parameter works.  I checked the 
Linux, OpenBSD, and POSIX manual pages.


All of the pages just say that the parameter tells the kernel the size 
of the structure, as if one was obligated to pass it as 'sizeof(struct 
sockaddr_un)'.  And while that's partly correct, in that the kernel will 
not read past that, it's not a great thing to word it, or at least some 
more info could be added:


A user can use that field to make the kernel read less bytes than what 
the structure can hold.  You can for example pass 4 as the argument, and 
then sun_path will effectively be 2 bytes.  No matter what the real size 
of the structure was.


This is only lightly mentioned in a paragraph of Linux's unix(7), AFAICS:

   *  abstract: an abstract socket address is  distinguished
  (from  a pathname socket) by the fact that sun_path[0]
  is a null byte ('\0').  The socket’s address  in  this
  namespace is given by the additional bytes in sun_path
  that  are  covered  by the specified length of the ad‐
  dress structure.  (Null bytes in the name have no spe‐
  cial significance.)  The name has no  connection  with
  filesystem pathnames.  When the address of an abstract
  socket  is  returned,  the returned addrlen is greater
  than sizeof(sa_family_t) (i.e., greater than  2),  and
  the  name of the socket is contained in the first (ad‐
  drlen - sizeof(sa_family_t)) bytes of sun_path.


This is especially important, because sun_path is one of the few places 
in C where we deal with fixed-width char arrays, instead of 
NUL-terminated strings, so programmers should know in detail how the 
kernel will handle corner cases, and AFAIK different kernels behave 
differently with sun_path, so it is even more important to document it 
in detail.


I more or less know how bind(2) works regarding socklen_t, but am not 
comfortable enough to write documentation about it.  Would you mind 
documenting it in OpenBSD, so that it may help me document it in Linux?


Cheers,

Alex

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Re: cwm bind-key with space

[Okan Demirmen]

On Sat 2022.04.09 at 21:04 +0200, Mare Dedeu wrote:
> Hello,
> 
> I am trying to used Mod4 + space to bind a key to a script, but I seem to
> not be able to find out what is the name of the keysym key. "Space" is not
> working. I have tried to pick up the name
> from /usr/X11R6/include/X11/keysymdef.h
> 
> ---> "XK_KP_Space" or "0xff80"

That's a different one, try "space" (lowercase). One way to find the
right one is with xev(1).

bind-key M-space 

> but neither is recognised by cwmrc.
> 
> What am I doing wrong? Thanks!
> 
> thanks

Re: isc-bind doesn't start...

[Stuart Henderson]

On 2021-11-28, Stuart Henderson  wrote:
> On 2021-11-28, Christer Solskogen  wrote:
>> on the recent snapshot (OpenBSD 7.0-current (GENERIC.MP) #126: Sun Nov 28
>> 00:04:30 MST 2021)
>>
>> tugs# /usr/local/sbin/named -t /var/named -u _bind -U 4
>> named:/usr/local/lib/libisc-9.16.23.so: undefined symbol
>> '__emutls_get_address'
>> ld.so: named: lazy binding failed!
>> Killed
>>
>
> A change in base affected how some ports are built and I don't see
> how it could be handled automatically. pkg_delete isc-bind and reinstall
> with pkg_add for now to force an update. I have bumped REVISION so that
> it will happen for snapshot users doing a pkg_add -u when builds have
> worked through.
>
> If someone sees this same error with __emutls_get_address in another
> port (or has already seen it and worked around by reinstalling themselves)
> then please mail me so it can be bumped.
>

* that aeen't fixed by a plain "pkg_add -u" without extra flags

-- 
Please keep replies on the mailing list.

Re: isc-bind doesn't start...

[Stuart Henderson]

On 2021-11-28, Christer Solskogen  wrote:
> on the recent snapshot (OpenBSD 7.0-current (GENERIC.MP) #126: Sun Nov 28
> 00:04:30 MST 2021)
>
> tugs# /usr/local/sbin/named -t /var/named -u _bind -U 4
> named:/usr/local/lib/libisc-9.16.23.so: undefined symbol
> '__emutls_get_address'
> ld.so: named: lazy binding failed!
> Killed
>

A change in base affected how some ports are built and I don't see
how it could be handled automatically. pkg_delete isc-bind and reinstall
with pkg_add for now to force an update. I have bumped REVISION so that
it will happen for snapshot users doing a pkg_add -u when builds have
worked through.

If someone sees this same error with __emutls_get_address in another
port (or has already seen it and worked around by reinstalling themselves)
then please mail me so it can be bumped.

-- 
Please keep replies on the mailing list.

Re: isc-bind doesn't start...

[Christer Solskogen]

On Sun, Nov 28, 2021 at 4:56 PM Theo de Raadt  wrote:

>
>
> Perhaps you know how the saying goes:
>
> new base snapshot, new snapshot packages
>
>
Yes, I do. The one I've got installed is isc-bind-9.16.23v3.tgz from 26th
of november which is the latest one I've found on
https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64.

Re: isc-bind doesn't start...

[Theo de Raadt]

Christer Solskogen  wrote:

> on the recent snapshot (OpenBSD 7.0-current (GENERIC.MP) #126: Sun Nov 28
> 00:04:30 MST 2021)
> 
> tugs# /usr/local/sbin/named -t /var/named -u _bind -U 4
> named:/usr/local/lib/libisc-9.16.23.so: undefined symbol
> '__emutls_get_address'
> ld.so: named: lazy binding failed!
> Killed

Perhaps you know how the saying goes:

new base snapshot, new snapshot packages

isc-bind doesn't start...

[Christer Solskogen]

on the recent snapshot (OpenBSD 7.0-current (GENERIC.MP) #126: Sun Nov 28
00:04:30 MST 2021)

tugs# /usr/local/sbin/named -t /var/named -u _bind -U 4
named:/usr/local/lib/libisc-9.16.23.so: undefined symbol
'__emutls_get_address'
ld.so: named: lazy binding failed!
Killed

Re: bind dhcpd to IP address

[Valdrin MUJA]

Thanks, working like a charm.

From: owner-m...@openbsd.org  on behalf of Stuart 
Henderson 
Sent: Thursday, June 10, 2021 12:15 PM
To: misc@openbsd.org 
Subject: Re: bind dhcpd to IP address

On 2021-06-10, Ralf Horstmann  wrote:
> Hi Valdrin,
>
> that setup works fine. You would use "ip helper-address" on the Ciscos to
> forward the DHCP requests to your OpenBSD box. The forwarded requests use the
> specified helper address as unicast destination. No need to have the VLANs
> present on your OpenBSD box.
>
> I'm running dhcpd without -u for that. dhcpd will pickup all packets with
> destination port 67 on the specified interface via bpf. No need to bind to a
> specific IP.

dhcpd will need to be listening on the interface containing the helper-address
though; if you don't want it to actually serve clients on that network, the
subnet declaration can be empty e.g. subnet 192.0.2.0 netmask 255.255.255.0 { }


> I understand your last question as: Can dhcpd provide leases for subnets when
> the dhcpd box has no IP addresses within the range? The answer is yes. You 
> will
> need subnet declarations for all pools in dhcpd.conf though.

The relay includes its own address on the client-facing interface in the
relayed DHCP request; dhcpd uses that to determine which subnet to use.

Re: bind dhcpd to IP address

[Stuart Henderson]

On 2021-06-10, Ralf Horstmann  wrote:
> Hi Valdrin,
>
> that setup works fine. You would use "ip helper-address" on the Ciscos to
> forward the DHCP requests to your OpenBSD box. The forwarded requests use the
> specified helper address as unicast destination. No need to have the VLANs
> present on your OpenBSD box.
>
> I'm running dhcpd without -u for that. dhcpd will pickup all packets with
> destination port 67 on the specified interface via bpf. No need to bind to a
> specific IP.

dhcpd will need to be listening on the interface containing the helper-address
though; if you don't want it to actually serve clients on that network, the
subnet declaration can be empty e.g. subnet 192.0.2.0 netmask 255.255.255.0 { }


> I understand your last question as: Can dhcpd provide leases for subnets when
> the dhcpd box has no IP addresses within the range? The answer is yes. You 
> will
> need subnet declarations for all pools in dhcpd.conf though.

The relay includes its own address on the client-facing interface in the
relayed DHCP request; dhcpd uses that to determine which subnet to use.

Ynt: bind dhcpd to IP address

[Valdrin MUJA]

Thanks. I'll give a try.

Gönderen: Ralf Horstmann 
Gönderildi: 10 Haziran 2021 Perşembe 08:42
Kime: misc@openbsd.org 
Bilgi: Valdrin MUJA 
Konu: Re: bind dhcpd to IP address

Hi Valdrin,

that setup works fine. You would use "ip helper-address" on the Ciscos to
forward the DHCP requests to your OpenBSD box. The forwarded requests use the
specified helper address as unicast destination. No need to have the VLANs
present on your OpenBSD box.

I'm running dhcpd without -u for that. dhcpd will pickup all packets with
destination port 67 on the specified interface via bpf. No need to bind to a
specific IP.

I understand your last question as: Can dhcpd provide leases for subnets when
the dhcpd box has no IP addresses within the range? The answer is yes. You will
need subnet declarations for all pools in dhcpd.conf though.

Regards,
Ralf

* Valdrin MUJA  [2021-06-09 23:45]:
> Hi misc,
>
>
> I have 5 vlans terminated in Cisco switch as Layer 3.
>
> So the users' gateway is Cisco switch.
>
> The default gateway of Cisco switch is OpenBSD 6.9, which works as an office 
> firewall.
>
> The switch also works as a dhcp server. However, I want OpenBSD office 
> firewall to also act as a dhcp server.
>
> Is this possible while OpenBSD has no vlans on it? Only static routes for 
> these ip networks are installed.
>
>
> I would set dhcp relay on the Cisco switch side, but when I looked at 
> dhcpd(8), I was not entirely sure.
>
> I see that dhcpd can listen on an ip address with the -u[bind_address] 
> parameter, but these lines confused me:
>
> ''With this option, dhcpd can answer DHCPINFORM from clients on non Ethernet 
> interfaces such as tun(4) or pppx(4)’’
>
> What I understand from above is; if I configure -u for a physical (em0) 
> interface’s ip address it will not bind to em0’s IP address.
>
> It will use 255.255.255.255 instead of this. So it will not work; right?
>
>
> One last and probably related question:
>
> Can OpenBSD be configured to distribute ip pools which it doesn’t have?
>
> Thanks for reading…​
>

Re: bind dhcpd to IP address

[Ralf Horstmann]

Hi Valdrin,

that setup works fine. You would use "ip helper-address" on the Ciscos to
forward the DHCP requests to your OpenBSD box. The forwarded requests use the
specified helper address as unicast destination. No need to have the VLANs
present on your OpenBSD box.

I'm running dhcpd without -u for that. dhcpd will pickup all packets with
destination port 67 on the specified interface via bpf. No need to bind to a
specific IP.

I understand your last question as: Can dhcpd provide leases for subnets when
the dhcpd box has no IP addresses within the range? The answer is yes. You will
need subnet declarations for all pools in dhcpd.conf though.

Regards,
Ralf

* Valdrin MUJA  [2021-06-09 23:45]:
> Hi misc,
> 
> 
> I have 5 vlans terminated in Cisco switch as Layer 3.
> 
> So the users' gateway is Cisco switch.
> 
> The default gateway of Cisco switch is OpenBSD 6.9, which works as an office 
> firewall.
> 
> The switch also works as a dhcp server. However, I want OpenBSD office 
> firewall to also act as a dhcp server.
> 
> Is this possible while OpenBSD has no vlans on it? Only static routes for 
> these ip networks are installed.
> 
> 
> I would set dhcp relay on the Cisco switch side, but when I looked at 
> dhcpd(8), I was not entirely sure.
> 
> I see that dhcpd can listen on an ip address with the -u[bind_address] 
> parameter, but these lines confused me:
> 
> ''With this option, dhcpd can answer DHCPINFORM from clients on non Ethernet 
> interfaces such as tun(4) or pppx(4)’’
> 
> What I understand from above is; if I configure -u for a physical (em0) 
> interface’s ip address it will not bind to em0’s IP address.
> 
> It will use 255.255.255.255 instead of this. So it will not work; right?
> 
> 
> One last and probably related question:
> 
> Can OpenBSD be configured to distribute ip pools which it doesn’t have?
> 
> Thanks for reading…​
> 

bind dhcpd to IP address

[Valdrin MUJA]

Hi misc,


I have 5 vlans terminated in Cisco switch as Layer 3.

So the users' gateway is Cisco switch.

The default gateway of Cisco switch is OpenBSD 6.9, which works as an office 
firewall.

The switch also works as a dhcp server. However, I want OpenBSD office firewall 
to also act as a dhcp server.

Is this possible while OpenBSD has no vlans on it? Only static routes for these 
ip networks are installed.


I would set dhcp relay on the Cisco switch side, but when I looked at dhcpd(8), 
I was not entirely sure.

I see that dhcpd can listen on an ip address with the -u[bind_address] 
parameter, but these lines confused me:

''With this option, dhcpd can answer DHCPINFORM from clients on non Ethernet 
interfaces such as tun(4) or pppx(4)’’

What I understand from above is; if I configure -u for a physical (em0) 
interface’s ip address it will not bind to em0’s IP address.

It will use 255.255.255.255 instead of this. So it will not work; right?


One last and probably related question:

Can OpenBSD be configured to distribute ip pools which it doesn’t have?

Thanks for reading…​

Re: how to update remote bind zone from pppoe client?

[Stuart Henderson]

On 2019-07-05, Paco Esteban  wrote:
> On Fri, 05 Jul 2019, Marko Cupać wrote:
>
>> Hi,
>> 
>> I have a bunch of branch offices whose gateways (OpenBSD on APU) connect
>> to 'net via PPPoE and obtain their dynamic public IP addresses from
>> ISPs. Is there a way for them to update remote bind zone every time IP
>> changes so I have their current public IP in DNS?
>
> I've used bind's nsupdate in the past to do something like this (not on
> dynamic ip change, but on provisioning vms but quite similar).
>
> It was some time ago but, iirc the provisioning scripts uploaded some
> file like this:
>
> update add $FULL_DNS_NAME. 300 A $INT_IP
> send
>
> and then executed nsupdate. I guess you can do something similar with
> cron jobs.
>
> But there's probably an easier/more reliable option.

nsupdate is expected to be reliable.

The easy option is to outsource to an external service (there are plenty of
clients in /usr/ports/net). But if you want to run it yourself BIND+nsupdate
is probably about the easiest way, search for e.g. "nsupdate own dynamic dns",
you will find multiple examples. You will want to reserve a zone (separate
file) for the nsupdate-managed names rather than having it as part of your
main domain.

Re: how to update remote bind zone from pppoe client?

[Paco Esteban]

On Fri, 05 Jul 2019, Marko Cupać wrote:

> Hi,
> 
> I have a bunch of branch offices whose gateways (OpenBSD on APU) connect
> to 'net via PPPoE and obtain their dynamic public IP addresses from
> ISPs. Is there a way for them to update remote bind zone every time IP
> changes so I have their current public IP in DNS?

I've used bind's nsupdate in the past to do something like this (not on
dynamic ip change, but on provisioning vms but quite similar).

It was some time ago but, iirc the provisioning scripts uploaded some
file like this:

update add $FULL_DNS_NAME. 300 A $INT_IP
send

and then executed nsupdate. I guess you can do something similar with
cron jobs.

But there's probably an easier/more reliable option.
Hope it helps.

Cheers,

-- 
Paco Esteban.
https://onna.be/gpgkey.asc
9A6B 6083 AD9E FDC2 0EAF  5CB3 5818 130B 8A6D BC03

how to update remote bind zone from pppoe client?

[Marko Cupać]

Hi,

I have a bunch of branch offices whose gateways (OpenBSD on APU) connect
to 'net via PPPoE and obtain their dynamic public IP addresses from
ISPs. Is there a way for them to update remote bind zone every time IP
changes so I have their current public IP in DNS?

Thank you in advance,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

[Job Snijders]

On Fri, May 17, 2019 at 2:13 PM Stuart Henderson  wrote:
> On 2019/05/16 23:37, Rachel Roch wrote:
> > > RFC3513 says this:
> > >
> > >  o An anycast address must not be used as the source address of
> > >  an IPv6 packet.
> > >
> > >  o An anycast address must not be assigned to an IPv6 host, that
> > >  is, it may be assigned to an IPv6 router only.
> > >
> > > And to help ensure this, the kernel denies binding to an address marked
> > > with the anycast flag (see netinet6/in6_pcb.c).
> > >
> > > This was obsoleted by RFC4291, including this change:
> > >
> > >  o The restrictions on using IPv6 anycast addresses were removed because
> > >  there is now sufficient experience with the use of anycast addresses,
> > >  the issues are not specific to IPv6, and the GROW working group is
> > >  working in this area.
> > >
> > > So I think this restriction can now be removed, at least with this
> > > change, but more might be needed
> >
> > Certainly in my case the current OpenBSD situation represents a bit too 
> > much "nanny knows best".
>
> No, it represents "following the (old) RFCs".

patches welcome, indeed the openbsd behaviour is adhering to
now-outdated standards.

> > My use-case is anycast DNS with NSD and Unbound.
> >
> > Both NSD and unbound provide config parameters that allow distinguishing 
> > between listen address and source address.
> >
> > But then again, is there any real reason to use the anycast flag ?  To make 
> > NSD and unbound work I reconfigured to remove the anycast flag from IPv6 
> > addresses and nothing seems broken ?
> >
> If you are doing a typical "internet anycast services" setup with some
> routing protocol announcing the anycasted address then I don't see a use
> for the flag, AFAICT it was mostly in conjunction with using an anycast
> address for a local router, it feels like the usual IPv6 overengineering
> to me..

Overengineering or not, there is no reason to disallow binding to
interfaces which have the ANYCAST flag set.

Kind regards,

Job

Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

[Henry Bonath]

To chime in here, how I have always implemented Anycast DNS
is by creating additional Loopback adapters in the OS, and then
using BGP or OSPF to distribute said Loopback IPs into a routing
table.

Each DNS server participating in Anycast would have the same
IPv4 and IPv6 address configured on that loopback adapter.

e.g:
/etc/hostname.lo1:
inet 192.0.2.53/32
inet6 2001:db8:dead:beef::53/128

/etc/ospfd.conf and /etc/ospf6d.conf:
router-id 192.0.2.53
fib-update no
stub router yes

auth-type crypt
auth-md 1 "mysecretkey"
auth-md-keyid 1

area 0.0.0.0 {
interface em0
interface lo1 {
passive
}
}


Aside from that, I also believe that if you are going by the old RFCs
The "0" address is reserved as the anycast, so you would have to use
2001:db8:dead:beef::/128 in that case.

On Fri, May 17, 2019 at 8:21 AM Stuart Henderson  wrote:
>
> On 2019/05/16 23:37, Rachel Roch wrote:
> >
> >
> > > RFC3513 says this:
> > >
> > >  o An anycast address must not be used as the source address of
> > >  an IPv6 packet.
> > >
> > >  o An anycast address must not be assigned to an IPv6 host, that
> > >  is, it may be assigned to an IPv6 router only.
> > >
> > > And to help ensure this, the kernel denies binding to an address marked
> > > with the anycast flag (see netinet6/in6_pcb.c).
> > >
> > > This was obsoleted by RFC4291, including this change:
> > >
> > >  o The restrictions on using IPv6 anycast addresses were removed because
> > >  there is now sufficient experience with the use of anycast addresses,
> > >  the issues are not specific to IPv6, and the GROW working group is
> > >  working in this area.
> > >
> > > So I think this restriction can now be removed, at least with this
> > > change, but more might be needed
> > >
> >
> > Certainly in my case the current OpenBSD situation represents a bit too 
> > much "nanny knows best".
>
> No, it represents "following the (old) RFCs".
>
> > My use-case is anycast DNS with NSD and Unbound.
> >
> > Both NSD and unbound provide config parameters that allow distinguishing 
> > between listen address and source address.
> >
> > But then again, is there any real reason to use the anycast flag ?  To make 
> > NSD and unbound work I reconfigured to remove the anycast flag from IPv6 
> > addresses and nothing seems broken ?
> >
>
> If you are doing a typical "internet anycast services" setup with some
> routing protocol announcing the anycasted address then I don't see a use
> for the flag, AFAICT it was mostly in conjunction with using an anycast
> address for a local router, it feels like the usual IPv6 overengineering
> to me..
>

Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

[Stuart Henderson]

On 2019/05/16 23:37, Rachel Roch wrote:
> 
> 
> > RFC3513 says this:
> >
> >  o An anycast address must not be used as the source address of
> >  an IPv6 packet.
> >
> >  o An anycast address must not be assigned to an IPv6 host, that
> >  is, it may be assigned to an IPv6 router only.
> >
> > And to help ensure this, the kernel denies binding to an address marked
> > with the anycast flag (see netinet6/in6_pcb.c).
> >
> > This was obsoleted by RFC4291, including this change:
> >
> >  o The restrictions on using IPv6 anycast addresses were removed because
> >  there is now sufficient experience with the use of anycast addresses,
> >  the issues are not specific to IPv6, and the GROW working group is
> >  working in this area.
> >
> > So I think this restriction can now be removed, at least with this
> > change, but more might be needed
> >
> 
> Certainly in my case the current OpenBSD situation represents a bit too much 
> "nanny knows best".

No, it represents "following the (old) RFCs".

> My use-case is anycast DNS with NSD and Unbound.
> 
> Both NSD and unbound provide config parameters that allow distinguishing 
> between listen address and source address.
> 
> But then again, is there any real reason to use the anycast flag ?  To make 
> NSD and unbound work I reconfigured to remove the anycast flag from IPv6 
> addresses and nothing seems broken ?
> 

If you are doing a typical "internet anycast services" setup with some
routing protocol announcing the anycasted address then I don't see a use
for the flag, AFAICT it was mostly in conjunction with using an anycast
address for a local router, it feels like the usual IPv6 overengineering
to me..

Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

[Rachel Roch]

> RFC3513 says this:
>
>  o An anycast address must not be used as the source address of
>  an IPv6 packet.
>
>  o An anycast address must not be assigned to an IPv6 host, that
>  is, it may be assigned to an IPv6 router only.
>
> And to help ensure this, the kernel denies binding to an address marked
> with the anycast flag (see netinet6/in6_pcb.c).
>
> This was obsoleted by RFC4291, including this change:
>
>  o The restrictions on using IPv6 anycast addresses were removed because
>  there is now sufficient experience with the use of anycast addresses,
>  the issues are not specific to IPv6, and the GROW working group is
>  working in this area.
>
> So I think this restriction can now be removed, at least with this
> change, but more might be needed
>

Certainly in my case the current OpenBSD situation represents a bit too much 
"nanny knows best".

My use-case is anycast DNS with NSD and Unbound.

Both NSD and unbound provide config parameters that allow distinguishing 
between listen address and source address.

But then again, is there any real reason to use the anycast flag ?  To make NSD 
and unbound work I reconfigured to remove the anycast flag from IPv6 addresses 
and nothing seems broken ?

Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

[Stuart Henderson]

(moving from misc to tech)

On 2019-05-11, Rachel Roch  wrote:
> I'm still learning IPv6 intricacies, so forgive me if this is a silly 
> question.
>
> When I have interfaces set in the standard manner, e.g.:
>
> inet6 2001:DB8:beef::1 128
> up
>
> NSD and Unbound will bind to that address without problem.
>
> However if I add the anycast flag:
> inet6 2001:DB8:beef::1 128 anycast
> up
>
> and then destroy and re-create the interfaces and  pkill and relaunch unbound 
> and NSD, they both complain bitterly:
>
> [2019-05-11 21:00:51.665] nsd[43360]: notice: nsd starting (NSD 4.1.27)
> [2019-05-11 21:00:51.666] nsd[43360]: error: can't bind udp socket: Can't 
> assign requested address
> [2019-05-11 21:00:51.666] nsd[43360]: error: server initialization failed, 
> nsd could not be started
> [1557604863] unbound[69433:0] error: can't bind socket: Can't assign 
> requested address for 2001:DB8:beef::1 port 53[1557604863] unbound[69433:0] 
> fatal error: could not open ports
>
> The interface shows correctly in ifconfig so I don't know what the problem is 
> ?
>
> This is on OpenBSD 6.5 if it makes any difference.
>
>

RFC3513 says this:

  o An anycast address must not be used as the source address of
an IPv6 packet.

  o An anycast address must not be assigned to an IPv6 host, that
is, it may be assigned to an IPv6 router only.

And to help ensure this, the kernel denies binding to an address marked
with the anycast flag (see netinet6/in6_pcb.c).

This was obsoleted by RFC4291, including this change:

  o The restrictions on using IPv6 anycast addresses were removed because
there is now sufficient experience with the use of anycast addresses,
the issues are not specific to IPv6, and the GROW working group is
working in this area.

So I think this restriction can now be removed, at least with this
change, but more might be needed.

Index: in6_pcb.c
===
RCS file: /cvs/src/sys/netinet6/in6_pcb.c,v
retrieving revision 1.108
diff -u -p -r1.108 in6_pcb.c
--- in6_pcb.c   4 Oct 2018 17:33:41 -   1.108
+++ in6_pcb.c   13 May 2019 07:28:02 -
@@ -185,10 +185,6 @@ in6_pcbaddrisavail(struct inpcb *inp, st
sin6->sin6_port = lport;
 
/*
-* bind to an anycast address might accidentally
-* cause sending a packet with an anycast source
-    * address, so we forbid it.
-*
 * We should allow to bind to a deprecated address,
 * since the application dare to use it.
 * But, can we assume that they are careful enough
@@ -197,8 +193,8 @@ in6_pcbaddrisavail(struct inpcb *inp, st
 * flag to control the bind(2) behavior against
 * deprecated addresses (default: forbid bind(2)).
 */
-   if (ifa && ifatoia6(ifa)->ia6_flags & (IN6_IFF_ANYCAST|
-   IN6_IFF_TENTATIVE|IN6_IFF_DUPLICATED|IN6_IFF_DETACHED))
+   if (ifa && ifatoia6(ifa)->ia6_flags & (IN6_IFF_TENTATIVE|
+   IN6_IFF_DUPLICATED|IN6_IFF_DETACHED))
return (EADDRNOTAVAIL);
}
if (lport) {

NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

[Rachel Roch]

I'm still learning IPv6 intricacies, so forgive me if this is a silly question.

When I have interfaces set in the standard manner, e.g.:

inet6 2001:DB8:beef::1 128
up

NSD and Unbound will bind to that address without problem.

However if I add the anycast flag:
inet6 2001:DB8:beef::1 128 anycast
up

and then destroy and re-create the interfaces and  pkill and relaunch unbound 
and NSD, they both complain bitterly:

[2019-05-11 21:00:51.665] nsd[43360]: notice: nsd starting (NSD 4.1.27)
[2019-05-11 21:00:51.666] nsd[43360]: error: can't bind udp socket: Can't 
assign requested address
[2019-05-11 21:00:51.666] nsd[43360]: error: server initialization failed, nsd 
could not be started
[1557604863] unbound[69433:0] error: can't bind socket: Can't assign requested 
address for 2001:DB8:beef::1 port 53[1557604863] unbound[69433:0] fatal error: 
could not open ports

The interface shows correctly in ifconfig so I don't know what the problem is ?

This is on OpenBSD 6.5 if it makes any difference.

Re: bind and error sending response: would block

[Kapetanakis Giannis]

On 19/11/2018 12:30, Stuart Henderson wrote:
> On 2018-11-16, Kapetanakis Giannis  wrote:
>> Hi,
>>
>> after upgrading one of my bind (cache resolver) machines to 6.4 (release) 
>> I'm getting these errors quite often:
>>
>> Nov 16 15:55:14 server named[30616]: client: warning: client @0x6591da02440 
>> xxx.xxx.xxx.xxx#39702 (a1928.d.akamai.net): error sending response: would 
>> block
>>
>> https://kb.isc.org/docs/aa-00717
>> it's either EWOULDBLOCK or EAGAIN errors.
>>
>> I've tried playing with -U and -n settings.
>> Setting -n 1 (one cpu/core) solves the problem
>>
>> Ideally I would set it to -n 8 -U 8
>>
>> any ideas?
> 
> 
> Maybe try raising sysctl net.inet.udp.sendspace?
> 

I've increased it to 41600 (same as recv), 131072, 1048576
without any change. Default is 9216

G

Re: bind and error sending response: would block

[Stuart Henderson]

On 2018-11-16, Kapetanakis Giannis  wrote:
> Hi,
>
> after upgrading one of my bind (cache resolver) machines to 6.4 (release) I'm 
> getting these errors quite often:
>
> Nov 16 15:55:14 server named[30616]: client: warning: client @0x6591da02440 
> xxx.xxx.xxx.xxx#39702 (a1928.d.akamai.net): error sending response: would 
> block
>
> https://kb.isc.org/docs/aa-00717
> it's either EWOULDBLOCK or EAGAIN errors.
>
> I've tried playing with -U and -n settings.
> Setting -n 1 (one cpu/core) solves the problem
>
> Ideally I would set it to -n 8 -U 8
>
> any ideas?


Maybe try raising sysctl net.inet.udp.sendspace?

isc bind - error sending response: would block

[Paul B. Henson]

I recently updated a couple servers that were running OpenBSD 6.3 with bind
9.11.3 to OpenBSD 6.4 and bind 9.11.4pl2. Since then, I'm been getting a large
number of "error sending response: would block" log messages:

Nov 15 11:03:58 lisa named[79587]: client @0x6f2f02bc440 10.128.30.77#65198 
(p64-keyvalueservice.icloud.com): view internal: error sending response: would 
block

Nov 15 11:07:42 lisa named[79587]: client @0x6f325b7a440 10.128.0.19#1851 
(alt1.gmail-smtp-in.l.google.com): view internal: error sending response: would 
block

I reviewed the article at https://kb.isc.org/docs/aa-00717 ; but it's not clear
if this just a warning message, and it tries again and successfully responds
to the client, or is it's a hard error and the client never gets a response? I
wasn't getting any errors before the upgrade, and I don't think the load on
these servers is anywhere near high enough to cause them to be overloaded.

Any thoughts on what might be going on? New bug in bind? Change in OpenBSD?
So far I haven't gotten a response on the bind mailing list.

Thanks...

bind and error sending response: would block

[Kapetanakis Giannis]

Hi,

after upgrading one of my bind (cache resolver) machines to 6.4 (release) I'm 
getting these errors quite often:

Nov 16 15:55:14 server named[30616]: client: warning: client @0x6591da02440 
xxx.xxx.xxx.xxx#39702 (a1928.d.akamai.net): error sending response: would block

https://kb.isc.org/docs/aa-00717
it's either EWOULDBLOCK or EAGAIN errors.

I've tried playing with -U and -n settings.
Setting -n 1 (one cpu/core) solves the problem

Ideally I would set it to -n 8 -U 8

any ideas?

system is:
isc-bind-9.11.4pl2
6.4 GENERIC.MP#364 amd64

hw.machine=amd64
hw.model=Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
hw.ncpu=8
hw.cpuspeed=1995
hw.vendor=Dell Inc.
hw.product=PowerEdge 1950
hw.physmem=4273274880
hw.usermem=4273262592
hw.ncpufound=8
hw.smt=0
hw.ncpuonline=8

# netstat -m
57 mbufs in use:
42 mbufs allocated to data
11 mbufs allocated to packet headers
4 mbufs allocated to socket names and addresses
35/192 mbuf 2048 byte clusters in use (current/peak)
0/45 mbuf 2112 byte clusters in use (current/peak)
0/64 mbuf 4096 byte clusters in use (current/peak)
0/56 mbuf 8192 byte clusters in use (current/peak)
0/42 mbuf 9216 byte clusters in use (current/peak)
0/50 mbuf 12288 byte clusters in use (current/peak)
0/56 mbuf 16384 byte clusters in use (current/peak)
0/48 mbuf 65536 byte clusters in use (current/peak)
6016/6296/524288 Kbytes allocated to network (current/peak/max)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

# netstat -s
udp:
2939445 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
2251 with no checksum
620 input packets software-checksummed
1995 output packets software-checksummed
1327 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to missing IPsec protection
0 dropped due to full socket buffers
2938118 delivered
2964353 datagrams output
2133126 missed PCB cache


thanks,

G

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Tinker]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Saturday, November 3, 2018 5:18 PM,  wrote:
..
> > > bind ^L=clear-screen
> > > It's been working like a charm.
..
> > Ah, perfect - finally. This is way cleaner, perfect even - the previous
> > solution had the space prefix history filtering quirk and would also
> > flash the word "clear" on the screen when pressing ctrl+L.
> > Works out of the box in 6.4. Thanks a ton.
> > Tinker
>
> Hi Diogo, Tinker, misc@,
>
> Yes indeed. I tried that at the time of addition and now again, only to
> reiterate once more why I kept using the complex combination assignment.
>
> In my use case, it doesn't work clean on multiple line prompts like with
> '\n' in PS1, a clear-screen loses all prompt lines before the last line.
>
> To see if you could reproduce this behaviour try the following examples:
>
> PS1='=== line1 ===\n=== line2 ===\nline3 h\! \$ '
> bind ^L=clear-screen
> HISTCONTROL=ignoredups:ignorespace
> export PS1 HISTCONTROL
>
> Here the history line count stays accurate on issuing ^L, try 'fc -l 1'.
> For comparison with the actual prompt and working clear assignment, see:
>
> PS1='\a=== \D{%a %b %d [%H:%M]} \u@\h:\w (\l) j\j e$? h\! ===\n\$ '
> bind -m '^L'=^U\ clear'^J^Y'
> HISTCONTROL=ignoredups:ignorespace
> export PS1 HISTCONTROL
>
> Here the multiple line output prompt is kept, and indeed screen flashes.
> Oddly the history line count '\!' increases on ^L, albeit 'ignorespace'.
>
> I can understand why it changes, but it renumbers the history sequences.
> The command issued first is listed as a different higher number, really?
>
> Ideally, clear-screen would honour the prompt more faithfully, and for a
> perfect score would have (please suggest) a variant to also issue reset.
>
> Most probably, it is too much weight to have reset-clear-screen builtin.
>
> Not sure anything needs fixes, definitely using the work around for now.
> But the history count renumbering, plus the discrepancy is just bugging.
>
> Kind regards,
> Anton Lazarov

Hi Anton,

Aha so "bind ^L=clear-screen" is perfect for your usecase also, except
in a multi-line PS1 it will presently only show the last line of the
PS1 after the clearscreen.

I wonder if this is deliberate - I'd wildguess this behavior requires
more implementational complexity than printing the whole multiline set
would - you can check the code. If it's the other way around and a
trivial tweak is needed to print the multiline prompt (if fixing your
thing would mean removal of complexity maybe it would be welcome too),
maybe a diff would be welcome, just guessing.

(About your space prefix based approach I understand you have issues, I
think that whole approach looks like asking for problems. I'd be
interested first to understand if clear-screen is supposed to match
your usecase, I think it is but don't know.)

Tinker

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[lists]

Sat, 03 Nov 2018 03:12:37 + Tinker 
> On Saturday, November 3, 2018 10:29 AM, Diogo Galvao  
> wrote:
> > Em sex, 2 de nov de 2018 às 19:06, li...@wrant.com escreveu:
> >  
> > > I use these bindings and history control options in the $HOME/.profile:
> > > bind -m '^L'=^U\ clear'^J^Y'
> > > bind -m '^[^L'=^U\ reset\;clear'^J^Y'
> > > export HISTCONTROL=ignoredups:ignorespace  
> >
> > Since June 18 [1] there's a new clear-screen editing command that we can
> > bind accordingly:
> >
> > bind ^L=clear-screen
> >
> > It's been working like a charm.
> >
> > [1]: https://cvsweb.openbsd.org/src/bin/ksh/ksh.1#rev1.201
> >
> > Yours,
> > Diogo  
> 
> Ah, perfect - finally. This is way cleaner, perfect even - the previous
> solution had the space prefix history filtering quirk and would also
> flash the word "clear" on the screen when pressing ctrl+L.
> 
> Works out of the box in 6.4. Thanks a ton.
> 
> Tinker
> 

Hi Diogo, Tinker, misc@,

Yes indeed.  I tried that at the time of addition and now again, only to
reiterate once more why I kept using the complex combination assignment.

In my use case, it doesn't work clean on multiple line prompts like with
'\n' in PS1, a clear-screen loses all prompt lines before the last line.

To see if you could reproduce this behaviour try the following examples:

PS1='=== line1 ===\n=== line2 ===\nline3 h\! \$ '
bind ^L=clear-screen
HISTCONTROL=ignoredups:ignorespace
export PS1 HISTCONTROL

Here the history line count stays accurate on issuing ^L, try 'fc -l 1'.
For comparison with the actual prompt and working clear assignment, see:

PS1='\a=== \D{%a %b %d [%H:%M]} \u@\h:\w (\l) j\j e$? h\! ===\n\$ '
bind -m '^L'=^U\ clear'^J^Y'
HISTCONTROL=ignoredups:ignorespace
export PS1 HISTCONTROL

Here the multiple line output prompt is kept, and indeed screen flashes.
Oddly the history line count '\!' increases on ^L, albeit 'ignorespace'.

I can understand why it changes, but it renumbers the history sequences.
The command issued first is listed as a different higher number, really?

Ideally, clear-screen would honour the prompt more faithfully, and for a
perfect score would have (please suggest) a variant to also issue reset.

Most probably, it is too much weight to have reset-clear-screen builtin.

Not sure anything needs fixes, definitely using the work around for now.
But the history count renumbering, plus the discrepancy is just bugging.

Kind regards,
Anton Lazarov

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Tinker]

On Saturday, November 3, 2018 10:29 AM, Diogo Galvao  wrote:
> Em sex, 2 de nov de 2018 às 19:06, li...@wrant.com escreveu:
>
> > I use these bindings and history control options in the $HOME/.profile:
> > bind -m '^L'=^U\ clear'^J^Y'
> > bind -m '^[^L'=^U\ reset\;clear'^J^Y'
> > export HISTCONTROL=ignoredups:ignorespace
>
> Since June 18 [1] there's a new clear-screen editing command that we can
> bind accordingly:
>
> bind ^L=clear-screen
>
> It's been working like a charm.
>
> [1]: https://cvsweb.openbsd.org/src/bin/ksh/ksh.1#rev1.201
>
> Yours,
> Diogo

Ah, perfect - finally. This is way cleaner, perfect even - the previous
solution had the space prefix history filtering quirk and would also
flash the word "clear" on the screen when pressing ctrl+L.

Works out of the box in 6.4. Thanks a ton.

Tinker

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Diogo Galvao]

Em sex, 2 de nov de 2018 às 19:06,  escreveu:
>
> I use these bindings and history control options in the $HOME/.profile:
>
> bind -m '^L'=^U\ clear'^J^Y'
> bind -m '^[^L'=^U\ reset\;clear'^J^Y'
> export HISTCONTROL=ignoredups:ignorespace
>

Since June 18 [1] there's a new clear-screen editing command that we can
bind accordingly:

bind ^L=clear-screen

It's been working like a charm.

[1]: https://cvsweb.openbsd.org/src/bin/ksh/ksh.1#rev1.201


Yours,
Diogo

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[lists]

Fri, 02 Nov 2018 15:38:17 + Tinker 
> On Friday, November 2, 2018 9:11 PM, Klemens Nanni  wrote:
> > On Fri, Nov 02, 2018 at 11:03:34AM +, Tinker wrote:
> >  
> > > Could some other ^ shortcut be an ignore-this-line-from-history marker?  
> >
> > I'm inclined to say no; HISTCONTROL=ignorespace works fine and adding
> > yet another way to do achieve the same only to compensate user errors
> > is out of scope here.
> >  
> > > ^I as in ignore, "bind -m '^L'=^U^Iclear'^J^Y'" :)  
> >
> > ^I is tab, see `complete-list' under "Emacs editing mode" in ksh(1).  
> 
> Unimportant, only for completeness to round up,
> 
> I just meant: using "space prefix" as "ignore from history marker"
> overlaps with any other use of space prefix, such as when pasting a
> script with indentation.

Hi Tinker,

Very obvious: if you don't want the 'ignorespace' effect for lines with
leading spaces, remove these in the commands to record them in history.

> Meaning using space prefix can make things not register in the shell
> history, that you thought would. This would lead to someone's surprise
> that they are tapping arrow-up/down and can't find what they looked
> for, or, that someone thought they'd have a disk recording of their
> shell pastes and other interaction and what they get is partial data,
> that's all.

Exactly, see previous comment & read carefully the manual page section:

https://man.openbsd.org/ksh#HISTCONTROL

I use these bindings and history control options in the $HOME/.profile:

bind -m '^L'=^U\ clear'^J^Y'
bind -m '^[^L'=^U\ reset\;clear'^J^Y'
export HISTCONTROL=ignoredups:ignorespace

They work as expected.  You don't just paste commands in the terminal..

First, carefully inspect them in a text editor for safety & correctness
or make scripts from them.  You will save yourself nasty paste mishaps.

Kind regards,
Anton Lazarov

> Using a ignore marker that unlike space prefix doesn't overlap, would
> provide a symmetrical, coherent experience, but again this is truly
> unimportant.
> 
> I thought ^-something could be neat if a script file cannot trig it,
> have not studied that. I see that ^I was taken already.
> 
> Thanks,
> Tinker
> 

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Tinker]

On Friday, November 2, 2018 9:11 PM, Klemens Nanni  wrote:
> On Fri, Nov 02, 2018 at 11:03:34AM +, Tinker wrote:
>
> > Could some other ^ shortcut be an ignore-this-line-from-history marker?
>
> I'm inclined to say no; HISTCONTROL=ignorespace works fine and adding
> yet another way to do achieve the same only to compensate user errors
> is out of scope here.
>
> > ^I as in ignore, "bind -m '^L'=^U^Iclear'^J^Y'" :)
>
> ^I is tab, see `complete-list' under "Emacs editing mode" in ksh(1).

Unimportant, only for completeness to round up,

I just meant: using "space prefix" as "ignore from history marker"
overlaps with any other use of space prefix, such as when pasting a
script with indentation.

Meaning using space prefix can make things not register in the shell
history, that you thought would. This would lead to someone's surprise
that they are tapping arrow-up/down and can't find what they looked
for, or, that someone thought they'd have a disk recording of their
shell pastes and other interaction and what they get is partial data,
that's all.

Using a ignore marker that unlike space prefix doesn't overlap, would
provide a symmetrical, coherent experience, but again this is truly
unimportant.

I thought ^-something could be neat if a script file cannot trig it,
have not studied that. I see that ^I was taken already.

Thanks,
Tinker

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Klemens Nanni]

On Fri, Nov 02, 2018 at 11:03:34AM +, Tinker wrote:
> Could some other ^ shortcut be an ignore-this-line-from-history marker?
I'm inclined to say no; HISTCONTROL=ignorespace works fine and adding
yet another way to do achieve the same only to compensate user errors
is out of scope here.

> ^I as in ignore, "bind -m '^L'=^U^Iclear'^J^Y'" :)
^I is tab, see `complete-list' under "Emacs editing mode" in ksh(1).

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Tinker]

On Friday, November 2, 2018 7:03 PM, Tinker  wrote:
..
> > Try this one: bind -m '^L'=^Uclear'^J^Y'
>
> Thank you so much for coming up with this one.
>
> It does work as advertised - it clears the screen while keeping the
> content and cursor position in the command line.
>
> I just realized that it does one inadvertent thing though: It adds a
> line to ksh's history with the text "clear", which will surprise you
> and unnecessarily steal some attention next time you press the up
> arrow.
>
> I found this thread https://marc.info/?t=15329961564=1=2 which
> discusses how to get the "clear" out of the ksh history file, and, the
> trick described there also applies to the history - great!
>
> So your suggestion above is amended with:
>
> bind -m '^L'=^U clear'^J^Y'
> HISTCONTROL=ignorespace

Correction:

bind -m '^L'='^U clear^J^Y'
HISTCONTROL=ignorespace

> I find the notion of using space prefix as ignore condition just a bit
> primitive and with a very big risk of unintentional trigging, e.g., if
> you paste a script in your shell its indentation would make it ignored.
>
> Could some other ^ shortcut be an ignore-this-line-from-history marker?
>
> ^I as in ignore, "bind -m '^L'=^U^Iclear'^J^Y'" :)
>
> Anyhow it works - great, thanks again for pointing out.

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Tinker]

Hi misc@ and Anton,

This is a continuation of https://marc.info/?t=1522353=1=2
from April:

On Wednesday, April 4, 2018 2:01 AM, Anton Lindqvist  wrote:
> On Tue, Apr 03, 2018 at 01:45:13PM -0400, Tinker wrote:
> > I looked around for advise for how to make ctrl+L get bash's behavior
> > of first clearing the screen and then redrawing the current command
> > prompt including content that has been typed.
> > "bind -m '^L'=clear'^J'" is a partial solution to this problem as it
> > will have that effect but only if the command line is empty.
> > If the command line is not empty then instead the text "clear" will be
> > typed into it, and an enter key press will be emulated.
> > Is there any way to give ksh the clear+redraw behavior also when typing
> > started, so same independent of whether typing started or not i.e. just
> > like in bash?
>
> Try this one: bind -m '^L'=^Uclear'^J^Y'

Thank you so much for coming up with this one.

It does work as advertised - it clears the screen while keeping the
content and cursor position in the command line.

I just realized that it does one inadvertent thing though: It adds a
line to ksh's history with the text "clear", which will surprise you
and unnecessarily steal some attention next time you press the up
arrow.

I found this thread https://marc.info/?t=15329961564=1=2 which
discusses how to get the "clear" out of the ksh history file, and, the
trick described there also applies to the history - great!

So your suggestion above is amended with:

 bind -m '^L'=^U clear'^J^Y'
 HISTCONTROL=ignorespace

I find the notion of using space prefix as ignore condition just a bit
primitive and with a very big risk of unintentional trigging, e.g., if
you paste a script in your shell its indentation would make it ignored.

Could some other ^ shortcut be an ignore-this-line-from-history marker?

^I as in ignore, "bind -m '^L'=^U^Iclear'^J^Y'" :)

Anyhow it works - great, thanks again for pointing out.

Tinker

Re: Which key shortcuts are safe to bind and some Q:s about history and OS diffs Re: Ctrl+4 means SIGQUIT+coredump, where is this documented, what more shortcuts are there?

[Christian Weisgerber]

On 2018-11-01, Tinker  wrote:

>> > No idea how ^4 is mapped to ^\, but for some reason it is,
>>
>> See "Table 3-5 Keys Used to Generate 7-Bit Control Characters" in
>> the VT220 Programmer Reference Manual:
>> https://vt100.net/docs/vt220-rm/table3-5.html
>
> Historial reasons, a ha.

And I'll venture a guess why DEC added those combinations:  In order
to type ^[ ^\ ^] to produce the ESC, FS, GS characters, you need
keys for [ \ ].  If you look at non-English keyboard layouts, you'll
see that the corresponding keys have been re-purposed for other
characters.  In the old days of national ASCII variants, even the
characters [ \ ] didn't exist in many national encodings.  Later,
when extended 8-bit character sets were introduced, [ \ ] were only
made available in a secondary mapping reachable with an extra
modifier key (AltGr or such).  And that's the situation right into
the present.

By contrast, combinations like ^3, ^4, ^5 were readily available
on keyboards.

https://en.wikipedia.org/wiki/ISO/IEC_646#ISO_646_national_variants

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Which key shortcuts are safe to bind and some Q:s about history and OS diffs Re: Ctrl+4 means SIGQUIT+coredump, where is this documented, what more shortcuts are there?

[Tinker]

On Thursday, November 1, 2018 2:15 AM, Christian Weisgerber 
 wrote:
> On 2018-10-31, Stuart Henderson s...@spacehopper.org wrote:
>
> > No idea how ^4 is mapped to ^\, but for some reason it is,
>
> This goes back to the VT220, if not older terminals. Ctrl-3 for
> ESC aka ^[ is particularly handy if the Esc key is in some inconvenient
> place as on most PC keyboards.
>
> See "Table 3-5 Keys Used to Generate 7-Bit Control Characters" in
> the VT220 Programmer Reference Manual:
> https://vt100.net/docs/vt220-rm/table3-5.html

Historial reasons, a ha. Ok so this relates to a whole universe of
questions.


Is there a lot of effectively-unused legacy handling logics for
hardware that has not been manufactured for many decades, or is this
central today also?


Do unices e.g. OpenBSD/BSD, Linux, Solaris-whatever differ very much in
how they handle terminals?


Similar to how certain ctrl+ shortcut bindings are problematic, ESC is
also problematic as terminals easily confuse it right, e.g. ESC and
then rightarrow is easily confused for alt+rightarrow, right?


So this means that key bindings in your favourite console program, be
it KSH or TMUX or any other, better bind ctrl-shortcuts with great
discernment only, as they tend to have hardcoded lower-level terminal
behaviors so can't easily be preserved up to the tmux-etc. application
level and customized there, maybe you get it to work in a particular
setup but it would be fragile and maybe easily break when switching
terminal software or what not.

So binding ctrl+0-9 e.g. to switch windows is a bad idea.

More general-purpose are alt+ shortcuts e.g. alt+0-9.

Are shift+alt+-shortcuts, ctrl+shift+-, ctrl+alt+- shortcuts any
good, or any other control char I may not have thought of?


If I recall right, I did bind ctrl+0-9 successfully back in approx
OpenBSD 6.2 last year, from the latest Putty terminal then.

Did anything change in OpenBSD's terminal handling since then?


Last on this topic, are there any relevant terminal server-side
shortcut-related behaviors that can be tweaked in some environment
variable or configuration file?


Anyhow thanks for your comments, I think I kind of got the point about
what's safe and not safe shortcuts to bind.

If there are any further reading references or books on this topic feel
free to
share.

Thanks,
Tinker

Re: ~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Anton Lindqvist]

On Tue, Apr 03, 2018 at 01:45:13PM -0400, Tinker wrote:
> Hi,
> 
> First, thank you very much for 6.3!
> 
> 
> I looked around for advise for how to make ctrl+L get bash's behavior
> of first clearing the screen and then redrawing the current command
> prompt including content that has been typed.
> 
> "bind -m '^L'=clear'^J'" is a partial solution to this problem as it
> will have that effect but only if the command line is empty.
> 
> If the command line is not empty then instead the text "clear" will be
> typed into it, and an enter key press will be emulated.
> 
> Is there any way to give ksh the clear+redraw behavior also when typing
> started, so same independent of whether typing started or not i.e. just
> like in bash?

Try this one: bind -m '^L'=^Uclear'^J^Y'

~OT:In ksh,can bind ctrl+L to clear+redraw also wh. typing started,like in bash?

[Tinker]

Hi,

First, thank you very much for 6.3!


I looked around for advise for how to make ctrl+L get bash's behavior
of first clearing the screen and then redrawing the current command
prompt including content that has been typed.

"bind -m '^L'=clear'^J'" is a partial solution to this problem as it
will have that effect but only if the command line is empty.

If the command line is not empty then instead the text "clear" will be
typed into it, and an enter key press will be emulated.

Is there any way to give ksh the clear+redraw behavior also when typing
started, so same independent of whether typing started or not i.e. just
like in bash?

Thanks,
Tinker

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[gwes]

On 06/04/17 19:09, Kevin Chadwick wrote:


fxp0,1,2 are in order of pci slot. I assume usbs are the same after
boot so anyone who unplugs and plugs devices and doesn't check the
outcome on critical hardware deserves what they get. Also having
critical hardware that can be physically damaged is also asking for
trouble, so I cannot see an issue at all??


I've seen more than one instance where a critical system has
to add an interface on the fly to either (a) replace a failing interface
while maintaining traffic on all the other interfaces or (b)
add an interface when all installed ports are busy.

Saying "you shouldn't do that" or "why would you want to
do that" shows lack of real-world experience.

That said, I agree that the Linux solution is bad.
OpenBSD reports hardware during boot and new hardware
with kernel messages. Using that information to configure
the appropriate daemons and utilities is the right solution.

Geoff Steckel

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Kevin Chadwick]

On Fri, 2 Jun 2017 08:25:57 -0400


> Linux's (and Windows and Solaris and ...) attempts to "fix" this
> problem is one of the reasons I'd consider Linux (and Windows
> and ...) crappy. A complicated solution that creates far more
> problems than it ever solves, and usually at the worst times possible
> (i.e., disaster recovery, where you are trying to rebuild a failed
> system).
> 
> The tools to deal with this are already in OpenBSD as I and Peter
> indicated.  We don't need an "automatic" solution that penalizes
> everyone for an edge-case problem (and yes, I'd consider this an edge
> case.  I can't imagine a serious, industrial firewall with USB
> interfaces).

Yeah, definitely, there are more than a few mailing list requests on
switching the linux solution back to eth0...1 etc to fix new issues. The
linux code before (eth0,1,2) did have issues OpenBSD does not too.

My experience that has always been better than Linux is that the e.g.
fxp0,1,2 are in order of pci slot. I assume usbs are the same after
boot so anyone who unplugs and plugs devices and doesn't check the
outcome on critical hardware deserves what they get. Also having
critical hardware that can be physically damaged is also asking for
trouble, so I cannot see an issue at all?? 

p.s. I love the ethernet card driver specific man pages!!

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Nick Holland]

On 06/01/17 20:50, Tinker wrote:
> On 2017-06-02 00:45, Joe Gidi wrote:
>> Good news! You can have this already.
> 
> Yay!
> 
>> Go run Linux.
> 
> Em -
> 
> Nay!
> 
> No yay. Hope to see a solid solution to this problem on a non-crappy OS 
> soon.
> 

Linux's (and Windows and Solaris and ...) attempts to "fix" this problem
is one of the reasons I'd consider Linux (and Windows and ...) crappy.
A complicated solution that creates far more problems than it ever
solves, and usually at the worst times possible (i.e., disaster
recovery, where you are trying to rebuild a failed system).

The tools to deal with this are already in OpenBSD as I and Peter
indicated.  We don't need an "automatic" solution that penalizes
everyone for an edge-case problem (and yes, I'd consider this an edge
case.  I can't imagine a serious, industrial firewall with USB interfaces).

Nick.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Tinker]

Oh. Yeah if there's no performance penalty on such a solution then 
great. Could someone confirm that?



So this works for cabled ethernet, where NIC promiscuous mode due to the 
bridge won't hurt.


Also it wouldn't work for wireless interfaces. Also to be robust it 
presumes that NIC unplug implies automatic immediate detachment of the 
unplugged interface from the bridge, so that a newly plugged/replugged 
NIC not under any circumstance will be made by the kernel to 
automatically participate in any bridge.


On 2017-06-02 02:41, Joel Wirāmu Pauling wrote:

I don't know the bridge code in OpenBSD as well as I know it in Linux -
basic bridges don't add any appreciable overhead on that platform until 
you

start mucking around with bridge specific things.

It just means you maintain an arp table distinct from each 
sub-interface.


tl;dr - it's not going to hurt your performance.



On 2 June 2017 at 14:37, Tinker  wrote:


In the kernel however that implies an internal indirection/one or more
additional rounds copying of all traffic and passing around, right, so 
even

it works quite well, it's not optimal right?

Anyhow sure that is an effective workaround if needed.


On 2017-06-02 02:20, Joel Wirāmu Pauling wrote:


There are several ways of doing this.

I suggest just using a bridge and adding a bunch of sub-devices into
it.

On 2 June 2017 at 14:00, Tinker  wrote:

Wait, can you give an example of how that would work?


I was not aware of any aliasing mechanism e.g. I could designate
"cdce10001" or "virt10001" to be the cdce that has MAC so and so.

On 2017-06-02 01:12, Joel Wirāmu Pauling wrote:
You can use a Virtual Interface/Alias that is consistent so that
you
don't need to change scripts/etc in relation to network config - I
believe this is suggested in several man pages etc as a solution to
consistent interface naming.

On 2 June 2017 at 12:50, Tinker  wrote:

On 2017-06-02 00:45, Joe Gidi wrote:

Good news! You can have this already.

Yay!

Go run Linux.

Em -

Nay!

No yay. Hope to see a solid solution to this problem on a
non-crappy OS soon.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Joel Wirāmu Pauling]

I don't know the bridge code in OpenBSD as well as I know it in Linux -
basic bridges don't add any appreciable overhead on that platform until you
start mucking around with bridge specific things.

It just means you maintain an arp table distinct from each sub-interface.

tl;dr - it's not going to hurt your performance.



On 2 June 2017 at 14:37, Tinker  wrote:

> In the kernel however that implies an internal indirection/one or more
> additional rounds copying of all traffic and passing around, right, so even
> it works quite well, it's not optimal right?
>
> Anyhow sure that is an effective workaround if needed.
>
>
> On 2017-06-02 02:20, Joel Wirāmu Pauling wrote:
>
>> There are several ways of doing this.
>>
>> I suggest just using a bridge and adding a bunch of sub-devices into
>> it.
>>
>> On 2 June 2017 at 14:00, Tinker  wrote:
>>
>> Wait, can you give an example of how that would work?
>>>
>>> I was not aware of any aliasing mechanism e.g. I could designate
>>> "cdce10001" or "virt10001" to be the cdce that has MAC so and so.
>>>
>>> On 2017-06-02 01:12, Joel Wirāmu Pauling wrote:
>>> You can use a Virtual Interface/Alias that is consistent so that
>>> you
>>> don't need to change scripts/etc in relation to network config - I
>>> believe this is suggested in several man pages etc as a solution to
>>> consistent interface naming.
>>>
>>> On 2 June 2017 at 12:50, Tinker  wrote:
>>>
>>> On 2017-06-02 00:45, Joe Gidi wrote:
>>>
>>> Good news! You can have this already.
>>>
>>> Yay!
>>>
>>> Go run Linux.
>>>
>>> Em -
>>>
>>> Nay!
>>>
>>> No yay. Hope to see a solid solution to this problem on a
>>> non-crappy OS soon.
>>>
>>
>

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Tinker]

In the kernel however that implies an internal indirection/one or more 
additional rounds copying of all traffic and passing around, right, so 
even it works quite well, it's not optimal right?


Anyhow sure that is an effective workaround if needed.

On 2017-06-02 02:20, Joel Wirāmu Pauling wrote:

There are several ways of doing this.

I suggest just using a bridge and adding a bunch of sub-devices into
it.

On 2 June 2017 at 14:00, Tinker  wrote:


Wait, can you give an example of how that would work?

I was not aware of any aliasing mechanism e.g. I could designate
"cdce10001" or "virt10001" to be the cdce that has MAC so and so.

On 2017-06-02 01:12, Joel Wirāmu Pauling wrote:
You can use a Virtual Interface/Alias that is consistent so that
you
don't need to change scripts/etc in relation to network config - I
believe this is suggested in several man pages etc as a solution to
consistent interface naming.

On 2 June 2017 at 12:50, Tinker  wrote:

On 2017-06-02 00:45, Joe Gidi wrote:

Good news! You can have this already.

Yay!

Go run Linux.

Em -

Nay!

No yay. Hope to see a solid solution to this problem on a
non-crappy OS soon.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Tinker]

On 2017-06-02 00:45, Joe Gidi wrote:

Good news! You can have this already.


Yay!


Go run Linux.


Em -

Nay!

No yay. Hope to see a solid solution to this problem on a non-crappy OS 
soon.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Joe Gidi]

Good news! You can have this already. Go run Linux.

On June 1, 2017 8:42:45 PM EDT, Tinker <ti...@openmailbox.org> wrote:
>Ah - having an interface name naming scheme that, instead of just being
>
>a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical 
>slot where the device is connected, e.g. CDCE + USB root-hub: 0 + slot:
>
>17 + address: 4 = "cdceur0s17a4", would do the job too.
>
>On 2017-06-02 00:24, Tinker wrote:
>> Hi,
>> 
>> What I meant was, it's fairly easy for interface numbers (e.g. NIC A
>> as CDCE0 and NIC B as CDCE1) to become exchanged.
>> 
>> With lots of unluck, there could be mechanical stress on USB ports so
>> that they would rearrange spontaneously so NIC B would become CDCE0
>> and NIC A would become CDCE1.
>> 
>> Or more probable, an ignorant user would intentionally replug his
>> devices but the change of order of interfaces would be unintentional
>> to him, and then when he ifconfig/dhclient:s his interfaces, very bad
>> things could happen.
>> 
>> This is not a big deal, but it does add one more thing to think
>about,
>> and in extreme corner cases it could be a security problem - God
>> forbid you'd have a public network on CDCE0 and a private network on
>> CDCE1 and then a little mistake causes everyone's medical records
>etc.
>> to be leaked on the Internet.
>> 
>> 
>> The same would apply to USB serial ports (UART:s) and probably some
>> other hardware -
>> 
>> I was talking to someone who was worried that it (unintended device
>> ordering) could happen even to PCI devices though I guess that's
>> overkill.
>> 
>> His solution is to enforce device names by using different hardware,
>> though that kind of illustrates the problem rather than resolve it,
>> doesn't it.
>> 
>> 
>> OpenBSD leaves IP configuration as manual work to the user so OpenBSD
>> itself won't mess it up for you, so this is not a per-se OpenBSD
>> problem.
>> 
>> But maybe OpenBSD could help people do it right. Interface number
>> hard-binding to a particular device descriptor (MAC/USB serial etc.)
>> would solve it.
>> 
>> Interface name aliasing would work too (hardbound to descriptor).
>> 
>> 
>> Anyhow I just wanted to bring up the potential problem.
>> 
>> (Also Peter - this is not specifically a PF problem, however, how
>> would you use egress as part of the solution?)
>> 
>> Thanks,
>> Tinker
>> 
>> On 2017-05-30 07:04, Peter Hessler wrote:
>>> On 2017 May 29 (Mon) at 02:13:57 + (+), Tinker wrote:
>>> :Hi misc@,
>>> :
>>> :For pluggable devices such as USB NIC:s, is there any way to make 
>>> OpenBSD
>>> :bind a particular device based on its MAC or USB serial number or
>the 
>>> like
>>> :variable, to a particular interface or device filename?
>>> :
>>> :E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external
>
>>> USB
>>> :harddrive with serial number Z as /dev/sd0 and the one with serial 
>>> number A
>>> :as /dev/sd1 (and plugging in other devices would automatically).
>>> :
>>> :(For storage devices there's the DUID-based mounting already
>though, 
>>> so I
>>> :guess those are a non-issue.)
>>> :
>>> :Some things in the OS are specified per interface/device name, e.g.
>
>>> PF rules
>>> :(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1
>..", 
>>> "match
>>> :out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having
>the
>>> :interface numbers garbled on replug may be an unnecessary reason to
>
>>> reboot?
>>> :
>>> :Would be happy to learn any best practice here, thanks,
>>> :Tinker
>>> :
>>> 
>>> match out on egress from 192.168.0.0/16 to any nat-to (egress)
>>>  ^^   
>>> 
>>> the interface group "egress" is added to the interface a default
>route
>>> uses.  Wrapping that with (), will ensure that interface is updated 
>>> when
>>> the default routes uses a different interface.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Tinker]

Ah - having an interface name naming scheme that, instead of just being 
a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical 
slot where the device is connected, e.g. CDCE + USB root-hub: 0 + slot: 
17 + address: 4 = "cdceur0s17a4", would do the job too.


On 2017-06-02 00:24, Tinker wrote:

Hi,

What I meant was, it's fairly easy for interface numbers (e.g. NIC A
as CDCE0 and NIC B as CDCE1) to become exchanged.

With lots of unluck, there could be mechanical stress on USB ports so
that they would rearrange spontaneously so NIC B would become CDCE0
and NIC A would become CDCE1.

Or more probable, an ignorant user would intentionally replug his
devices but the change of order of interfaces would be unintentional
to him, and then when he ifconfig/dhclient:s his interfaces, very bad
things could happen.

This is not a big deal, but it does add one more thing to think about,
and in extreme corner cases it could be a security problem - God
forbid you'd have a public network on CDCE0 and a private network on
CDCE1 and then a little mistake causes everyone's medical records etc.
to be leaked on the Internet.


The same would apply to USB serial ports (UART:s) and probably some
other hardware -

I was talking to someone who was worried that it (unintended device
ordering) could happen even to PCI devices though I guess that's
overkill.

His solution is to enforce device names by using different hardware,
though that kind of illustrates the problem rather than resolve it,
doesn't it.


OpenBSD leaves IP configuration as manual work to the user so OpenBSD
itself won't mess it up for you, so this is not a per-se OpenBSD
problem.

But maybe OpenBSD could help people do it right. Interface number
hard-binding to a particular device descriptor (MAC/USB serial etc.)
would solve it.

Interface name aliasing would work too (hardbound to descriptor).


Anyhow I just wanted to bring up the potential problem.

(Also Peter - this is not specifically a PF problem, however, how
would you use egress as part of the solution?)

Thanks,
Tinker

On 2017-05-30 07:04, Peter Hessler wrote:

On 2017 May 29 (Mon) at 02:13:57 + (+), Tinker wrote:
:Hi misc@,
:
:For pluggable devices such as USB NIC:s, is there any way to make 
OpenBSD
:bind a particular device based on its MAC or USB serial number or the 
like

:variable, to a particular interface or device filename?
:
:E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external 
USB
:harddrive with serial number Z as /dev/sd0 and the one with serial 
number A

:as /dev/sd1 (and plugging in other devices would automatically).
:
:(For storage devices there's the DUID-based mounting already though, 
so I

:guess those are a non-issue.)
:
:Some things in the OS are specified per interface/device name, e.g. 
PF rules
:(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 ..", 
"match

:out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having the
:interface numbers garbled on replug may be an unnecessary reason to 
reboot?

:
:Would be happy to learn any best practice here, thanks,
:Tinker
:

match out on egress from 192.168.0.0/16 to any nat-to (egress)
 ^^   

the interface group "egress" is added to the interface a default route
uses.  Wrapping that with (), will ensure that interface is updated 
when

the default routes uses a different interface.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Tinker]

Hi,

What I meant was, it's fairly easy for interface numbers (e.g. NIC A as 
CDCE0 and NIC B as CDCE1) to become exchanged.


With lots of unluck, there could be mechanical stress on USB ports so 
that they would rearrange spontaneously so NIC B would become CDCE0 and 
NIC A would become CDCE1.


Or more probable, an ignorant user would intentionally replug his 
devices but the change of order of interfaces would be unintentional to 
him, and then when he ifconfig/dhclient:s his interfaces, very bad 
things could happen.


This is not a big deal, but it does add one more thing to think about, 
and in extreme corner cases it could be a security problem - God forbid 
you'd have a public network on CDCE0 and a private network on CDCE1 and 
then a little mistake causes everyone's medical records etc. to be 
leaked on the Internet.



The same would apply to USB serial ports (UART:s) and probably some 
other hardware -


I was talking to someone who was worried that it (unintended device 
ordering) could happen even to PCI devices though I guess that's 
overkill.


His solution is to enforce device names by using different hardware, 
though that kind of illustrates the problem rather than resolve it, 
doesn't it.



OpenBSD leaves IP configuration as manual work to the user so OpenBSD 
itself won't mess it up for you, so this is not a per-se OpenBSD 
problem.


But maybe OpenBSD could help people do it right. Interface number 
hard-binding to a particular device descriptor (MAC/USB serial etc.) 
would solve it.


Interface name aliasing would work too (hardbound to descriptor).


Anyhow I just wanted to bring up the potential problem.

(Also Peter - this is not specifically a PF problem, however, how would 
you use egress as part of the solution?)


Thanks,
Tinker

On 2017-05-30 07:04, Peter Hessler wrote:

On 2017 May 29 (Mon) at 02:13:57 + (+), Tinker wrote:
:Hi misc@,
:
:For pluggable devices such as USB NIC:s, is there any way to make 
OpenBSD
:bind a particular device based on its MAC or USB serial number or the 
like

:variable, to a particular interface or device filename?
:
:E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external 
USB
:harddrive with serial number Z as /dev/sd0 and the one with serial 
number A

:as /dev/sd1 (and plugging in other devices would automatically).
:
:(For storage devices there's the DUID-based mounting already though, 
so I

:guess those are a non-issue.)
:
:Some things in the OS are specified per interface/device name, e.g. PF 
rules
:(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 ..", 
"match

:out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having the
:interface numbers garbled on replug may be an unnecessary reason to 
reboot?

:
:Would be happy to learn any best practice here, thanks,
:Tinker
:

match out on egress from 192.168.0.0/16 to any nat-to (egress)
 ^^   

the interface group "egress" is added to the interface a default route
uses.  Wrapping that with (), will ensure that interface is updated 
when

the default routes uses a different interface.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Peter Hessler]

On 2017 May 29 (Mon) at 02:13:57 + (+), Tinker wrote:
:Hi misc@,
:
:For pluggable devices such as USB NIC:s, is there any way to make OpenBSD
:bind a particular device based on its MAC or USB serial number or the like
:variable, to a particular interface or device filename?
:
:E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external USB
:harddrive with serial number Z as /dev/sd0 and the one with serial number A
:as /dev/sd1 (and plugging in other devices would automatically).
:
:(For storage devices there's the DUID-based mounting already though, so I
:guess those are a non-issue.)
:
:Some things in the OS are specified per interface/device name, e.g. PF rules
:(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 ..", "match
:out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having the
:interface numbers garbled on replug may be an unnecessary reason to reboot?
:
:Would be happy to learn any best practice here, thanks,
:Tinker
:

match out on egress from 192.168.0.0/16 to any nat-to (egress)
 ^^   

the interface group "egress" is added to the interface a default route
uses.  Wrapping that with (), will ensure that interface is updated when
the default routes uses a different interface.


-- 
It looks like blind screaming hedonism won out.

Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Nick Holland]

On 05/28/17 22:13, Tinker wrote:
> Hi misc@,
> 
> For pluggable devices such as USB NIC:s, is there any way to make 
> OpenBSD bind a particular device based on its MAC or USB serial number 
> or the like variable, to a particular interface or device filename?

no but ...
...
> (For storage devices there's the DUID-based mounting already though, so 
> I guess those are a non-issue.)

right.  so we'll ignore those...but that's a hint: there's more than one
way to do things.

> Some things in the OS are specified per interface/device name, e.g. PF 
> rules (e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 
> ..", "match out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so 
> having the interface numbers garbled on replug may be an unnecessary 
> reason to 
> reboot?http://www.providr.com/now/spartans-facts/26/?utm_source=fbkxd_medium=spartan_d_f

My thought would be to have an include file in your pf.conf that defines
a macro to the desired interface to what it happens to be connected as
this moment.

So maybe a hotplugd(8) script that looks at the MAC address (or ...
something else?) of whatever device was just plugged in and create an
entry in /etc/pf/interfaces.inc something like
ext=run0
or
int=run1

as appropriate.  Have an 'include "/etc/pf/interfaces.inc" ' in your
pf.conf, and reload pf.conf when a hotplug event takes place.

Nick.

Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

[Tinker]

Hi misc@,

For pluggable devices such as USB NIC:s, is there any way to make 
OpenBSD bind a particular device based on its MAC or USB serial number 
or the like variable, to a particular interface or device filename?


E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external USB 
harddrive with serial number Z as /dev/sd0 and the one with serial 
number A as /dev/sd1 (and plugging in other devices would 
automatically).


(For storage devices there's the DUID-based mounting already though, so 
I guess those are a non-issue.)


Some things in the OS are specified per interface/device name, e.g. PF 
rules (e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 
..", "match out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so 
having the interface numbers garbled on replug may be an unnecessary 
reason to reboot?


Would be happy to learn any best practice here, thanks,
Tinker

Re: Problems building BIND 9.10.3 on OpenBSD 5.7

[Stuart Henderson]

On 2015-09-17, Research <resea...@nativemethods.com> wrote:
> Hello,
>
> I am currently having issues compiling BIND 9.10.3 (released by ISC this week 
> to correct for DoS vulnerabilities), on my OpenBSD 5.7 test machine.  I am 
> running the OpenBSD 5.7 release build with the 14 errata patches successfully 
> applied and with the userland also rebuilt.

9.10.3 is a feature release, it's in -current ports but I don't intend to
backport to -stable yet. The security fixes are in 9.10.2-P4 which is
in -stable ports.

> I can successfully make configure, but when I attempt make build, I receive:
>
> …previous successful build messages removed...
>
> making all in /home/developer/bind-9.10.3/lib/samples
> gcc -pthread  -I/home/developer/bind-9.10.3 -I../.. -I./include 
> -I../dns/include  -I/home/developer/bind-9.10.3/lib/dns/include  
> -I../../lib/dns/include -I/home/developer/bind-9.10.3/lib/isc/include  
> -I../../lib/isc  -I../../lib/isc/include  -I../../lib/isc/unix/include  
> -I../../lib/isc/pthreads/include  -I../../lib/isc/x86_32/include  
> -I../../lib/irs/include  -I../../lib/irs/include   -D_REENTRANT 
> -DVERSION=\"9.10.3\" -DSYSCONFDIR=\"/etc/bind\"  -g -O2   -W -Wall 
> -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith 
> -fno-strict-aliasing -fno-delete-null-pointer-checks  -c resolve.c
> gcc -pthread -g -O2  -o resolve  resolve.o ../irs/libirs.a ../dns/libdns.a  
> -lcrypto ../isccfg/libisccfg.a ../isc/libisc.a -lpthread 
> ../irs/libirs.a(getnameinfo.o)(.text+0x18f): In function `getnameinfo':
> /home/developer/bind-9.10.3/lib/irs/getnameinfo.c:220: warning: strcpy() is 
> almost always misused, please use strlcpy()
> ../dns/libdns.a(resolver.o)(.text+0x9774): In function 
> `dns_resolver_createfetch3':
> /home/developer/bind-9.10.3/lib/dns/resolver.c:4155: warning: strcat() is 
> almost always misused, please use strlcat()
> ../dns/libdns.a(name.o)(.text+0x426b): In function `dns_name_tofilenametext':
> /home/developer/bind-9.10.3/lib/dns/name.c:1636: warning: sprintf() is often 
> misused, please use snprintf()
> ../dns/libdns.a(openssldh_link.o)(.text+0xed5): In function 
> `openssldh_generate':
> /home/developer/bind-9.10.3/lib/dns/openssldh_link.c:212: undefined reference 
> to `BN_GENCB_new'
> ../dns/libdns.a(openssldh_link.o)(.text+0xf23):/home/developer/bind-9.10.3/lib/dns/openssldh_link.c:234:
>  undefined reference to `BN_GENCB_free'
> ../dns/libdns.a(openssldh_link.o)(.text+0xffe):/home/developer/bind-9.10.3/lib/dns/openssldh_link.c:229:
>  undefined reference to `BN_GENCB_free'

Our OPENSSL_VERSION_NUMBER #defines don't (and can't) directly map from
libressl's api to openssl's. If you have a requirement to use 9.10.3 now
then either run -current, backport my patches, or disable crypto support
if you don't need it (untested but should work).

Re: Problems building BIND 9.10.3 on OpenBSD 5.7

[Research]

Hi Raf and Stuart,


On Sep 17, 2015, at 3:36 AM, Stuart Henderson  wrote:

> 9.10.3 is a feature release, it's in -current ports but I don't intend to
> backport to -stable yet. The security fixes are in 9.10.2-P4 which is
> in -stable ports.

Ok.  I believe Raf was mentioning this as well, that the security fixes are in 
9.10.2-P4, which I currently have.  I misread the ISC release notes and thought 
there was a new patch included in 9.10.3.  I have 9.10.2-P4 successfully 
running and will stick with this until 9.10.3 is backported to stable.

> Our OPENSSL_VERSION_NUMBER #defines don't (and can't) directly map from
> libressl's api to openssl's. If you have a requirement to use 9.10.3 now
> then either run -current, backport my patches, or disable crypto support
> if you don't need it (untested but should work).

Ah, ok - that’s good to know.  Wasn’t entirely sure what the build error meant 
but this makes sense.

Raf, thanks for pointer regarding @ports - will remember that going forward.

Regards,

- Scott

Problems building BIND 9.10.3 on OpenBSD 5.7

[Research]

Hello,

I am currently having issues compiling BIND 9.10.3 (released by ISC this week 
to correct for DoS vulnerabilities), on my OpenBSD 5.7 test machine.  I am 
running the OpenBSD 5.7 release build with the 14 errata patches successfully 
applied and with the userland also rebuilt.

I can successfully make configure, but when I attempt make build, I receive:

…previous successful build messages removed...

making all in /home/developer/bind-9.10.3/lib/samples
gcc -pthread  -I/home/developer/bind-9.10.3 -I../.. -I./include 
-I../dns/include  -I/home/developer/bind-9.10.3/lib/dns/include  
-I../../lib/dns/include -I/home/developer/bind-9.10.3/lib/isc/include  
-I../../lib/isc  -I../../lib/isc/include  -I../../lib/isc/unix/include  
-I../../lib/isc/pthreads/include  -I../../lib/isc/x86_32/include  
-I../../lib/irs/include  -I../../lib/irs/include   -D_REENTRANT 
-DVERSION=\"9.10.3\" -DSYSCONFDIR=\"/etc/bind\"  -g -O2   -W -Wall 
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith 
-fno-strict-aliasing -fno-delete-null-pointer-checks  -c resolve.c
gcc -pthread -g -O2  -o resolve  resolve.o ../irs/libirs.a ../dns/libdns.a  
-lcrypto ../isccfg/libisccfg.a ../isc/libisc.a -lpthread 
../irs/libirs.a(getnameinfo.o)(.text+0x18f): In function `getnameinfo':
/home/developer/bind-9.10.3/lib/irs/getnameinfo.c:220: warning: strcpy() is 
almost always misused, please use strlcpy()
../dns/libdns.a(resolver.o)(.text+0x9774): In function 
`dns_resolver_createfetch3':
/home/developer/bind-9.10.3/lib/dns/resolver.c:4155: warning: strcat() is 
almost always misused, please use strlcat()
../dns/libdns.a(name.o)(.text+0x426b): In function `dns_name_tofilenametext':
/home/developer/bind-9.10.3/lib/dns/name.c:1636: warning: sprintf() is often 
misused, please use snprintf()
../dns/libdns.a(openssldh_link.o)(.text+0xed5): In function 
`openssldh_generate':
/home/developer/bind-9.10.3/lib/dns/openssldh_link.c:212: undefined reference 
to `BN_GENCB_new'
../dns/libdns.a(openssldh_link.o)(.text+0xf23):/home/developer/bind-9.10.3/lib/dns/openssldh_link.c:234:
 undefined reference to `BN_GENCB_free'
../dns/libdns.a(openssldh_link.o)(.text+0xffe):/home/developer/bind-9.10.3/lib/dns/openssldh_link.c:229:
 undefined reference to `BN_GENCB_free'
../dns/libdns.a(openssldh_link.o)(.text+0x107d): In function `progress_cb':
/home/developer/bind-9.10.3/lib/dns/openssldh_link.c:164: undefined reference 
to `BN_GENCB_get_arg'
../dns/libdns.a(openssldsa_link.o)(.text+0xab0): In function 
`openssldsa_generate':
/home/developer/bind-9.10.3/lib/dns/openssldsa_link.c:385: undefined reference 
to `BN_GENCB_new'
../dns/libdns.a(openssldsa_link.o)(.text+0xb01):/home/developer/bind-9.10.3/lib/dns/openssldsa_link.c:408:
 undefined reference to `BN_GENCB_free'
../dns/libdns.a(openssldsa_link.o)(.text+0xb4e):/home/developer/bind-9.10.3/lib/dns/openssldsa_link.c:404:
 undefined reference to `BN_GENCB_free'
../dns/libdns.a(openssldsa_link.o)(.text+0xbcd): In function `progress_cb':
/home/developer/bind-9.10.3/lib/dns/openssldsa_link.c:348: undefined reference 
to `BN_GENCB_get_arg'
../dns/libdns.a(opensslrsa_link.o)(.text+0x1352): In function 
`opensslrsa_generate':
/home/developer/bind-9.10.3/lib/dns/opensslrsa_link.c:777: undefined reference 
to `BN_GENCB_new'
../dns/libdns.a(opensslrsa_link.o)(.text+0x145b):/home/developer/bind-9.10.3/lib/dns/opensslrsa_link.c:821:
 undefined reference to `BN_GENCB_free'
../dns/libdns.a(opensslrsa_link.o)(.text+0x1489):/home/developer/bind-9.10.3/lib/dns/opensslrsa_link.c:835:
 undefined reference to `BN_GENCB_free'
../dns/libdns.a(opensslrsa_link.o)(.text+0x14bc):/home/developer/bind-9.10.3/lib/dns/opensslrsa_link.c:810:
 undefined reference to `BN_GENCB_free'
../dns/libdns.a(opensslrsa_link.o)(.text+0x152d): In function `progress_cb':
/home/developer/bind-9.10.3/lib/dns/opensslrsa_link.c:757: undefined reference 
to `BN_GENCB_get_arg'
collect2: ld returned 1 exit status
*** Error 1 in lib/samples (Makefile:479 'resolve')
*** Error 1 in lib (Makefile:100 'subdirs')
*** Error 1 in /home/developer/bind-9.10.3 (Makefile:105 'subduers’)


It appears to be failing while building in lib/samples and is seeing undefined 
references to BN_GENCB functions.

I am almost 100% certain this is something that I’ve overlooked.  I am 
wondering (guessing ?), if it is referring to something in OpenSSL that is not 
in LibreSSL and that is why it is failing ?

Interestingly enough I had no problems building BIND 10.9.2-P4 (the previous 
release).

I would welcome any suggestions as to how I can fix the build - running BIND as 
opposed to Unbound in my current scenario is unfortunately a requirement.

Thanks

- Scott

Re: Problems building BIND 9.10.3 on OpenBSD 5.7

[Raf Czlonka]

On Thu, Sep 17, 2015 at 02:03:01AM BST, Research wrote:

> Hello,

Hi,

> I am currently having issues compiling BIND 9.10.3 (released by ISC
> this week to correct for DoS vulnerabilities), on my OpenBSD 5.7
> test machine.  I am running the OpenBSD 5.7 release build with the
> 14 errata patches successfully applied and with the userland also
> rebuilt. [...] It appears to be failing while building in lib/samples
> and is seeing undefined references to BN_GENCB functions.
>
> I am almost 100% certain this is something that I’ve overlooked.  I
> am wondering (guessing ?), if it is referring to something in OpenSSL
> that is not in LibreSSL and that is why it is failing ?

Yes, it appears to be OpenSSL-related[0].

Check the ports tree[0] for the patches which Stuart added to HEAD and
see whether the port would built cleanly on 5.7.

Rule of thumb - if there's a port in OpenBSD tree, you might be better
of consulting ports@.

Regards,

Raf

P.S. BTW, security patches for bind-9.10.2-P4 in the OPENBSD_5_7 branch
are from 2nd September.

[0] https://marc.info/?l=openbsd-ports-cvs=144241734102813
[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/isc-bind/

bind iked to carp ip address

[Marko Cupać]

Hi,

is there a way to bind iked to carp ip address? I've tried with 'local
carp.ip.ali.as' but it still binds to all addresses:

Proto   Recv-Q Send-Q  Local Address  Foreign Address(state) 
udp  0  0  *.ipsec-na *.* 
udp  0  0  *.isakmp   *.*   

When client tries to connect to carp ip, iked responds with source
address of physical interface.

I have a pair of carp firewalls which are giving my users the ability
to connect over pptp (npppd) and openvpn - both of those listen on one
of carp ip aliases. Failover is not graceful but it is good enough. I
wanted to add ikev2 to the mix, but I'd like to keep it on the same
(carp) ip address as the other two vpn services.

Is this possible?

Thank you in advance,
-- 
Marko Cupać
https://www.mimar.rs/

local daemons udp bind to multiple IPs with same netmask?

[Chris Cappuccio]

For various reasons that include Asterisk restrictions and Metaswitch
restrictions, I've had to setup multiple IP addresses to talk to
different partitions of a Metaswitch with Asterisk...

That means, for all practical purposes, my config looks like:

/etc/hostname.em0:
inet 10.10.10.2 255.255.255.0 NONE
inet alias 10.10.10.3 255.255.255.0
inet alias 10.10.10.4 255.255.255.0

/etc/asterisk/sip.conf:
[meta1]
host=10.10.10.100
bindaddr=10.10.10.2
..
[meta2]
host=10.10.10.100
bindaddr=10.10.10.3
..
[meta3]
host=10.10.10.100
bindaddr=10.10.10.4
..

After upgrading, I now take advantage of the new, reworked routing
table. Now, when packets come in to 10.10.10.4 or 10.10.10.3,
asterisk never gets them.

I thought about the routing table changes and how claudio or mpi
described the multiple-/24 config on the same interface as broken
(you are creating multiple network routes pointing to the same
interface, which is apparently a broken concept) and then I
changed /etc/hostname.em0 to this:

/etc/hostname.em0:
inet 10.10.10.2 255.255.255.0 NONE
inet alias 10.10.10.3 255.255.255.255
inet alias 10.10.10.4 255.255.255.255

which is the old school, recommended way. (I seem to remember the 
same-netmask-for-multiple-IPs-on-an-interfce as passable/usable
one point, but it certainly isn't now)

And it works. Just thought I'd mention this on misc since I am
probably not the only person who is binding multiple IPs in the
same subnet to an interface?

Chris

failed to bind on local port remmina

[Joseph Oficre]

Hi.
I've configured freenx server on Centos machine and wanna connect to it
from my Openbsd.
unfortunately Opennx client doesnt work (session just crash after start),
but NX plugin with remmina works fine, BUT only fisrt connect.
If i want reconnect i get failed to bind on local port error, even if i
restart remmina. How can i determine what causes this problem? What logs
should i explore?
googled it, but didnt find any usefull info.
The same remmina with nx plugin works fine on debian machine.

PS: Sorry, if this kind of question is not allowed in this mailing list..

[solved]Re: bind: Permission denied

[Henrique Lengler]

On Wed, Dec 24, 2014 at 03:26:21AM +, Maurice McCarthy wrote:
 Have a look at the documentation installed with the port.
 
 $ pkg_info -L cmus
 
 will list all the files installed. There maybe something in
 /usr/local/share/doc/pkg-readmes
 Check the configuration files to see if you need to adjust anything.

I solved doing a chown in all the home to my userz

Regards,
-- 
Henrique Lengler

bind: Permission denied

[Henrique Lengler]

Hi,

When I try to run cmus in a normal user, I get

$ cmus
cmus: bind: Permission denied

I never heard about bind before, so I can't imagine a way to solve this.
Can someone help me?

Regards,
--
Henrique Lengler

Re: bind: Permission denied

[Maurice McCarthy]

On 2014-12-24 02:49, Henrique Lengler wrote:

Hi,

When I try to run cmus in a normal user, I get

$ cmus
cmus: bind: Permission denied

I never heard about bind before, so I can't imagine a way to solve 
this.

Can someone help me?

Regards,


I don't use cmus but it is something to do with keybindings
https://github.com/cmus/cmus/blob/master/Doc/cmus.txt

Re: bind: Permission denied

[Maurice McCarthy]

On 2014-12-24 03:15, Maurice McCarthy wrote:


I don't use cmus but it is something to do with keybindings
https://github.com/cmus/cmus/blob/master/Doc/cmus.txt


Have a look at the documentation installed with the port.

$ pkg_info -L cmus

will list all the files installed. There maybe something in 
/usr/local/share/doc/pkg-readmes

Check the configuration files to see if you need to adjust anything.

Re: OpenBSD 5.5: BIND lacks permission to create/modify journal...

[Jason Unovitch]

On 09/20/2014 10:33 PM, Andrew Lester wrote:

Hey Steve,

Thanks for the response. I actually found the solution. It turns out that the 
.jnl files are not the only ones that get modified when using DDNS. Performing 
a chown -R for named:named on /var/named/master fixed the problem. The actual 
zone data file, db.home.lan, also gets reformatted in the process, with the new 
entries. That seems a bit odd to me, I would have thought the whole point of 
the journal file is preventing the main datafile from being reformatted or 
changed.

Thanks so much,
Andrew


The journal is just to keep track of changes until they can get written 
to the zone file.  The journal here works the same way as a filesystem 
journal or transaction journal in a database.  An 'rndc sync -clean' 
will write updates to the zone file and remove the .jnl file so having 
permissions to update the zone file, .jnl file , as well as create a new 
.jnl file inside the directory should all be required.


-Jason

OpenBSD 5.5: BIND lacks permission to create/modify journal...

[Andrew Lester]

Hi all,

I am running OpenBSD 5.5-STABLE, and I am experiencing some frustration with 
BIND. I use 
it for my internal DNS which works great. However, I now need to do some work 
with Active
Directory and create a domain controller. I do not want to use the Microsoft 
DNS server,
I am trying to use my BIND server and keep things simple.

Problem:
The domain controller needs to perform dynamic DNS updates. Despite my best 
efforts,
the dynamic update sent from the domain controller to my BIND server always 
results in the
BIND server responding with a server failure (code 2) message.

Upon inspecting my named logs, this is the problem:

general: info: journal file master/db.home.lan.jnl does not exist, creating it
general: error: master/db.home.lan.jnl: create: permission denied

The zone journal file can't be created, presumably because the chrooted 
location BIND is
attempting to create the file (/var/named/master) only has permissions for 
root:wheel, not
the named user/group which the process runs as.

I thought I would be smart and do:
# touch /var/named/master/db.home.lan.jnl
# chmod 666 /var/named/master/db.home.jnl

This however also fails (even 777). I would see log entries for the dynamic 
updates now, but
then those are followed up with these errors:

update: info: client 192.168.1.250#51951: updating zone 'home.lan/IN': error: 
journal open failed: no more

This is my zone configuration in named.conf:

zone home.lan in {
type master;
file master/db.home.lan;
allow-update { 192.168.1.250; };
};

192.168.1.250 is the IP address of the domain controller. Note I am not using 
DNSSEC or
keys here. I am aware this is not particularly secure, but this is my personal 
network
and I just need to test some basic functionality with Active Directory.

Does anybody know what I can do to make the zone journal file be accessible by 
named?


Warm regards,
Andrew

Re: OpenBSD 5.5: BIND lacks permission to create/modify journal...

[Steve Shockley]

On 9/20/2014 1:46 PM, Andrew Lester wrote:

Does anybody know what I can do to make the zone journal file be accessible by 
named?


It's been a while since I set it up, but I gave up and made 
/var/named/master owned by named.  I also had to set 
managed-keys-directory /master in the config so managed-keys.bind and 
managed-keys.bind.jnl were writable.  I found ktrace to be helpful for 
debugging as well.  I probably should have documented everything I did...

Re: OpenBSD 5.5: BIND lacks permission to create/modify journal...

[Andrew Lester]

Hey Steve,

Thanks for the response. I actually found the solution. It turns out that the 
.jnl files are not the only ones that get modified when using DDNS. Performing 
a chown -R for named:named on /var/named/master fixed the problem. The actual 
zone data file, db.home.lan, also gets reformatted in the process, with the new 
entries. That seems a bit odd to me, I would have thought the whole point of 
the journal file is preventing the main datafile from being reformatted or 
changed.

Thanks so much,
Andrew

On Sep 20, 2014, at 5:18 PM, Steve Shockley steve.shock...@shockley.net wrote:

 On 9/20/2014 1:46 PM, Andrew Lester wrote:
 Does anybody know what I can do to make the zone journal file be accessible 
 by named?
 
 It's been a while since I set it up, but I gave up and made /var/named/master 
 owned by named.  I also had to set managed-keys-directory /master in the 
 config so managed-keys.bind and managed-keys.bind.jnl were writable.  I found 
 ktrace to be helpful for debugging as well.  I probably should have 
 documented everything I did...

syslogd fails to bind /dev/log with inet6

[Josh Grosse]

I have several machines running the August 29 i386 snapshot, one of which
is unable to create /dev/log.  I'm not clear on why the code path of the
failing machine is significantly different, or, why this particular
failure occurs.

It is repeatable on the failing platform.  In single user mode:

# mount -a
# syslogd
syslogd: bind: Can't assign requested address
#

ktrace shows that it is an error with inet6:

 19063 syslogd  CALL  bind(0x5,0x783d99e0,0x1c)
 19063 syslogd  STRU  struct sockaddr { AF_INET6, [::]:514 }
 19063 syslogd  RET   bind -1 errno 49 Can't assign requested address

I have implemented a simple circumvention, in rc.conf.local:

syslogd_flags=-4

Any clues to help isolate and repair would be appreciated.


OpenBSD 5.6-current (GENERIC.MP) #319: Fri Aug 29 03:07:28 MDT 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF
real mem  = 1064464384 (1015MB)
avail mem = 1034641408 (986MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/18/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS 
rev. 2.5 @ 0xf0720 (30 entries)
bios0: vendor American Megatrends Inc. version 1601 date 04/18/2011
bios0: ASUSTeK Computer INC. 1005HA
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4) P0P5(S4) 
P0P7(S4) P0P9(S4) P0P6(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 2
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (P0P5)
acpiprt2 at acpi0: bus 1 (P0P7)
acpiprt3 at acpi0: bus -1 (P0P6)
acpiec0 at acpi0
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpitz0 at acpi0: critical temperature is 88 degC
acpibat0 at acpi0: BAT0 model 1005HA serial   type LION oem ASUS
acpiac0 at acpi0: AC unit online
acpiasus0 at acpi0
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: PWRB
bios0: ROM list: 0xc/0xec00!
cpu0: Enhanced SpeedStep 1600 MHz: speeds: 1600, 1333, 1067, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82945GME Host rev 0x03
vga1 at pci0 dev 2 function 0 Intel 82945GME Video rev 0x03
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x600
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi
azalia0: codecs: Realtek ALC269
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 2 int 16
pci1 at ppb0 bus 4
ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 2 int 17
pci2 at ppb1 bus 2
athn0 at pci2 dev 0 function 0 Atheros AR9285 rev 0x01: apic 2 int 17
athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:25:d3:8a:f6:b4
ppb2 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 2 int 19
pci3 at ppb2 bus 1
alc0 at pci3 dev 0 function 0 Attansic Technology L2C rev 0xc0: msi, address 
90:e6:ba:37:cf:5e
atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 2 int 23
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 2 int 18
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 2 int 16
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2
pci4 at ppb3 bus 5
ichpcib0 at pci0 dev 31 function 0 Intel 82801GBM LPC rev 0x02: PM disabled
ahci0 at pci0 dev 31 function 2 Intel 82801GBM AHCI rev 0x02: msi, AHCI 1.1
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: ATA, ST9160314AS, 0002 SCSI3 0/direct fixed 
naa

Re: syslogd fails to bind /dev/log with inet6

[Josh Grosse]

On Mon, Sep 01, 2014 at 01:26:07PM -0400, Josh Grosse wrote:
 I have several machines running the August 29 i386 snapshot, one of which
 is unable to create /dev/log.  I'm not clear on why the code path of the
 failing machine is significantly different, or, why this particular
 failure occurs.
 
 It is repeatable on the failing platform.  In single user mode:
 
 # mount -a
 # syslogd
 syslogd: bind: Can't assign requested address
 #
 
 ktrace shows that it is an error with inet6:
 
  19063 syslogd  CALL  bind(0x5,0x783d99e0,0x1c)
  19063 syslogd  STRU  struct sockaddr { AF_INET6, [::]:514 }
  19063 syslogd  RET   bind -1 errno 49 Can't assign requested address
 
 I have implemented a simple circumvention, in rc.conf.local:
 
 syslogd_flags=-4
 

I neglected to state that syslogd.conf is the default r1.17 from 2005, without
local modification.

link-local and bind

[babut]

have a problem with bind(fe80::222:4dff:fe9d:e4e8%em0) and 
ipv6-client(fe80::e0bf:7fff:9954:d5ff) query:
named[10809]: .. client: warning: client fe80::e0bf:7fff:9954:d5ff#55536: error 
sending response: network unreachable

i wiped out all rejects from netstart, but dont known what add to the routing 
table for fe80::/10
route add fe80::/10 fe80::222:4dff:fe9d:e4e8 -priority 2 -ifp em0 does not 
help

Re: bind port broken

[Stuart Henderson]

Stéphane Guedon stephane at 22decembre.eu writes:

 I don't know if I am doing things ok, but the Bind9 port seems broken 
 (in a fresh 5.5 install).
 
 Thanks if someone fix it.

Is there a particular reason you're not just using the packages provided?
I see no advantage to building it yourself.

# pkg_add isc-bind

Re: bind port broken

[Stéphane Guedon]

Le mardi 20 mai 2014, 12:41:35 Stuart Henderson a écrit :
 Stéphane Guedon stephane at 22decembre.eu writes:
  I don't know if I am doing things ok, but the Bind9 port seems
  broken (in a fresh 5.5 install).
 
  Thanks if someone fix it.

 Is there a particular reason you're not just using the packages
 provided? I see no advantage to building it yourself.

 # pkg_add isc-bind

yeah, actually it seems to have solved the trick…
But at the same I have fixed some others… All in all, I improved my
setup !

Thanks !

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

bind port broken

[Stéphane Guedon]

hello.

I don't know if I am doing things ok, but the Bind9 port seems broken 
(in a fresh 5.5 install).

Thanks if someone fix it.

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: bind port broken

[Stéphane Guedon]

Le lundi 19 mai 2014 14:59:54, vous avez écrit :
 You provide zero details on what you are doing, how can someone know
 what to fix without the minimum bits of information.

I was aware of the thing, yet didn't know what to do since I have done
really really few.

I just placed myself in /usr/ports/net/isc-bind and launched a make
clean, then make as explained on the faq page.

Then, make produced a lot of compil work which ended at :

Error while executing cc -o .libs/named -pthread -I/usr/obj/ports/isc-
bind-9.9.3pl1/build-amd64 -I/usr/obj/ports/isc-
bind-9.9.3pl1/bind-9.9.3-P1/bin/named/include -I/usr/obj/ports/isc-
bind-9.9.3pl1/bind-9.9.3-P1/bin/named/unix/include -I. -
I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/lwres/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/lwres/unix/include
-I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/lwres/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/dns/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/dns/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/bind9/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/bind9/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/isccfg/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isccfg/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/isccc/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isccc/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/isc/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isc -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isc/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isc/unix/include -
I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-
P1/lib/isc/pthreads/include -I/usr/obj/ports/isc-
bind-9.9.3pl1/bind-9.9.3-P1/lib/isc/x86_32/include -D_REENTRANT -
DOPENSSL -O2 -pipe -I/usr/local/include/libxml2 -I/usr/local/include -
W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -
Wpointer-arith -fno-strict-aliasing builtin.o client.o config.o
control.o controlconf.o interfacemgr.o listenlist.o log.o logconf.o
main.o notify.o query.o server.o sortlist.o statschannel.o tkeyconf.o
tsigconf.o update.o xfrout.o zoneconf.o lwaddr.o lwresd.o lwdclient.o
lwderror.o lwdgabn.o lwdgnba.o lwdgrbn.o lwdnoop.o lwsearch.o
unix/os.o unix/dlz_dlopen_driver.o -L.libs -llwres -lbind9 -lisccfg -
ldns -lcrypto -lisccc -lisc -lpthread -lxml2 -lz -liconv -lm -Wl,-
rpath-link,/usr/local/lib
*** Error 2 in bin/named (Makefile:559 'named')
*** Error 1 in bin (Makefile:100 'subdirs')
*** Error 1 in /usr/obj/ports/isc-bind-9.9.3pl1/build-amd64
(Makefile:107 'subdirs')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2659
'/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/.build_done')
*** Error 1 in /usr/ports/net/isc-bind
(/usr/ports/infrastructure/mk/bsd.port.mk:2388 'all')

The release is bind 9.9.3, I am on amd64 and my openbsd is a 5.5 just
upgraded (so I had to rebuild my bind cause it contains the dnssec
signer I use).

I tried to compil manually bind 9.10 from the release available on
the isc website and get this error as well :

*** Error 1 in lib/samples (Makefile:486 'resolve')
*** Error 1 in lib (Makefile:100 'subdirs')
*** Error 1 in /usr/local/src/bind-9.10.0-P1 (Makefile:105 'subdirs')

hope you get better info now.


 Reading this page http://www.openbsd.org/report.html could help you.

 -luis

 On Mon, May 19, 2014 at 2:53 PM, Stéphane Guedon
steph...@22decembre.euwrote:
  hello.
 
  I don't know if I am doing things ok, but the Bind9 port seems
  broken (in a fresh 5.5 install).
 
  Thanks if someone fix it.
 
  [demime 1.01d removed an attachment of type
  application/pgp-signature which had a name of signature.asc]

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: bind port broken

[Jérémie Courrèges-Anglas]

Stéphane Guedon steph...@22decembre.eu writes:

 Le lundi 19 mai 2014 14:59:54, vous avez écrit :
 You provide zero details on what you are doing, how can someone know
 what to fix without the minimum bits of information.

 I was aware of the thing, yet didn't know what to do since I have done
 really really few.

 I just placed myself in /usr/ports/net/isc-bind and launched a make
 clean, then make as explained on the faq page.

 Then, make produced a lot of compil work which ended at :

[...]

 *** Error 2 in bin/named (Makefile:559 'named')
 *** Error 1 in bin (Makefile:100 'subdirs')
 *** Error 1 in /usr/obj/ports/isc-bind-9.9.3pl1/build-amd64
 (Makefile:107 'subdirs')
 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2659
 '/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/.build_done')
 *** Error 1 in /usr/ports/net/isc-bind
 (/usr/ports/infrastructure/mk/bsd.port.mk:2388 'all')

 The release is bind 9.9.3, I am on amd64 and my openbsd is a 5.5 just
 upgraded (so I had to rebuild my bind cause it contains the dnssec
 signer I use).

$ cd /usr/ports/net/isc-bind  cvs up -r OPENBSD_5_5 Makefile

gives me a 9.9.5 bind port, not 9.9.3.  Confusing...

[...]


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

[cwm] menusearch/exec bind problem

[Jiri B]

Hi,

I have following configuration:

$ egrep search|exec .cwmrc
bind 4-p menusearch
bind C-/ exec

But even after restart, C-/ shows me menusearch (application)
search, instead of search for command.

I tried even this but same situation:

bind 4-p menusearch
bind C-/ unbind
bind C-/ exec

Any idea?

PS: Does exist any specific list or IRC channel for cwm?

jirib

Re: [cwm] menusearch/exec bind problem

[Okan Demirmen]

There's no keysym /, but there is one called slash.

On Fri, Jan 10, 2014 at 5:35 PM, Jiri B ji...@devio.us wrote:
 Hi,

 I have following configuration:

 $ egrep search|exec .cwmrc
 bind 4-p menusearch
 bind C-/ exec

 But even after restart, C-/ shows me menusearch (application)
 search, instead of search for command.

 I tried even this but same situation:

 bind 4-p menusearch
 bind C-/ unbind
 bind C-/ exec

 Any idea?

 PS: Does exist any specific list or IRC channel for cwm?

 jirib

Re: [cwm] menusearch/exec bind problem

[Jiri B]

On Fri, Jan 10, 2014 at 05:55:11PM -0500, Okan Demirmen wrote:
 There's no keysym /, but there is one called slash.

Yes, thank you (both). So...

literally - cwmrc syntax:

C-/ - C-slash
C-? - C-question
C-? - SC-slash

jirib

 On Fri, Jan 10, 2014 at 5:35 PM, Jiri B ji...@devio.us wrote:
  Hi,
 
  I have following configuration:
 
  $ egrep search|exec .cwmrc
  bind 4-p menusearch
  bind C-/ exec
 
  But even after restart, C-/ shows me menusearch (application)
  search, instead of search for command.
 
  I tried even this but same situation:
 
  bind 4-p menusearch
  bind C-/ unbind
  bind C-/ exec
 
  Any idea?
 
  PS: Does exist any specific list or IRC channel for cwm?
 
  jirib

Re: [cwm] menusearch/exec bind problem

[Thomas Adam]

On 10 January 2014 22:35, Jiri B ji...@devio.us wrote:
 Hi,

 I have following configuration:

 $ egrep search|exec .cwmrc
 bind 4-p menusearch
 bind C-/ exec

 But even after restart, C-/ shows me menusearch (application)
 search, instead of search for command.

It's slash, not / in X11 parlance.

 PS: Does exist any specific list or IRC channel for cwm?

We have ##cwm on Freenode.

-- Thomas Adam

Re: Bind with GSSAPI

[Remco]

Jeff Powell wrote:

 I've been tearing my hair out trying to get this to work.  I'm running
 OpenBSD 5.3 x64 and I'm trying to build isc-bind from ports using the
 -with-gssapi in the Makefile (I want to have the -g option in nsupdate so
 I can use iscp-dhcp to register  dynamic DNS updates against a secure
 Windows nameserver).
 I've specified --with-gssapi=/usr in the Makefile.  Now, OpenBSD seems to
 put the gssapi.h in /usr/include/kerberosV, and krb5.h is there too.

You need to tell the compiler to look for include files in that directory. 
Setting up CFLAGS to do so might help.

Scanning the ports tree to see how other ports deal with this may be 
worthwhile too.

 Yet,  when I make the port it gives the following errors:
 
 checking for GSSAPI library... looking in /usr/lib checking gssapi.h
 usability... no checking gssapi.h presence... no checking for gssapi.h...
 no checking gssapi/gssapi.h usability... no checking gssapi/gssapi.h
 presence... no checking for gssapi/gssapi.h... no configure: error:
 gssapi.h not found
 

If the above doesn't help, did you check the output of config.log ? It may 
give you a more exact reason for this failure.

 I've tried adding symlinks here and there, but nothing works.  I also see
 that the configure script wants to tack /lib onto the end of whatever path
 I enter for --with-gssapi=, even though the .h files aren't located in any
 such folder.
 

Did you check whether this option actually modifies the include file search 
path in any way ? If it somehow sets a hardcoded path you probably need to 
cook up a patch yourself.

 Am I doing something wrong?  I'd appreciate any insights.
 

You're posting too often in too many places on a short notice.

 Thanks,
 
 Jeff

Building bind with gssapi

[Jeff Powell]

I've been tearing my hair out trying to get this to work.  I'm running OpenBSD 
5.3 x64 and I'm trying to build isc-bind from ports using the -with-gssapi in 
the Makefile (I want to have the -g option in nsupdate so I can use iscp-dhcp 
to register  dynamic DNS updates against a secure Windows nameserver).
I've specified --with-gssapi=/usr in the Makefile.  Now, OpenBSD seems to put 
the gssapi.h in /usr/include/kerberosV, and krb5.h is there too.  Yet, when I 
make the port it gives the following errors:

checking for GSSAPI library... looking in /usr/lib
checking gssapi.h usability... no
checking gssapi.h presence... no
checking for gssapi.h... no
checking gssapi/gssapi.h usability... no
checking gssapi/gssapi.h presence... no
checking for gssapi/gssapi.h... no
configure: error: gssapi.h not found

I've tried adding symlinks here and there, but nothing works.  I also see that 
the configure script wants to tack /lib onto the end of whatever path I enter 
for --with-gssapi=, even though the .h files aren't located in any such folder.

Am I doing something wrong?  I'd appreciate any insights.

Thanks,

Jeff

Jeff Powell
Systems Administrator
Valley Services Electronics
(408) 284-7751

Bind with GSSAPI

[Jeff Powell]

I've been tearing my hair out trying to get this to work.  I'm running OpenBSD 
5.3 x64 and I'm trying to build isc-bind from ports using the -with-gssapi in 
the Makefile (I want to have the -g option in nsupdate so I can use iscp-dhcp 
to register  dynamic DNS updates against a secure Windows nameserver).
I've specified --with-gssapi=/usr in the Makefile.  Now, OpenBSD seems to put 
the gssapi.h in /usr/include/kerberosV, and krb5.h is there too.  Yet, when I 
make the port it gives the following errors:

checking for GSSAPI library... looking in /usr/lib checking gssapi.h 
usability... no checking gssapi.h presence... no checking for gssapi.h... no 
checking gssapi/gssapi.h usability... no checking gssapi/gssapi.h presence... 
no checking for gssapi/gssapi.h... no
configure: error: gssapi.h not found

I've tried adding symlinks here and there, but nothing works.  I also see that 
the configure script wants to tack /lib onto the end of whatever path I enter 
for --with-gssapi=, even though the .h files aren't located in any such folder.

Am I doing something wrong?  I'd appreciate any insights.

Thanks,

Jeff

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Kostas Zorbadelos]

Claudio Jeker cje...@diehard.n-r-g.com writes:

 Don't forget to increase the UDP recvbuffer space. The default is somewhat
 small and will result in drops. At least you should invest some time to
 play with that value and see if it helps.

I played with the net.inet.udp.recvspace sysctl option today. The
maximum allowed value for it is 262144. After that things break (as in
no daemons start, network is disabled and during boot I get the message
ifconfig: socket: No buffer space available). I guess I am reaching some
sort of kernel limit, without producing kernel panic. 

With the maximum value I do see udp packet drops in my tests (that
increase as the test provides larger query rates)

root@dmeg-dns1 ~ # netstat -s -p udp 
udp:
268217 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
194 with no checksum
267842 input packets hardware-checksummed
0 output packets hardware-checksummed
130 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to missing IPsec protection
64705 dropped due to full socket buffers
^
203382 delivered
212059 datagrams output
187019 missed PCB cache 
 
Unfortunately I see no real difference in BIND's performance with the
values I tested (262144, 131072). 

-- 
Kostas Zorbadelos   
twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba 

()  www.asciiribbon.org - against HTML e-mail  proprietary attachments
/\  

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Kostas Zorbadelos]

Stuart Henderson s...@spacehopper.org writes:

 On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote:
 root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with
 --enable-shared' '--enable-threads'

 You could try rebuilding the port without --enable-threads and see if it's 
 any different.


I rebuilt the port without threads

root@dmeg-dns1 ~ # /usr/local/sbin/named -V
BIND 9.9.2-P2 built with '--enable-shared' '--with-libtool'
'--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man'
'--infodir=/usr/local/info' '--localstatedir=/var'
'--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2 -pipe' 'CXX=c++'
'CXXFLAGS=-O2 -pipe'
using OpenSSL version: OpenSSL 1.0.1c 10 May 2012
using libxml2 version: 2.8.0

There was no great difference in performance. I could see in the
multi-threaded BIND version CPU utilization of up to 300% (Linux showed
up to 800% on the same tests).
In repeating tests with
resperf (to have a full cache) and giving more slack in the rampup time
of the queries (resperf -r 240 -s server IP -d recorded_queries) I
was able to reach around 20K queries / sec on my hardware, half the
performance of Linux on the same hardware, BIND version and
configuration. PF disabled.

Might also test unbound. If I do, I will post the results.

PS: I think I saw a slight improvement using -U 4 (provided by the
port's init script)
 
-- 
Kostas Zorbadelos   
twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba 

()  www.asciiribbon.org - against HTML e-mail  proprietary attachments
/\  

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Claudio Jeker]

On Mon, Apr 22, 2013 at 04:50:52PM +0300, Kostas Zorbadelos wrote:
 Stuart Henderson s...@spacehopper.org writes:
 
  On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote:
  root@dmeg-dns1 ~ # /usr/local/sbin/named -V BIND 9.9.2-P2 built with
  --enable-shared' '--enable-threads'
 
  You could try rebuilding the port without --enable-threads and see if it's 
  any different.
 
 
 I rebuilt the port without threads
 
 root@dmeg-dns1 ~ # /usr/local/sbin/named -V
 BIND 9.9.2-P2 built with '--enable-shared' '--with-libtool'
 '--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man'
 '--infodir=/usr/local/info' '--localstatedir=/var'
 '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2 -pipe' 'CXX=c++'
 'CXXFLAGS=-O2 -pipe'
 using OpenSSL version: OpenSSL 1.0.1c 10 May 2012
 using libxml2 version: 2.8.0
 
 There was no great difference in performance. I could see in the
 multi-threaded BIND version CPU utilization of up to 300% (Linux showed
 up to 800% on the same tests).
 In repeating tests with
 resperf (to have a full cache) and giving more slack in the rampup time
 of the queries (resperf -r 240 -s server IP -d recorded_queries) I
 was able to reach around 20K queries / sec on my hardware, half the
 performance of Linux on the same hardware, BIND version and
 configuration. PF disabled.
 
 Might also test unbound. If I do, I will post the results.
 
 PS: I think I saw a slight improvement using -U 4 (provided by the
 port's init script)
  

Don't forget to increase the UDP recvbuffer space. The default is somewhat
small and will result in drops. At least you should invest some time to
play with that value and see if it helps.

-- 
:wq Claudio

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Aaron Glenn]

I've never used BIND in this sort of instance, so I can't speak to that. I
can say, however, I've run reasonably large authoritative anycast DNS
setups with NSD and OpenBSD. two north american sites, 10Kqps average, with
one notable 80K spike.

the whole system ran practically untouched (minor BGPd and NSD patches) for
two years.

ymmv


On Sat, Apr 20, 2013 at 3:18 PM, Stuart Henderson s...@spacehopper.orgwrote:

 On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote:
  root@dmeg-dns1 ~ # /usr/local/sbin/named -V
 BIND 9.9.2-P2 built with
 '--enable-shared' '--enable-threads'

 You could try rebuilding the port without --enable-threads and see if it's
 any different.

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Stuart Henderson]

On 2013-04-19, Kostas Zorbadelos kzo...@otenet.gr wrote:
 root@dmeg-dns1 ~ # /usr/local/sbin/named -V   
   BIND 9.9.2-P2 built with 
 '--enable-shared' '--enable-threads'

You could try rebuilding the port without --enable-threads and see if it's any 
different.

Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Kostas Zorbadelos]

Hello all,

quite a few months ago I had evaluated OpenBSD for a large scale anycast
DNS resolving setup:

http://marc.info/?l=openbsd-miscm=133828399728289w=2

The findings at the time (using VMs in a lab environment) was that
OpenBSD failed to meet my performance requirements and the main
suspicion was the lack of kernel-level thread support that could be
utilized by BIND.
Since then we purchased real hardware (Dell R620), with complete dmesg
attached and I decided to re-evaluate OpenBSD just before the 5.3
release. 

# sysctl hw
hw.machine=amd64
hw.model=Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
hw.ncpu=12
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0:a8089dcaa911bf20,cd0:
hw.diskcount=2
hw.sensors.cpu0.temp0=73.00 degC
hw.sensors.cpu1.temp0=73.00 degC
hw.sensors.cpu2.temp0=73.00 degC
hw.sensors.cpu3.temp0=73.00 degC
hw.sensors.cpu4.temp0=73.00 degC
hw.sensors.cpu5.temp0=73.00 degC
hw.sensors.cpu6.temp0=73.00 degC
hw.sensors.cpu7.temp0=73.00 degC
hw.sensors.cpu8.temp0=73.00 degC
hw.sensors.cpu9.temp0=73.00 degC
hw.sensors.cpu10.temp0=73.00 degC
hw.sensors.cpu11.temp0=73.00 degC
hw.sensors.mfi0.drive0=online (sd0), OK
hw.cpuspeed=2800
hw.vendor=Dell Inc.
hw.product=PowerEdge R620
hw.serialno=4J89G5J
hw.uuid=44454c4c-4a00-1038-8039-b4c04f47354a
hw.physmem=17082220544
hw.usermem=17082163200
hw.ncpufound=12
hw.allowpowerdown=1

I used the isc bind 9.9 port generously provided by Stuart using default
compile options on a snapshot:

root@dmeg-dns1 ~ # uname -a
OpenBSD dmeg-dns1.otenet.gr 5.3 GENERIC.MP#40 amd64

root@dmeg-dns1 ~ # /usr/local/sbin/named -V 
BIND 9.9.2-P2 built with '--enable-shared' 
'--enable-threads'
'--with-libtool' '--prefix=/usr/local' '--sysconfdir=/etc'
'--mandir=/usr/local/man' '--infodir=/usr/local/info'
'--localstatedir=/var' '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2
-pipe' 'CXX=c++' 'CXXFLAGS=-O2 -pipe'
using OpenSSL version: OpenSSL 1.0.1c 10 May 2012
using libxml2 version: 2.8.0

And using the following shell environment 

root@dmeg-dns1 /var/named # ulimit -a
time(cpu-seconds)unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 8388608
stack(kbytes)8192
lockedmem(kbytes)5409752
memory(kbytes)   16227120
nofiles(descriptors) 7030
processes1310

I started bind as  

root@dmeg-dns1 ~ # /usr/local/sbin/named -t /var/named/

The tests were conducted using two identical machines running CentOS 6.4
and the OpenBSD snapshot reffered to above. BIND configuration was
identical, a validating caching resolver setup. PF was disabled on
OpenBSD, while I had an IPtables ruleset on Linux.

Using Nominum's resperf (like in the last evaluation) I could achieve
~40K queries / sec on Linux (after 3 times resperf running with options
-s server IP -r 120 -d ~/recorded_queries) while only ~9K queries / sec
on OpenBSD (this is less than the current load on our nameservers).

Is there anything I could be missing or a configuration I should try,
before giving up? The thing is that the performance on OpenBSD was worse
than the last time I checked using a release without threading
support!!!

Any suggestions are highly welcome.

-- 
Kostas Zorbadelos   
twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba 

()  www.asciiribbon.org - against HTML e-mail  proprietary attachments
/\  

[demime 1.01d removed an attachment of type application/octet-stream]

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[mxb]

Give up.

For the record.
I had BIND on Ubuntu 12.04 on Dell R610. It constantly segfaulted for yet 
unknown reason (lazy to debug).
This machine was overloaded with resources.

However, not much of load as yours, but I'v tired of this and put all zones to 
R620 with OpenBSD 5.3.

So far not a sound of any slow queries because of segfaulted BIND-slave.

//mxb

On 19 apr 2013, at 16:36, Kostas Zorbadelos kzo...@otenet.gr wrote:

 Hello all,
 
 quite a few months ago I had evaluated OpenBSD for a large scale anycast
 DNS resolving setup:
 
 http://marc.info/?l=openbsd-miscm=133828399728289w=2
 
 The findings at the time (using VMs in a lab environment) was that
 OpenBSD failed to meet my performance requirements and the main
 suspicion was the lack of kernel-level thread support that could be
 utilized by BIND.
 Since then we purchased real hardware (Dell R620), with complete dmesg
 attached and I decided to re-evaluate OpenBSD just before the 5.3
 release. 
 
 # sysctl hw
 hw.machine=amd64
 hw.model=Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
 hw.ncpu=12
 hw.byteorder=1234
 hw.pagesize=4096
 hw.disknames=sd0:a8089dcaa911bf20,cd0:
 hw.diskcount=2
 hw.sensors.cpu0.temp0=73.00 degC
 hw.sensors.cpu1.temp0=73.00 degC
 hw.sensors.cpu2.temp0=73.00 degC
 hw.sensors.cpu3.temp0=73.00 degC
 hw.sensors.cpu4.temp0=73.00 degC
 hw.sensors.cpu5.temp0=73.00 degC
 hw.sensors.cpu6.temp0=73.00 degC
 hw.sensors.cpu7.temp0=73.00 degC
 hw.sensors.cpu8.temp0=73.00 degC
 hw.sensors.cpu9.temp0=73.00 degC
 hw.sensors.cpu10.temp0=73.00 degC
 hw.sensors.cpu11.temp0=73.00 degC
 hw.sensors.mfi0.drive0=online (sd0), OK
 hw.cpuspeed=2800
 hw.vendor=Dell Inc.
 hw.product=PowerEdge R620
 hw.serialno=4J89G5J
 hw.uuid=44454c4c-4a00-1038-8039-b4c04f47354a
 hw.physmem=17082220544
 hw.usermem=17082163200
 hw.ncpufound=12
 hw.allowpowerdown=1
 
 I used the isc bind 9.9 port generously provided by Stuart using default
 compile options on a snapshot:
 
 root@dmeg-dns1 ~ # uname -a
 OpenBSD dmeg-dns1.otenet.gr 5.3 GENERIC.MP#40 amd64
 
 root@dmeg-dns1 ~ # /usr/local/sbin/named -V   
   BIND 9.9.2-P2 built with 
 '--enable-shared' '--enable-threads'
 '--with-libtool' '--prefix=/usr/local' '--sysconfdir=/etc'
 '--mandir=/usr/local/man' '--infodir=/usr/local/info'
 '--localstatedir=/var' '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2
 -pipe' 'CXX=c++' 'CXXFLAGS=-O2 -pipe'
 using OpenSSL version: OpenSSL 1.0.1c 10 May 2012
 using libxml2 version: 2.8.0
 
 And using the following shell environment 
 
 root@dmeg-dns1 /var/named # ulimit -a
 time(cpu-seconds)unlimited
 file(blocks) unlimited
 coredump(blocks) unlimited
 data(kbytes) 8388608
 stack(kbytes)8192
 lockedmem(kbytes)5409752
 memory(kbytes)   16227120
 nofiles(descriptors) 7030
 processes1310
 
 I started bind as  
 
 root@dmeg-dns1 ~ # /usr/local/sbin/named -t /var/named/
 
 The tests were conducted using two identical machines running CentOS 6.4
 and the OpenBSD snapshot reffered to above. BIND configuration was
 identical, a validating caching resolver setup. PF was disabled on
 OpenBSD, while I had an IPtables ruleset on Linux.
 
 Using Nominum's resperf (like in the last evaluation) I could achieve
 ~40K queries / sec on Linux (after 3 times resperf running with options
 -s server IP -r 120 -d ~/recorded_queries) while only ~9K queries / sec
 on OpenBSD (this is less than the current load on our nameservers).
 
 Is there anything I could be missing or a configuration I should try,
 before giving up? The thing is that the performance on OpenBSD was worse
 than the last time I checked using a release without threading
 support!!!
 
 Any suggestions are highly welcome.
 
 -- 
 Kostas Zorbadelos 
 twitter:@kzorbadelos  http://gr.linkedin.com/in/kzorba 
 
 ()  www.asciiribbon.org - against HTML e-mail  proprietary attachments
 /\  
 
 [demime 1.01d removed an attachment of type application/octet-stream]

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Kostas Zorbadelos]

Kostas Zorbadelos kzo...@otenet.gr writes:

Here is the missing dmesg:

OpenBSD 5.3-current (GENERIC.MP) #40: Tue Mar 26 10:25:59 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17082220544 (16290MB)
avail mem = 16619790336 (15849MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (95 entries)
bios0: vendor Dell Inc. version 1.2.6 date 05/10/2012
bios0: Dell Inc. PowerEdge R620
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT EINJ 
TCPA SRAT SSDT
acpi0: wakeup devices PCI0(S5) PCI1(S5)
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) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.39 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 100MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu3: 256KB 64b/line 8-way L2 cache
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz
cpu4: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu4: 256KB 64b/line 8-way L2 cache
cpu5 at mainbus0: apid 10 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz
cpu5: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu5: 256KB 64b/line 8-way L2 cache
cpu6 at mainbus0: apid 1 (application processor)
cpu6: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz
cpu6: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu6: 256KB 64b/line 8-way L2 cache
cpu7 at mainbus0: apid 3 (application processor)
cpu7: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.01 MHz
cpu7: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu7: 256KB 64b/line 8-way L2 cache
cpu8 at mainbus0: apid 5 (application processor)
cpu8: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz
cpu8: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu8: 256KB 64b/line 8-way L2 cache
cpu9 at mainbus0: apid 7 (application processor)
cpu9: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz
cpu9: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu9: 256KB 64b/line 8-way L2 cache
cpu10 at 

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[mxb]

From mine point of view, OpenBSD is a stable OS (even some aged snapshots).
I don't put any performance pressure on it. I just want services to be STABLE.
If I want STABLE, I replace Linux or any other with OpenBSD.

//mxb

On 19 apr 2013, at 20:22, Kostas Zorbadelos kzo...@otenet.gr wrote:

 mxb m...@alumni.chalmers.se writes:
 
 Give up.
 
 For the record.
 I had BIND on Ubuntu 12.04 on Dell R610. It constantly segfaulted for yet 
 unknown reason (lazy to debug).
 This machine was overloaded with resources.
 
 However, not much of load as yours, but I'v tired of this and put all zones 
 to R620 with OpenBSD 5.3.
 
 So far not a sound of any slow queries because of segfaulted BIND-slave.
 
 
 Never had an issue with custom compiled latest BIND version on CentOS 5
 or 6. 
 Although I proceed with my project on CentOS Linux, I want to keep an
 eye to OpenBSD developments. I guess all the threading work is happening
 to give a performance boost and not the other way round, correct?
 Either way I am willing to test. 
 
 -- 
 Kostas Zorbadelos 
 twitter:@kzorbadelos  http://gr.linkedin.com/in/kzorba 
 
 ()  www.asciiribbon.org - against HTML e-mail  proprietary attachments
 /\  

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[Kostas Zorbadelos]

mxb m...@alumni.chalmers.se writes:

 From mine point of view, OpenBSD is a stable OS (even some aged snapshots).
 I don't put any performance pressure on it. I just want services to
 be STABLE. 

I really can't speak for the developers, but achieving less that 1/4 of
the performance of Linux for DNS and mainly, achieving LESS with thread
support than before threads sound like an issue to me.

Perhaps it is just the beginning of a lot of work than lies ahead after
the thread introduction.

 If I want STABLE, I replace Linux or any other with OpenBSD.


I don't see why stable and decently performant should be contradictory.

Regards
 
 //mxb

-- 
Kostas Zorbadelos   
twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba 

()  www.asciiribbon.org - against HTML e-mail  proprietary attachments
/\  

Re: Disappointing ISC BIND performance on OpenBSD 5.3 snapshot

[mxb]

Well,

I actually told you to Give up in my first mail :)
So do it.

In your env. in is(probably) better to run Linux. Do it.
I just tell you MINE point of view. If your don't want to hear it - I'll shut 
up.

P.S.
std. answer to ANY on this list - You ever contribute with code or you wait for 
your turn (or you solve it other way by yourself).

If you want it right - you have to do it yourself.

P.S.S.
No offense. It's just how it works in real world - you DO it yourself or you 
don't.
 
//mxb

On 19 apr 2013, at 21:57, Kostas Zorbadelos kzo...@otenet.gr wrote:

 mxb m...@alumni.chalmers.se writes:
 
 From mine point of view, OpenBSD is a stable OS (even some aged snapshots).
 I don't put any performance pressure on it. I just want services to
 be STABLE. 
 
 I really can't speak for the developers, but achieving less that 1/4 of
 the performance of Linux for DNS and mainly, achieving LESS with thread
 support than before threads sound like an issue to me.
 
 Perhaps it is just the beginning of a lot of work than lies ahead after
 the thread introduction.
 
 If I want STABLE, I replace Linux or any other with OpenBSD.
 
 
 I don't see why stable and decently performant should be contradictory.
 
 Regards
 
 //mxb
 
 -- 
 Kostas Zorbadelos 
 twitter:@kzorbadelos  http://gr.linkedin.com/in/kzorba 
 
 ()  www.asciiribbon.org - against HTML e-mail  proprietary attachments
 /\  

dhcpd seems not to bind to interface

[Jasper Bal]

Hi all,

I have dhcpd running on interface xl0:
$ps aux | grep dhcpd
_dhcp 6850  0.0  0.2   632  1020 ??  Is 3:24PM0:00.01 dhcpd xl0

xl0 is 1 of three interfaces on a gateway with ip forwarding enabled. 1 
interface services an internet line. 1 interface (dc0) services network 
192.168.2/24. xl0 services network 192.168.1/24.


My problem is that most of the time DHCP requests from network 2 are 
answered by the gateway (thales) with a network 1 address. I made a 
tcpdump of a typical DHCP process for the MAC adress involved 
(00:19:66:75:68:bf). Now in this case you see both thales and device 
192.168.2.254 (some fritzbox) making DHCP offers. Eventually you see the 
request setteling for address 192.168.2.6, which is desired but 
circumstantial. In my opinion thales should not have made it's offer 
(192.168.1.90) since the requesting device (xccube) is on a different 
network and therefor other device.


$sudo tcpdump -i xl0 -vvv -s 1500 '((port 67 or port 68) and (udp[38:4] 
= 0x19667568bf))'

tcpdump: listening on xl0, link-type EN10MB
16:21:53.149948 0.0.0.0.bootpc  255.255.255.255.bootps: [udp sum ok] 
xid:0x9cf53d1c vend-rfc1048 DHCP:DISCOVER T116:1 
CID:1.0.25.102.117.104.191 RQ:192.168.1.15 HN:xccube 
VC:77.83.70.84.32.53.46.48 PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+249+VO 
VO:220.0 (ttl 64, id 33544, len 328)
16:21:53.150850 192.168.2.254.bootps  255.255.255.255.bootpc: [udp sum 
ok] xid:0x9cf53d1c Y:192.168.2.6 S:192.168.2.254 ether 00:19:66:75:68:bf 
vend-rfc1048 DHCP:OFFER SID:192.168.2.254 LT:4294967295 SM:255.255.255.0 
DG:192.168.2.254 NS:192.168.2.254 (ttl 64, id 14904,len 328)
16:21:53.151374 thales.mercatortrading.nl.bootps  192.168.1.90.bootpc: 
[udp sum ok] xid:0x9cf53d1c Y:192.168.1.90 S:thales.mercatortrading.nl 
vend-rfc1048 DHCP:OFFER SID:thales.mercatortrading.nl LT:43200 
SM:255.255.255.0 DN:thales.mercatortrading.nl 
DG:thales.mercatortrading.nl 
NS:google-public-dns-a.google.com,google-public-dns-b.google.com 
RN:21600 RB:37800 [tos 0x10] (ttl 16, id 0, len 345)
16:21:56.145577 0.0.0.0.bootpc  255.255.255.255.bootps: [udp sum ok] 
xid:0x9cf53d1c vend-rfc1048 DHCP:REQUEST CID:1.0.25.102.117.104.191 
RQ:192.168.2.6 SID:192.168.2.254 HN:xccube T81:0,120,25443,30050,25902 
VC:77.83.70.84.32.53.46.48 PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+249+VO 
VO:220.1.0 (ttl 64, id 33593, len 341)
16:21:56.146466 thales.mercatortrading.nl.bootps  
255.255.255.255.bootpc: [udp sum ok] xid:0x9cf53d1c flags:0x8000 
S:thales.mercatortrading.nl ether 00:19:66:75:68:bf vend-rfc1048 
DHCP:NACK MSG:requested address not available [tos 0x10] (ttl 16, id 
0, len 328)
16:21:56.146758 192.168.2.254.bootps  255.255.255.255.bootpc: [udp sum 
ok] xid:0x9cf53d1c Y:192.168.2.6 S:192.168.2.254 ether 00:19:66:75:68:bf 
vend-rfc1048 DHCP:ACK SID:192.168.2.254 LT:4294967295 SM:255.255.255.0 
DG:192.168.2.254 NS:192.168.2.254 (ttl 64, id 14950, len 328)
16:22:00.145563 0.0.0.0.bootpc  255.255.255.255.bootps: [udp sum ok] 
xid:0x9cf53d1c vend-rfc1048 DHCP:REQUEST CID:1.0.25.102.117.104.191 
RQ:192.168.2.6 SID:192.168.2.254 HN:xccube T81:0,120,25443,30050,25902 
VC:77.83.70.84.32.53.46.48 PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+249+VO 
VO:220.1.0 (ttl 64, id 33602, len 341)
16:22:00.146482 192.168.2.254.bootps  255.255.255.255.bootpc: [udp sum 
ok] xid:0x9cf53d1c Y:192.168.2.6 S:192.168.2.254 ether 00:19:66:75:68:bf 
vend-rfc1048 DHCP:ACK SID:192.168.2.254 LT:4294967295 SM:255.255.255.0 
DG:192.168.2.254 NS:192.168.2.254 (ttl 64, id 15009, len 328)
16:22:00.146535 thales.mercatortrading.nl.bootps  
255.255.255.255.bootpc: [udp sum ok] xid:0x9cf53d1c flags:0x8000 
S:thales.mercatortrading.nl ether 00:19:66:75:68:bf vend-rfc1048 
DHCP:NACK MSG:requested address not available [tos 0x10] (ttl 16, id 
0, len 328)
16:22:06.474639 192.168.2.254.bootps  255.255.255.255.bootpc: [udp sum 
ok] xid:0xfb3941a6 C:192.168.2.6 Y:192.168.2.6 S:192.168.2.254 ether 
00:19:66:75:68:bf vend-rfc1048 DHCP:ACK SID:192.168.2.254 LT:4294967295 
SM:255.255.255.0 DG:192.168.2.254 NS:192.168.2.254 (ttl 64, id 15021, 
len 328)
16:22:06.497490 192.168.2.6.bootpc  255.255.255.255.bootps: [udp sum 
ok] xid:0x3bb5802a C:192.168.2.6 vend-rfc1048 DHCP:INFORM 
CID:1.0.25.102.117.104.191 HN:xccube VC:77.83.70.84.32.53.46.48 
PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+249+VO+252 VO:220.1.0 (ttl 64, id 
33628, len 328)
16:22:09.489187 192.168.2.6.bootpc  255.255.255.255.bootps: [udp sum 
ok] xid:0x3bb5802a secs:768 C:192.168.2.6 vend-rfc1048 DHCP:INFORM 
CID:1.0.25.102.117.104.191 HN:xccube VC:77.83.70.84.32.53.46.48 
PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+249+VO+252 VO:220.1.0 (ttl 64, id 
33677, len 328)


An arp lookup for ip 192.168.2.6 shows xccube indeed is on device dc0 
and not xl0

$arp 192.168.2.6
? (192.168.2.6) at 00:19:66:75:68:bf on dc0

The tcpdump was taken on interface xl0 (i.e. -i xl0). So it seems 
something is forwarding the traffic to the xl0 interface. I guess that 
is actually what ip forwarding means. Does anyone have any thoughts on 
how to tackle this?

Re: dhcpd seems not to bind to interface

[Jasper Bal]

Op 12/5/2012 7:50 PM, Martin Pelikan schreef:
Did you make sure you don't have any bridge accidentally between those 
two subnets (two cards going into the same switch or VLAN). Especially 
in buildings with complex wiring this mistake can easily happen. Local 
broadcast (255.255.255.255) packets are never forwarded to different 
interfaces (if not in a bridge). 

Hi Martin,

Facepalm... Thank you for your reply. Turns out interfaces dc0, xl0 and 
both subnets all came together on the same switch. The memories are 
starting to come back now. It was a long time ago in a galaxy far, far 
away. I was tired of mixing up the interfaces. Shoved everything in the 
switch. Made a mental note I should setup a VLAN for this. Forgot this 
within the hour.


Anyway, the tcpdump on xl0 is now quit. This is a tcpdump on the dc0 
interface with the -n and -e options you suggested:


$sudo tcpdump -n -e -i dc0 -vvv -s 1500 '((port 67 or port 68) and 
(udp[38:4] = 0x19667568bf))'

tcpdump: listening on dc0, link-type EN10MB
22:38:08.282731 00:19:66:75:68:bf ff:ff:ff:ff:ff:ff 0800 343: 
192.168.2.6.68  255.255.255.255.67: [udp sum ok] xid:0x2b6e0b3f 
C:192.168.2.6 vend-rfc1048 DHCP:REQUEST CID:1.0.25.102.117.104.191 
HN:xccube T81:0,120,25443,30050,25902 VC:77.83.70.84.32.53.46.48 
PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+249+VO VO:220.1.0 (ttl 64, id 41874, 
len 329)
22:38:08.283711 7c:4f:b5:93:47:b8 ff:ff:ff:ff:ff:ff 0800 342: 
192.168.2.254.67  255.255.255.255.68: [udp sum ok] xid:0x2b6e0b3f 
C:192.168.2.6 Y:192.168.2.6 S:192.168.2.254 ether 00:19:66:75:68:bf 
vend-rfc1048 DHCP:ACK SID:192.168.2.254 LT:4294967295 SM:255.255.255.0 
DG:192.168.2.254 NS:192.168.2.254 (ttl 64, id 6765, len 328)
22:38:10.822393 7c:4f:b5:93:47:b8 ff:ff:ff:ff:ff:ff 0800 342: 
192.168.2.254.67  255.255.255.255.68: [udp sum ok] xid:0xca7dd1a6 
C:192.168.2.6 Y:192.168.2.6 S:192.168.2.254 ether 00:19:66:75:68:bf 
vend-rfc1048 DHCP:ACK SID:192.168.2.254 LT:4294967295 SM:255.255.255.0 
DG:192.168.2.254 NS:192.168.2.254 (ttl 64, id 6766, len 328)


Thanks again!

Cheers,
Jasper

Re: NSD vs BIND

[Martin Pelikan]

2012/8/22, Gabriel Kihlman g...@stacken.kth.se:
 Chris Cappuccio ch...@nmedia.net writes:

 I don't think the in-tree bind supports dnssec.

 Just for the archives; it does, I am using it.

It does not support NSEC3 records, which in today's world can result
in bad queries (there's a hash inside of a readable domain name) and
consequently in someone's website being inaccessible.

There's a reason BIND is being updated, but unfortunately more reasons
why it's not done so in OpenBSD base. Most of them have a CVE article
already. If I were you, I'd consider BIND in our base as a legacy
option and go straight for NSD.

Seriously, it's just a matter of time before someone in your network
notices this and will wonder why some websites load and others not.
-- 
Martin Pelikan

Re: NSD vs BIND

[David Walker]

Mikkel Bang facebookmannen () gmail ! com
 For authoritative nameservers

Disregarding other reasons, easier documentation and simpler
configuration are definite wins ...

Re: NSD vs BIND

[John Bond]

On 22 August 2012 04:57, Mikkel Bang facebookman...@gmail.com wrote:
 Hello!

 For authoritative nameservers - which do you guys prefer, NSD or BIND?
NSD requires a restart of the daemon to add or remove zones (this
should be resolved in nsd 4).  So if this is something you do a lot
and you need to avoid down time i would go with bind.  In relation to
dnssec belive 9.4.2 is able to serve a DNSSEC signed zone; however
there where a few things it didn't support NSEC3 (avalible in 9.5) and
sha256 (available in 9.7).  If you are serving a simple zone and you
dont care about nsec3 then you could probably get away with using the
bind in base although you may be asking for trouble.

Re: NSD vs BIND

[Gabriel Kihlman]

Chris Cappuccio ch...@nmedia.net writes:

 I don't think the in-tree bind supports dnssec. 

Just for the archives; it does, I am using it.

/gabriel