IPv6 with wide-dhcpv6
Comcast provides me with IPv6 via DHCPv6, which I've finally tried to configure on my OpenBSD 6.1 router. I am having difficulty maintaining my IPv6 public IP address when using the wide-dhcpv6 package when in client mode. Specifically, when the pltime/vltime goes to zero, the address is removed from the interface but dhcp6c doesn't seem interested in renewing either before or after this happens until I manually send it a HUP. When running tcpdump, I see the following RA packet(s) but do not see the prefixes in my routing table. 13:27:09.986879 fe80::201:5cff:fe86:7046 > ff02::1: icmp6: router advertisement(chlim=0, MO, pref=medium, router_ltime=1800, reachable_time=360, retrans_time=1000)(prefix info: valid_ltime=604800, preferred_ltime=302400, prefix=2001:558:4083:17::/64)(prefix info: valid_ltime=604800, preferred_ltime=302400, prefix=2001:558:5018:69::/64)(prefix info: valid_ltime=604800, preferred_ltime=302400, prefix=2001:558:6020:117::/64)(prefix info: valid_ltime=604800, preferred_ltime=302400, prefix=2001:558:8026:22::/64) [icmp6 cksum ok] (len 144, hlim 255) Several questions: - Have I configured something wrong? - Should the RA prefixes appear in my routing table? Is this related at all to my issues? - I plan to get prefix delegation going eventually, are there any other surprises to worry about? - Is there a security/quality preference between wide-dhcpv6 and dhcpcd? I notice that dhcp6c doesn't appear to support a dedicated chroot/user... - Does the project have any near-term plans to write a DHCPv6 daemon to live in base? Happy to provide further info; thanks in advance for any feedback. --david
Re: IPv6 with wide-dhcpv6
On Sat, Jul 15, 2017 at 2:17 AM, Stuart Henderson wrote: > On 2017-07-14, David Higgs wrote: > > Comcast provides me with IPv6 via DHCPv6, which I've finally tried to > > configure on my OpenBSD 6.1 router. I am having difficulty maintaining > my > > IPv6 public IP address when using the wide-dhcpv6 package when in client > > mode. > > Switch to dhcpcd, which has a workaround for the vltime/pltime bug, or > use a snapshot, where it has been fixed. Or both. > > > - Is there a security/quality preference between wide-dhcpv6 and > dhcpcd? I > > notice that dhcp6c doesn't appear to support a dedicated chroot/user... > > dhcpcd is more modern and actively maintained. I'm not aware of any > client that does DHCPv6-PD that has privsep though. > > > - Does the project have any near-term plans to write a DHCPv6 daemon to > > live in base? > > I'm not aware of any. > > After a good amount of trial and error, it appears that Comcast will only dole out a single /128 via DHCPv6. Annoying but easy enough to work around with pf(4) nat-to and some static RFC 4193 prefixes. No apparent problems when running dhcpcd. FWIW, I did notice that sometimes my upstream link does not have the accept_rtadv flag set (as per ndp -i $INTF), but I haven't investigated this in depth. Thanks! --david
relayd for TLS termination
I run several services on the same host and would like to consolidate
certificate management with the help of relayd.
Before:
- acme-client generates certificates via LE
- kibana running https on port 5601
- unifi running https on port 8443
- httpd running http+https on port 80
- daily.local script to install new certs and restart all services
when LE updates
After:
- register new LE domains for kibana and unifi
- switch kibana and unifi back to running http on localhost
- relayd transparently terminates all https and demuxes to http
service based on Host header
- daily.local has much fewer services to manage
First off, is this even possible with relayd?
Second, I am having difficulty grokking how to structure my
relayd.conf. Will I need one relay and protocol block for EACH
service? Do I need a pf.conf anchor if I am only using relay
behavior?
Lastly and perhaps indicative of my difficulties, I am having
difficulty building (or debugging) even a single host as
proof-of-concept using the config below. The relayd daemon starts
just fine, loading symlinked .crt and .key files. (Should
I be using the fullchain.pem instead?)
Behavior seems to vary based on client / environment - I have seen
both wget and curl complain about certificate verification (relaying
to :80), while curl on a different box reported an empty reply from
the server after timeout (relaying to 127.0.0.1:80).
Hints or clue sticks would be most appreciated.
--david
### relayd.conf
http protocol wwwproto {
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# seen in example, not sure of purpose
match request header set "Connection" value "close"
# notify client if relay failed
return error
# reject unknown hosts by default
block
# traffic for httpd, forward
pass request header "Host" value "example.com"
pass request header "Host" value "www.example.com"
}
relay wwwrelay {
listen on em1 port 443 tls
protocol wwwproto
transparent forward to lo port http
}
Re: relayd for TLS termination
On Sat, Apr 28, 2018 at 9:58 AM, Claudio Jeker wrote:
> On Sat, Apr 28, 2018 at 09:39:56AM -0400, David Higgs wrote:
>> I run several services on the same host and would like to consolidate
>> certificate management with the help of relayd.
>>
>> Before:
>> - acme-client generates certificates via LE
>> - kibana running https on port 5601
>> - unifi running https on port 8443
>> - httpd running http+https on port 80
>> - daily.local script to install new certs and restart all services
>> when LE updates
>>
>> After:
>> - register new LE domains for kibana and unifi
>> - switch kibana and unifi back to running http on localhost
>> - relayd transparently terminates all https and demuxes to http
>> service based on Host header
>> - daily.local has much fewer services to manage
>>
>> First off, is this even possible with relayd?
>
> More or less. relayd does not do SNI so you need to have per hostname or
> actually per certificate a different IP. Doing complicated rule based
> relays is not working all that well. So try to keep it simple one port one
> service.
Single IP, one hostname per port (and thereby service) at 1:1
correspondence. Hostnames will all be aliases on the same LE cert, so
it seems like SNI is not a problem.
>> Second, I am having difficulty grokking how to structure my
>> relayd.conf. Will I need one relay and protocol block for EACH
>> service? Do I need a pf.conf anchor if I am only using relay
>> behavior?
>
> Depends. You may be able to just use one 'http protocol' block that is
> referenced by multiple relays. It depends on the config.
> I think the pf.conf anchor is required even if you are not using
> redirects (I assume that relayd would even refuse to start without the
> anchor).
My pf.conf is a bit complex with tag usage, but I definitely wasn't
using the pf anchor. (Not sure if this is a bug?)
>> Lastly and perhaps indicative of my difficulties, I am having
>> difficulty building (or debugging) even a single host as
>> proof-of-concept using the config below. The relayd daemon starts
>> just fine, loading symlinked .crt and .key files. (Should
>> I be using the fullchain.pem instead?)
>
> Yes, you should use a full chain certificate else there is no trust anchor
> for the clients.
I was concerned that relayd might not grok PEM files - all the example
use .crt extensions.
>> Behavior seems to vary based on client / environment - I have seen
>> both wget and curl complain about certificate verification (relaying
>> to :80), while curl on a different box reported an empty reply from
>> the server after timeout (relaying to 127.0.0.1:80).
>>
>> Hints or clue sticks would be most appreciated.
>>
>> --david
>>
>> ### relayd.conf
>>
>> http protocol wwwproto {
>> tcp { nodelay, sack, socket buffer 65536, backlog 128 }
>
> Honestly most of this tuning is not helpful. sack and backlog may be OK
> but esp. changing the socket buffer will disable the automatic socket
> buffer scaling and leave you with a much smaller buffer then the default.
I'm not concerned about scale or performance; it was just present in
the example/relayd.conf.
>> # seen in example, not sure of purpose
>> match request header set "Connection" value "close"
>
> This tells the server to close the connection after each request and so no
> keep-alive is happening. In some cases this is needed. Especially when
> mutliple backends are used in match or pass rules.
Same as above.
>> # notify client if relay failed
>> return error
>> # reject unknown hosts by default
>> block
>> # traffic for httpd, forward
>> pass request header "Host" value "example.com"
>> pass request header "Host" value "www.example.com"
>
> I'm not sure why you do this. In general I leave the Host parsing to the
> backend servers. Also I think Host may include the port number if it is
> not a default port.
This was because I want relayd to demux the service/port based on the
"Host" header. I mainly hope to accomplish something like the
following, since httpd(8) doesn't support proxying.
tls on port 443 w/ "Host: unifi.example.com" => localhost port 8443, no tls
tls on port 443 w/ "Host: kibana.example.com" => localhost port 5601, no tls
tls on port 443 w/ "Host: www.example.com" => localhost port 80, no tls
anything else => error
>> }
>>
>> relay wwwrelay {
>> listen on em1 port 443 tls
>> protocol wwwproto
>> transparent forward to lo port http
>
> On hig volume servers I would not use transparent forwading but instead
> set the X-Forwarded-For header. Also transparent needs help from pf.
I was mainly looking to use default log configuration on my services.
This gives me plenty to work with; will experiment and report back, thanks.
--david
Re: relayd for TLS termination
On Sat, Apr 28, 2018 at 11:33 AM, David Higgs wrote:
> On Sat, Apr 28, 2018 at 9:58 AM, Claudio Jeker
> wrote:
>> On Sat, Apr 28, 2018 at 09:39:56AM -0400, David Higgs wrote:
>>> I run several services on the same host and would like to consolidate
>>> certificate management with the help of relayd.
>>>
>>> Before:
>>> - acme-client generates certificates via LE
>>> - kibana running https on port 5601
>>> - unifi running https on port 8443
>>> - httpd running http+https on port 80
>>> - daily.local script to install new certs and restart all services
>>> when LE updates
>>>
>>> After:
>>> - register new LE domains for kibana and unifi
>>> - switch kibana and unifi back to running http on localhost
>>> - relayd transparently terminates all https and demuxes to http
>>> service based on Host header
>>> - daily.local has much fewer services to manage
>>>
>>> First off, is this even possible with relayd?
>>
>> More or less. relayd does not do SNI so you need to have per hostname or
>> actually per certificate a different IP. Doing complicated rule based
>> relays is not working all that well. So try to keep it simple one port one
>> service.
>
> Single IP, one hostname per port (and thereby service) at 1:1
> correspondence. Hostnames will all be aliases on the same LE cert, so
> it seems like SNI is not a problem.
>
>>> Second, I am having difficulty grokking how to structure my
>>> relayd.conf. Will I need one relay and protocol block for EACH
>>> service? Do I need a pf.conf anchor if I am only using relay
>>> behavior?
>>
>> Depends. You may be able to just use one 'http protocol' block that is
>> referenced by multiple relays. It depends on the config.
>> I think the pf.conf anchor is required even if you are not using
>> redirects (I assume that relayd would even refuse to start without the
>> anchor).
>
> My pf.conf is a bit complex with tag usage, but I definitely wasn't
> using the pf anchor. (Not sure if this is a bug?)
>
>>> Lastly and perhaps indicative of my difficulties, I am having
>>> difficulty building (or debugging) even a single host as
>>> proof-of-concept using the config below. The relayd daemon starts
>>> just fine, loading symlinked .crt and .key files. (Should
>>> I be using the fullchain.pem instead?)
>>
>> Yes, you should use a full chain certificate else there is no trust anchor
>> for the clients.
>
> I was concerned that relayd might not grok PEM files - all the example
> use .crt extensions.
>
>>> Behavior seems to vary based on client / environment - I have seen
>>> both wget and curl complain about certificate verification (relaying
>>> to :80), while curl on a different box reported an empty reply from
>>> the server after timeout (relaying to 127.0.0.1:80).
>>>
>>> Hints or clue sticks would be most appreciated.
>>>
>>> --david
>>>
>>> ### relayd.conf
>>>
>>> http protocol wwwproto {
>>> tcp { nodelay, sack, socket buffer 65536, backlog 128 }
>>
>> Honestly most of this tuning is not helpful. sack and backlog may be OK
>> but esp. changing the socket buffer will disable the automatic socket
>> buffer scaling and leave you with a much smaller buffer then the default.
>
> I'm not concerned about scale or performance; it was just present in
> the example/relayd.conf.
>
>>> # seen in example, not sure of purpose
>>> match request header set "Connection" value "close"
>>
>> This tells the server to close the connection after each request and so no
>> keep-alive is happening. In some cases this is needed. Especially when
>> mutliple backends are used in match or pass rules.
>
> Same as above.
>
>>> # notify client if relay failed
>>> return error
>>> # reject unknown hosts by default
>>> block
>>> # traffic for httpd, forward
>>> pass request header "Host" value "example.com"
>>> pass request header "Host" value "www.example.com"
>>
>> I'm not sure why you do this. In general I leave the Host parsing to the
>> backend servers. Also I think Host may include the port number if it is
>> not a default port.
>
> This was because I want relayd to demux the service/port based on the
> "Host" header. I mainly hope to accomplish somet
Confusing IPv6 route(8) results
I am using route(8) in a script but found some odd behavior when querying routes for some IPv6 addresses - lookups seem to fail if the trailing address bytes are zero (implicit or explicitly) as shown below. However, the routing table still seems to be forwarding traffic correctly, as shown in my final example. Can anyone shed light on this, perhaps explain how I'm misusing route(8)? This is on amd64 running 6.3-stable. Thanks. --david $ route -n get 2607:f8b0:4004:805::2004 route to: 2607:f8b0:4004:805::2004 destination: :: mask: :: gateway: fe80:1::201:5cff:fe86:7046%em0 interface: em0 if address: fe80::5e8c:75d:e349:26fd%em0 priority: 56 (default) flags: label: slaacd use mtuexpire 220369 0 0 sockaddrs: $ route -n get 2607:f8b0:4004:805:: get net 2607:f8b0:4004:805::: not in table $ route -n get 2600:1901:0:94b6:: get net 2600:1901:0:94b6::: not in table $ ping6 2600:1901:0:94b6:: PING 2600:1901:0:94b6:: (2600:1901:0:94b6::): 56 data bytes 64 bytes from 2600:1901:0:94b6::: icmp_seq=0 hlim=54 time=10.302 ms 64 bytes from 2600:1901:0:94b6::: icmp_seq=1 hlim=54 time=11.270 ms
Re: Confusing IPv6 route(8) results
On Thu, May 24, 2018 at 5:35 AM Denis Fondras wrote: > Hi, > > On Wed, May 23, 2018 at 10:34:19PM -0400, David Higgs wrote: > > I am using route(8) in a script but found some odd behavior when > > querying routes for some IPv6 addresses - lookups seem to fail if the > > trailing address bytes are zero (implicit or explicitly) as shown > > below. However, the routing table still seems to be forwarding > > traffic correctly, as shown in my final example. > > > > Can anyone shed light on this, perhaps explain how I'm misusing route(8)? > > > > route is getting confused between host address and network address. > Try with route -n get 2607:f8b0:4004:805::/128 Awesome, that should fix my script. But shouldn’t the answer be the same, since I have a valid default route? —david
Re: relayd for TLS termination
On Sat, Apr 28, 2018 at 2:12 PM, David Higgs wrote:
> On Sat, Apr 28, 2018 at 11:33 AM, David Higgs wrote:
>> On Sat, Apr 28, 2018 at 9:58 AM, Claudio Jeker
>> wrote:
>>> On Sat, Apr 28, 2018 at 09:39:56AM -0400, David Higgs wrote:
>>>> I run several services on the same host and would like to consolidate
>>>> certificate management with the help of relayd.
>>>>
>>>> Before:
>>>> - acme-client generates certificates via LE
>>>> - kibana running https on port 5601
>>>> - unifi running https on port 8443
>>>> - httpd running http+https on port 80
>>>> - daily.local script to install new certs and restart all services
>>>> when LE updates
>>>>
>>>> After:
>>>> - register new LE domains for kibana and unifi
>>>> - switch kibana and unifi back to running http on localhost
>>>> - relayd transparently terminates all https and demuxes to http
>>>> service based on Host header
>>>> - daily.local has much fewer services to manage
>>>>
>>>> First off, is this even possible with relayd?
>>>
>>> More or less. relayd does not do SNI so you need to have per hostname or
>>> actually per certificate a different IP. Doing complicated rule based
>>> relays is not working all that well. So try to keep it simple one port one
>>> service.
>>
>> Single IP, one hostname per port (and thereby service) at 1:1
>> correspondence. Hostnames will all be aliases on the same LE cert, so
>> it seems like SNI is not a problem.
>>
>>>> Second, I am having difficulty grokking how to structure my
>>>> relayd.conf. Will I need one relay and protocol block for EACH
>>>> service? Do I need a pf.conf anchor if I am only using relay
>>>> behavior?
>>>
>>> Depends. You may be able to just use one 'http protocol' block that is
>>> referenced by multiple relays. It depends on the config.
>>> I think the pf.conf anchor is required even if you are not using
>>> redirects (I assume that relayd would even refuse to start without the
>>> anchor).
>>
>> My pf.conf is a bit complex with tag usage, but I definitely wasn't
>> using the pf anchor. (Not sure if this is a bug?)
>>
>>>> Lastly and perhaps indicative of my difficulties, I am having
>>>> difficulty building (or debugging) even a single host as
>>>> proof-of-concept using the config below. The relayd daemon starts
>>>> just fine, loading symlinked .crt and .key files. (Should
>>>> I be using the fullchain.pem instead?)
>>>
>>> Yes, you should use a full chain certificate else there is no trust anchor
>>> for the clients.
>>
>> I was concerned that relayd might not grok PEM files - all the example
>> use .crt extensions.
>>
>>>> Behavior seems to vary based on client / environment - I have seen
>>>> both wget and curl complain about certificate verification (relaying
>>>> to :80), while curl on a different box reported an empty reply from
>>>> the server after timeout (relaying to 127.0.0.1:80).
>>>>
>>>> Hints or clue sticks would be most appreciated.
>>>>
>>>> --david
>>>>
>>>> ### relayd.conf
>>>>
>>>> http protocol wwwproto {
>>>> tcp { nodelay, sack, socket buffer 65536, backlog 128 }
>>>
>>> Honestly most of this tuning is not helpful. sack and backlog may be OK
>>> but esp. changing the socket buffer will disable the automatic socket
>>> buffer scaling and leave you with a much smaller buffer then the default.
>>
>> I'm not concerned about scale or performance; it was just present in
>> the example/relayd.conf.
>>
>>>> # seen in example, not sure of purpose
>>>> match request header set "Connection" value "close"
>>>
>>> This tells the server to close the connection after each request and so no
>>> keep-alive is happening. In some cases this is needed. Especially when
>>> mutliple backends are used in match or pass rules.
>>
>> Same as above.
>>
>>>> # notify client if relay failed
>>>> return error
>>>> # reject unknown hosts by default
>>>> block
>>>> # traffic for httpd, forward
>>>> pass request header "Host" value "example.com"
>
iked.conf basics
I am looking to configure iked(8) on my OpenBSD router to provide IPsec services to remote clients. I would like to tunnel (nearly) all my traffic from my phone or laptop back into my home router, and leverage the services there (DNS, firewall, etc.), then either access my local network or the rest of the internet. I think I want my router to be a VPN proxy - is there more accurate/common terminology? I am having difficulty extracting what is and is not relevant from the iked.conf(5) man page, since this is new terminology to me. I believe that the first example is most appropriate for my router configuration, adapted something like this: # candidate iked.conf set mobike user "test" "password123" ikev2 esp \ eap "mschap-v2" \ config dhcp-server 10.0.0.1 The parts I'm confused on are the from/to and peer/local fields. Which pair describes the IPs of the tunnel endpoints, and which describes the traffic allowed to flow through the tunnel? I guess I don't know whether "IPsec flow" refers to the encapsulating ESP packets or the encapsulated traffic. Thanks for any help / cluebats. --david
Re: iked.conf basics
On Fri, Jun 1, 2018 at 4:09 AM, Stuart Henderson wrote: > On 2018-05-31, David Higgs wrote: >> I am looking to configure iked(8) on my OpenBSD router to provide >> IPsec services to remote clients. I would like to tunnel (nearly) all >> my traffic from my phone or laptop back into my home router, and >> leverage the services there (DNS, firewall, etc.), then either access >> my local network or the rest of the internet. >> >> The parts I'm confused on are the from/to and peer/local fields. >> Which pair describes the IPs of the tunnel endpoints, and which > > peer/local > >> describes the traffic allowed to flow through the tunnel? I guess I > > from/to > >> don't know whether "IPsec flow" refers to the encapsulating ESP >> packets or the encapsulated traffic. > > The "flow" is an SADB entry which matches traffic and selects it for > encapsulation. The addresses in a flow have to cover the packets sent > over the vpn. Great, these hints got me moving in what seems like the right direction. > Here's an iked example from my live config, it allows mobile clients to > connect and route all traffic over the VPN, assigning a dynamic address > from 192.168.47.160/27, with not-too-terrible ciphers for most typical > clients. > > ikev2 "vpn" passive esp from 0.0.0.0/0 to 0.0.0.0/0 \ > local x.x.x.x \ > peer any \ > ikesa enc aes-256 enc aes-128 prf hmac-sha2-256 auth > hmac-sha2-256 group ecp256 \ > ikesa enc aes-256 enc aes-128 prf hmac-sha2-256 prf hmac-sha1 auth > hmac-sha2-256 group ecp256 group modp2048 group modp1024 \ > childsa enc aes-256-gcm enc aes-128-gcm \ > childsa enc aes-256 enc aes-128 auth hmac-sha2-256 auth hmac-sha1 \ > srcid "my.host.name" \ > eap "mschap-v2" \ > config address 192.168.47.160/27 \ > config name-server x.x.x.x \ > tag "$name-$id" > > include "/etc/iked.users" > > If you have any Windows clients note that the default ciphers are > absolutely bloody useless, for the powershell snippets needed to fix > this see comments in https://github.com/trailofbits/algo/issues/9. > If you don't need to support Windows clients you can probably get > rid of hmac-sha1/group modp1024 and the non-gcm aes entries. This is only for iPhone / Mac clients at the moment. I have attacked configuration from several different angles and can't seem to get it working. # iked.conf user "myuser" "mypassword" set mobike ikev2 "vpn" passive esp \ from any to any \ local $external_ip_addr peer any \ srcid vpn.example.com \ eap "mschap-v2" \ config dhcp-server 10.0.128.1 # ikectl ca vpn create password ca-password # ca.example.com # ikectl ikectl ca vpn certificate vpn.example.com create server # ikectl ikectl ca vpn certificate client.example.com create client # ikectl ca vpn install # ikectl ca vpn certificate vpn.example.com install # ikectl ca vpn certificate client.example.com export password client-password I then copy and import ca/ca.crt, certs/vpn.example.com.crt, and export/client.example.com.pfx into my OS X and iPhone systems; with the CA trusted, everything appears to be validating. Only my "vpn.example.com" is resolvable via DNS, but I used FQDNs for everything except the "local" keyword in iked.conf (due to split-brain DNS shenanigans). I don't think this is the cause of my issues, but I mention it just in case... So with the PKI configured, I launch iked(8) with debugging and tcpdump running, then attempt to enable the VPN: # iked -vvd ikev2 "vpn" passive esp inet from any to any local $external_ip_addr peer any ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 srcid vpn.example.com lifetime 10800 bytes 536870912 eap "MSCHAP_V2" config dhcp-server 10.0.128.1 /etc/iked.conf: loaded 2 configuration rules ca_privkey_serialize: type RSA_KEY length 1194 ca_pubkey_serialize: type RSA_KEY length 270 config_new_user: inserting new user myuser user "myuser" "mypassword" ca_privkey_to_method: type RSA_KEY method RSA_SIG ca_getkey: received private key type RSA_KEY length 1194 ca_getkey: received public key type RSA_KEY length 270 ca_dispatch_parent: config reset config_getpolicy: received policy config_getpfkey: received pfkey fd 3 config_getcompile: compilation done config_getsocket: received socket fd 4 config_getsocket: received socket fd 5 config_getsocket: received socket fd 6 config_getsocket: received socket fd 7 config_getmobike: mobike ca_reload: loaded ca file ca.crt ca_reload: loaded crl
Re: iked.conf basics
On Fri, Jun 1, 2018 at 2:52 PM, David Higgs wrote: > On Fri, Jun 1, 2018 at 4:09 AM, Stuart Henderson wrote: >> On 2018-05-31, David Higgs wrote: >>> I am looking to configure iked(8) on my OpenBSD router to provide >>> IPsec services to remote clients. I would like to tunnel (nearly) all >>> my traffic from my phone or laptop back into my home router, and >>> leverage the services there (DNS, firewall, etc.), then either access >>> my local network or the rest of the internet. >>> >>> The parts I'm confused on are the from/to and peer/local fields. >>> Which pair describes the IPs of the tunnel endpoints, and which >> >> peer/local >> >>> describes the traffic allowed to flow through the tunnel? I guess I >> >> from/to >> >>> don't know whether "IPsec flow" refers to the encapsulating ESP >>> packets or the encapsulated traffic. >> >> The "flow" is an SADB entry which matches traffic and selects it for >> encapsulation. The addresses in a flow have to cover the packets sent >> over the vpn. > > Great, these hints got me moving in what seems like the right direction. > >> Here's an iked example from my live config, it allows mobile clients to >> connect and route all traffic over the VPN, assigning a dynamic address >> from 192.168.47.160/27, with not-too-terrible ciphers for most typical >> clients. >> >> ikev2 "vpn" passive esp from 0.0.0.0/0 to 0.0.0.0/0 \ >> local x.x.x.x \ >> peer any \ >> ikesa enc aes-256 enc aes-128 prf hmac-sha2-256 auth >> hmac-sha2-256 group ecp256 \ >> ikesa enc aes-256 enc aes-128 prf hmac-sha2-256 prf hmac-sha1 auth >> hmac-sha2-256 group ecp256 group modp2048 group modp1024 \ >> childsa enc aes-256-gcm enc aes-128-gcm \ >> childsa enc aes-256 enc aes-128 auth hmac-sha2-256 auth hmac-sha1 \ >> srcid "my.host.name" \ >> eap "mschap-v2" \ >> config address 192.168.47.160/27 \ >> config name-server x.x.x.x \ >> tag "$name-$id" >> >> include "/etc/iked.users" >> >> If you have any Windows clients note that the default ciphers are >> absolutely bloody useless, for the powershell snippets needed to fix >> this see comments in https://github.com/trailofbits/algo/issues/9. >> If you don't need to support Windows clients you can probably get >> rid of hmac-sha1/group modp1024 and the non-gcm aes entries. > > This is only for iPhone / Mac clients at the moment. I have attacked > configuration from several different angles and can't seem to get it > working. > > # iked.conf > user "myuser" "mypassword" > set mobike > ikev2 "vpn" passive esp \ > from any to any \ > local $external_ip_addr peer any \ > srcid vpn.example.com \ > eap "mschap-v2" \ > config dhcp-server 10.0.128.1 > > # ikectl ca vpn create password ca-password # ca.example.com > # ikectl ikectl ca vpn certificate vpn.example.com create server > # ikectl ikectl ca vpn certificate client.example.com create client > # ikectl ca vpn install > # ikectl ca vpn certificate vpn.example.com install > # ikectl ca vpn certificate client.example.com export password client-password > > I then copy and import ca/ca.crt, certs/vpn.example.com.crt, and > export/client.example.com.pfx into my OS X and iPhone systems; with > the CA trusted, everything appears to be validating. Only my > "vpn.example.com" is resolvable via DNS, but I used FQDNs for > everything except the "local" keyword in iked.conf (due to split-brain > DNS shenanigans). I don't think this is the cause of my issues, but I > mention it just in case... > > So with the PKI configured, I launch iked(8) with debugging and > tcpdump running, then attempt to enable the VPN: > > # iked -vvd > ikev2 "vpn" passive esp inet from any to any local $external_ip_addr > peer any ikesa enc aes-256,aes-192,aes-128,3des prf > hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group > modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth > hmac-sha2-256,hmac-sha1 srcid vpn.example.com lifetime 10800 bytes > 536870912 eap "MSCHAP_V2" config dhcp-server 10.0.128.1 > /etc/iked.conf: loaded 2 configuration rules > ca_privkey_serialize: type RSA_KEY length 1194 > ca_pubkey_serialize: type RSA_KEY length 270 > config_new_user: inserting new user myuser > user "myuser" "mypassword" > ca_privkey_to_method: type RSA_KEY method R
pf(4) queuing and interfaces
My wireless AP puts traffic from each WiFi network (trusted, guests,
etc.) into a separate VLAN, which are then picked up by my OpenBSD
router and filtered appropriately via pf rules.
In other words:
em1 is for untagged traffic to the AP itself
vlan100 has parent em1 and is for my "trusted" WLAN
vlan200 also has parent em1 and is for my "guest" WLAN
pf.conf includes the following line:
queue wlan_q on em1 bandwidth 50M max 50M flows 1024 qlimit 1024 default
When I specify only the queuing rule as shown above, is traffic sent
on vlanXXX also receive this queuing policy?
If not, should I divide the physical bandwidth between logical
interfaces? Does FQ-CoDel work correctly if they are each assigned
the full physical bandwidth? Or should I be dividing one or both of
the configurable interface rates?
And lastly, if I define a queue as below - does this expand into two
different queues with the same name or one queue with bandwidth shared
between two interfaces? Running "pfctl -vsq" indicates the former,
but I'd like to be sure.
queue some_q on { em2, em3 } bandwidth 95M max 95M flows 1024 qlimit
1024 default
Thanks.
--david
Re: pf: matching untagged traffic
On Tue, Jul 24, 2018 at 6:15 AM Damien Miller wrote: > Hi, > > Is it possible for pf to match traffic that has not been tagged? > It seems possible to match a tag, or traffic that lacks a particular tag > but I can't see any way to match traffic that has no tag at all? > > Any clues? > > Context: I'd like to tag at input particular traffic for specific > outbound processing but have a catch-all for everything else. Tag everything CATCHALL to start with, re-tag as you are currently doing, then process your CATCHALL packets. —david
Fwd: pf(4) queuing and interfaces
Resending now that the hackathon has died down.
—david
-- Forwarded message -
From: David Higgs
Date: Sun, Jul 15, 2018 at 2:12 PM
Subject: pf(4) queuing and interfaces
To: misc@openbsd.org
My wireless AP puts traffic from each WiFi network (trusted, guests,
etc.) into a separate VLAN, which are then picked up by my OpenBSD
router and filtered appropriately via pf rules.
In other words:
em1 is for untagged traffic to the AP itself
vlan100 has parent em1 and is for my "trusted" WLAN
vlan200 also has parent em1 and is for my "guest" WLAN
pf.conf includes the following line:
queue wlan_q on em1 bandwidth 50M max 50M flows 1024 qlimit 1024 default
When I specify only the queuing rule as shown above, is traffic sent
on vlanXXX also receive this queuing policy?
If not, should I divide the physical bandwidth between logical
interfaces? Does FQ-CoDel work correctly if they are each assigned
the full physical bandwidth? Or should I be dividing one or both of
the configurable interface rates?
And lastly, if I define a queue as below - does this expand into two
different queues with the same name or one queue with bandwidth shared
between two interfaces? Running "pfctl -vsq" indicates the former,
but I'd like to be sure.
queue some_q on { em2, em3 } bandwidth 95M max 95M flows 1024 qlimit
1024 default
Thanks.
--david
growfs(8) to lower offset
I read both the FAQ section and the growfs(8) man page but I am not yet confident that what I want to do is supported / safe. http://www.openbsd.org/faq/faq14.html#GrowPartition I started with a number of partitions and a bunch of free space. I later needed the free space and allocated a /project partition that went to the end of my disk. More recently, I emptied the /data partition immediately prior. Now I would like to use growfs(8) to merge this unused space with the /project partition without losing any of the existing data. See disklabel output below. I have only grown partitions "down", never in the other direction. Am I being overly paranoid? Thanks. --david [david@apu2 ~]$ doas disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: SATA SSD duid: dab5be6fe5a0d623 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 7297 total sectors: 117231408 boundstart: 64 boundend: 117226305 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 2104448 64 4.2BSD 2048 16384 12958 # / b: 8385933 2104512swap# none c:1172314080 unused d: 8401952 10490464 4.2BSD 2048 16384 12958 # /tmp e: 8385952 18892416 4.2BSD 2048 16384 12958 # /var f: 4192960 27278368 4.2BSD 2048 16384 12958 # /usr g: 2088448 31471328 4.2BSD 2048 16384 12958 # /usr/X11R6 h: 6281424 33559776 4.2BSD 2048 16384 38128 # /usr/local i: 6297440 39841216 4.2BSD 2048 16384 12958 # /usr/ports j: 2088448 46138656 4.2BSD 2048 16384 12958 # /home k: 16771872 48227104 4.2BSD 2048 16384 12958 # /data l: 52227328 64998976 4.2BSD 2048 16384 12958 # /project
Re: growfs(8) to lower offset
On Tue, Nov 6, 2018 at 8:58 AM Bruno Flueckiger wrote: > > On 05.11.18 19:47, David Higgs wrote: > > I read both the FAQ section and the growfs(8) man page but I am not > > yet confident that what I want to do is supported / safe. > > > > http://www.openbsd.org/faq/faq14.html#GrowPartition > > > > I started with a number of partitions and a bunch of free space. I > > later needed the free space and allocated a /project partition that > > went to the end of my disk. More recently, I emptied the /data > > partition immediately prior. Now I would like to use growfs(8) to > > merge this unused space with the /project partition without losing any > > of the existing data. > > > > See disklabel output below. I have only grown partitions "down", > > never in the other direction. Am I being overly paranoid? > > > > Thanks. > > > > --david > > > > As the FAQ entry states, you can use growfs(8) if the empty space > is after the existing partition, not prior. You can only grow a > partition "down", never "up". What you want to do would require the > following steps: > > 1. Create a new partition on the free space > 2. Move all data to the new partition > 3. Remove the existing /project partition > 4. Use growfs(8) on the new partition to include the space from the old >/project partition You appear to be right - I see it now. I had not read closely enough, and had focused more on what I could change with the 'm' disklabel(8) command. It would be nice if this info were made explicit in the growfs(8) man page as well. I had already successfully rearranged some partitions using the method you propose, but unfortunately the amount of data in /project is slightly too big to be easily shifted into my remaining free space. I'll try to compress it or temporarily move the data off-system. Thanks for the clue-stick. --david
More fun with IPv6 route(8) output
Last year, I reported some confusing behavior with route(8), which was kindly resolved with both an immediate workaround and code improvements. https://marc.info/?l=openbsd-misc&m=152712936731762&w=2 I now realize that I am experiencing the reverse problem in 6.6, in that I cannot resolve any IPv6 address with explicit netmasks. This applies to IPv6 addresses with and without the trailing double-colon. There have been several changes in mid-2018 that could have caused this, but I had blamed failures on intermittent (intermittent) ISP / dhcpcd issues without investigating. I can easily fix my script, but figured I should report the regression. (Apologies for formatting as usual.) Thanks! --david $ route -n get 2607:f8b0:4004:805::/128 get host 2607:f8b0:4004:805::/128: not in table $ route -n get 2607:f8b0:4004:805:: route to: 2607:f8b0:4004:805:: destination: :: mask: :: gateway: fe80::201:5cff:fe86:7046%em0 interface: em0 if address: fe80::20d:b9ff:fe4a:52e4%em0 priority: 56 (default) flags: label: slaacd use mtuexpire 1631319 0 0 sockaddrs:
Re: SIGBUS on octeon for my program
I don't speak ktrace but looks like alignment problems with a stack
variable. What does gdb report?
--david
On Wed, Nov 27, 2019 at 8:48 AM Peter J. Philipp wrote:
> Hi,
>
> My DNS program gets a SIGBUS when I execute it. I have ktraced it, upped
> limits and searched in the mips64 source for answers, could this be a
> compiler
> problem?
>
> ktrace->
> 41651 dddctl CALL connect(6,0xfcacb0,16)
> 41651 dddctl STRU struct sockaddr { AF_INET, 192.168.177.2:10053 }
> 41651 dddctl RET connect 0
> 41651 dddctl CALL kbind(0xfc9b48,24,0x801d30cbade359aa)
> 41651 dddctl RET kbind 0
> 41651 dddctl PSIG SIGBUS SIG_DFL code BUS_ADRALN<1> addr=0xfca17d
> trapno=0
> 82637 dddctl RET wait4 41651/0xa2b3
> <---
>
> The SIGBUS code ADRALN I have found in /sys/arch/mips64/mips64/trap.c
> around
> line 463 on OpenBSD 6.6:
>
> >
> case T_ADDR_ERR_LD+T_USER: /* misaligned or kseg access */
> case T_ADDR_ERR_ST+T_USER: /* misaligned or kseg access */
> ucode = 0; /* XXX should be PROT_something */
> signal = SIGBUS;
> sicode = BUS_ADRALN;
> break;
> <---
>
> I have also set the stack ulimit to 32K but no relief. I'm stuck,
> wondering
> if you guys can help with interpreting this.
>
> My program can be downloaded with
>
> ftp https://delphinusdns.org/download/snapshot/delphinusdnsd-snapshot.tgz
>
> Where it's remade at midnight CET every day.
>
> As far as I know it should work on macppc although this particular function
> wasn't tested on macppc. And it works on amd64 as I run this delphinusdnsd
> in production on my personal nameservers. Getting this working on octeon
> would broaden my test network.
>
> Best Regards,
> -peter
>
>
Re: SIGBUS on octeon for my program
Be warned that __packed doesn't do quite what you think it does.
void func(int *p) {
*p = 0;
}
If you pass an unaligned pointer into this function on a strict-alignment
platform, your program will likely crash. I am unaware of any attribute
that can inform the compiler that 'p' may be misaligned.
--david
On Fri, Nov 29, 2019 at 2:54 AM Peter J. Philipp wrote:
> On Thu, Nov 28, 2019 at 11:44:07PM -0700, Theo de Raadt wrote:
> > Half the cpu platforms fault on unaligned access.
> >
> > There are strategies for handling this. Your code must use them.
> >
> > It is kind of boring, actually.
>
> I took a look at how libasr does it, and I have similar code ie. pack8(),
> pack16(), pack32(), I will just change all my functions, as unalignment
> flags passed per -m aren't standard on every arch. I did use __packed on
> structs already but the way libasr does is a great example I think.
>
> It's a bit of work but the fact that this could work on architectures like
> octeon make it worth it for me.
>
> Thanks a lot!
> -peter
>
>
Re: Kibana/Elasticsearch fail
On Mon, Feb 10, 2020 at 11:20 PM Aaron Bieber wrote:
> On Thu, 06 Feb 2020 at 23:31:01 -0600, Eric Zylstra wrote:
> > I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using
> pkg_add. Installs went fine. I checked out the pkg documentation
> (pkg_reames) and followed the steps for those that had documentation to
> follow.
> >
> > When I boot, Logstash and Kibana fail. I can use rcctl to start
> Logstash with no problem. When I try to start Kibana, the following is
> what I see:
> >
> > # rcctl -d start kibana
> > doing _rc_parse_conf
> > doing _rc_quirks
> > kibana_flags empty, using default ><
> > doing _rc_parse_conf /var/run/rc.d/kibana
> > doing _rc_quirks
> > doing rc_check
> > kibana
> > doing rc_start
> > doing _rc_wait start
> > doing rc_check
> > No home directory /nonexistent!
> > Logging in with home = "/".
> > Kibana does not support the current Node.js version v10.16.3. Please use
> Node.js v>=10.15.0 <10.16.
> > doing _rc_rm_runfile
> > (failed)
> >
> >
> > I’m not sure what to do with this. Why is Logstash not starting on
> reboot? Why does Kibana fail? I assume there is some config that need be
> done, because that Node.js error wouldn’t have made it to distribution,
> right?
>
> > that Node.js error wouldn’t have made it to distribution
>
> It did, and it's entirely my fault.
>
> Kibana is failing because it is very strict about the version of node it
> wants
> to use (hence the "Kibana does not support.." message).
>
> Apparently the tests I had run to verify this update worked failed:
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/kibana/patches/patch-package_json?rev=1.4&content-type=text/x-cvsweb-markup
>
> Here is a diff that fixes it for 6.6 (you will have to build it from ports
> until (if?) a proper fix is in place).
>
> https://deftly.net/patches/kibana-6.6.1.diff
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/kibana/Makefile,v
> retrieving revision 1.32
> diff -u -p -r1.32 Makefile
> --- Makefile28 Sep 2019 09:37:54 - 1.32
> +++ Makefile11 Feb 2020 04:13:52 -
> @@ -3,7 +3,7 @@
> COMMENT= browser based analytics/search interface to ElasticSearch
>
> V =6.6.1
> -REVISION = 1
> +REVISION = 2
> PKGNAME = kibana-${V}
> DISTNAME = kibana-oss-${V}-darwin-x86_64
>
> Index: patches/patch-package_json
> ===
> RCS file: /cvs/ports/www/kibana/patches/patch-package_json,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-package_json
> --- patches/patch-package_json 13 May 2019 22:08:11 - 1.4
> +++ patches/patch-package_json 11 Feb 2020 04:13:52 -
> @@ -8,7 +8,7 @@ Index: package.json
> },
> "engines": {
> -"node": "10.15.1"
> -+"node": ">=10.15.0 <10.16"
> ++"node": "10.16.3"
> }
> -}
> \ No newline at end of file
>
> >
> > Thanks,
> >
> > EZ
>
> --
> PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9
> ADCE
>
>
Works great for me, thanks for the belated update.
--david
Re: sensorsd, upd, and state changes
On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov wrote: > On Mon, Dec 8, 2014 at 3:45 PM, David Higgs wrote: > > On Mon, Dec 8, 2014 at 3:37 PM, trondd wrote: > >> On Mon, Dec 8, 2014 at 3:23 PM, trondd wrote: > >>> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs wrote: > >>>> > >>>> > >>>> sysctl(8) will display Off if the value is zero, and On for nonzero. > >>>> So, using the "closed interval" rule above, you should use "high=0" > >>>> for indicators that you consider in "good" state when Off (i.e. > >>>> ShutdownImminent), and "low=1" for indicators that you consider in > >>>> "good" state when On (i.e. ACPresent). > >>>> > >>> > >>> Isn't saying high=0 kind of the same thing as saying low=1? > >> > >> > >> Oh, I think I get this. Since the sensor doesn't trigger if it is on > the > >> limit, only outside the limit, you have to set up which is the OK state. > >> > >> Still a little confusing but I guess there is no way to automatically > know > >> if an indicator is supposed to be Off or On when it's in it's good > state? > >> > > > > Kind of. The high/low difference is what values you consider "within" > > normal operating parameters (and the output of %l). The upd(4) code > > hasn't yet been taught how to map specific indicator values to OK / > > WARN / CRITICAL status. Currently any value successfully read is > > marked OK. > > > > I'm working with tech@ and slowly writing diffs to improve these things. > > > > --david > > Resurrecting an old thread since I just ran into the same problem in > 5.8. To summarize, upd(4) exposes some SENSOR_INDICATOR-type sensors > for attached UPSes, such as ACPresent = On/Off, and it's not clear how > to configure sensorsd(8) to execute a command when this value changes. > Also, upd always sets sensor status to "OK," so sensorsd never > triggers commands for status changes; we have to use low/high limits > until this is fixed. One proposed hack was to use "low=1:high=2" in > sensorsd.conf, but this doesn't seem to work for everybody. > > Has anyone tried using "low=0:high=0"? I'm pretty sure that should > solve the problem in all cases. > > The low/high range is inclusive at both ends. Off is 0, but On can be > any other int64 value, including negative. For my UPS, ACPresent = On > is actually a value of -1. I know this because when I set > "low=-1:high=-1" sensorsd reports "upd0.indicator2: within limits: > On". That being the case, "low=1:high=2" would not work because the > value changes from -1 (On) to 0 (Off), and is always below the lower > limit. > > Using "low=0:high=0" should always work for On -> Off -> On > transitions, but it will show On as outside (below or above) the > limits. If you want On to be within limits, then just play with the > values until you figure out whether On is 1, -1, or something else > entirely. That may not be as reliable. I'm not actually sure whether > this value is UPS-specific or something that upd determines. > Yes, the values reported are UPS-specific. You may need to adjust the ranges, but (as previously discussed) you can just use either high or low (not both) to detect transition between good and bad indicator states. This is still all just a hack; I ran out of free time to keep working on upd(4). I made the driver less terrible and added a few sensors, but didn't get as far as changing sensor statuses which could make reporting much easier. --david
Re: Virtualbox vs latest snapshot
On Tue, Apr 10, 2018 at 9:27 AM, Juan Francisco Cantero Hurtado < i...@juanfra.info> wrote: > On Tue, Apr 10, 2018 at 11:26:44AM +0200, Janne Johansson wrote: > > Yes, same here. First boot after update to Apr10 snap worked, then > > fw_update and pkg_add -u and so on, and now it immediately reboots after > > loading the kernel from the bootloader. > > Maybe a stupid idea, but can you both try changing the settings to a > different OS (like Linux 64 bits or Windows) or changing the hypervisor > to KVM or Hyper-V?. Was experiencing the same issue, but now appears to be fixed as of snapshot #151 dated April 10. --david > > 2018-04-10 10:50 GMT+02:00 csszep : > > > > > Hi! > > > > > > I installed the latest 04.10 snapshot, the install procedure went > fine, but > > > after reboot the VM stucks at endless boot loop . > > > > > > It prints only the "booting hda0:/bsd" line.. before reboot > > > > > > The 04.03 snapshot works fine. > > > > > > There is a similar experience for someone with Virtualbox 5.2.8? > > > > > > > > > > > -- > > May the most significant bit of your life be positive. > > -- > Juan Francisco Cantero Hurtado http://juanfra.info > >
Re: Virtualbox vs latest snapshot
On Tue, Apr 10, 2018 at 5:21 PM, David Higgs wrote: > On Tue, Apr 10, 2018 at 9:27 AM, Juan Francisco Cantero Hurtado < > i...@juanfra.info> wrote: > >> On Tue, Apr 10, 2018 at 11:26:44AM +0200, Janne Johansson wrote: >> > Yes, same here. First boot after update to Apr10 snap worked, then >> > fw_update and pkg_add -u and so on, and now it immediately reboots after >> > loading the kernel from the bootloader. >> >> Maybe a stupid idea, but can you both try changing the settings to a >> different OS (like Linux 64 bits or Windows) or changing the hypervisor >> to KVM or Hyper-V?. > > > > Was experiencing the same issue, but now appears to be fixed as of > snapshot #151 dated April 10. > > Sorry for any confusion, I spoke too soon. What I ACTUALLY did was booted #151 from the snapshot cd63.iso. Virtualbox hard drive currently reports BOOT 3.34, will not load bsd or bsd.rd. cd63.iso uses CDBOOT 3.29, appears to boot everything fine. Suspect the problem is with this boot code, but I do not have the expertise to diagnose further. Hope this helps. --david > >> > 2018-04-10 10:50 GMT+02:00 csszep : >> > >> > > Hi! >> > > >> > > I installed the latest 04.10 snapshot, the install procedure went >> fine, but >> > > after reboot the VM stucks at endless boot loop . >> > > >> > > It prints only the "booting hda0:/bsd" line.. before reboot >> > > >> > > The 04.03 snapshot works fine. >> > > >> > > There is a similar experience for someone with Virtualbox 5.2.8? >> > > >> > >> > >> > >> > -- >> > May the most significant bit of your life be positive. >> >> -- >> Juan Francisco Cantero Hurtado http://juanfra.info >> >> >
Re: Virtualbox vs latest snapshot
On Tue, Apr 10, 2018 at 6:50 PM, Stuart Henderson wrote: > On 2018-04-10, csszep wrote: > > Hi! > > > > I installed the latest 04.10 snapshot, the install procedure went fine, > but > > after reboot the VM stucks at endless boot loop . > > > > It prints only the "booting hda0:/bsd" line.. before reboot > > > > The 04.03 snapshot works fine. > > > > There is a similar experience for someone with Virtualbox 5.2.8? > > > > There's a recent bootloader problem, possibly following the update > to clang 6, that affects some machines. I suspect this might be > involved here. > > To confirm if this is the problem, can you install the older > snapshot as normal, then update kernel and file sets to the newer > one? (follow the "Upgrade without the install kernel" steps on > http://www.openbsd.org/faq/upgrade63.html, except skip the part > about running installboot do install a new bootloader). > > Can you report back either way please (preferably to bugs@, with > dmesg and anything special about the VM config).. If it is the > same thing it would be useful for developers to have a way to > reproduce the problem that doesn't involve specific hardware.. > > FWIW, I noticed that the latest snapshot installed BOOT 3.39, which booted kernels in VirtualBox just fine for me. Thanks again. --david
acme-client error: unknown SAN entry
acme-client: /etc/ssl/primary.example.com.crt: unknown SAN entry: alternate.example.com acme-client: bad exit: revokeproc(55821): 1 (My real domain is legitimate, and not example.com.) I recently decommissioned one of the aliases for my servers, but my nightly acme-client run threw an error. Although I removed the alias from acme-client.conf, it is obviously still present in my certificate and seems to be confusing the renewal process. Does anyone know how to resolve this? I tried force-renewal (-F) without success but haven't tried revoking yet. Is it possible to fix without revocation? Thanks. --david
Re: acme-client error: unknown SAN entry
On Sun, Feb 7, 2021 at 4:49 PM Stuart Henderson wrote: > On 2021-02-07, David Higgs wrote: > > acme-client: /etc/ssl/primary.example.com.crt: unknown SAN entry: > > alternate.example.com > > acme-client: bad exit: revokeproc(55821): 1 > > > > (My real domain is legitimate, and not example.com.) > > > > I recently decommissioned one of the aliases for my servers, but my > nightly > > acme-client run threw an error. Although I removed the alias from > > acme-client.conf, it is obviously still present in my certificate and > seems > > to be confusing the renewal process. > > > > Does anyone know how to resolve this? I tried force-renewal (-F) without > > success but haven't tried revoking yet. Is it possible to fix without > > revocation? > > > > Thanks. > > > > --david > > > > Update to -current, or move /etc/ssl/primary.example.com.crt out the way. > For the archives: I moved the cert as suggested, manually ran my nightly script, and everything worked great. Thanks! --david
Re: Bufferbloat, FQ-CoDel, and performance
On Fri, Feb 26, 2021 at 3:58 AM Stuart Henderson wrote: > On 2021-02-26, Sven F. wrote: > > On Thu, Feb 25, 2021 at 8:38 PM Steven Shockley > > wrote: > >> > >> I can try it, but I don't think it'll help in my case: > > It's worth trying anyway I think. > > > Can the patch sys/net/pf.c r1.1096 be applied on 6.8 ? > > or does it need some others files to be changed as well ? > > It csn be applied directly. > For a month or two my home router has been running 6.8-stable augmented with this pf.c fix as well as sys/net/fq_codel.c r1.14, without any obvious performance regressions. The commit message (and code) on the fq_codel.c fix seemed to indicate that it might improve performance in much the same way as the pf.c fix, though perhaps under different circumstances / configurations. However, I'm not a dev and my opinion isn't worth very much so YMMV. --david
Bridging em and vlan
All of my devices until now have been behind my OpenBSD NAT router, but I recently acquired a Internet of Trash device that I would like to be accessible to the internet (yes, I know). My home configuration uses a Unifi AP to translate my various SSIDs into VLANs which plug into one of my APU em(4) ports. The IoT thing already has its own dedicated SSID/VLAN, but doesn't enjoy living behind my NAT. Is there a way for me to bridge just one of the vlan(4) logical interfaces with my other em(4) uplink, so that my IoT item can speak DHCP directly with my internet provider? Can this be done with veb/vport or bridge, or will I need to use something more exotic to strip the 802.1q tags before they are sent to my ISP? Thanks in advance, --david
Re: Bridging em and vlan
On Sun, Oct 1, 2023 at 9:13 AM Zé Loff wrote: > On Sat, Sep 30, 2023 at 11:39:36AM -0400, David Higgs wrote: > > All of my devices until now have been behind my OpenBSD NAT router, but I > > recently acquired a Internet of Trash device that I would like to be > > accessible to the internet (yes, I know). > > > > My home configuration uses a Unifi AP to translate my various SSIDs into > > VLANs which plug into one of my APU em(4) ports. The IoT thing already > has > > its own dedicated SSID/VLAN, but doesn't enjoy living behind my NAT. > > Define "doesn't enjoy". It absolutely requires a public IP? It needs > some ports to be forwarded? Has some sort of network connection > detection that fails because some ports are blocked for outgoing > traffic? > I'm still trying to determine ground truth with manufacturer support. Port forwarding doesn't seem sufficient. The device can reach out just fine but is not remotely controllable as advertised. > Is there a way for me to bridge just one of the vlan(4) logical interfaces > > with my other em(4) uplink, so that my IoT item can speak DHCP directly > > with my internet provider? > > Assuming your WAN connection also gets its IP address by DHCP, will your > ISP assign you multiple IP addresses, one for your uplink, one for the > IoT device? > Hopefully so, but that's orthogonal to the question I'm asking. If you absolutely need the IoT device to have unfiltered connection to > the internet, you can just create a DMZ of sorts for that VLAN, let all > traffic pass out, forward the necessary ports for incoming traffic, and, > assuming you don't trust the device at all, block all traffic from that > VLAN to the rest of the network (or be very selective about it), and > maybe also from other VLANs to that VLAN. Putting it in a different > rdomain altogether might also be a good idea. I've already tried that without success. > Can this be done with veb/vport or bridge, or will I need to use something > > more exotic to strip the 802.1q tags before they are sent to my ISP? > Self-replying here: I don't see many examples of veb(4) use online, but it seems as if I can add my physical uplink and the IoT VLAN both to a veb and attach a vport to become my new uplink. That should be logically equivalent to putting a three-port switch between my router and my ISP CPE, with the third port for the IoT device. Is anyone able to shoot holes in this or suggest a superior alternative, before I attempt the configuration later this week? Related question: It doesn't appear that veb (and bridge) are part of either amd64 RAMDISK. Does this create any added complexity with (sys)upgrades or does it somehow Just Work(tm)? Thanks again, --david
Re: Bridging em and vlan
On Mon, Oct 2, 2023 at 9:26 AM David Higgs wrote: > On Sun, Oct 1, 2023 at 9:13 AM Zé Loff wrote: > >> On Sat, Sep 30, 2023 at 11:39:36AM -0400, David Higgs wrote: >> > All of my devices until now have been behind my OpenBSD NAT router, but >> I >> > recently acquired a Internet of Trash device that I would like to be >> > accessible to the internet (yes, I know). >> > >> > My home configuration uses a Unifi AP to translate my various SSIDs into >> > VLANs which plug into one of my APU em(4) ports. The IoT thing already >> has >> > its own dedicated SSID/VLAN, but doesn't enjoy living behind my NAT. >> >> Define "doesn't enjoy". It absolutely requires a public IP? It needs >> some ports to be forwarded? Has some sort of network connection >> detection that fails because some ports are blocked for outgoing >> traffic? >> > > I'm still trying to determine ground truth with manufacturer support. > Port forwarding doesn't seem sufficient. The device can reach out just > fine but is not remotely controllable as advertised. > > > Is there a way for me to bridge just one of the vlan(4) logical >> interfaces >> > with my other em(4) uplink, so that my IoT item can speak DHCP directly >> > with my internet provider? >> > > > Can this be done with veb/vport or bridge, or will I need to use >> something >> > more exotic to strip the 802.1q tags before they are sent to my ISP? >> > > Self-replying here: I don't see many examples of veb(4) use online, but it > seems as if I can add my physical uplink and the IoT VLAN both to a veb and > attach a vport to become my new uplink. That should be logically > equivalent to putting a three-port switch between my router and my ISP CPE, > with the third port for the IoT device. Is anyone able to shoot holes in > this or suggest a superior alternative, before I attempt the configuration > later this week? > I appreciate the previous replies/cluebats, but my initial attempt was rushed and unsuccessful. In broad strokes, I created veb0 and added em0, vlan222, and vport0 to it. Then I tried getting vport0 to speak DHCP with my upstream, but nothing seemed to happen or appear in logs. I will have to spend more time on this to eliminate the possibility of fat-fingering, remove various confounding variables, and produce a better result/report. Silly question, does it even make sense to add a single vlan interface to a veb? Is there maybe parent confusion between veb0 and em2 (Wifi AP iface)? Thanks. --david
Re: Bridging em and vlan
On Tue, Oct 3, 2023 at 10:10 AM David Higgs wrote: > On Mon, Oct 2, 2023 at 9:26 AM David Higgs wrote: > >> On Sun, Oct 1, 2023 at 9:13 AM Zé Loff wrote: >> >>> On Sat, Sep 30, 2023 at 11:39:36AM -0400, David Higgs wrote: >>> > All of my devices until now have been behind my OpenBSD NAT router, >>> but I >>> > recently acquired a Internet of Trash device that I would like to be >>> > accessible to the internet (yes, I know). >>> > >>> > My home configuration uses a Unifi AP to translate my various SSIDs >>> into >>> > VLANs which plug into one of my APU em(4) ports. The IoT thing >>> already has >>> > its own dedicated SSID/VLAN, but doesn't enjoy living behind my NAT. >>> >>> Define "doesn't enjoy". It absolutely requires a public IP? It needs >>> some ports to be forwarded? Has some sort of network connection >>> detection that fails because some ports are blocked for outgoing >>> traffic? >>> >> >> I'm still trying to determine ground truth with manufacturer support. >> Port forwarding doesn't seem sufficient. The device can reach out just >> fine but is not remotely controllable as advertised. >> >> > Is there a way for me to bridge just one of the vlan(4) logical >>> interfaces >>> > with my other em(4) uplink, so that my IoT item can speak DHCP directly >>> > with my internet provider? >>> >> >> > Can this be done with veb/vport or bridge, or will I need to use >>> something >>> > more exotic to strip the 802.1q tags before they are sent to my ISP? >>> >> >> Self-replying here: I don't see many examples of veb(4) use online, but >> it seems as if I can add my physical uplink and the IoT VLAN both to a >> veb and attach a vport to become my new uplink. That should be logically >> equivalent to putting a three-port switch between my router and my ISP CPE, >> with the third port for the IoT device. Is anyone able to shoot holes in >> this or suggest a superior alternative, before I attempt the configuration >> later this week? >> > > I appreciate the previous replies/cluebats, but my initial attempt was > rushed and unsuccessful. > > In broad strokes, I created veb0 and added em0, vlan222, and vport0 to > it. Then I tried getting vport0 to speak DHCP with my upstream, but > nothing seemed to happen or appear in logs. > > I will have to spend more time on this to eliminate the possibility of > fat-fingering, remove various confounding variables, and produce a better > result/report. > For the archives, this worked swimmingly once I paid closer attention to what I was doing. Based on my second attempt, I hadn't put my vport0 interface up. Of course, my ISP isn't handing out more than a single IPv4 address by default, so all this has been simply a good learning experience. --david
Re: Bridging em and vlan
On Thu, Oct 5, 2023 at 9:04 AM David Gwynne wrote: > > > > On 5 Oct 2023, at 11:17, David Higgs wrote: > > > > On Tue, Oct 3, 2023 at 10:10 AM David Higgs wrote: > > > >> On Mon, Oct 2, 2023 at 9:26 AM David Higgs wrote: > >> > >>> On Sun, Oct 1, 2023 at 9:13 AM Zé Loff wrote: > >>> > >>>> On Sat, Sep 30, 2023 at 11:39:36AM -0400, David Higgs wrote: > >>>>> All of my devices until now have been behind my OpenBSD NAT router, > >>>> but I > >>>>> recently acquired a Internet of Trash device that I would like to be > >>>>> accessible to the internet (yes, I know). > >>>>> > >>>>> My home configuration uses a Unifi AP to translate my various SSIDs > >>>> into > >>>>> VLANs which plug into one of my APU em(4) ports. The IoT thing > >>>> already has > >>>>> its own dedicated SSID/VLAN, but doesn't enjoy living behind my NAT. > >>>> > >>>> Define "doesn't enjoy". It absolutely requires a public IP? It needs > >>>> some ports to be forwarded? Has some sort of network connection > >>>> detection that fails because some ports are blocked for outgoing > >>>> traffic? > >>>> > >>> > >>> I'm still trying to determine ground truth with manufacturer support. > >>> Port forwarding doesn't seem sufficient. The device can reach out just > >>> fine but is not remotely controllable as advertised. > >>> > >>>> Is there a way for me to bridge just one of the vlan(4) logical > >>>> interfaces > >>>>> with my other em(4) uplink, so that my IoT item can speak DHCP > directly > >>>>> with my internet provider? > >>>> > >>> > >>>> Can this be done with veb/vport or bridge, or will I need to use > >>>> something > >>>>> more exotic to strip the 802.1q tags before they are sent to my ISP? > >>>> > >>> > >>> Self-replying here: I don't see many examples of veb(4) use online, but > >>> it seems as if I can add my physical uplink and the IoT VLAN both to a > >>> veb and attach a vport to become my new uplink. That should be > logically > >>> equivalent to putting a three-port switch between my router and my ISP > CPE, > >>> with the third port for the IoT device. Is anyone able to shoot holes > in > >>> this or suggest a superior alternative, before I attempt the > configuration > >>> later this week? > >>> > >> > >> I appreciate the previous replies/cluebats, but my initial attempt was > >> rushed and unsuccessful. > >> > >> In broad strokes, I created veb0 and added em0, vlan222, and vport0 to > >> it. Then I tried getting vport0 to speak DHCP with my upstream, but > >> nothing seemed to happen or appear in logs. > >> > >> I will have to spend more time on this to eliminate the possibility of > >> fat-fingering, remove various confounding variables, and produce a > better > >> result/report. > >> > > > > For the archives, this worked swimmingly once I paid closer attention to > > what I was doing. Based on my second attempt, I hadn't put my vport0 > > interface up. > > > > Of course, my ISP isn't handing out more than a single IPv4 address by > > default, so all this has been simply a good learning experience. > > For future reference, if you just want to join two ethernet interfaces on > an openbsd box together you can use tpmr(4). It was almost called xcon(4), > short for cross-connect. > > It's also worth noting the steps taken by the Ethernet stack when it > processes packets and which drivers can take packets at which point. Let's > assume an ethernet packet is coming in on a physical interface, em0 in this > case. > > 1: trunk/aggr processing > > If em0 is part of trunk/aggr, then those drivers will steal the packet and > start processing it again as if it was received on the relevant trunk/aggr > interface. > > 2. service delimited packet filtering, ie, vlan/svlan handling > > If em0 is a parent interface to vlan or svlan interfaces, this is when > they get taken and processing starts again as if they were received on the > virtual interfaces. > > If no vlan/svlan interface is configured, the packets are marked as now > marked as "service delimited".
Slow relink in 7.4
I have an underpowered amd64 VPS and attempted to (auto)upgrade it to 7.4. Everything went swimmingly until it attempted to relink the kernel, at which point it (seemingly) hung. With previous releases, I would expect the host to become unresponsive for a few minutes, and eventually recover. I chalked the issue up to insufficient RAM and hitting swap - however, my upgrade has been in this state for more than 6 hours. I plan to consult the manual upgrade guide to hopefully figure out a way to successfully finish the install, and then disable relinking while I find a solution. Does anyone have tips for this situation, aside from throwing more hardware at it? Thanks! —david
Re: Slow relink in 7.4
On Tue, Oct 17, 2023 at 8:18 AM Nick Holland wrote: > On 10/17/23 05:07, David Higgs wrote: > > I have an underpowered amd64 VPS and attempted to (auto)upgrade it to > 7.4. > > Everything went swimmingly until it attempted to relink the kernel, at > > which point it (seemingly) hung. > > > > With previous releases, I would expect the host to become unresponsive > for > > a few minutes, and eventually recover. I chalked the issue up to > > insufficient RAM and hitting swap - however, my upgrade has been in this > > state for more than 6 hours. > > > > I plan to consult the manual upgrade guide to hopefully figure out a way > to > > successfully finish the install, and then disable relinking while I find > a > > solution. > > > > Does anyone have tips for this situation, aside from throwing more > hardware > > at it? > > I had some issues with a VPS for a while -- absolutely horrific disk > performance. Upgrades that used to take ten minutes (and yes, THAT was > really bad) started taking well over an hour (I gave up, stopped it, and > did it manually by unpacking tar files, coping kernel, etc., so I have no > idea what the actual time was going to be if I had let it complete). I > contacted tech support at the VPS, and they came back with, "oh yeah, you > are on some really old hardware. Please set up a new instance and migrate > to that, that should solve your problem", but since the machine was doing > its usual job just fine (low volume mail and webserver), I was slow to > actually do this. Finally, they sent me notice they were decommissioning > the old hw I was on, and I HAD to move by x/x/, and thus, I did, and > things are much better. And it turned out, cheaper. > > However, I did find it interesting that my poor disk performance was even > worse when doing the upgrade. > > Moral: might be worth talking to your VPS provider. You might be on old > hw, too. > > A number of releases ago, but after KARL and library relinks1, I found > that on i386, 384MB was required to prevent swapping during the kernel and > library relink at boot. I'm assuming it is "worse" now, and worse yet on > amd64. > For the record, my VPS had 256 MB RAM and another 256 MB of swap. Seems like I can easily provision a new VPS - beefier and for the same price - using their dashboard, so the solution is pretty trivial. Thanks to all who replied! --david --david
Re: PC Engines APU platform EOL
On Thu, Apr 20, 2023 at 1:30 AM fRANz wrote: > On Wed, Apr 19, 2023 at 11:30 AM Martin Schröder > wrote: > > > https://www.pcengines.ch/eol.htm > > The end is near for APUs :-( > > :( > Happy apu2 & apu4 user here. > Are there other OpenBSD friendly options? > Regards, > -f > Someday I'll need to replace my APU and prefer not to wade through aliexpress. If there aren't any spares left, it looks like the ODROID H3 with the expansion NIC board might be a good match for my needs. https://www.hardkernel.com/shop/odroid-h3/ https://www.hardkernel.com/shop/h2-net-card/ Someone recently posted a dmesg too: https://marc.info/?l=openbsd-misc&m=168182784030477&w=2 I've got no particular affinity for x86 hardware. Has anyone found an equivalent that can run arm64 with a minimum of installation fussiness and 3x NICs? --david
ral0 hangs during sftp
I recently installed 4.4-stable and started using wireless with WPA2.
Basic web browsing had been working fine all week, but today I started
moving some files around via sftp and suddenly the link stalled. Log
messages indicate resource problems with named but not a total link
failure, since dhcpd still worked. Running ifconfig up/down appeared
to fix the problem temporarily; I lost patience and found a wired
connection after the second hang.
Is this somehow related to "Fix HW crypto on ral(4) devices." in the
list of -current changes? Is there any additional information I can
provide?
Thanks.
--david
[snip from /var/log/daemon]
Jan 24 12:19:47 www named[25693]: client 10.0.128.9#50328: error
sending response: not enough free resources
Jan 24 12:20:01 www named[25693]: client 10.0.128.9#57053: error
sending response: not enough free resources
Jan 24 12:22:24 www dhcpd[29360]: DHCPREQUEST for 10.0.128.9 from
00:1c:b3:c0:9e:66 via ral0
Jan 24 12:22:24 www dhcpd[29360]: DHCPACK on 10.0.128.9 to
00:1c:b3:c0:9e:66 via ral0
Jan 24 12:27:02 www named[25693]: client 10.0.128.9#52452: error
sending response: not enough free resources
Jan 24 12:27:17 www named[25693]: client 10.0.128.9#59183: error
sending response: not enough free resources
[da...@www david]$ ifconfig ral0
ral0: flags=8c43 mtu 1500
lladdr 00:1d:7d:34:0e:ec
groups: wlan
media: IEEE802.11 autoselect mode 11g hostap
status: active
ieee80211: nwid headcrabs chan 3 bssid 00:1d:7d:34:0e:ec
wpapsk wpaprotos wpa2 wpaakms psk wpaciphers tkip,ccmp
wpagroupcipher tkip 100dBm
inet 10.0.128.1 netmask 0xff00 broadcast 10.0.128.255
inet6 fe80::21d:7dff:fe34:eec%ral0 prefixlen 64 scopeid 0x1
[da...@www david]$ netstat -niI ral0
NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls
ral0150000:1d:7d:34:0e:ec 897711 1124 1790425 1290 0
ral01500 10.0.128/24 10.0.128.1 897711 1124 1790425 1290 0
ral01500 fe80::%ral0 fe80::21d:7dff:fe 897711 1124 1790425 1290 0
OpenBSD 4.4-stable (GENERIC) #0: Sat Jan 17 23:04:52 EST 2009
r...@www.d33p.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 599 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem = 267993088 (255MB)
avail mem = 250699776 (239MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/13/00, BIOS32 rev. 0 @
0xfd790, SMBIOS rev. 2.1 @ 0xefa30 (49 entries)
bios0: vendor Intel Corp. version "A11" date 10/13/2000
bios0: Dell Computer Corporation XPST600
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xfd790/0x870
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/192 (10 entries)
pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xf800 0xcf800/0x800 0xd/0x800
0xe/0x4000! 0xe4000/0xc000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA GeForce FX 5500" rev 0xa1
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
agp0 at vga1: aperture at 0xd000, size 0x1000
drm at vga1 unsupported
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 19473MB, 39882528 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets, initiator 7
cd0 at scsibus0 targ 0 lun 0: <_NEC, DVD_RW ND-3500AG, 2.18> ATAPI
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 9
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 128MB SDRAM ECC PC100CL3
spdmem1 at iic0 addr 0x51: 128MB SDRAM ECC PC100CL3
emu0 at pci0 dev 14 function 0 "Creative Labs SoundBlaster Live" rev 0x05: irq 3
ac97: codec id 0x54524123 (TriTech Microelectronics TR28602)
audio0 at emu0
"Creative Labs PCI Gameport Joystick" rev 0x05 at pci0 dev 14 function
1 not configured
ral0 at pci0 dev 15 function 0 "Ralink RT2561S" rev 0x00: irq 10,
address 00:1d:7d:34:0e:ec
ral0: MAC/BBP RT2561C, RF RT2527
skc0 at pci0 dev 16 function 0 "3Com 3c940" rev 0x10, Yukon (0x1): irq 9
sk0 at skc0 port A: address 00:0a:5e:5c:50:41
eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3
skc1 at pci0 dev 17 function 0 "3Com 3c940" rev 0x10, Yukon (0x1): irq 10
sk
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
On Fri, Jan 25, 2019 at 7:59 AM Peter N. M. Hansteen wrote: > On 1/24/19 11:55 PM, John Page wrote: > > I decided on installing OpenBSD 6.4 on a PC Engines apu4. I > > had previously been using an Asus RT-86U as both my router and wireless > > access point. > > OpenBSD's newer-wifi protocol support unfortunately lags what is > available in various commercial products. > > For that reason, in similar environments to what you describe I've tried > to get hold of APs with good radios and support for all the protocol > variants, then disabled all functionality on the access points > themselves other than the access point functionality, in some cases down > to even letting the things get the IP address for their Ethernet > interface from the OpenBSD dhcpd. > > With 'dumb' access points little more than Ethernet interfaces > themselves, you get to control how things work from the sane OpenBSD > environment. > I second this approach as working quite well, and is almost as easy to manage as HostAP from within OpenBSD. I have my commercial AP configured to bridge each SSID/network onto a different VLAN. My OpenBSD router can then process each VLAN in a way appropriate to their purpose (family, guests, streaming appliances, etc). --david
More missing file removals from upgrade*.html?
While the upgrade process is so painless that I often forgot the #RmFiles steps, I may have found some omissions in past releases... The 5.2 => 5.3 upgrade is the last one that removed this directory: /usr/lib/gcc-lib/*-unknown-openbsd5.x I haven't seen any upgrades that removed these directories either: /usr/include/g++/*-unknown-openbsd5.x /usr/libdata/perl5/site_perl/*-openbsd/g++/*-unknown-openbsd5.x Is or was there any reason to keep these around, or was this intentional? --david
Re: More missing file removals from upgrade*.html?
On Tuesday, November 4, 2014, Nick Holland wrote: > On 11/04/14 16:18, David Higgs wrote: > > While the upgrade process is so painless that I often forgot the > > #RmFiles steps, I may have found some omissions in past releases... > > > > The 5.2 => 5.3 upgrade is the last one that removed this directory: > > /usr/lib/gcc-lib/*-unknown-openbsd5.x > > > > I haven't seen any upgrades that removed these directories either: > > /usr/include/g++/*-unknown-openbsd5.x > > /usr/libdata/perl5/site_perl/*-openbsd/g++/*-unknown-openbsd5.x > > > > Is or was there any reason to keep these around, or was this intentional? > > > > --david > > There's no reason to keep them around, but no real reason to get excited > about removing them, either. If there is something that will CAUSE > PROBLEMS, hopefully it ends up on current.html, and I'll incorporate it > into upgradexx.html, but the rest is mostly cosmetic. > > There are gobs of library files and other things that get left behind on > an upgrade that really aren't an issue. The deletion list this time > around was too long as it is. If you want to look for files that are > older than the upgrade you just did, go for it, but I suspect you have > better uses of your time. > No doubt. There was just other chatter about file removal which tickled my memory about the gcc-lib directory. It's probably safe to assume this isn't automated so as not to break packages prior to pkg_add -u or manually installed things. If they start annoying me and I can't figure out the magic find(1) incantation, I'll just reinstall and call it a day. Sorry for the noise, and thanks for another great release. --david
Local changes to /etc/services?
I defined the 'svn' port in /etc/services but as of 5.6 this file now appears to be unconditionally overwritten during upgrades (previously it was handled via sysmerge). Is there a better mechanism to keep these, or should I just update pf.conf to use the numeric port number? The services(5) man page doesn't provide any hints. Thanks. --david
Re: Postfix compilation error.
On Wed, Nov 12, 2014 at 11:28 AM, giacomo wrote: > On 12.11.14, 09:01, Jiri B wrote: >> >> Shot in the dark... but isn't the problem you have sasl, mysql built with >> kerberos from the past? Try to rebuild sasl, mysql. >> >> j. > > Hi, > No postfix is the only port installated on the system. I use it for the > integration > of MySQL and SASL2. The pakages installated are: > # pkg_info ... > cyrus-sasl-2.1.26p10 RFC SASL (Simple Authentication and Security Layer) That version of SASL is from 5.5 and still has kerberos support. At minimum, you forgot to upgrade your packages for 5.6. http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/cyrus-sasl2/Makefile.diff?r1=1.81&r2=1.82 --david
Re: apcupsd via USB on 5.6
On Thu, Nov 20, 2014 at 11:03 AM, Steven Surdock wrote: > I just upgrade from 5.5 to 5.6 on i386 and apcupsd won't recognize my UPS > plugged into a USB port. On 5.5 the UPS was attached to ugen0 but on 5.6 it > say uhidev0. Apcupsd mentions that the uhidev0 device type won't work. I > see that I can get some info from sensord (which is cool). Any suggestions > for getting the UPS working with apcupds? > > Oct 22 16:16:42 builder02 /bsd: ugen0 at uhub1 port 1 "American Power > Conversion Smart-UPS 1500 FW:601.3.D USB FW:1.3" rev 1.10/0.06 addr 2 > > Nov 20 08:54:27 builder02 /bsd: uhidev0 at uhub1 port 1 configuration 1 > interface 0 "American Power Conversion Smart-UPS 1500 FW:601.3.D USB FW:1.3" > rev 1.10/0.06 addr 2 > Depending on what you configured apcupsd to do and what sysctl exposes, you may be able to create equivalent behavior using sensorsd(8). There's a brief overview in the comments of the undeadly article below, to serve as starting point for your needs: http://undeadly.org/cgi?action=article&sid=20140320093943 --david
Fixes for newsyslog(8) time parsing
The tm_mon already adjusts by 1, so the allowed range should be 0 - 11. Since mktime(3) is permissive in what it accepts, I think this check is correct. The second part handles the (theoretically valid but essentially useless) parsing of a configuration file with an ISO 8601 date with leap second. I'm not sure whether mktime(3) discards or keeps valid leap seconds, or if the "restrictedness" of the implementation should permit them, so maybe this isn't necessary. Apologies since gmail will probably mangle the diff. --david --- usr.bin/newsyslog/newsyslog.c Thu Nov 20 15:11:02 2014 +++ usr.bin/newsyslog/newsyslog.c Thu Nov 20 15:12:39 2014 @@ -1186,7 +1186,7 @@ parse8601(char *s) } /* sanity check */ - if (tm.tm_year < 70 || tm.tm_mon < 0 || tm.tm_mon > 12 || + if (tm.tm_year < 70 || tm.tm_mon < 0 || tm.tm_mon > 11 || tm.tm_mday < 1 || tm.tm_mday > 31) return (-1); @@ -1213,7 +1213,7 @@ parse8601(char *s) } /* sanity check */ - if (tm.tm_sec < 0 || tm.tm_sec > 60 || tm.tm_min < 0 || + if (tm.tm_sec < 0 || tm.tm_sec > 61 || tm.tm_min < 0 || tm.tm_min > 59 || tm.tm_hour < 0 || tm.tm_hour > 23) return (-1); }
Re: sensorsd, upd, and state changes
On Fri, Nov 28, 2014 at 2:45 AM, Marcus MERIGHI wrote: > What I have now: > > $ getcap -a -f /etc/sensorsd.conf > hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \ > %l %n %s %x %t %2 %3 %4 > hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \ > %l %n %s %x %t %2 %3 %4 > hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \ > %l %n %s %x %t %2 %3 %4 > hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \ > %l %n %s %x %t %2 %3 %4 > hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \ > %l %n %s %x %t %2 %3 %4 > hw.sensors.upd0.percent0:low=10:high=100:command=\ > /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4 > hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \ > %l %n %s %x %t %2 %3 %4 Do you mind saying what type of USB you have, and what these sensors map are for your hardware? I have: uhidev0 at uhub1 port 2 configuration 1 interface 0 "American Power Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3" rev 1.10/1.01 addr 2 uhidev0: iclass 3/0, 146 report ids upd0 at uhidev0 Which only appears to provide: hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK Thanks. --david
Re: sensorsd, upd, and state changes
On Sun, Nov 30, 2014 at 10:54 AM, Marcus MERIGHI wrote: > for the impatient, here are my questions: > > - Although I use the same (undocumented, undeadly.org) trick of > "low=1:high=2" for indicators everywhere, this can result in > "On is below On", and "Off is below On" > - Although I use "low=1:high=2", I get "On" for %3 (low limit) as well > as for %4 (high limit) > - Reading sensorsd.conf(5): > "If the limits are crossed or if the status provided by the driver > changes, sensorsd(8)'s alert functionality is triggered and a command, > if specified, is executed" > If limits are crossed, yes; if status changes, no, unless you use the > "low=1:high=2" trick. > - Reading sensorsd.conf(5): > "Values for all other types of sensors can be specified in the same > units as they appear under the sysctl(8) hw.sensors tree." > No: "low=Off:high=On" results in (sensorsd -c 1 -d): > "sensorsd: incorrect value: Off: file or directory not found" > Now that I have a reporting upd(4) device, I've had a chance to poke at this. There is currently no code in upd(4) that sets WARN or CRITICAL. Yes, it appears that SENSOR_INDICATOR items require numeric high/low values. This is not documented in sensorsd.conf(5). It is either an oversight in documentation or parsing. I've found that it helps to think of the high/low values in sensorsd.conf(5) as the closed interval for "normal" operation. The example "hw.sensors.lm0.volt3:low=4.8V:high=5.2V" will trigger when the voltage goes below (but not at) 4.8V and above (but not at) 5.2V. sysctl(8) will display Off if the value is zero, and On for nonzero. So, using the "closed interval" rule above, you should use "high=0" for indicators that you consider in "good" state when Off (i.e. ShutdownImminent), and "low=1" for indicators that you consider in "good" state when On (i.e. ACPresent). # sensorsd.conf(5) hw.sensors.upd0.indicator0:high=0:command=/etc/sensorsd_log.sh %x Charging %2 %s hw.sensors.upd0.indicator1:high=0:command=/etc/sensorsd_log.sh %x Discharging %2 %s hw.sensors.upd0.indicator2:low=1:command=/etc/sensorsd_log.sh %x ACPresent %2 %s hw.sensors.upd0.indicator3:high=0:command=/etc/sensorsd_log.sh %x ShutdownImminent %2 %s hw.sensors.upd0.indicator4:low=1:command=/etc/sensorsd_log.sh %x BatteryPresent %2 %s hw.sensors.upd0.percent0:low=25:command=/etc/sensorsd_log.sh %x RemainingCapacity %2 %s hw.sensors.upd0.percent1:low=25:command=/etc/sensorsd_log.sh %x FullChargeCapacity %2 %s --david
Re: sensorsd, upd, and state changes
On Mon, Dec 8, 2014 at 3:37 PM, trondd wrote: > On Mon, Dec 8, 2014 at 3:23 PM, trondd wrote: >> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs wrote: >>> >>> >>> sysctl(8) will display Off if the value is zero, and On for nonzero. >>> So, using the "closed interval" rule above, you should use "high=0" >>> for indicators that you consider in "good" state when Off (i.e. >>> ShutdownImminent), and "low=1" for indicators that you consider in >>> "good" state when On (i.e. ACPresent). >>> >> >> Isn't saying high=0 kind of the same thing as saying low=1? > > > Oh, I think I get this. Since the sensor doesn't trigger if it is on the > limit, only outside the limit, you have to set up which is the OK state. > > Still a little confusing but I guess there is no way to automatically know > if an indicator is supposed to be Off or On when it's in it's good state? > Kind of. The high/low difference is what values you consider "within" normal operating parameters (and the output of %l). The upd(4) code hasn't yet been taught how to map specific indicator values to OK / WARN / CRITICAL status. Currently any value successfully read is marked OK. I'm working with tech@ and slowly writing diffs to improve these things. --david
Xmas
slippers Saffron Ornament Beer things?
Re: CPU criteria for OpenBSD firewall
On Thu, Feb 19, 2015 at 10:33 AM, Dmitrij D. Czarkoff wrote: > Stuart Henderson said: >> Half of that page is obsolete. > [...] >> Various things are recommended without explaining that they are a >> trade-off or can cause problems. There are >> It includes "tweaks" which may improve performance of an end host (but >> have trade-offs) in a page mostly talking about routers, other >> "tweaks" which are nothing to do with networking and in some cases >> dangerous. > > It would be nice if someone with expertise could write a detailed > explanation of the issues with that article... > It shouldn't be any developer's responsibility to refute or confirm unofficial guidance found anywhere else. Unnecessary configuration tweaks frequently confuse and discourage those who would otherwise help you troubleshoot legitimate issues, either because they have caused the problem in the first place or have introduced red herrings. The defaults are suitable as defaults. If and when a default no longer makes sense, it will likely be changed. If a default is not appropriate for YOUR personal needs, it is YOUR responsibility to figure out what needs fixing or changing. Refer to the official FAQs, manuals, source, mailing list archives, etc to figure out what to do -- prior to asking questions. --david
Re: Maintaining your system with snapshots
On Fri, Feb 20, 2015 at 10:21 AM, Steve Williams < st...@williamsitconsulting.com> wrote: > Hi, > > I have been using snapshots for my system, but don't update too often. > Sometimes there's a package I want to install, but because my snapshot > is old (stale when compared to the current repository), I can't get the > package. > > What I have started to do is download the ports.tar.gz when I install a > snapshot. I have no idea if this is a "supported" approach, but I've > never had a problem building from ports when I need something "after the > fact". The downside of doing this is I get MANY packages installed > that are dependencies of building a port. > As someone else mentioned, snapshot packages are usually perfectly sufficient, unless you have some corner case like an arch that doesn't refresh frequently or you need a very recent fix. There are occasional hiccups but rarely are they serious; this is the tradeoff for following closer to the development edge. If you are tired of old build dependencies, look into pkg_delete -a. You may need to alternate pkg_info -m and pkg_add -aa to mark your packages appropriately. On my systems, ONLY my required packages are marked as "manually" installed, so that I can run pkg_delete -a immediately after sysmerge and pkg_add -u. --david
Signal handling questions
I am continuing my wanderings through the guts of signal handling, and wonder if can anyone can help me confirm (or better understand) the end result from userland's point of view. Signal delivery can be nested/reentrant. Calling raise(3) in a signal handler -- even with the same signal number -- will work as expected (until you blow your stack). What I'm not sure about is when multiple, identical signals arrive *before* the signal handler is invoked. A naive interpretation of sigpending(2) suggests only one of each signal can be pending at a time. However, the kernel could place multiple signal contexts on the stack before invoking any handlers, and then userland will process them in LIFO order. FWIW, I'm looking at 5.1 code, and don't expect much/any of this high level behavior to change with rthreads in 5.2. Thanks. --david
Re: Signal handling questions
On Sun, Oct 14, 2012 at 1:07 AM, Philip Guenther wrote: > On Sat, Oct 13, 2012 at 9:38 PM, David Higgs wrote: >> Signal delivery can be nested/reentrant. Calling raise(3) in a signal >> handler -- even with the same signal number -- will work as expected >> (until you blow your stack). > > By default, a signal is deferred when the signal itself is being > handled; c.f. the SA_NODEFER flag on the sigaction(2) manpage. If > that isn't set then raising the signal in its own signal handler will > just result in it being pending until you return from the signal > handler, at which point the signal mask will be restored and the > pending signal will be delivered. (That's specified by POSIX.) > > >> What I'm not sure about is when multiple, identical signals arrive >> *before* the signal handler is invoked. A naive interpretation of >> sigpending(2) suggests only one of each signal can be pending at a >> time. However, the kernel could place multiple signal contexts on the >> stack before invoking any handlers, and then userland will process >> them in LIFO order. > > OpenBSD doesn't support signal queuing; a signal sent to a process > while that signal is already pending for the process will be ignored. Very informative, thank you. --david
5.2 bsd.rd -- panic: cannot open disk, error EINVAL
I seem to be unable to boot from locally-compiled bsd.rd (i386). I
have triple-checked everything I'm doing against release(8)
instructions and tried both 5.2 -stable and release CVS tags; the
result is the same: "panic: cannot open disk, 0x1100/0x2f02, error 22"
It may be of note that the bsd.rd distributed by the project works
fine and I have had no problems at all with bsd.sp. This problem is
also reproducible in the VMware VM that I use to compile.
Included below is bsd.rd output from my ALIX system and dmesg from bsd.sp.
Thanks.
--david
### bsd.rd ###
PC Engines ALIX.2 v0.99h
640 KB Base Memory
261120 KB Extended Memory
01F0 Master 044A TS16GCF133
Phys C/H/S 16383/15/63 Log C/H/S 1023/240/63
Using drive 0, partition 3.
Loading...
probing: pc0 com0 com1 pci mem[640K 255M a20=on]
disk: hd0+
>> OpenBSD/i386 BOOT 3.18
switching console to com0
>> OpenBSD/i386 BOOT 3.18
boot> boot bsd.rd
booting hd0a:bsd.rd: 6968724+961936 [52+229744+218028]=0x7fd9e8
entry point at 0x200120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.2 (RAMDISK_CD) #2: Fri Nov 2 15:19:26 EDT 2012
root@vm.localdomain:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 267976704 (255MB)
avail mem = 254894080 (243MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
"AMD Geode LX Crypto" rev 0x00 at pci0 dev 1 function 2 not configured
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:0d:b9:1e:60:7c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:0d:b9:1e:60:7d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 15,
address 00:0d:b9:1e:60:7e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
pcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 15296MB, 31326208 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 12,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 12
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
"American Power Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3" rev
1.10/1.01 addr 2 at uhub1 port 2 not configured
softraid0 at root
scsibus0 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
panic: cannot open disk, 0x1100/0x2f02, error 22
syncing disks... done
dumping to dev 1101, offset 0
dump area unavailable
rebooting...
### bsd ###
OpenBSD 5.2 (GENERIC) #2: Fri Nov 2 15:15:16 EDT 2012
root@vm.localdomain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 267976704 (255MB)
avail mem = 252735488 (241MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:0d:b9:1e:60:7c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6
Re: 5.2 bsd.rd -- panic: cannot open disk, error EINVAL
You guessed right. Apparently I don't understand the build process as well as I thought. I skipped the userland + release steps, since there hadn't been any -stable patches against those with 5.2. Sorry for the noise. --david On Mon, Nov 5, 2012 at 8:51 AM, Miod Vallat wrote: >> I seem to be unable to boot from locally-compiled bsd.rd (i386). I >> have triple-checked everything I'm doing against release(8) >> instructions and tried both 5.2 -stable and release CVS tags; the >> result is the same: "panic: cannot open disk, 0x1100/0x2f02, error 22" > > Let me guess. You have compiled RAMDISK, copied that to bsd.rd, and > tried to boot it, didn't you? > > Compiling RAMDISK is not enough for it to work. You need to put a > filesystem in it afterwards - this is what the machinery within > src/distrib/ does. > > Miod
Panic during halt (5.2)
Got this panic while running "halt -p" to shut down my VMware system
this evening. First time I've seen it and haven't been able to
reproduce in several reboot since.
I can't see this being related to my mistakes this morning with
bsd.rd, but don't feel entirely confident it wasn't somehow my fault.
Either way, here's ps+trace+dmesg for posterity.
Thanks.
--david
syncing disks... uvm_fault(0xd54eea00, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at handle_workitem_freeblocks+0x2b:movl0x10(%eax),%eax
ddb> ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
*22985 1 22985 0 7 0halt
12 0 0 0 30x100200 aiodoned aiodoned
11 0 0 0 30x100200 syncerupdate
10 0 0 0 30x100200 cleaner cleaner
9 0 0 0 30x100200 reaperreaper
8 0 0 0 30x100200 pgdaemon pagedaemon
7 0 0 0 30x100200 bored crypto
6 0 0 0 30x100200 pftm pfpurge
5 0 0 0 30x100200 acpi0 acpi0
4 0 0 0 30x100200 bored syswq
3 0 0 0 3 0x40100200idle0
2 0 0 0 30x100200 kmalloc kmthread
1 0 1 0 30x80 wait init
0 -1 0 0 3 0x200 scheduler swapper
ddb> trace
handle_workitem_freeblocks(d546d498,d532e1fc,d5430e88,f3776dbc) at
handle_workitem_freeblocks+0x2b
process_worklist_item(d11ff000,0,f3776dfc,d041b72e,0) at
process_worklist_item+0x171
softdep_process_worklist(d11ff000,0,f3776e2c,d041a8ca,d54bcd7c) at
softdep_process_worklist+0x136
softdep_flushworklist(d11ff000,f3776e6c,d5430e88,d041c8fa,50) at
softdep_flushworklist+0x7c
ffs_sync(d11ff000,1,d54fd5f0,d5430e88,d11ff01c) at ffs_sync+0x119
dounmount(d11ff000,8,d5430e88,0,f3776ee8) at dounmount+0x66
vfs_unmountall(d0a36420,0,0,d5430e88,9) at vfs_unmountall+0x68
vfs_shutdown(d5430e88,d54eea00,3c00e000,1000,d54eea00) at vfs_shutdown+0x7f
boot(1008,0,f3776f9c,d057f7aa,d5430e88) at boot+0x18a
sys_reboot(d5430e88,f3776f64,f3776f84,d057fbea,d5430e88) at sys_reboot+0x2c
syscall() at syscall+0x26a
--- syscall (number 0) ---
0x2:
ddb> boot reboot
vmware: sending length failed, eax=, ecx=
vmt0: failed to send shutdown ping
vmware: close failed, eax=, ecx=
rebooting...
OpenBSD 5.2 (GENERIC) #1: Mon Nov 5 08:54:29 EST 2012
root@vm.localdomain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz ("GenuineIntel"
686-class) 2.40 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,SSSE3,CX16,LAHF
real mem = 267907072 (255MB)
avail mem = 252665856 (240MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/02/11, BIOS32 rev. 0 @
0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 06/02/2011
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3)
S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3)
Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3)
Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3)
Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3)
Z01B(S3) Z01C(S3) P2P1(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3)
S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) Z00Q(S3) Z00R(S3)
Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3)
Z00Z(S3) Z010(S3) Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3)
Z016(S3) Z017(S3) Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) Z01C(S3)
P2P2(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3)
S7F0(S3) S8F0(S3) S9F0(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3)
Z00U(S3) Z00V(S3) Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3)
Z011(S3) Z012(S3) Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3)
Z018(S3) Z019(S3) Z01A(S3) Z01B(S3) Z01C(S3) P2P3(S3) S1F0(S3)
S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3)
S9F0(S3) Z00Q(S3) Z00R(S3) Z00S(S3) Z00T(S3) Z00U(S3) Z00V(S3)
Z00W(S3) Z00X(S3) Z00Y(S3) Z00Z(S3) Z010(S3) Z011(S3) Z012(S3)
Z013(S3) Z014(S3) Z015(S3) Z016(S3) Z017(S3) Z018(S3) Z019(S3)
Z01A(S3) Z01B(S3) Z01C(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3)
PE60(S3) S1F0(S3) PE70(S3) S1F0(S3) PE80(S3) S1F0(S3) PE90(S3)
S1F0(S3) PEA0(S3) S1F0(S3) PEB0(S3) S1F0(S3) PEC0(S3) S1F0(S3)
PED0(S3) S1F0(S3) PEE0(S3) S1F0(S3) PE41(S3) S1F0(S3) PE42(S3)
S1F0(S3) PE43(S3) S1F0(S3) PE44(S3) S1F0(S3) PE45(S3) S1F0(S3)
PE46(S3) S1F0(S3) PE47(S3) S1F0(S3) PE51(S3) S1F0(S3) PE52(S3)
S1F0(S3) PE53(S3) S1F0(S3) PE54(S3) S1F0(S3) PE55(S3) S1F0(S3)
PE56(S3) S1F0(S3) PE57(S3) S1F0(S3) PE61(S3) S1F0(S3) PE
NFS cluestick needed
In trying to avoid multiple copies of OpenBSD source on my VMs, I am
trying to use NFS; however, permissions don't seem to be working
right. I would very much appreciate help in figuring out what I'm
doing wrong, and am also interested in tips on how to compile from
read-only source trees.
Thanks in advance,
--david
SERVER VM
[vm@vm ~]$ dmesg | head
OpenBSD 5.2 (GENERIC) #2: Mon Nov 5 10:42:07 EST 2012
root@vm.localdomain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz ("GenuineIntel"
686-class) 2.45 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,SSSE3,CX16,LAHF
real mem = 267907072 (255MB)
avail mem = 252665856 (240MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/20/12, BIOS32 rev. 0 @
0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 09/20/2012
bios0: VMware, Inc. VMware Virtual Platform
[vm@vm ~]$ cat /etc/exports
# $OpenBSD: exports,v 1.2 2002/05/31 08:15:44 pjanzen Exp $
#
# NFS exports Database
# See exports(5) for more information. Be very careful: misconfiguration
# of this file can result in your filesystems being readable by the world.
/usr/src /usr/ports /usr/xenocara -maproot=root:wheel
-network=172.16.223.0 -mask=255.255.255.0
[vm@vm ~]$ showmount -a
All mount points on localhost:
172.16.223.129:/usr/ports
172.16.223.129:/usr/src
172.16.223.129:/usr/xenocara
CLIENT VM
# dmesg | head
OpenBSD 5.2-stable (GENERIC) #2: Wed Dec 26 12:19:49 EST 2012
root@vm.localdomain:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 267321344 (254MB)
avail mem = 237985792 (226MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 09/20/2012
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
# mount
/dev/wd0a on / type ffs (local, softdep)
/dev/wd0f on /home type ffs (local, noatime, nodev, nosuid, softdep)
/dev/wd0d on /tmp type ffs (local, nodev, nosuid, softdep)
/dev/wd0g on /usr type ffs (local, noatime, nodev, softdep)
/dev/wd0e on /var type ffs (local, nodev, nosuid, softdep)
172.16.223.128:/usr/src on /usr/src type nfs (noatime, nodev, noexec,
nosuid, v3, udp, timeo=100, retrans=101)
172.16.223.128:/usr/ports on /usr/ports type nfs (noatime, nodev,
noexec, nosuid, v3, udp, timeo=100, retrans=101)
172.16.223.128:/usr/xenocara on /usr/xenocara type nfs (noatime,
nodev, noexec, nosuid, v3, udp, timeo=100, retrans=101)
# id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty),
5(operator), 20(staff), 31(guest)
# ls -la /usr/src/sys/arch/amd64/compile/
total 16
drwxr-xr-x 3 root wheel 512 Feb 27 2009 .
drwxr-xr-x 10 root wheel 512 Nov 29 2010 ..
-rw-r--r-- 1 root wheel 38 Jun 25 2004 .cvsignore
drwxr-xr-x 2 root wheel 512 Mar 30 16:37 CVS
# mkdir /usr/src/sys/arch/amd64/compile/GENERIC
mkdir: /usr/src/sys/arch/amd64/compile/GENERIC: Permission denied
Re: NFS cluestick needed
On Mon, Apr 1, 2013 at 7:33 AM, Stuart Henderson wrote: > On 2013-03-31, David Higgs wrote: >> In trying to avoid multiple copies of OpenBSD source on my VMs, I am >> trying to use NFS; however, permissions don't seem to be working >> right. I would very much appreciate help in figuring out what I'm >> doing wrong, and am also interested in tips on how to compile from >> read-only source trees. > > > On the NFS server, is /usr/src in the same filesystem as some other > path which you export with different options? > > (NFS server options (-maproot etc) are per-filesystem not per export.) > I originally provided the entirety of my /etc/exports file, but experimenting with debugging flags produced output that varied depending on whether /etc/exports had one or multiple lines. Using multiple lines fixes my permissions problem, interestingly enough. Is this sendbug(1) worthy? Will experiment with read-only and lndir(1) in the coming week. Thanks. --david [vm@vm ~]$ mount /dev/wd0a on / type ffs (local, softdep) /dev/wd0f on /home type ffs (local, noatime, nodev, nosuid, softdep) /dev/wd0d on /tmp type ffs (local, nodev, nosuid, softdep) /dev/wd0g on /usr type ffs (NFS exported, local, noatime, nodev, softdep) /dev/wd0e on /var type ffs (local, nodev, nosuid, softdep) # /etc/exports has one line with multiple paths exported [vm@vm ~]$ sudo /sbin/mountd -d Getting export list. Got line # $OpenBSD: exports,v 1.2 2002/05/31 08:15:44 pjanzen Exp $ Got line # Got line # NFS exports Database Got line # See exports(5) for more information. Be very careful: misconfiguration Got line # of this file can result in your filesystems being readable by the world. Got line /usr/src /usr/ports /usr/xenocara -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 Making new ep fs=0x6,0x602f3b81 doing opt -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 doing opt -network=172.16.223.0 -mask=255.255.255.0 doing opt -mask=255.255.255.0 exporting /usr/xenocara unexporting / / unexporting /home /home unexporting /tmp /tmp unexporting /usr /usr unexporting /var /var Getting mount list. Here we go. ^C ### updated /etc/exports with multiple lines [vm@vm ~]$ sudo /sbin/mountd -d Getting export list. Got line # $OpenBSD: exports,v 1.2 2002/05/31 08:15:44 pjanzen Exp $ Got line # Got line # NFS exports Database Got line # See exports(5) for more information. Be very careful: misconfiguration Got line # of this file can result in your filesystems being readable by the world. Got line /usr/src -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 Making new ep fs=0x6,0x602f3b81 doing opt -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 doing opt -network=172.16.223.0 -mask=255.255.255.0 doing opt -mask=255.255.255.0 exporting /usr/src Got line /usr/ports -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 Found ep fs=0x6,0x602f3b81 doing opt -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 doing opt -network=172.16.223.0 -mask=255.255.255.0 doing opt -mask=255.255.255.0 exporting /usr/ports Got line /usr/xenocara -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 Found ep fs=0x6,0x602f3b81 doing opt -maproot=root:wheel -network=172.16.223.0 -mask=255.255.255.0 doing opt -network=172.16.223.0 -mask=255.255.255.0 doing opt -mask=255.255.255.0 exporting /usr/xenocara unexporting / / unexporting /home /home unexporting /tmp /tmp unexporting /usr /usr unexporting /var /var Getting mount list. Here we go.
Re: NFS cluestick needed
On Tue, Apr 2, 2013 at 7:05 AM, Stuart Henderson wrote: > On 2013-04-01, David Higgs wrote: >> On Mon, Apr 1, 2013 at 7:33 AM, Stuart Henderson >> wrote: >>> On 2013-03-31, David Higgs wrote: >>>> In trying to avoid multiple copies of OpenBSD source on my VMs, I am >>>> trying to use NFS; however, permissions don't seem to be working >>>> right. I would very much appreciate help in figuring out what I'm >>>> doing wrong, and am also interested in tips on how to compile from >>>> read-only source trees. >>> >>> >>> On the NFS server, is /usr/src in the same filesystem as some other >>> path which you export with different options? >>> >>> (NFS server options (-maproot etc) are per-filesystem not per export.) >>> >> >> I originally provided the entirety of my /etc/exports file, but > > The exports file isn't enough to show whether directories are in > the same filesystem (see the warning in the BUGS section of exports(5). > >> experimenting with debugging flags produced output that varied >> depending on whether /etc/exports had one or multiple lines. Using >> multiple lines fixes my permissions problem, interestingly enough. Is >> this sendbug(1) worthy? > > Looks like this is documented: > > Each line in the file (other than comment lines that begin with a ``#'') > specifies the mount point(s) and export flags within one local server > filesystem for one or more hosts. Highlighting this and the BUGS section makes more sense. While accurate, the combined terminology of mount points, filesystems, local, and remote was terse enough to confuse me. I may experiment more to definitively reproduce my permissions issue. >> Will experiment with read-only and lndir(1) in the coming week. > > iirc there's something in the source tree which doesn't work with > a read-only mount (xenocara is OK though), not sure whether lndir > gets around that or not. > I'm slowly whittling down the options required. Building the kernel creates and populates a compile directory, while userland wants to create obj symlinks and has problems with binutils/gdb when using noexec. Haven't gotten to lndir yet. Thanks again. --david
dhclient drops address on re-exec in 5.3 bsd.rd
Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not "right". Thanks! --david
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback wrote: > On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote: >> Confirmed in 5.3-current downloaded several minutes ago. >> >> Steps to reproduce: >> - Boot bsd.rd >> - Select upgrade, hit enter until dhclient gets and assigns an address >> - Complete upgrade or control-C, then restart the upgrade process >> - dhclient on 2nd run REMOVES the assigned address >> >> Probably affects the bsd.rd install option as well. This does not >> happen with 5.2 bsd.rd. >> >> Easy to work around, but probably not "right". >> >> Thanks! >> >> --david >> > > Can't reproduce on amd64 -current here. I did control-C after getting > dhclient lease, entered 'upgrade' at command prompt, and re-started > upgrade. dhclient worked fine. Checked 'ifconfig' and the expected > address was present. > > So more info you what exactly you are doing, on what machine are > you doing it, and perhaps anything interesting in your dhclient.conf > would be helpful. Thanks. > > Ken I would have provided output, but I haven't figured out how to log console output from VMware images. Hopefully this will suffice: i386 / 5.3-current / RAMDISK_CD #120 dhclient #1 (good) DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds dhclient #2 (bad) DHCPREQUEST on vic0 to 255.255.255.255 port 67 Active address (172.16.223.131) deleted; exiting dhclient #3 (good) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds amd64 / 5.3-current / RAMDISK_CD #132 dhclient #1 (good) DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds dhclient #2 (still good) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds /etc/dhclient.conf appears to be identical to between i386 and amd64. I am sending an identical hostname FWIW, but I am only launching only one VM at a time. initial-interval 1; send host-name "vm"; request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; Let me know if you want me to try anything else. --david
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 6:39 PM, Kenneth R Westerback
wrote:
> On Sun, Apr 28, 2013 at 05:29:05PM -0400, David Higgs wrote:
>> On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback
>> wrote:
>> > On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote:
>> >> Confirmed in 5.3-current downloaded several minutes ago.
>> >>
>> >> Steps to reproduce:
>> >> - Boot bsd.rd
>> >> - Select upgrade, hit enter until dhclient gets and assigns an address
>> >> - Complete upgrade or control-C, then restart the upgrade process
>> >> - dhclient on 2nd run REMOVES the assigned address
>> >>
>> >> Probably affects the bsd.rd install option as well. This does not
>> >> happen with 5.2 bsd.rd.
>> >>
>> >> Easy to work around, but probably not "right".
>> >>
>> >> Thanks!
>> >>
>> >> --david
>> >>
>> >
>> > Can't reproduce on amd64 -current here. I did control-C after getting
>> > dhclient lease, entered 'upgrade' at command prompt, and re-started
>> > upgrade. dhclient worked fine. Checked 'ifconfig' and the expected
>> > address was present.
>> >
>> > So more info you what exactly you are doing, on what machine are
>> > you doing it, and perhaps anything interesting in your dhclient.conf
>> > would be helpful. Thanks.
>> >
>> > Ken
>>
>> I would have provided output, but I haven't figured out how to log
>> console output from VMware images. Hopefully this will suffice:
>>
>> i386 / 5.3-current / RAMDISK_CD #120
>>
>> dhclient #1 (good)
>> DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1
>> DHCPOFFER from 172.16.223.254 (mac addr)
>> DHCPREQUEST on vic0 to 255.255.255.255 port 67
>> DHCPACK from 172.16.223.254 (mac addr)
>> bound to 172.16.223.131 -- renewal in 900 seconds
>>
>> dhclient #2 (bad)
>> DHCPREQUEST on vic0 to 255.255.255.255 port 67
>> Active address (172.16.223.131) deleted; exiting
>
> Trying the exact same RAMDISK_CD #120 on 'real' i386 hardware with
> an nfe(4) interface, I cannot reproduce. So I suspect (assuming it
> is not just an errant log message) something is broken in the i386/vm
> interface you are trying.
>
> Ken
More simple tests on i386 follow. The "every other failure" is pretty
repeatable but I have seen a couple cases where it worked. I wouldn't
be surprised if the opposite applies to the non-zero sleep test.
1. Always OK: from bsd.rd - "dhclient vic0"
2. Fail: from bsd.rd - "ifconfig vic0 down ; dhclient vic0"
3. Fail: from bsd.rd - "ifconfig vic0 down ; sleep 0 ; dhclient vic0"
4. OK: from bsd.rd - "ifconfig vic0 down ; sleep 0.001 ; dhclient vic0"
5. Always OK: from bsd - "ifconfig vic0 down ; dhclient vic0"
Smells like a driver timing or hardware emulation bug to me. I am
running OpenBSD as 32-bit "Other", inside VMware Fusion 4.0.4 if that
makes any difference. Anything else I can do or provide to help?
dmesg output (apologies for gmail's line wrapping):
OpenBSD 5.3-current (RAMDISK_CD) #120: Thu Apr 25 17:10:53 MDT 2013
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz ("GenuineIntel"
686-class) 2.40 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,SSSE3,CX16,LAHF,PERF,ITSC
real mem = 267907072 (255MB)
avail mem = 256258048 (244MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/20/12, BIOS32 rev. 0 @
0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 09/20/2012
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 65MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xdc000/0x4000! 0xe/0x8000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 chan
pkg_add loop/merge problems (postgresql upgrade)
Had some minor problems this morning upgrading my new 5.3 install with the -stable pg package that I built elsewhere. Not sure if this is because I hadn't cleaned up the partial 9.1.9 from 5.2 before upgrading or the package order problem that would have happened anyways. As usual, apologies for gmail's line-wrapping. Thanks. --david [mom@www pkgs]$ sudo pkg_add ./postgresql-client-9.2.4.tgz ./postgresql-server-9.2.4.tgz postgresql-client-9.2.3->9.2.4 forward dependencies: | Dependency of postgresql-server-9.2.3 on postgresql-client-=9.2.3 doesn't match Merging postgresql-server-9.2.3->9.2.3 (ok) Detected loop, merging sets ok | [postgresql-server-9.2.3]postgresql-client-9.2.3->9.2.4 Detected loop, merging sets ok | [postgresql-server-9.2.3]postgresql-client-9.2.3->9.2.4 Detected loop, merging sets ok | [postgresql-server-9.2.3]postgresql-client-9.2.3->9.2.4 Detected loop, merging sets ok | [postgresql-server-9.2.3]postgresql-client-9.2.3->9.2.4 Detected loop, merging sets ok ...etc... ^CFatal error: Caught SIGINT at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 40 in /var/db/pkg/postgresql-client-9.2.3/+CONTENTS, at /usr/libdata/perl5/OpenBSD/PackingList.pm line 306, <$fh> line 334. [mom@www pkgs]$ sudo pkg_add ./postgresql-server-9.2.4.tgz ./postgresql-client-9.2.4.tgz postgresql-client-9.2.3->9.2.4 forward dependencies: | Dependency of postgresql-server-9.2.3 on postgresql-client-=9.2.3 doesn't match Merging partial-postgresql-server-9.1.9+postgresql-server-9.2.3->postgresql-server-9.2.4 (ok) partial-postgresql-server-9.1.9+postgresql-client-9.2.3+postgresql-server-9.2.3->postgresql-client-9.2.4+postgresql-server-9.2.4: ok Read shared items: ok Look in /usr/local/share/doc/pkg-readmes for extra documentation. dmesg header: OpenBSD 5.3 (GENERIC) #53: Tue Mar 12 18:15:44 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Re: adsuck: script missing?
On Wed, Jul 15, 2015 at 5:09 PM, Erling Westenvik < erling.westen...@gmail.com> wrote: > On Wed, Jul 15, 2015 at 08:25:03PM +0200, Stefan Wollny wrote: > > Hi misc@! > > > > [Running i386/current: OpenBSD 5.8-beta (GENERIC.MP) #1026] > > > > I have been using adsuck for some time now - at least I thought so. > > Today I dared to read /usr/local/share/doc/pkg-readmes/adsuck-2.5.0p > > only to find out that apparently I need to add the following line to my > > /etc/dhclient.conf: > > script "/usr/local/sbin/dhclient-adsuck"; > > because "this script will prevent from using /etc/resolv.conf to resolve > > non-blacklisted entries but use /var/adsuck/files/resolv.conf instead." > > I've given up on adsuck. In addition to being unusable in a DHCP > environment, it proved useless anyway, making both firefox and chrome > sessions crash all the time for no apparent reason. > > Instead I'm using unbound(1) to block ads on both my gateway and on my > roadwarriors. Check out unbound.conf(5) and its include: directive. > Point it to a file with a two line format for each host/domain to > block, similar to this: > > local-zone: "adclick.com" redirect > local-data: "adclick.com A 127.0.0.1" > > I use adsuck without issues on my gateway; it hangs off a stable DHCP uplink so I don't have to monkey with /var/adsuck/resolv.conf after initial setup. The following lets me blackhole DNS for internal devices without exposing the service to external hosts. Also, I figured out how to regularly update the hosts file. [/etc/rc.conf.local] pkg_scripts="adsuck" adsuck_flags="-c /var/adsuck -f /files/resolv.conf /files/hosts.small" [/etc/pf.conf] # redirect all DNS from internal networks to adsuck # note: adsuck does not handle TCP DNS # note: gateway lookups are unfiltered match in on $internal_ifs proto udp to port domain rdr-to 127.0.0.1 [/etc/weekly.local] # periodically update blackhole list, needs reformatting if TMP=`mktemp`; then HFILE=/var/adsuck/files/hosts.small trap 'rm -f $TMP; exit 1' 0 1 15 mv $HFILE $HFILE.out ftp -Vo $TMP http://winhelp2002.mvps.org/hosts.txt sed -e 's/^M$//' -e '/::1/d' -e 's/^0.0.0.0/127.0.0.1/' $TMP > $HFILE /etc/rc.d/adsuck reload > /dev/null else echo "Cannot install adsuck hosts file" fi --david
Re: adsuck: script missing?
On Thu, Jul 16, 2015 at 2:44 AM, Stefan Wollny wrote: > Am 07/16/15 um 02:29 schrieb David Higgs: > > On Wed, Jul 15, 2015 at 5:09 PM, Erling Westenvik < > > erling.westen...@gmail.com> wrote: > > > >> On Wed, Jul 15, 2015 at 08:25:03PM +0200, Stefan Wollny wrote: > >>> Hi misc@! > >>> > >> > [ ... ] > >> > >> > > I use adsuck without issues on my gateway; it hangs off a stable DHCP > > uplink so I don't have to monkey with /var/adsuck/resolv.conf after > initial > > setup. The following lets me blackhole DNS for internal devices without > > exposing the service to external hosts. Also, I figured out how to > > regularly update the hosts file. > > > > > > [/etc/rc.conf.local] > > pkg_scripts="adsuck" > > adsuck_flags="-c /var/adsuck -f /files/resolv.conf /files/hosts.small" > > > > [/etc/pf.conf] > > # redirect all DNS from internal networks to adsuck > > # note: adsuck does not handle TCP DNS > > # note: gateway lookups are unfiltered > > match in on $internal_ifs proto udp to port domain rdr-to 127.0.0.1 > > > > [/etc/weekly.local] > > # periodically update blackhole list, needs reformatting > > if TMP=`mktemp`; then > > HFILE=/var/adsuck/files/hosts.small > > trap 'rm -f $TMP; exit 1' 0 1 15 > > mv $HFILE $HFILE.out > > ftp -Vo $TMP http://winhelp2002.mvps.org/hosts.txt > > sed -e 's/^M$//' -e '/::1/d' -e 's/^0.0.0.0/127.0.0.1/' $TMP > > > $HFILE > > /etc/rc.d/adsuck reload > /dev/null > > else > > echo "Cannot install adsuck hosts file" > > fi > > > > --david > > > > Hi David! > > Thank you for sharing your solution. > > I think you can omit the "adsuck_flags"-line in /etc/rc.conf.local as > the rc.d-script for adsuck has identical parameters for 'daemon_flags'. > > Basically I used the same script for updating hosts.small though your > implementation seems to be more sophisticated - mine is just more > complex as I want to keep the entries for my private network (plus some > additions/exceptions mvps does not have). Another thing is that I fetch > the zip-file as I used adsuck on my laptop and sometimes the connections > are slooow - that's why I update manually at irregular intervals. > > I find it astounding that using the mvps-entries on a regular > /etc/hosts-file gives me the same results without any noticeable delay - > what is adsuck actually providing if I get the same with one daemon less? > > If all you have is an endpoint (that doesn't provide DNS for anyone else), there is no benefit to using adsuck. A correctly-configured resolv.conf should find all the blackholed hosts directly from /etc/hosts. You are right, and this is the better solution for road warriors. However, DNS servers like my gateway will (generally?) not consult the local /etc/hosts file. Adsuck provides blackholing as a service for my internal networks from a single point, including devices (e.g. smartphones) that can't otherwise do this. I wouldn't call my script particularly sophisticated; it definitely needs improvement in handing of failed commands. Good point on the adsuck_flags variable - once upon a time I was different options. --david
Bad system calls in snapshot bsd.rd
While upgrading my snapshot VMs this morning, bsd.rd on both the i386 and amd64 produced 'Bad System Call' somewhere between making device nodes and reboot. If you're already aware of this, sorry for the noise. --david ### i386 bsd.rd OpenBSD 5.5-current (RAMDISK_CD) #161: Wed Jun 11 13:21:05 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD ### amd64 dmesgs (sorry for the gmail wrapping) OpenBSD 5.5-current (RAMDISK_CD) #181: Wed Jun 11 13:31:42 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 251592704 (239MB) avail mem = 239661056 (228MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 09/20/2012 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz, 2632.57 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,SSE3,SSSE3,CX16,NXE,LONG,LAHF,PERF,ITSC cpu0: 4MB 64b/line 16-way L2 cache cpu0: apic clock running at 67MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 "Intel 82371AB PIIX4 ISA" rev 0x08 at pci0 dev 7 function 0 not configured pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 64-sector PIO, LBA, 16384MB, 33554432 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) "Intel 82371AB Power" rev 0x08 at pci0 dev 7 function 3 not configured "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02 pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 "Intel 82545EM" rev 0x01: apic 1 int 18, address 00:0c:29:19:70:c8 ppb2 at pci0 dev 21 function 0 "VMware PCIE" rev 0x01 pci3 at ppb2 bus 3 ppb3 at pci0 dev 21 function 1 "VMware PCIE" rev 0x01 pci4 at ppb3 bus 4 ppb4 at pci0 dev 21 function 2 "VMware PCIE" rev 0x01 pci5 at ppb4 bus 5 ppb5 at pci0 dev 21 function 3 "VMware PCIE" rev 0x01 pci6 at ppb5 bus 6 ppb6 at pci0 dev 21 function 4 "VMware PCIE" rev 0x01 pci7 at ppb6 bus 7 ppb7 at pci0 dev 21 function 5 "VMware PCIE" rev 0x01 pci8 at ppb7 bus 8 ppb8 at pci0 dev 21 function 6 "VMware PCIE" rev 0x01 pci9 at ppb8 bus 9 ppb9 at pci0 dev 21 function 7 "VMware PCIE" rev 0x01 pci10 at ppb9 bus 10 ppb10 at pci0 dev 22 function 0 "VMware PCIE" rev 0x01 pci11 at ppb10 bus 11 ppb11 at pci0 dev 22 function 1 "VMware PCIE" rev 0x01 pci12 at ppb11 bus 12 ppb12 at pci0 dev 22 function 2 "VMware PCIE" rev 0x01 pci13 at ppb12 bus 13 ppb13 at pci0 dev 22 function 3 "VMware PCIE" rev 0x01 pci14 at ppb13 bus 14 ppb14 at pci0 dev 22 function 4 "VMware PCIE" rev 0x01 pci15 at ppb14 bus 15 ppb15 at pci0 dev 22 function 5 "VMware PCIE" rev 0x01 pci16 at ppb15 bus 16 ppb16 at pci0 dev 22 function 6 "VMware PCIE" rev 0x01 pci17 at ppb16 bus 17 ppb17 at pci0 dev 22 function 7 "VMware PCIE" rev 0x01 pci18 at ppb17 bus 18 ppb18 at pci0 dev 23 function 0 "VMware PCIE" rev 0x01 pci19 at ppb18 bus 19 ppb19 at pci0 dev 23 function 1 "VMware PCIE" rev 0x01 pci20 at ppb19 bus 20 ppb20 at pci0 dev 23 function 2 "VMware PCIE" rev 0x01 pci21 at ppb20 bus 21 ppb21 at pci0 dev 23 function 3 "VMware PCIE" rev 0x01 pci22 at ppb21 bus 22 ppb22 at pci0 dev 23 function 4 "VMware PCIE" rev 0x01 pci23 at ppb22 bus 23 ppb23 at pci0 dev 23 function 5 "VMware PCIE" rev 0x01 pci24 at ppb23 bus 24 ppb24 at pci0 dev 23 function 6 "VMware PCIE" rev 0x01 pci25 at ppb24 bus 25 ppb25 at pci0 dev 23 function 7 "VMware PCIE" rev 0x01 pci26 at ppb25 bus 26 ppb26 at pci0 dev 24 function 0 "VMware PCIE" rev 0x01 pci27 at ppb26 bus 27 ppb27 at pci0 dev 24 function 1 "VMware PCIE" rev 0x01 pci28 at ppb27 bus 28 ppb28 at pci0 dev 24 function 2 "VMware PCIE" rev 0x01 pci29 at ppb28 bus 29 ppb29 at pci0 dev 24 function 3 "VMware PCIE" rev 0x01 pci30 at ppb29 bus 30 ppb30 at pci0 dev 24 function 4 "VMware PCIE" rev 0x01 pci31 at ppb30 bus 31 ppb31 at pci0 dev 24 function 5 "VMware PCIE" rev 0x01 pci32 at ppb31 bus 32 ppb32 at pci0 dev 24 function 6 "VMware PCIE" rev 0x01 pci33 at ppb32 bus 33 ppb33 at pci0 dev 24 function 7 "VMware PCIE" rev 0x01 pci34 at ppb33 bus 34 isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc
Re: Bad system calls in snapshot bsd.rd
On Wed, Jun 18, 2014 at 11:47 AM, Matthew Dempsky wrote: > On Wed, Jun 18, 2014 at 5:32 AM, David Higgs wrote: >> While upgrading my snapshot VMs this morning, bsd.rd on both the i386 >> and amd64 produced 'Bad System Call' somewhere between making device >> nodes and reboot. > > That might happen if the bsd.rd you're using for the upgrade process > is older than the sets you're installing. We added a new system call > (getentropy(2)) in the last few days, and libc is already making use > of it. > > If you can reproduce the issue with a fully up-to-date bsd.rd, then > I'd be interested in tracking down what's going on. Interesting, I didn't know that bsd.rd made use of installed components - I had assumed it was fully self-contained, hence my surprise/confusion. It seems I downloaded bsd.rd shortly before my preferred mirror updated. Everything seems better now. Thanks again. --david
Remove outdated /etc/examples/unwind.conf?
I was looking into how to configure unwind for my needs, and found significant discrepancies between /etc/examples/unwind.conf and the unwind.conf(5) manual. Namely, the example file had lots of captive portal info, while the manual made no mention of it. After browsing source history, I learned that when captive portal support was removed, the example config was removed. I'm going to compare the contents of etc.tgz versus my /etc/examples directory to avoid confusion in the future, but should sysmerge(8) have removed example files such as this? Thanks. --david
Re: Remove outdated /etc/examples/unwind.conf?
On Fri, Jul 23, 2021 at 5:33 AM Stuart Henderson wrote: > On 2021-07-21, David Higgs wrote: > > I was looking into how to configure unwind for my needs, and found > > significant discrepancies between /etc/examples/unwind.conf and the > > unwind.conf(5) manual. Namely, the example file had lots of captive > portal > > info, while the manual made no mention of it. > > > > After browsing source history, I learned that when captive portal support > > was removed, the example config was removed. > > > > I'm going to compare the contents of etc.tgz versus my /etc/examples > > directory to avoid confusion in the future, but should sysmerge(8) have > > removed example files such as this? > > sysmerge doesn't deal with files in /etc/examples, they aren't expected > to be modified in-place so they are just overwritten as part of > extracting the base set. As with other files in the base there's nothing > to remove old ones no longer present, but you can use "sysclean" (in > packages) to identify files in system directories that aren't present > in base - either local additions or obsolete files - if you'd like to > remove them. > Oh, that makes more sense. I use sysclean on my -stable systems, but not on this VM running -current. I had somehow gotten the idea in my head that sysmerge ingested files from /etc/examples to perform updates - and thus they were treated differently - but clearly I was very wrong. I wonder if there would be any benefit to a sysclean-like tool as part of a standard upgrade/sysmerge that automatically deletes everything older than the (supported) current and prior release? It would remove the need to curate removal lists in upgrade.html. Just an idle thought... pay me no mind. Apologies for the noise. --david
MAKEDEV hangs on amd64 sysupgrade in virtualbox
I've been infrequently following snapshots with a vbox installation and have been experiencing hangs like this for a year or two now. Everything works great on my actual hardware. The VM boots fine after resetting, but the subsequent fsck and performing the skipped upgrade steps is mildly annoying. >From the install ramdisk, how would I go about collecting more diagnostic information? Thanks. --david (dmesg below, apologies for line-wrapping) OpenBSD 7.6-beta (GENERIC) #274: Fri Aug 23 19:04:48 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1056899072 (1007MB) avail mem = 1001926656 (955MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries) bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006 bios0: innotek GmbH VirtualBox acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz, 1860.00 MHz, 06-4e-03 cpu0: cpuid 1 edx=178bfbff ecx=56da220b cpu0: cpuid 6 eax=4 cpu0: cpuid 7.0 ebx=842529 edx=3400 cpu0: cpuid 8001 edx=28100800 ecx=121 cpu0: cpuid 8007 edx=100 cpu0: MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: CPU supports MTRRs but not enabled by BIOS cpu0: apic clock running at 1000MHz cpu0: mwait min=64, max=64 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpiprt0 at acpi0: bus 0 (PCI0) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpibat0 at acpi0: BAT0 model "1" serial 0 type VBOX oem "innotek" acpiac0 at acpi0: AC unit online acpicpu0 at acpi0: C1(@1 halt!) acpivideo0 at acpi0: GFX0 cpu0: using VERW MDS workaround (except on vmm entry) pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 vga1 at pci0 dev 2 function 0 "InnoTek Graphics Adapter" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 1 int 19, address 08:00:27:e9:64:ff "InnoTek Guest Service" rev 0x00 at pci0 dev 4 function 0 not configured ohci0 at pci0 dev 6 function 0 "Apple Intrepid USB" rev 0x00: apic 1 int 22, version 1.0 piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: apic 1 int 23 iic0 at piixpm0 em1 at pci0 dev 8 function 0 "Intel 82540EM" rev 0x02: apic 1 int 16, address 08:00:27:1f:8f:14 em2 at pci0 dev 9 function 0 "Intel 82540EM" rev 0x02: apic 1 int 17, address 08:00:27:13:48:5a ehci0 at pci0 dev 11 function 0 "Intel 82801FB USB" rev 0x00: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ahci0 at pci0 dev 13 function 0 "Intel 82801HBM AHCI" rev 0x02: apic 1 int 21, AHCI 1.1 ahci0: device on port 0 didn't come ready, TFD: 0x171 ahci0: port 0: 3.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: t10.ATA_VBOX_HARDDISK_VBa5540626-6a15461b_ sd0: 20480MB, 512 bytes/sector, 41943040 sectors isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "Apple OHCI root hub" rev 1.00/1.00 addr 1 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (ddf460662c748e5c.a) swap on sd0b dump on sd0b WARNING: /mnt was not properly unmounted
Re: ral(4) driver and RT2860 + RT2850 chips
On Thu, Apr 9, 2009 at 1:40 AM, Chris Jones wrote:
> Good evening,
>
> I just picked up a SparkLan WMIR-200N which I've put in my Soekris
> net4501. The ral(4) driver says it supports the Ralink RT2860 and RT2850
> chips on this card. OpenBSD detects the card however when I configure it
> in hostap mode with WPA2-PSK, my Macbook or any wifi capable computer
> will connect momentarily and then disconnects.
>
> Has anyone had any experience with this card running under OpenBSD?
> Also, how can I debug the ral(4) driver? Here is my dmesg output as
> well as my hostname.if configuration.
>
> Thanks,
> -Chris
>
> dmesg
> -
>
> OpenBSD 4.4 (GENERIC) #0: Sat Nov 15 07:42:40 PST 2008
>r...@ob44dev.localdomain:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: AMD Am5x86 W/B 133/160 ("AuthenticAMD" 486-class)
> cpu0: FPU
> real mem = 66678784 (63MB)
> avail mem = 55017472 (52MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 20/80/03, BIOS32 rev. 0 @ 0xf7840
> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc8000/0x9000
> cpu0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> elansc0 at pci0 dev 0 function 0 "AMD ElanSC520 PCI" rev 0x00: product 0
> stepping 1.1, CPU clock 133MHz, reset 40
> gpio0 at elansc0: 32 pins
> hifn0 at pci0 dev 16 function 0 "Hifn 7951" rev 0x01: LZS 3DES ARC4 MD5
> SHA1 RNG PK, 128KB sram, irq 10
> ral0 at pci0 dev 17 function 0 "Ralink RT2860" rev 0x00: irq 11, address
> 00:0e:8e:20:84:94
> ral0: MAC/BBP RT2860 (rev 0x0102), RF RT2850 (2T3R)
> sis0 at pci0 dev 18 function 0 "NS DP83815 10/100" rev 0x00, DP83815D:
> irq 5, address 00:00:24:c0:7a:ac
> nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
> sis1 at pci0 dev 19 function 0 "NS DP83815 10/100" rev 0x00, DP83815D:
> irq 9, address 00:00:24:c0:7a:ad
> nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
> sis2 at pci0 dev 20 function 0 "NS DP83815 10/100" rev 0x00, DP83815D:
> irq 12, address 00:00:24:c0:7a:ae
> nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
> isa0 at mainbus0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard
> wdc0 at isa0 port 0x1f0/8 irq 14
> wd0 at wdc0 channel 0 drive 0:
> wd0: 1-sector PIO, LBA, 999MB, 2046240 sectors
> wd0(wdc0:0:0): using BIOS timings
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0:
> spkr0 at pcppi0
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> biomask e1c5 netmask ffe5 ttymask
> softraid0 at root
> root on wd0a swap on wd0b dump on wd0b
>
>
> hostname.ral0
> -
>
> up media autoselect mode 11g mediaopt hostap \
>nwid MYNWID wpa wpaprotos wpa2 \
>wpapsk MYPRESHAREDKEY \
>chan 7
>
>
$ dmesg | grep ral
ral0 at pci0 dev 15 function 0 "Ralink RT2561S" rev 0x00: irq 10,
address 00:1d:7d:34:0e:ec
ral0: MAC/BBP RT2561C, RF RT2527
$ sudo cat /etc/hostname.ral0
inet 10.0.128.1 255.255.255.0 NONE media autoselect mediaopt hostap
mode 11g nwid wpa wpaakms psk wpaprotos wpa2 wpapsk
Works great for me (4.4-stable) when connecting from my MacBookPro,
though it occasionally locks up and needs a quick ifconfig down/up.
Supposedly things are much improved in -current, but I haven't tested
to confirm.
--david
Re: 5.0 kernel won't compile on 4.9 i386 system
On Sat, Jan 28, 2012 at 12:42 PM, Stefan Midjich wrote:
> Thanks everyone for the info, I clearly didn't read the whole FAQ but only
> the parts I needed.
>
> The reason I was using 4.9 was because 5.0 i386 didn't boot in vmware
> fusion 3, it hangs at mtrr. And since I was formatting a CF card from the
> vm I thought I had to use the same arch as the kernel that will run from
> it, so I ended up trying on a 4.9.
I do exactly the same thing: use VMWare Fusion 3 to build release(8)
whenever there's changes to -stable that I need (otherwise I just
install -release directly). I've been doing this since 4.8 and have
never had a problem using stock i386 GENERIC. You might try changing
the VM type to "Other" or disabling some peripheral emulation. FWIW,
amd64 works like a champ too using "Other 64-bit". I haven't tried
running i386 on "Other 64-bit".
> Also the reason I wanted to compile is something I should have stated,
> there's a kernel config online for pcengines alix boards so I wanted to use
> it on mine thinking it was better optimized for the tiny board with very
> few peripherals.
>
> https://raw.github.com/openbsd/flashboot/master/PCENGINES
Keep reading the FAQ: http://www.openbsd.org/faq/faq5.html#Why
I run i386 GENERIC on my ALIX 2D13, no custom anything required. I
included my dmesg below for posterity. Everything I need fits more
than comfortably on a 16GB CF card.
I performed the initial install using the VM as well. I gave my
OpenBSD VM access to the CF via USB card reader, booted the VM into
bsd.rd, did a fresh install to the CF card, added tty items to
/etc/boot.conf, and tweaked /etc/fstab. Then I installed the CF card
into the ALIX board and from there just configured everything else
over serial / network.
Good luck,
--david
OpenBSD 5.0-stable (GENERIC) #1: Tue Nov 8 02:05:22 EST 2011
root@vm.localdomain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem = 267976704 (255MB)
avail mem = 253542400 (241MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:0d:b9:1e:60:7c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:0d:b9:1e:60:7d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 15,
address 00:0d:b9:1e:60:7e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 15296MB, 31326208 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 12,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 12
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
mtrr: K6-family MTRR support (2 registers)
nvram: invalid checksum
ugen0 at uhub1 port 2 "American Power Conversion Back-UPS ES 750
FW:841.I3 .D USB FW:I3" rev 1.10/1.01 addr 2
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
scsibus1 at softraid0: 256 targets
root on wd0a (295fd65258ac0a48.a) swap on wd0b dump on wd0b
clock: unknown CMOS layout
Re: securing OpenBSD wireless network
On Nov 16, 2007 2:39 PM, Juan Miscaro <[EMAIL PROTECTED]> wrote:
> Hi gang,
>
> So I'm setting up my first wireless network for a small business with
> OpenBSD acting as internet gateway. I am familiar with OpenBSD as
> gateway but not in the wireless context. I picked myself up a card
> that the docs say is supported (Linksys WMP54G) and will be installing
> 4.2 from my CD this evening.
>
> At this point I'm asking myself the obvious question. How do I secure
> my network? I see the authpf is used a lot but is there anything else
> I can do? What of VPN? If so, what implementation?
>
> My client stations will be Ubuntu Linux.
>
> Thank you in advance to any responders,
>
> // juan
>
>
> Get a sneak peak at messages with a handy reading pane with All new
> Yahoo! Mail: http://mail.yahoo.ca
I combined authpf with OpenVPN, using some big hints from some easily
google-able places. Even though WEP and WPA aren't supported by
OpenBSD, I still wanted to have authenticated and encrypted traffic.
This might be overkill for some but it works for me.
After setting up the wireless interface to dhcpd a private netblock, I
locked it down with pf:
block in on $wlan_if
pass in on $wlan_if proto udp to port { bootps, bootpc }
pass in on $wlan_if proto udp to ($wlan_if:0) port domain
pass in on $wlan_if proto tcp to ($wlan_if:0) port ssh
Then I setup authpf to allow authenticated users the ability to
connect to the VPN:
pass in on $wlan_if proto udp from to ($wlan_if:0) port 1194
Next I configured OpenVPN in routed mode. It hands out IPs from yet
another private netblock I have permanently attached to lo1.
Finally, I treat the tun0 interface like a semi-trusted wired
interface in pf and apply my standard list of allowable client
applications:
client_if = "{ sk0, tun0 }"
pass in on $client_if proto udp to port $udp_client_ports
pass in on $client_if proto tcp to port $tcp_client_ports
This obviously isn't my full pf.conf, and care must be taken because
the rules are highly dependent on order. My initial setup took nearly
a full day to configure and troubleshoot, since I had to get pf,
authpf, dhcpd, named, and OpenVPN to all cooperate. I found that
selectively allowing and denying ICMP was of great assistance while
testing pf rules and tcpdump to be essential when I had other services
misconfigured.
Windows and OS X OpenVPN clients are readily available and
configuration is easy if you understood what you were doing when
setting up the OpenVPN server.
Although I feel like I've got a good handle on all the interactions
here, I'm no professional and if there are any gaping holes in this
setup, I am eager to hear about them. I plan to investigate IPSEC in
the near future, which may be an alternative.
--david
Re: Using the C programming language
On Dec 22, 2007 5:53 PM, Rico Secada <[EMAIL PROTECTED]> wrote: > You are right, Ada is widely used in avionics, aerospace and defence > systems, systems that demand a VERY high level of security and safety > regarding lives and expensive equipment. And Ada is specifically > designed for embedded systems too. Ada's original foothold was gained because it was mandated by the US government for many projects and was standardized before C. If Ada's benefits were not realizable with other tools, the mandate would still be in place. > It is my understanding that C is the hackers tool while Ada is the tool > of the engineer. I think it is mostly because of tradition. Your understanding is wrong. I suspect that many professional engineers using C (and/or other languages) would strongly disagree with your offhand characterization. > You find Ada in almost all of Boings airplanes, and in most industry > critical systems. Ada was written with compile time protection against > bugs such as buffer-overflows and so on. Didn't I read a Slashdot article about the NYSE going to Linux? What language is medical software written in? What about the competing companies that aren't using Ada? How does their track record of software faults compare? Compile time protection isn't worth the time it takes to run them if your specification has flaws, your code doesn't match the spec, or the compiler has errors. There are MANY other types of errors that can never be caught at compile-time. Just because these errors SHOULD be accounted for in the program's spec doesn't mean that they WILL be. > But like many has stated, what makes programs good and secure is the > programmer, but IMHO the tools and languages are important too. > > You cannot use something like C in a really security demanding > situation, and here I think about humans lives, like in spacecrafts. Completely false. You can use any tool you want with an appropriate model of the system; this includes your tools and code. The software for the original US moon missions was written in assembly code; portions may still be in use today because of its extreme reliability. > A simple buffer overflow might crash the plane, and you have to have > some ways of eliminating that completely. That is why Ada was designed > the way it was. You can read about the history of Ada on Wikipedia. > > Why so much is written in C on Unix-like systems, I think its mainly > tradition. IMO Ada would be much better from a security point of view. Your opinion means nothing without code. Even with code, the OpenBSD project likely won't care anyways. You are barking up the wrong tree. > I agree that it would be better if OpenBSD or any other system for that > matter was written in Ada rather than C, and they could just as well, > but re-writing something as huge as OpenBSD is a MAJOR task, and what > would the real benefits be in this situation? > > The OpenBSD team knows exactly what they are doing hence the extra > security of Ada becomes almost un-necessary, but again I agree, had > OpenBSD been in Ada from day one, that would save them a LOT of time! > Bugs would be caught on compile time and bad-coding would almost be > eliminated. Go back to Wikipedia. OpenBSD was a fork and essentially worked from day one. However, as you say, rewriting something as big as OpenBSD is a MAJOR task in the timeframe of years or decades. Instead of improving security in a known system, all those years would be "wasted" reinventing the wheel and playing catch-up with the pre-existing feature set of modern operating systems. Your insistence on equating compile-time checks with secure programming is incorrect, and indicates your inexperience in secure programming. Academic questions like this should be googled or asked on comp.lang.ada. Good luck. --david
Re: strftime bug?
On Jan 9, 2008 11:25 PM, Duncan Patton a Campbell <[EMAIL PROTECTED]> wrote:
> This may be a bug in FreeBSD, because it will work correctly if I pass a size
> of length +2 to strftime
> in OpenBSD.
>
>
> On Wed, 9 Jan 2008 22:06:42 -0600
> Duncan Patton a Campbell <[EMAIL PROTECTED]> wrote:
>
> > There appears to be a bug in strftime such that the last digit is chopped
> > off the seconds.
> >
> > I built a gprolog instance with a time function primitive (to get around
> > 27bit ints in gprolog/386)
> > so:
> >
> > Bool c_adstm(char *timeS0, long secs, char **newtm)
> > {
> >
> > struct tm Tm;
> > char *sZnewtm;
> > size_t Xlen0 = 0;
> > time_ttm;
> > Tm.tm_isdst = -1;
> > Xlen0 = strlen(timeS0);
> > sZnewtm = *newtm = (char*)Malloc(Xlen0+1);
> > if(strptime(timeS0,"%Y%m%d%H%M%S",&Tm)==NULL) return FALSE;
> > tm = mktime(&Tm) ;
> > fprintf(stdout,"B: %ld\n",tm);
> > tm = tm + secs;
> > fprintf(stdout,"C: %ld\n",tm);
> > if(localtime_r(&tm,&Tm)==NULL) return FALSE;
> > // if(strftime(sZnewtm,Xlen0,"%Y%m%d%H%M%S",&Tm)==0) return FALSE;
> > strftime(sZnewtm,Xlen0,"%Y%m%d%H%M%S",&Tm) ;
> > fprintf(stdout,"E\n");
> > return TRUE;
> > }
> >
> > When I run this on OpenBSD I get
> > | ?- c_adstm("20080101010101",30,X),atom_codes(XA,X).
> > B: 1199174461
> > C: 1199174491
> > E
> >
> > X = [50,48,48,56,48,49,48,49,48,49,48,49,51]
> > XA = '2008010101013'
> >
> > yes
> > | ?-
> >
> > But on FreeBSD I get the correct (expected) output:
> > | ?- c_adstm("20080101010101",30,X),atom_codes(XA,X).
> > B: 1199170861
> > C: 1199170891
> > E
> >
> > X = [50,48,48,56,48,49,48,49,48,49,48,49,51,49]
> > XA = '20080101010131'
> >
> > yes
> > | ?-
> >
> > I have entered a bug with sendbug/1, but it told me some (unspecified)
> > fields
> > were blank so I'm not sure if it went in.
> >
> > Also, could anyone tell me where the source for the strftime & strptime
> > functions is located?
> >
> > Thanks,
> > Dhu
man 3 strftime
The maxsize parameter is the buffer size _including_ terminating NUL,
so the bug is yours.
Also note the BUGS section which warns that other implementations may
not NUL-terminate the string if the length is not large enough.
Sounds like the standard wasn't specific enough.
--david
Re: WAP setup problems
On Feb 4, 2008 10:12 PM, Brian Richardson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here's my problem and my current understanding:
>
> I have 3 interfaces in my WAP box, external, internal and wireless.
>
> I'd like to have MAC filtering for addresses with access to the external
> network, but allow guests to connect to the wireless network to help
> with copying files around in the same room.
>
> I need to run dhcpd on both the internal interface and the wireless
> interface as guests might not have wireless. ALL clients on the wireless
> network MUST use DHCP to obtain their address.
>
> My dhcpd.conf is as follows:
>
> --
> shared-network LOCAL-NET {
> option domain-name "example.org";
> option domain-name-servers 192.168.1.1;
>
> subnet 192.168.1.0 netmask 255.255.255.0 {
> option routers 192.168.1.1;
> range 192.168.1.32 192.168.1.127;
> }
>
> host laptop {
> hardware ethernet 00:de:ad:be:ef:00;
> fixed-address 192.168.1.10;
> }
> }
>
> shared-network WIRELESS-NET {
> option domain-name "example.org";
> option domain-name-servers 192.168.1.1;
>
> subnet 192.168.2.0 netmask 255.255.255.0 {
> option routers 192.168.2.1;
> range 192.168.2.32 192.168.2.127;
> }
>
> host laptop-wireless {
> hardware ethernet 11:de:ad:be:ef:11;
> fixed-address 192.168.2.10;
> }
> }
> --
>
> So, the problem is that dhcpd listens on both ends of the bridge that
> would be used for MAC filtering. DHCPDISCOVER requests are acknowledged
> on both interfaces, and the wireless client will receive a random
> address from either the internal or wireless network. laptop does not
> consistently receive its fixed address. I understand why this is so, as
> the DHCPDISCOVER/DHCPOFFER packets cannot be filtered in BPF. HOWEVER, I
> have been unable to find dhcpd configuration which will prevent the
> request from being processed on both interfaces. If I turn off the
> bridge, I lose the MAC filtering. Is there any way I can have the setup
> I desire? Not all registered MAC addresses will have a fixed-address, so
> I can allow a guest access to the external network by simply adding
> their MAC address to the bridge.
>
> Thanks,
> Brian
First, I don't see your fixed-address hosts getting a router option.
Also, my fixed-address hosts are part of the subnet, not outside it.
Lastly, I don't have the shared-network "wrappers" around my subnet
definitions, but that seems like an ommission on my part.
Anyways, I've effectively got this same physical setup and it works
perfectly in 4.1. Your laptop has two interfaces and a different MAC
for each; assuming everything is configured right, dhcpd will give out
the fixed IP mapped to the requesting MAC address. If you don't want
both LAN and WLAN addresses, shut down the interface you don't care
about.
Good luck.
--david
Re: Where is NAN Defined?
On Feb 10, 2008 12:55 PM, Jim Razmus <[EMAIL PROTECTED]> wrote: > * Chris Kuethe <[EMAIL PROTECTED]> [080210 12:34]: > > On Feb 10, 2008 8:31 AM, Jim Razmus <[EMAIL PROTECTED]> wrote: > > > I'm trying to compile a program that uses NAN. It includes math.h which > > > I'm told C99 says should define it. I've grepped the entire source tree > > > and read up on man 3 math and man 3 isinf. Still no joy. > > > > > > Trying to compile the program yields "error: `NAN' undeclared (first use > > > in this function)". > > > > > > Can anyone point me in the right direction? > > > > #ifndef NAN > > #define NAN (0.0/0.0) > > #endif > > > > > > -- > > GDB has a 'break' feature; why doesn't it have 'fix' too? > > > > I'm told that math.h should do this for me. Moreover, I think NAN is a > machine dependent value. > > Adding the line you mention would break on VAX (assuming I understand > this correctly). Although I don't think anyone would run this program > on a VAX, if it's in the ports tree there's the possibility. > > Worst case, I could add those defines though. > > Thanks. > Jim Is your source familiar with OpenBSD? You say C99 math.h supposedly provides NAN. math(3) says nothing about C99. That's your first clue. Looking through gcc(1) for -std=c99 points to the GCC webpage [1]. It says "additional math library functions" are missing. That might be another clue. If you can't use NAN in a simple test program using -std=c99 and/or -lm, you're SOL unless you start patching your program. Both math(3) and the source for isnan(3) (see [2]) indicate that there are many potential NaN values. Unless you know exactly what this program is doing or are very familiar with your arch's floating point support, don't assume that #define will work 100% of the time. I'm no expert though. Good luck. --david [1] http://gcc.gnu.org/gcc-3.3/c99status.html [2] http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libm/src/s_isnan.c
Re: prng and a fix wich should (not?) happen..?
You saw the official status. Increased public attention rarely changes a technical opinion around here. Reading the bugtraq link indicates that in other OSes, the default sysctl disables the PRNG, resulting in a sequential IP ID counter. Anyone with half a brain can see that sequential is infinitely worse than a weak PRNG. I didn't look up the others, but FreeBSD CVS indicates that their fixed PRNG is still not enabled by default. How's that for security? Also, I thought BIND 9 had its own PRNG flaws, which is what prompted OpenBSD to provide their own in the first place. What algorithm is BIND 9 currently using? At any rate, OpenBSD developers likely believe (or know from firsthand experience) that there are already satisfactory measures that can be taken by concerned admins to secure DNS or other traffic. If superior methods are already available and improving this PRNG has minimal overall benefit, it is therefore uninteresting and of low priority. Note that this does not preclude it from ever being fixed. If you are that concerned about the issue, you are certainly welcome to patch and compile it yourself. IIRC, the fields affected by this PRNG flaw were originally intended to be sequential counters, and therefore must be monotonic. Simply swapping in a "more random" PRNG doesn't necessarily come without repercussions. OpenBSD developers may be waiting for real-world evidence or independent research indicating that the new PRNG causes a minimum of compatibility problems, is cryptographically better than the old one, and has suitable performance characteristics. Just my unsolicited take on the situation... --david On Feb 10, 2008 1:41 PM, <[EMAIL PROTECTED]> wrote: > I would like to get the point of the developers related to the PRNG issue > wich was discovered last year. > > Back then OpenBSD developers said OpenBSD is not affected but now I read a > Slashdot-Article wich links to informations wich say the total opposite. > > http://it.slashdot.org/it/08/02/10/0136236.shtml > leads to: > http://readlist.com/lists/securityfocus.com/bugtraq/4/22004.html > > So could somebody finaly tell me what's the status about it? > And please no "oBSD rocks" or "OpenBSD sucks" or "We're l33t and > unbreakable ubercoders" talks. I think the informations provided are > pretty "omg" and bad PR too :-/ > > "OpenBSD's coordinator stated, in an email, that OpenBSD is completely > uninterested in the problem and that the problem is completely irrelevant > in the real world." > > So I would be happy about a technical explantation why so many (even BSD > projects) think it's a problem but OpenBSD does not. > > Another "omg" comment: > > > "Interestingly enough, OpenBSD uses a flavor of this PRNG for > another field, this time the IP fragmentation ID, part of the > OpenBSD kernel network stack. The analysis carries out quite > similarly to show that OpenBSD's IP ID is predictable as well, > which gives way to O/S fingerprinting, idle-scanning, host alias > detection, traffic analysis, and in some cases, even to TCP blind > data injection." > > That doesn't sound like "Theory" but like a PoC wich lays arround > somewhere > > Sebastian > > p.s. > I hate registrations (even if I may have used fake data) so: > http://www.trusteer.com/docs/DNS_Poisoning_paper.pdf
Re: harddisk impact on routing firewall performance/throughput
On Feb 12, 2008 9:44 PM, Darren Spiteri <[EMAIL PROTECTED]> wrote: > On Feb 13, 2008 11:47 AM, NetOne - Doichin Dokov <[EMAIL PROTECTED]> wrote: > > > Could we have a look at those numbers, in fact? > > > From the parent: > > "In the next step I increased the value for net.inet.tcp.recvspace and > net.inet.tcp.sendspace to 262144 and that had big impact on the network > throughput. > The network throughput increased from 550Mbit/s to 940Mbit/s." Unless I'm massively wrong about what net.inet.tcp.* is used for, this indicates that the parent was NOT testing throughput as one would typically define it for a router/firewall. He was testing his box's ability to send and receive TCP packets. I think these knobs are COMPLETELY unused by the code that inspects packets and decides which interface to send them out. --david
Re: harddisk impact on routing firewall performance/throughput
On Feb 12, 2008 8:37 PM, raven <[EMAIL PROTECTED]> wrote: > Ted Unangst ha scritto: > > On 2/12/08, Darren Spiteri <[EMAIL PROTECTED]> wrote: > > > >> I don't know why or how this poorly documented sysctl works, but the > >> result speaks for itself. Note the dramatic throughput increase of the > >> parent. > >> > > > > running netperf on a firewall is a poor test of forwarding performance. > > > > > > > So, Ted, what test he need to do, to have some results good ? I ask > because i was thinkin to use netperf too to test my network performance, > so if you can help both of us, i really appreciate. > Thanks. What's your definition of "network performance?" I believe Ted's point is that receiving and sending packets (i.e. using it as an endpoint) is the job of a server, not a router/firewall. Routers and firewall performance is measured in how well they can inspect and forward packets that are NOT destined for the hardware under test. That's probably why sendsize/recvsize should not matter on a router/firewall; I think these knobs configure how much space is allocated for endpoint send/recv operations. Can you use netperf to send traffic THROUGH the box you want to test? Otherwise, generate traffic load through your box using applications like wget, scp, ftp, tcpreplay, or a traffic generator. If you only care how much traffic your box can SERVE, you should describe it as a server. Here, netperf may be more suited to measuring your performance, or you can point the previously mentioned tools at your server. --david
Re: Multi-Threaded SSH/SCP made by university of Puttsburgh
On Feb 16, 2008 2:45 PM, Matthew Weigel <[EMAIL PROTECTED]> wrote: > Marco Peereboom wrote: > > The discussion on kernel threads is irrelevant. It is not about having > > some lower level support that will magically make threads not suck. > > Actually, this is the part of the discussion that interests me. Is threading > a doomed hope on OpenBSD, a model of utilizing multiple cores which the > developers have zero interest supporting? Has the work on libc_r and the like > been abandoned completely? Firstly, threading is not doomed, stillborn, or even missing on OpenBSD. The pthread implementation works well enough, and many ports make use of it. Due to the focus on security, threaded code in OpenBSD-provided userland is frowned upon in favor of programming techniques that are easier to secure and control. The threading implementation also has some design limitations that prevent it from performing as well as other OSes. That said, the rthreads replacement is still under development, to my knowledge. The goal of rthreads is to overcome these design limitations and be portable to most/all CPU architectures, as well as maintain or improve the current state of security and functionality. If you are interested, google or someone else should be able to supply more details. If someone can split SSH into multiple threads, it should be just as possible to split it into multiple processes. However, I expect that most high-speed SSH traffic is SCP-/SFTP-based and therefore largely I/O bound, so it hasn't been high on anyone's requirements list. --david
Re: What is our ultimate goal??
On Feb 17, 2008 9:10 AM, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > Who said, it must be about new features? There is an issue, about which I > wrote already - OK, once more: > > I noticed, that default path, where software from binary pkg and "ports" > gets unpacked, is /usr/local hierarchy - unfortunately, it's also the > "traditional" default of every individual source *.tar.gz package - such > way the software ported to OpenBSD gets mixed with any other package, > which I had installed. Wouldn't be reasonable to create new hierarchy, > especially for the "native" OpenBSD software (from binary packages and > ports) - I mean: something like /usr/pkg in NetBSD? Does the -B option to pkg_add do exactly this? Or YOU could do the equivalent and tell ./configure to install to a different base directory. This doesn't need any funding either. --david
Re: What is our ultimate goal??
On Feb 17, 2008 10:18 AM, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > On Sun, Feb 17, 2008 at 09:50:21AM -0500, William Boshuck wrote: > > > In essence, this is suggesting to move third party software > > installed by the project's third party software management > > tools out of /usr/local, so that it is out of the way for >^ > > users who want to install software on their system without > > using the project's third party software management tools. > > Yes, indeed; why not, if you know, that such approach can be a problem for > the user? > > > I can imagine one response: Port whatever it is, or else > > That cannot be a valid response, when given to the _user_. Sure it is. If you have permission to install to /usr/local, you are not a user, you are an admin. You can therefore fix the broken scripts to install wherever you need them to. If an admin refuses to install their software, users can install it themselves it to their home directory. --david
Re: What is our ultimate goal??
On Feb 17, 2008 7:36 AM, Mayuresh Kathe <[EMAIL PROTECTED]> wrote: > > On Feb 17, 2008 5:44 PM, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > On 2008/02/17 17:33, Mayuresh Kathe wrote: > > > It would be great if developers also start working on improving the > > > features currently offered by OpenBSD. > > > > eh? > > think soft-updates with background fsck, > think a generally usable 64/128 bit file system, > think a FireEngine style networking stack, > think ability to mount FreeBSD partitions off somebody else's hdd > attached to my OBSD system. FWIW, FFS2 and large disk support is being added. Calls for diff testing go out periodically, possibly on tech. If you need it faster, donate or otherwise help. --david
Re: What is our ultimate goal??
On Feb 17, 2008 7:36 AM, openbsd misc <[EMAIL PROTECTED]> wrote: > > -Urspr|ngliche Nachricht- > > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Im Auftrag von Tony Abernethy > > Gesendet: Sonntag, 17. Februar 2008 13:20 > > An: 'Mayuresh Kathe'; 'OpenBSD-Misc' > > Betreff: Re: What is our ultimate goal?? > > > > > Mayuresh Kathe wrote: > > > > > > OpenBSD is an OS with amazing security and stability, but it has too > > > few modern features. > > > > > H related? > > > > > > E.g. wpa[2] is one of the features I miss because I want to use OpenBSD as > Firewall / Access Point (SOHO customers)... VPN is not an option, because > windowsclients need network at startup. If WPA2 is considered secure and widespread, it will likely be added to OpenBSD at some point. Even more likely if it's been added to a relatively unmodified portion of NetBSD or FreeBSD. Is IPSEC an option for your SOHO customers? VPN could be an option, though it's definitely not as simple. OpenVPN clients are available for both Windows and OS X. You could distribute binaries and keys via USB drive or a local SSL-enabled webserver. There's been other discussions on-list about reducing your exposure to wireless sniffers. --david
Re: What is our ultimate goal??
On Feb 17, 2008 10:22 AM, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > On Sun, Feb 17, 2008 at 10:12:09AM -0500, David Higgs wrote: > > > Does the -B option to pkg_add do exactly this? Or YOU could do the > > equivalent and tell ./configure to install to a different base > > directory. This doesn't need any funding either. > > And did I ask for any funding? When? > > Of course, that I can - and thousands of other users are able to either - > play with "./configure" switches before compilation of every "non-ported" > package. I just would to point attention, that _one single change_ can save > the time of that thousands people. Instead of playing with "./configure" > switches - they could be busy... porting software to OpenBSD, for example. I meant, it doesn't need funding because it's a change that you make to your own install process. Be realistic. Thousands or even hundreds of people will not see this feature change and suddenly decide to contribute to ports. Aside from you, I don't even recall people complaining about it on a regular basis. They will be too busy complaining about this change. They'll have to figure out how to tell their non-ports ./configure scripts to search for their pkg_added libraries which NOW live in some non-standard /usr/pkg directory. That's just my take, good luck. --david
Re: What is our ultimate goal??
On Feb 17, 2008 1:53 PM, Mayuresh Kathe <[EMAIL PROTECTED]> wrote: > Its good to know that Ted did indeed try to scratch an itch of his and > laid down some ground work for future developers to take it beyond its > basic level. > But, it would have been *nicer* if Ted had put in some more of his > time and effort to complete what he started. > Also, we don't get to use his code for FREE, I suppose most of the > users *buy* CD sets. It would also be nice if you would learn C and code up your new TCP/IP stack yourself. We don't always get everything we want. His code is free to anyone that wants it for free. Do you not understand how the BSD license and AnonCVS work? > > You are talking about nebulous features that are over hyped and > > under proven. One needs a problem first before fixing it. You are > > putting it the wrong way around by saying "hey I'd like a super duper > > faster tcp/ip stack man!". Why? What problem are you solving? > > The problem that would get solved would be best presented by the > following article http://research.sun.com/minds/2007-0710/ What specifically about the OpenBSD TCP/IP stack is too slow for your needs? Perhaps some simple sysctl tuning or using a different NIC will fix what you mistakenly think is an inherent flaw. > > A frequent complaint is that we don't listen to our user base. That is > > utterly false. We listen and we implement what we have time for and > > what makes sense (chances are we have thought through the problem > > domain; ever considered that?). A single person's need is irrelevant in > > the grand scheme of things. If you need something you need to write it > > yourself. > > Agreed, but wouldn't it be better if there was some kind-a list of > features most requested by users who can't/don't code in C? > Then you core people could keep an eye on that list and think through > your problems keeping that detail in mind. This comes up once every few months. The general consensus is that lists are a waste of time that's better spent coding. Posting such a list implies that developers are actually interested in and/or committing resources to implementing everything on it. > Nothing of that sort, I don't _expect_ developers to do what I ask > for, in fact I've got very few needs above what the system is offering > me right now, just that it hurts to see rest of the projects getting > some nice features which we too would've got had the developers > focused and *completed* what they started. If the system does what you need, why do you care about writing this brand new TCP/IP stack then? As far as other projects getting these features, so what? If they're that critical to you, go use that project instead. If it's BSD-licensed code, kindly ask if someone can import it to OpenBSD, but don't expect it to happen without a thorough code audit. > I'm not belittling the developers, just that I really got irritated > when I lost 5 of the best developers (who were going to start work on > a new TCP/IP stack) I'd gathered because Ted lost interest in his own > work. Such is the nature of open source development. Have you spoken with Ted or any other developers regarding this? Perhaps they might regain interest after hearing your proposal, or at the very least provide some critique on its merits. --david
Re: What is our ultimate goal??
On Feb 17, 2008 2:58 PM, Mayuresh Kathe <[EMAIL PROTECTED]> wrote: > On Feb 18, 2008 1:16 AM, David Higgs <[EMAIL PROTECTED]> wrote: > > On Feb 17, 2008 1:53 PM, Mayuresh Kathe <[EMAIL PROTECTED]> wrote: > > His code is free to anyone that wants it for free. Do you not > > understand how the BSD license and AnonCVS work? > > It gets stranger. > How is a bare bones code ever going to be useful to a non developing user? > Its useful to them only when its part of an overall system. > And that overall system in a really usable state is only available via > CDs which need to be purchased. > I'm not saying that this purchase it if you want model is bad, I find > it to be really good, that way the development keeps going on. Goodness, what have you been smoking? Free, online install from mirrors has been available with every OpenBSD release for the last five years, at least. > > > > You are talking about nebulous features that are over hyped and > > > > under proven. One needs a problem first before fixing it. You are > > > > putting it the wrong way around by saying "hey I'd like a super duper > > > > faster tcp/ip stack man!". Why? What problem are you solving? > > > > > > The problem that would get solved would be best presented by the > > > following article http://research.sun.com/minds/2007-0710/ > > > > What specifically about the OpenBSD TCP/IP stack is too slow for your > > needs? Perhaps some simple sysctl tuning or using a different NIC > > will fix what you mistakenly think is an inherent flaw. > > I never said its an inherent flaw, its just that its dated. > Better to have something that is more in tune with what is needed in > the current world scenario. So there's no flaws, it's just old, you say. If it's old and it works, why would you ever want to replace it? Can you give anyone a legitimate, specific, real-world problem that you're trying to solve with this new stack? Because without one, it just sounds like you simply bought into some Sun marketing hype. Reinventing the wheel without a good reason does nothing but waste everyone's time. --david
Re: What is our ultimate goal??
On Feb 17, 2008 2:49 PM, Mayuresh Kathe <[EMAIL PROTECTED]> wrote: > I'm not telling Ted what to do at all, you're just assuming it in your > blind fury over me coming out with the truth that most of *your* > coding effort is directly or indirectly supported by non-developer > users who do so by buying CDs, making monetary donations and the like. You are insulting him because he didn't finish what he started. That's not going to help him or anyone else complete it, and may dissuade others from starting work again. > Marco you are an idiot, you should stick to coding, don't come in the > real world, you'll get wasted. Is this how you get things done in the real world? Name-calling the developers of a project you wish to help? > > > The problem that would get solved would be best presented by the > > > following article http://research.sun.com/minds/2007-0710/ > > > > I didn't read anything that fixes any problem that exists today. Sure > > it's a neat research project, no debate there. Whenever or if it > > becomes interesting in the real world somebody in this project will > > re-evaluate its merit. > > That's why I called you an idiot. > The project is not a research project, but a real live production > grade code working under Solaris 10. Not to beat a dead horse here, but what problem would it fix for you? Your refusal to answer this question is damning to your cause. > > > Not really, I'm not insulting you or any of the core developers. > > > What I meant is newer features. > > > Why is it that our soft-updates based file system can't do background > > > 'fsck'? > > > > Because what the other projects did is wrong. A background fsck renders > > a system useless. I don't think having a background fsck that prevents > > my machine from booting is about as useful as not having it. Do I want > > it? of course I do but not bad enough to write the code myself. > > So what you are saying is that what the god father of BSD file systems > (Marshal Kirk McKusik) is doing is wrong? You didn't even read Marco's reply! He is in favor of a well-implemented background fsck. > > > True, your investment as well as *ours*. > > > > How are you investing? Typing up an email does not constitute > > "investment". Sweating over a few lines of code for days on end is. > > The investment is not just from me, its from all those users who don't > code, but still support the project by buying CDs, T-Shirts, make > donations and help out developers by supporting their wish lists. The support is surely appreciated but does not guarantee anything in return. That's why they're called "donations". > > Every time you say "would be nice", "they should" or "why not?" you are > > belittling someone's blood sweat and tears. Ted gave you the starting > > point, go ahead and finish it. That is cooperative code development in > > action. > > Actually what Ted has done was utterly disastrous, he knows his own > code well enough to have completed it. > BTW, you are as big an oaf as Richard Stallman, you keep ranting about > how you've put in your blood, sweat and tears, but forget to > understand the point that without us users you are nothing. What developer would want a user like you? How would you like it if people started complaining when you decided to change hobbies? If you can round up five or more developers to work on a from-scratch TCP/IP stack, how hard can it be to get a few more that are interested in completing rthreads? If they're good enough to write a lockless or thread-safe IP stack, who's to say they can't do a thread library? Anyways, if you won't stop ranting, please stop the name-calling. It isn't helping anything. Good luck, --david
Re: take threads off the table
On Feb 17, 2008 8:01 PM, Geoff Steckel <[EMAIL PROTECTED]> wrote: > Gregg Reynolds wrote: > > On 2/17/08, Marc Balmer <[EMAIL PROTECTED]> wrote: > >> Geoff Steckel wrote: > >> > >>> Threads or any other form of uncontrolled resource sharing > >>> are very bad ideas. > >> that might be true for those that don't understand threads. > >> for other it can be highly benefitial. > > > > Indeed, "threads are bad" strikes me as just plain silly. In fact, > > it's not even a technical issue; anybody who thinks it is is in for a > > rude surprise (like, zero market share) in a few short years. It's a > > "threads" is a particular programming model of multiple execution > contexts in a (mostly) shared memory and (mostly) shared resource > environment which is not cost-effective for producing reliable software. Assuming that a software program is not system-critical or requires high security, and it benefits greatly from a shared memory/resource model, I fail to see why threading can not be cost-effective. > It is much easier to produce a reliable multithreaded application using > multiple processes and an appropriate communication method for sharing > the specific data needed. "Easier" is hard to quantify when writing software. I've written several programs with MPI that could have just as easily been written with threads or fork()ed processes. IMHO, some tasks lend themselves more easily towards threading than others, and others to multiple processes. > Any counterargument must speak to advantages the "threads" model has > over multiple processes or other protected multiple execution models > versus the increased cost of construction and maintenance of a reliable > program using the "threads" model. > > Any argument to experience must be from similar actual implementations > using "threads" and another model, such as multiple processes with > interprocess communications. Threads are hard to secure, this is commonly accepted as true. It does not logically follow that OpenBSD should entirely disallow the use of threads (or any other valid programming model) in software. That would significantly hinder adoption of OpenBSD for general workstation use. The availability of threads to userland programs shouldn't hurt any program that doesn't use them. OpenBSD developers are unlikely to introduce threaded features to userland tools without a clean bill of health from code audits, even when the changes are trivial. Using 'goto' and 'snprintf' in C software are also considered potentially harmful and easy to misuse. But OpenBSD does not limit their use; they CAN be used correctly and without error. The same applies to threads: only when appropriate. Since you (presumably) use OpenBSD, I hope you trust developers to decide when threading is and is not appropriate. Good luck, --david
Re: take threads off the table
On Feb 17, 2008 11:16 PM, Geoff Steckel <[EMAIL PROTECTED]> wrote: > David Higgs wrote: > > Assuming that a software program is not system-critical or requires > > high security, and it benefits greatly from a shared memory/resource > > model, I fail to see why threading can not be cost-effective. > > May I interpret this as saying "Threads are cost-effective in programs > which don't have to be reliable"? If so, what you're saying is > irrelevant to the argument I'm making. > > As an aside, I prefer all programs I use to be as reliable as possible. As do I, but my point is that not all programs have the same reliability requirements. > The only programs which I can see which could possibly justify > threads are strict SIMD. Any other cases where threads are proposed as > an optimal solution strongly suggest a very sloppy partitioning of data > or functionality. I think others may have a different opinion due to their own requirements and experiences. The benefits you extol upon multi-process programs do not come without a cost, otherwise there would have been no reason to invent threads in the first place. Furthermore, I would think that designing message-passing and notification mechanisms for a threaded program is of similar complexity to the marshalling, serialization, and validation mechanisms for inter-process communication. > > Using 'goto' and 'snprintf' in C software are also considered > > potentially harmful and easy to misuse. But OpenBSD does not limit > > their use; they CAN be used correctly and without error. The same > > applies to threads: only when appropriate. Since you (presumably) use > > OpenBSD, I hope you trust developers to decide when threading is and > > is not appropriate. > > In C, goto cannot be used non-locally. > C is vulnerable to buffer overruns. That requires vigilance. However, > the scrutiny needed to ensure snprintf and the like are not a problem is > also local. > Threading is a non-local vulnerability. Errors caused by misuse of goto can cause global effects. Buffer overflows can have non-local effects as well, and can cascade through flawed single-threaded programs just as easily as multi-process or multi-thread programs. It is harder to verify threaded programs for correctness, and the consequences of program flaws can be magnified when using threads over processes. However, it does not follow that threading is a vulnerability in and of itself. With suitable vigilance, I see no reason why a threaded program cannot be as secure or reliable as a multi-process program. It feels like I'm arguing semantics here (again?). I acknowledge that use of threading in most system utilities would be ill-advised, and that if applied incorrectly can lead to an insecure and unreliable system. I would simply like you to see my point, which is that regardless of your personal tastes, threading is not innately evil. --david
Re: OT: supposed advantages of "threads"
On Feb 18, 2008 1:26 PM, Geoff Steckel <[EMAIL PROTECTED]> wrote: > This is my last posting on this, take heart. > > The "threads" advocates have never specified any > advantages of a program written using that model > (multiple execution points in a single image) > over a multiple process model, assuming that > parallelism is useful. > > If the purported advantage is access to shared > data structures without explicit access mechanisms, > let's say I strongly disagree that that is an advantage. > It is a whole set of fatal bugs waiting to happen. > > Please enlighten me if there are any -other- > qualities of this model which are supposed to be > advantageous to the people paying for and using > the programs. I count faster development as an > advantage, increased maintenance (bugs) as a > disadvantage. The second strongly outweighs the > first. Just use google, you'll find any number of academic and research papers outlining the advantages and disadvantages of threads. I'm not an advocate of threads, simply playing devil's advocate because you patently refuse to believe this is anything but a mutually exclusive proposition. Is it not possible to decompose a complex program into a well-secured multi-process program, where one process leverages threads to perform something simple, massively SIMD parallel, and easy to verify? Not like this will matter, you've already made up your mind. Let the thread die. --david
Re: Multi-Threaded SSH/SCP made by university of Puttsburgh
On Feb 19, 2008 9:55 AM, chris rapier <[EMAIL PROTECTED]> wrote: > dhiggs wrote: > > If someone can split SSH into multiple threads, it should be just as > > possible to split it into multiple processes. However, I expect that > > most high-speed SSH traffic is SCP-/SFTP-based and therefore largely > > I/O bound, so it hasn't been high on anyone's requirements list. > > Based on my experience on working in the field of bulk data transfers on > high speed networks for the past 6 years I'd have to say that you are, > at the least, partly mistaken. However, maybe I'm not really > understanding what you are saying. Could you expand on this a bit more? Your experience vastly trumps mine, but I'll try to explain my thought processes: What is SSH used for? My initial breakdown was into two categories - shell/batch commands and SCP/SFTP file transport. I guessed that an application that outputs data to stdout at a rate of 10s or 100s of Mbit/s over long periods of time would quickly be changed. The output would be redirected into a file or postprocessed in some other fashion to reduce the amount of raw output a user would have to sort through. This left bulk file transfer as the primary source of SSH traffic. In retrospect I competely overlooked several very important facts. Modern disks have more than enough throughput to saturate gigabit connections - I have NO idea where my "I/O bound" statement came from. Also, SSH encrypted transport can be used for more than just 'put' and 'get'. There are probably more reasons why I'm misguided, but this is enough for now. I apologize and retract that portion of my post; you can safely disregard it as complete lunacy on my behalf. --david
Re: DHCP client failure with cable modem
On Fri, Feb 22, 2008 at 6:11 PM, David Murphy <[EMAIL PROTECTED]> wrote: > Greetings folks. This week I undertook a project to replace my cheapo home > broadband router with an old laptop running OpenBSD. Success appeared to > have been achieved, but I've run into a snag in the final implementation. > > I set up the OBSD router (more info below) to perform NAT and serve DHCP > and DNS for my LAN. After a ridiculously small amount of tweaking, I got > everything working just like I wanted it. Here was the arrangement: > > (Test hosts) -> (Switch) -> (OBSD router) -> (Cheapo router) -> (Cable > Modem) > > The cheapo router was still in the loop because I didn't want to disconnect > the rest of my LAN before I was ready. Yesterday I decided I was ready. I > removed the cheapo router and plugged the OBSD router directly into the > modem, there was some rebooting of devices involved, and my desktop could > no longer access the internet. A little sleuthing revealed that the router > was unable to retrieve an address from the modem. > > I've done some poking around and searched the list archives. There were a > couple of threads with similar issues, but no definitive solutions that I > found. There were references to cable modems only wanting to serve one > hardware address, but I'm able to use it with either the cheapo router, or > with my desktop plugged directly into it (and I verified that the modem saw > them as two different hardware addresses... no weird proxying going on in > the router). I powered the modem completely down for a few minutes and > plugged only the OBSD router into it when I brought it back up, but still > no luck. > > The hostname.ep1 file for that interface is a simple "dhcp NONE NONE NONE". > The dhclient.conf file is the default, which includes "send host-name > "hostname";", the only other helpful suggestion I saw in the list archives. > I've tried multiple cables and NICs, to rule out hardware. > > I checked the dhclient.conf file on the Ubuntu desktop that pulls an > address from the modem just fine (which is this one, so I'm sure it really > works), and while not identical, it's only configured to send the hostname > as well. > > I've hit dead ends with everything now, and so any further suggestions are > quite welcome. > > More info on the OBSD box: > > It's an old Toshiba Satellite 330CDS. I installed OBSD 4.2 with just > base42, etc42, and man42. The only non-stock program running is > isc-dhcp-server-3.0.4p0.tgz, which I installed in order to get dynamic DNS > going. The laptop has two PCMCIA NICs, ep1 (external) and ne3 (internal). > > The setup was done primarily by bending the following two guides to my > setup: > > http://www.openbsd.org/faq/pf/example1.html > http://www.bsdguides.org/guides/openbsd/networking/dynamic_dns_dhcp.php > > The former is just the sample home router from the PF guide, and the latter > addresses DHCP and DNS. > > Thanks in advance for any suggestions. > > David Murphy Firstly, post something that might help someone troubleshoot your problems. Something like a dmesg and any errors that dhclient is producing. Disable everything until you can get dhclient to work. Are you blocking dhcp packets with pf? Is your local dynamic DNS service screwing with your upstream DHCP? Maybe try unplugging your cable modem for a bit, sometimes they get picky about how many MAC addresses they'll give IPs to. --david
Re: OBSD hacks at ruxcon
On Tue, Mar 4, 2008 at 9:57 PM, steve szmidt <[EMAIL PROTECTED]> wrote: > Hi, > > I'm curious what the developers think about the attack angles Ben Hawkes put > forth at Ruxcon in 2006. I did manage to find a note in an archive suggesting > that these doors were closed, but I could not tell if they are? > > Ref: > http://ruxcon.org.au/files/hawkes_openbsd.pdf > Exploiting OpenBSD > by Ben Hawkes http://marc.info/?t=11602591855&r=1&w=2
Re: dvorak key layout
man kbd On Sat, Mar 15, 2008 at 10:17 PM, Timothy Wilson <[EMAIL PROTECTED]> wrote: > Hello misc@, > > I was wondering how I can use a dvorak keyboard on the console? I've > googled, but I can only find how to's for X11, or for 2.x OpenBSD. I'm > sure its something simple in rc.conf (.local!), but I can't find it. > Any help would be appreciated. > > Kind regards, > Timothy
Re: strange output on openbsd C code
Whenever a printf "fixes everything", it's usually because that forces
gcc to put the values on the stack. Without the printf, they're
probably in registers and p points to who knows what.
If you grok assembly, try objdump on the executable to see what's
going on. If you want to multiply the two halves of a long long, I'd
suggest shifting and masking it out explicitly instead of using
pointer tricks like this.
--david
On 3/19/07, Gustavo Rios <[EMAIL PROTECTED]> wrote:
No!
p sizeof is 4 bytes, p is the frst byt of &x, and p + 1 is the 4th
byte. Casting is only on attribution of &x to p.
Realize, p[0] evals to 1 and p[1] evals to 2 as it should be. Only
problem relates to p[0] * p[1]. I believe it should (1 * 2), i.e., 2.
Not a random value.
On 3/19/07, Nick ! <[EMAIL PROTECTED]> wrote:
> On 3/19/07, Gustavo Rios <[EMAIL PROTECTED]> wrote:
> >
> > On 3/19/07, Nick ! <[EMAIL PROTECTED]> wrote:
> > > On 3/19/07, Gustavo Rios <[EMAIL PROTECTED]> wrote:
> > > > I am writing a very simple program but the output change for the c
> > > > variable value change every time i run it. What would it be my mistake
> > > > on the source? Did i forget some thing?
> > > >
> > > > #include
> > > >
> > > > int
> > > > main(int argc, char **argv)
> > > > {
> > > > unsigned long long x, c;
> > > > unsigned*p;
> > >
> > > ^ this is bad. always say your types in full.
> > >
> > > >
> > > > x = 1, x+= (unsigned long long)1 << 33 ;
> > >
> > > This sets *(&x) to 1, and then sets *(&x) (yes, the same one) to 1+(1<<33)
> > >
> > > > p = (void *)&x;
> > > > c = p[0] * p[1];
> > >
> > > That is, p[1] == *(&x+1) is never getting set to anything. Thus the
> > > reason the output is always changing is because p[1] is always
> > > pointing at a different, random location in memory that has some
> > > previous value.
> > >
> > > Further, p[1] is not your memory, and it's only by chance that you're
> > > not segfaulting.
> > >
> > > > fprintf(stdout, "x:%llu\n", x);
> > > > fprintf(stdout, "0,1:%u,%u\n", p[0], p[1]);
> > > > fprintf(stdout, "c:%llu\n", c);
> > > >
> > > > return 0;
> > > > }
> > > >
> > So, why when i printf p[1], it correctly prints 2?
>
> Uhm. Hmm. Well, x is a long long which is 8 bytes right? A void (when
> doing pointer arithmetic) is taken to only be 1 byte (right?). So p[0]
> is the first byte of those 8, and p[1] is the second, and due to
> coincidence and twos-complement encoding it happens to show you the
> expected numbers. Maybe?
>
> But that doesn't explain why the output is always changing.
>
> Wait, how is * defined on two voids? That shouldn't even compile
> (unless it's autocasting to int?).
>
> -Nick
Troubleshooting NFS/SFU
I've tried to configure NFS and am nearly all the way there, but it seems like I've hit a pretty big stumbling block. I've got OpenBSD 4.1-stable (10.0.0.1) with an NFS export of my home directory. I also have a Windows XP machine (10.0.0.2) and installed the SFU 3.5 NFS client. [/etc/exports] /home/david -mapall=david:guest -network=10.0.0.0 -mask=255.255.255.0 I can successfully mount this share locally and perform both reads and writes. Without any of SFU's User Name Mapping configured, I can mount the share with uid/gid of -2/-2 as advertised. Appropriately, I cannot access any files or directories that are not world-readable. However, inside a chmod-777 directory, I cannot create files or directories (which might be as expected). After configuring User Name Mapping to map my Windows account to the UNIX account, I can mount the share with the expected uid/gid. Although I can read user-only files and directories, I still cannot create any files or directories. Windows keeps reporting that the drive has write-protection enabled. I know this isn't a SFU help forum, but any ideas to try or tips on troubleshooting the NFS side is more than welcome. Thanks in advance. --david P.S. On an unrelated sidenote, does mountd always bind to the same ports by default? If not, is there a way to fix them at certain values, so that PF rules can be written to match? Linux rpc.mountd(8) supposedly has a -p option that can be used for this purpose.
Re: Troubleshooting NFS/SFU
On 5/14/07, Ben Calvert <[EMAIL PROTECTED]> wrote:
On May 13, 2007, at 8:44 PM, David Higgs wrote:
> I've tried to configure NFS and am nearly all the way there, but it
> seems like I've hit a pretty big stumbling block. I've got OpenBSD
> 4.1-stable (10.0.0.1) with an NFS export of my home directory. I also
> have a Windows XP machine (10.0.0.2) and installed the SFU 3.5 NFS
> client.
Are most of your clients going to be windows machines? if so, you
should thing seriously about using samba.
This is my private network and I've used samba previously; I'm just
trying to learn how to configure NFS. I'll go back to samba if I
can't figure this out.
( you should also read http://www.openbsd.org/mail.html and include
all even vaguely related config files and output of things like dmesg
and nfsstat )
I've googled quite a bit on this as well as searched MARC. I don't
know any other files to include other than /etc/exports.
[EMAIL PROTECTED] dmesg
OpenBSD 4.1 (GENERIC) #1435: Sat Mar 10 19:07:45 MST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 599 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem = 267993088 (261712K)
avail mem = 236847104 (231296K)
using 3302 buffers containing 13524992 bytes (13208K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+ BIOS, date 10/13/00, BIOS32 rev. 0 @
0xfd790, SMBIOS rev. 2.1 @ 0xefa30 (49 entries)
bios0: Dell Computer Corporation XPST600
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xfd790/0x870
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/192 (10 entries)
pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xb800 0xcb800/0x800 0xcc000/0x800
0xe/0x4000! 0xe4000/0xc000
acpi at mainbus0 not configured
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA GeForce3" rev 0xa3
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 19473MB, 39882528 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 9
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
emu0 at pci0 dev 14 function 0 "Creative Labs SoundBlaster Live" rev 0x05: irq 3
ac97: codec id 0x54524123 (TriTech Microelectronics TR28602)
audio0 at emu0
"Creative Labs PCI Gameport Joystick" rev 0x05 at pci0 dev 14 function
1 not configured
skc0 at pci0 dev 16 function 0 "3Com 3c940" rev 0x10, Yukon (0x1): irq 9
sk0 at skc0 port A, address 00:0a:5e:5c:50:41
eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3
xl0 at pci0 dev 17 function 0 "3Com 3c905C 100Base-TX" rev 0x74: irq
10, address 00:01:03:c3:66:4e
bmtphy0 at xl0 phy 24: Broadcom 3C905C internal PHY, rev. 6
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask fb65 netmask ff65 ttymask ffe7
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
ugen0 at uhub0 port 1
ugen0: APC Back-UPS ES 750 FW:819.z2.D USB FW:z2, rev 1.10/1.06, addr 2
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
uhub1 at uhub0 port 2
uhub1: ATEN International product 0x7000, rev 1.10/1.00, addr 3
uhub1: 4 ports with 4 removable, self powered
uhidev0 at uhub1 port 1 configuration 1 interface 0
uhidev0: Logitech USB Receiver, rev 1.10/21.00, addr 4, icla
Re: APC UPSD
I've also had good luck with the latest sourceforge release of apcupsd, especially since the APC USB is now usefully detected as a ugen. Thanks again to the kind soul who provided the USB quirks patch back in the 3.8 or 3.9 days. Their configure script doesn't handle --prefix too well, though; it still insisted on installing things into /sbin. I ended up having to do something like this: ./configure --sbindir=/usr/local/sbin --mandir=/usr/local/man --enable-usb [your options] --david On 5/21/07, Marco S Hyman <[EMAIL PROTECTED]> wrote: "Jean-Daniel Beaubien" writes: > If you want to use an APC UPS you might need to compile nut from ports (or > download and compile the latest version). Or use apcuspd. Last time I got the source from sourceforge it just worked. ./configure --enable-usb make sudo make install neko[marc]# /etc/rc.apcupsd restart Stopping apcupsd power management Done. waiting for apcupsd to exit Starting apcupsd power management Done. neko[marc]# /etc/rc.apcupsd status APC : 001,037,0911 DATE : Mon May 21 13:40:56 PDT 2007 HOSTNAME : neko.snafu.org RELEASE : 3.14.0 VERSION : 3.14.0 (9 February 2007) openbsd UPSNAME : neko.snafu.org CABLE: USB Cable MODEL: Back-UPS RS 1500 UPSMODE : Stand Alone STARTTIME: Mon May 21 13:40:53 PDT 2007 STATUS : ONLINE LINEV: 118.0 Volts LOADPCT : 36.0 Percent Load Capacity BCHARGE : 100.0 Percent TIMELEFT : 91.5 Minutes MBATTCHG : 30 Percent MINTIMEL : 10 Minutes MAXTIME : 0 Seconds SENSE: Low LOTRANS : 097.0 Volts HITRANS : 132.0 Volts ALARMDEL : Always BATTV: 26.9 Volts LASTXFER : Low line voltage NUMXFERS : 0 TONBATT : 0 seconds CUMONBATT: 0 seconds XOFFBATT : N/A SELFTEST : NO STATFLAG : 0x0708 Status Flag MANDATE : 2004-09-25 SERIALNO : JB0439032522 BATTDATE : 2001-09-25 NOMINV : 120 NOMBATTV : 24.0 FIRMWARE : 8.g8 .D USB FW:g8 APCMODEL : Back-UPS RS 1500 END APC : Mon May 21 13:40:57 PDT 2007 // marc
Re: following stable, extra file sets?
On 6/30/07, Aaron <[EMAIL PROTECTED]> wrote: Ok this has answered the question, and thanks.This raises another question for me.. If updating just the sets that you install, and I am making an assumption here that people would want to update code when needed, and be supported, why even give the choice on which sets to install initially if the two extra sets will be installed anyway during the supported method of updating? Keep in mind there is more than one way of updating in a supported manner. Applying the errata patches rarely requires a full userland rebuild. Also, you can make a -stable release(8) on one machine and still choose your sets whenever you install/upgrade from them. --david
Re: Troubleshooting NFS/SFU
On 5/15/07, John Nietzsche <[EMAIL PROTECTED]> wrote: Dear folks, i am trying to get my windows boxes access nfs directly by means of SFU, too! I would like to have a global mount, say drive g: to mount from my home directories. Is it possible? How have you been doing in order to get a global drive mapping? Thanks in advance. I followed Microsoft's instructions for SFU and found that it worked quite well if all I cared about was read-only access. I didn't have any further success even after installing a bunch of SFU hotfixes (http://www.duh.org/interix/hotfixes.php). My troubleshooting seemed to indicate that the write requests were being denied somewhere inside the kernel, for reasons unknown. I didn't have the time or interest to pursue it any further, so I went back to samba and let the thread die. --david
