Re: bridge fails to broadcast ARP from gif tunnel

[Rolf Sommerhalder]

Hi Goda,

On Tue, Dec 1, 2015 at 10:07 AM, Kazuya GODA  wrote:
> It seems to bridge doesn't forward broadcast/multicast frames from gif.
> This pathc will fix this problem, so would you try it?

Indeed, your patch fixes the problem! Excellent, thank you very much.

Now, I will go on and try IPsec with the same bridge test setup... :-)

Will you merge the fix into -current?

Thanks again,
Rolf

Re: bridge fails to broadcast ARP from gif tunnel

[Rolf Sommerhalder]

Looking at the source in sys/netinet/ip_ether.c of
 void etherip_decap(struct mbuf *, int);
which calls etherip_getgif(struct mbuf *m) first, and then clears
these flags of the _inner_ Ethernet header:
...
/* Reset the flags based on the inner packet */
m->m_flags &= ~(M_BCAST|M_MCAST|M_AUTH|M_CONF|M_PROTO1);

Why? I can not yet understand this (false?) symmetry to what
gif_encap() does to the outer Ethernet header which gif_output() calls
in sys/net/if_gif.c .

Could that be the cause of my problem where Ethernet frames that come
out of the gif tunnel and are EtherIP decapsulated are actually not
forwarded by the other members of the bridge because the M_MCAST bit
got cleared, instead being left untouched on decapsulation?

Setting up a build host with current right now to find out...

Re: bridge fails to broadcast ARP from gif tunnel

[Rolf Sommerhalder]

After adding static ARP entries 'arp -s 172.16.1.5 ' to the ARP tables
on each end HostA and HostB respectively, ping (and tcpbench) work fine end
to end through the gif tunnels, from both sides.

Thus my problem appears to be limited to ARP Requests resp. their  Ethernet
broadcasts not being forwarded properly by the bridges if they come into
the bridge via an EtherIP tunnel from a gif interface...

bridge fails to broadcast ARP from gif tunnel

[Rolf Sommerhalder]

Using the simple Layer-2 bridge setup below, an ICMP Ping 172.17.1.5
from HostA does not get to HostB while using EtherIP encapsulation with
gif(4) at its tunnel end points.

The Ping's initial Ethernet broadcasts with the ARP Requests make it
through the gif tunnel to BridgeB, to both its bridge0 and vio2
interfaces (check with tcpdump, tshark).

However, vio2 never re-broadcasts those ARP Requests on the wire to
HostB!? E.g. the physical egress interface vio2, which is member of a
bridge(4) on BridgeB, receives the ARP Requests, but it fails
re-broadcast them to HostB so that Host could answer with ARP Reponses.

Also, BridgeB does not learn the source MAC from HostA (and of course it
can not learn the MAC of HostB, because ARP Requests never get there).

However, pinging the (numbered) vio2 on BridgeB succeeds (Ping
172.17.1.2 from HostA), e.g. the gif tunnel is OK.

Also, HostA can ping HostB after removal of the gif tunnel, e.g. after
deleting gif0 from bridge0 on both BridgeA and BridgeB, and adding vio1
to them instead.

Testing conditions:
- default installs of OpenBSD i386 snapshot from yesterday
- pf is disabled
- no L2 filter rules on the bridge member interfaces
- set sysctl net.inet.etherip.allow=1 to enable EtherIP on gif()
- the observation is the same on both VirtualBox with vio() interfaces,
as well as on a real hardware with APU2 that have em() interfaces.

Currently, experimenting with pf enabled on BridgeB, I found that ARP
Requests apparently do not generate state with a very basic rule-set,
such as 'pass log all'.

What did I miss?  Or, is there "just a bug" in the gif/bridge combo that
is haunting me?
Would it be worthwhile to try with -stable or an older version of
OpenBSD?  Years ago, I had such a setup working with 4.3, and I can make
configuration files available (although they are very minimal, mostly
running default install) ...

Thanks for any hints and suggestions!
Rolf


*HostA*
vio1 172.16.0.5/22
 |
 v
vio2 172.16.0.2/22
*BridgeA*
bridge0 add vio2 add gif0
gif0 tunnel 10.10.1.2 10.10.1.3
vio1 10.10.1.2/24
 |
 v
vio1 10.10.1.3/24
gif0 tunnel 10.10.1.3 10.10.1.2
bridge0 add vio2 add gif0
*BridgeB*
vio2 172.16.1.2/22
 |
 v
vio1 172.16.1.5/22
*HostB*

Install from snapshot unable boot

[Rolf Sommerhalder]

The current snapshot fails to install from .iso at the very last step
at writing the boot info to disk on VirtualBox.

http://mirror.switch.ch/ftp/pub/OpenBSD/snapshots/i386/BUILDINFO
Build date: 1448569476 - Thu Nov 26 20:24:36 UTC 2015

Using "the same procedure", install from an older i386 snapshot from 5
Nov 2015, followed by an update to the current snapshot using bsd.rd,
works as usual.

Re: Install from snapshot unable boot

[Rolf Sommerhalder]

On Fri, Nov 27, 2015 at 9:01 AM, Antoine Jacoutot  wrote:
> Yeah, that's because of pledge(2):
> installboot(19095): syscall 54 "ioctl"

Thank for your confirmation. I did not spot the error message above,
but saw a commit from Theo last night related to installboot. So I
thought this might be connected, and maybe relevant feedback.

pair(4) + pf(4) and ipsec(4)

[Rolf Sommerhalder]

Hi,

On a rainy/snowy Sunday, I am trying to "renovate" an ancient but
working Layer-2 Ethernet bridge over IPsec over wireless LAN setup
that I had implemented using isakmpd (IKEv1) in OpenBSD 4.3 on WRAP
boards from PC Engines, and bring it up to date with iked (IKEv2)
using latest crypto transforms in OpenBSD -current on two APU2 boards
:-)

With his OK in [1], Reyk briefly described of his test scenario(s):

"tested with pair(4) ... ipsec on pair(4) ... routed ipsec on pair(4) ...
(pair0 -> ipsec -> pair1 -> $ext_if) ... bridge/pair stp ..."

Do I interpret this correctly as representing (at least) five
different use cases that are separated by ellipses '...'?
Can ipsec() use pair() directly without going through gif(4) and
bridge(4) (with Link2 set), e.g. is only the last case above involving
bridge()? (Probably unlikely, as pair(4) like vether(4) are always
members of bridges according to ther man pages.)
What is the difference between the 2nd and 3rd use cases, e.g. Layer-2
bridging vs. Layer-3 routing over IPsec tunnels?

Would you mind to share maybe some (fragments of) configurations that
illustrate those use cases?

Thanks,
Rolf

[1] Re: pair(4) + pf(4): reset all state on "reinjected" packets
http://permalink.gmane.org/gmane.os.openbsd.tech/45411

carp(4) requires carpdev in OpenBSD 5.7

[Rolf Sommerhalder]

After upgrading a firewall cluster from 5.6 to 5.7, I observed that
carpX interfaces failed to come up with their settings.

A manual start 'sh /etc/netstart carpX' ran without errors, although
carpX still did not get its settings from hostname.carpX.
However, 'ifconfig carpX 10.0.8.1 vhid 108' failed:
 ifconfig: SIOCAIFADDR: Invalid argument

http://www.openbsd.org/57.html revealed that carp(4) now needs to be
configured with an explicit carpdev parent interface (as from 5.7).
Thus adding 'carpdev vlanX' to the ifconfig or hostname.carpX solved
my problem :-)

Apparently, I had been mentioned in a previous revision of following
-current, too.
May I suggest to mention it in the Other changes section of the
Upgrade 5.6-5.7 document?

Also, it might be helpful to add carpdev to the examples, which is now
mandatory, in the carp(4) man pages.

Thanks,
Rolf

Re: MPLS VPN on OpenBSD

[Rolf Sommerhalder]

Have you noticed the paper which Claudio Jeker had presented at
EuroBSDCon 2011?
  http://2011.eurobsdcon.org/papers/jeker/MPLS.pdf

Althought the talk is listed at
  http://www.openbsd.org/events.html
it is missing at
  http://www.openbsd.org/papers/

NAT64 sample config

[Rolf Sommerhalder]

Maybe you are interested in giving NAT64 a try which has been
committed to the tree a few weeks ago. In my first test I found it
works great. Thanks to the developers for their hard work!

Eventually, the following sample config saves you some time while the
man pages are in the works, although looking through the commit logs,
source code, and conference presentations is always educational. Note
that NAT64 is not in 5.0-release, but you need a snapshot which is not
older than three weeks or so.

The following line in /etc/pf.conf is all which is required to setup a
stateful NAT64 on an OpenBSD box which has one interface in an IPv6
segment, and another interface in an IPv4 segment (private LAN, or
even the Internet):

pass in log on vic1 inet6 from any to 64:ff9b::/96 \
 af-to inet from 192.168.98.74

For my test, I installed OpenBSD i386 snapshot from 3 Nov 11 on ESXi
4.1u1. vic1 is the inside interface on a vSwitch that accomodate
IPv6 hosts exclusively.
The outside interface vic0 is in IPv4-only segment and has the IP
address 192.168.98.74.

The above pf rule translates all ingress IPv6 traffic on vic1, which
wants to go to destinations with the special prefix 64:ff9b::/96, to
IPv4 with the source (NAT64) address of the outer interface vic0
ingress. pf implicitly takes the IPv4 destination (NAT64) from the
lower 32 bits of the IPv6 destination address.
This rule creates state, therefore return traffic is translated
implicitly, e.g. you should not add any rule for return traffic.

I derived this rule from Claudio@'s example in the commit log, which
translates from v4 to v6, and where Claudio mentioned that the
trailing to is optional for NAT64
  http://marc.info/?l=openbsd-cvsm=131853093528864

Besides testing a separate commercial virtual IPAM/DNS appliance from
Infoblox to provide DNS64 Application Level Gateway functionality, I
have also successfully tested the totd DNS proxy which provides
similar DNS64 functionality (less DNS resolver and caching). OpenBSD
has a package for totd, so just do pkg_add totd.

As time allows, I might move the virtual NAT64 and DNS64 gateway over
to an ALIX board. This portable demonstrator shall eventually gateway
IPv6-only clients on its wireless LAN IPv6-only interface to IPv4-only
Internet over 3G/UMTS - just for a fun alternative to v6 over v4
tunnels...

Regards,
Rolf


A) /etc/totd.conf :

interfaces vic1
#port 53
forwarder 192.168.99.26
prefix 64:ff9b::
retry 300


B) DNS lookup for  resource records of google.com using the DNS64
proxy yields answers with the 64:ff9b::/96 prefix:

[root@v6client:etc]# dig @2001:db8:123:64::1 google.com 

;  DiG 9.4.2-P2  @2001:db8:123:64::1 google.com 
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 30572
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.IN  

;; ANSWER SECTION:
google.com. 300 IN  64:ff9b::d155:9468
google.com. 300 IN  64:ff9b::d155:9467
google.com. 300 IN  64:ff9b::d155:9469
google.com. 300 IN  64:ff9b::d155:9493
google.com. 300 IN  64:ff9b::d155:946a
google.com. 300 IN  64:ff9b::d155:9463

;; AUTHORITY SECTION:
google.com. 8019IN  NS  ns3.google.com.
google.com. 8019IN  NS  ns1.google.com.
google.com. 8019IN  NS  ns4.google.com.
google.com. 8019IN  NS  ns2.google.com.

;; Query time: 71 msec
;; SERVER: 2001:db8:123:64::1#53(2001:db8:123:64::1)
;; WHEN: Sun Nov  6 13:25:08 2011
;; MSG SIZE  rcvd: 308


C) ping6 from IPv6-only client to google.com on the IPv4 Internet via
the NAT64 gateway works:

[root@v6client:etc]# ping6 64:ff9b::d155:9469
PING6(56=40+8+8 bytes) 2001:db8:123:64:20c:29ff:feaf:ad2f -- 64:ff9b::d155:9469
16 bytes from 64:ff9b::d155:9469, icmp_seq=0 hlim=55 time=23.094 ms
16 bytes from 64:ff9b::d155:9469, icmp_seq=1 hlim=55 time=22.825 ms
16 bytes from 64:ff9b::d155:9469, icmp_seq=2 hlim=55 time=22.762 ms
^C
--- 64:ff9b::d155:9469 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 22.762/22.894/23.094/0.144 ms


[root@v64gate:~]# tcpdump -i vic1 -nv icmp6
tcpdump: listening on vic1, link-type EN10MB
14:49:05.583129 2001:db8:123:64:20c:29ff:feaf:ad2f 
64:ff9b::d155:9469: icmp6: echo request (id:7397 seq:0) (len 16, hlim
64)
14:49:05.605904 64:ff9b::d155:9469 
2001:db8:123:64:20c:29ff:feaf:ad2f: icmp6: echo reply (id:7397 seq:0)
(len 16, hlim 55)
14:49:06.589012 2001:db8:123:64:20c:29ff:feaf:ad2f 
64:ff9b::d155:9469: icmp6: echo request (id:7397 seq:1) (len 16, hlim
64)
14:49:06.611583 64:ff9b::d155:9469 
2001:db8:123:64:20c:29ff:feaf:ad2f: icmp6: echo reply (id:7397 seq:1)
(len 16, hlim 55)
14:49:07.588874 

Re: MPLS: Disable Penultimate Hop Popping?

[Rolf Sommerhalder]

 What kind of HW do you use?

The MPLS test setup is made from five ALIX boards, three as P routers
in the core connected in a triangle, and two as PE routers.

 I do my tests with little soekris boxes and
 there the RTT is in the range of 4-5ms and indistinguishable from non MPLS
 operation.

After updating to -current as of this morning, I still observe RTTs of
113 ms when pinging from one PE router to the over PE via two P
routers.
I have been checking the usual suspects, such as duplex-mismatch, but
from tcpdumps it looks as if the P routers take two to three douzen
milliseconds before they route returning ICMP Echo Replies.

Later, I'll try to compile and post a more precise analysis, possibly
with timestamped traces, etc.

Re: MPLS: Disable Penultimate Hop Popping?

[Rolf Sommerhalder]

Here is a fix for the PHP issue.

Great, it fixes the problem. Thank you very much.

The test setup works now, although I had no time yet for in-depth
testing with other traffic than just ICMP pings. But pings from pe11
to pe21 make it now back to pe11 while p1 and p2 both do PHP.

However, in a brief test I observed that the RTT from pe11 to pe21 via
p1 and p2 and back is 73 ms. Sniffing on the interface of the target
pe21, I see that it takes 13 ms from the time the routed,
label-stripped Echo Request comes in, until the labeled Echo Reply is
sent back to p2.

I hope to find some time tomorrow to take a close look at p2, p1 and
pe11 in order to try and figure out why the RTT sums up to 73 ms where
I expect it to be in the order of a few ms only.

Rolf

MPLS: Disable Penultimate Hop Popping?

[Rolf Sommerhalder]

Dear list,

Is there an way to disable PHP, e.g. to prevent ldpd on the last P
router from stripping/popping the label before it reaches the PE
router?

In my little test network that runs -current as of 03 June, I observe
from ldpd's lfib on the last P router that it pops the label on the
ingress interface (see output below), but then it never outputs/routes
the stripped packet to the egress interface towards the PE router (the
use counter of the matching prefix on the P router does not increment,
e.g. the P router appears to blackhole the ICMP Echo Request packets).

Currently, I am using a very basic setup with RIP as IGP, LDP, without
any additional route tables, nor VLANs, pf is disabled on all nodes.

I can provide a more detailed description of my lab setup, and output
of the various routing tables, etc. However, if there would be an easy
way to disable PHP, then that would confirm that my setup is indeed OK
(as I have tried to verify manually so far).

Thank you,
Rolf


We ping from another PE router pe11 via two P routers p1 and p2 to
another PE router pe21=3.2.1.1:
[r...@pe11:root]# ping 3.2.1.1

The label switched packet makes it via another P router p1 to the
ingress interface of the last P router p2 just fine:
[r...@p2:root]# tcpdump -i vr2 -n
tcpdump: listening on vr2, link-type EN10MB
18:34:39.071600 MPLS(label 0x14, exp 0, ttl 254) 2.1.1.2  3.2.1.1:
icmp: echo request
18:34:40.091795 MPLS(label 0x14, exp 0, ttl 254) 2.1.1.2  3.2.1.1:
icmp: echo request
18:34:41.111994 MPLS(label 0x14, exp 0, ttl 254) 2.1.1.2  3.2.1.1:
icmp: echo request

According to the LFIB this P router knows it is the Penultimate Hop
which directly connects to pe21. Therefore (probably), it pops the
label 20:
[r...@p2:root]# ldpctl show lfib
flags: * = valid, C = Connected, S = Static
Flags  Destination  Nexthop   Local Label   Remote Label
*S 0.0.0.0/010.7.0.25416-
*C 1.1.2.0/29   link#3imp-null  -
*R 1.1.3.0/29   1.1.2.1   17Pop
*C 1.2.3.0/29   link#2imp-null  -
*R 2.1.1.0/30   1.1.2.1   18Pop
*C 2.2.1.0/30   link#1imp-null  -
*R 3.1.1.0/30   1.1.2.1   1919
*R 3.2.1.0/30   2.2.1.2   20Pop   ==
*R 3.2.1.4/30   2.2.1.2   21Pop
*R 3.2.1.8/30   2.2.1.2   22Pop
*R 7.0.0.1/32   1.1.2.1   2323
*  7.0.0.2/32   7.0.0.2   24-
*R 7.0.0.3/32   1.2.3.3   2517
*R 7.0.0.11/32  1.1.2.1   2626
*R 7.0.0.21/32  2.2.1.2   2726
*C 10.7.0.0/16  link#6imp-null  -
*C 127.0.0.0/8  link#0- -
*S 127.0.0.0/8  127.0.0.1 - -
*  127.0.0.1/32 127.0.0.1 - -
*S 224.0.0.0/4  127.0.0.1 - -
*  224.0.0.9/32 127.0.0.1 - -


[r...@p2:root]# ripctl show rib
Destination  Nexthop   Cost
1.1.2.0/29   0.0.0.0   1
1.1.3.0/29   1.1.2.1   2
1.2.3.0/29   0.0.0.0   1
2.1.1.0/30   1.1.2.1   2
2.2.1.0/30   0.0.0.0   1
3.1.1.0/30   1.1.2.1   3
3.2.1.0/30   2.2.1.2   2  ==
3.2.1.4/30   2.2.1.2   2
3.2.1.8/30   2.2.1.2   2
7.0.0.1/32   1.1.2.1   2
7.0.0.2/32   7.0.0.2   1
7.0.0.3/32   1.2.3.3   2
7.0.0.11/32  1.1.2.1   3
7.0.0.21/32  2.2.1.2   2

[r...@p2:root]# route -n get 3.2.1.1
   route to: 3.2.1.1
destination: 3.2.1.0
   mask: 255.255.255.252
gateway: 2.2.1.2
  interface: vr0
 if address: 2.2.1.1
   priority: 40 (rip)
  flags: UP,GATEWAY,DONE
 use   mtuexpire
  49 0 0

But p2 appears to eat up those packets, instead of forwarding them to
the egress interface vr0:
[r...@p2:root]# tcpdump -i vr0 -nvv
tcpdump: listening on vr0, link-type EN10MB
18:45:53.449355 2.2.1.2.646  224.0.0.2.646: [udp sum ok] udp 26 [tos
0xc0] [ttl 1] (id 64128, len 54)
18:45:53.682729 2.2.1.1.646  224.0.0.2.646: [udp sum ok] udp 26 [tos
0xc0] [ttl 1] (id 6099, len 54)
18:45:58.460172 2.2.1.2.646  224.0.0.2.646: [udp sum ok] udp 26 [tos
0xc0] [ttl 1] (id 6759, len 54)
^C
4 packets received by filter
0 packets dropped by kernel

Note that IP forwarding is enabled on all P and PE routers, e.g.
sysctl net.inet.ip.forwarding=1 .

Re: MPLS: Disable Penultimate Hop Popping?

[Rolf Sommerhalder]

Thanks Claudio for your speedy reply.

 Have a look at the route -n show -mpls output and check the input counter
for label 20.

It happily counts and confirms what tcpdump shows on the ingress interface:

[r...@p2:root]# route -n show -mpls
Routing tables

MPLS:
In label  Out label Op GatewayFlags   Refs  Use
Mtu  Prio Interface
3 - LOCAL  127.0.0.1  UGT00
3320056 lo0
16- LOCAL  10.7.0.254 UGT00
 -56 udav0
17- POP1.1.2.1UGT00
 -56 vr2
18- POP1.1.2.1UGT05
 -56 vr2
1919SWAP   1.1.2.1UGT00
 -56 vr2
20- POP2.2.1.2UGT0 7526
 -56 vr0   ==
21- POP2.2.1.2UGT00
 -56 vr0
22- POP2.2.1.2UGT00
 -56 vr0
2323SWAP   1.1.2.1UGT00
 -56 vr2
24- LOCAL  7.0.0.2UGT01
3320056 lo1
2517SWAP   1.2.3.3UGT00
 -56 vr1
2626SWAP   1.1.2.1UGT00
 -56 vr2
2726SWAP   2.2.1.2UGT00
 -56 vr0

Also, I have re-checked the counters of all other routes as well as
the traffic out of all other interface on this P router, but the
packets do not appear on a wrong interface.

 Setup looks fine. I use OSPF as IGP but I now Michele is using RIP in his
setup.

For a cross-check, I will move from RIP to OSPF and report again if it
made any difference.

 Please consider using IP blocks that are available for testing and not
publicly assigned ones.

But it so much more convenient with short addresses which reflect the
topology, although there is actually named running as well. As a
precaution against leakage into the wild Internet, I had added those
public ranges temporarily to the RFC1918 egress filter on my pf lab
firewall :-)

Re: MPLS: Disable Penultimate Hop Popping?

[Rolf Sommerhalder]

 Yeah, the packets are dropped in the POP case of mpls_input.c that's how
 far I got until now. I started with a fix but my magic is not strong
 enough for now.

After taking a look at the source, I essentially backed out changes
done in rev. 1.10  /src/usr.sbin/ldpd/kroute.c .

Now my test setup works *somehow* even though the LFIB still shows
that LDP applies PHP:

[r...@p2:root]# ldpctl sh lfib 3.2.1.1
flags: * = valid, C = Connected, S = Static
Flags  Destination  Nexthop   Local Label   Remote Label
*R 3.2.1.0/30   2.2.1.2   20Pop


But the kernel routing table is different, e.g. it applies no PHP but
does SWAP the labels, as desired :

[r...@p2:root]# route -n show -mpls
Routing tables

MPLS:
In label  Out label Op GatewayFlags   Refs  Use
Mtu  Prio Interface
3 - LOCAL  127.0.0.1  UGT00
3320056 lo0
16- LOCAL  10.7.0.254 UGT00
 -56 udav0
173 SWAP   1.1.2.1UGT00
 -56 vr2
183 SWAP   1.1.2.1UGT0   30
 -56 vr2
1919SWAP   1.1.2.1UGT00
 -56 vr2
203 SWAP   2.2.1.2UGT0   30
 -56 vr0  ==
213 SWAP   2.2.1.2UGT00
 -56 vr0
223 SWAP   2.2.1.2UGT00
 -56 vr0
2323SWAP   1.1.2.1UGT00
 -56 vr2
24- LOCAL  7.0.0.2UGT00
3320056 lo1
2517SWAP   1.2.3.3UGT00
 -56 vr1
2626SWAP   1.1.2.1UGT00
 -56 vr2
2726SWAP   2.2.1.2UGT00
 -56 vr0


Also, the RTT for the pings is approx. 150 ms (and increasing) which
should be in the 1 ms range:
[r...@pe11:root]# ping 3.2.1.1
PING 3.2.1.1 (3.2.1.1): 56 data bytes
64 bytes from 3.2.1.1: icmp_seq=364 ttl=252 time=113.307 ms
64 bytes from 3.2.1.1: icmp_seq=365 ttl=252 time=113.211 ms
64 bytes from 3.2.1.1: icmp_seq=366 ttl=252 time=113.285 ms
64 bytes from 3.2.1.1: icmp_seq=367 ttl=252 time=113.260 ms
64 bytes from 3.2.1.1: icmp_seq=368 ttl=252 time=113.204 ms
64 bytes from 3.2.1.1: icmp_seq=369 ttl=252 time=152.024 ms
64 bytes from 3.2.1.1: icmp_seq=370 ttl=252 time=151.746 ms
64 bytes from 3.2.1.1: icmp_seq=371 ttl=252 time=151.777 ms
64 bytes from 3.2.1.1: icmp_seq=373 ttl=252 time=151.778 ms
64 bytes from 3.2.1.1: icmp_seq=374 ttl=252 time=151.753 ms
64 bytes from 3.2.1.1: icmp_seq=375 ttl=252 time=151.729 ms
64 bytes from 3.2.1.1: icmp_seq=376 ttl=252 time=151.782 ms
64 bytes from 3.2.1.1: icmp_seq=377 ttl=252 time=151.789 ms
64 bytes from 3.2.1.1: icmp_seq=378 ttl=252 time=151.760 ms
64 bytes from 3.2.1.1: icmp_seq=379 ttl=252 time=151.712 ms
64 bytes from 3.2.1.1: icmp_seq=380 ttl=252 time=151.787 ms
64 bytes from 3.2.1.1: icmp_seq=381 ttl=252 time=151.853 ms
64 bytes from 3.2.1.1: icmp_seq=382 ttl=252 time=151.798 ms
64 bytes from 3.2.1.1: icmp_seq=383 ttl=252 time=190.438 ms
64 bytes from 3.2.1.1: icmp_seq=384 ttl=252 time=190.347 ms
64 bytes from 3.2.1.1: icmp_seq=385 ttl=252 time=190.349 ms
64 bytes from 3.2.1.1: icmp_seq=386 ttl=252 time=190.395 ms
64 bytes from 3.2.1.1: icmp_seq=387 ttl=252 time=190.315 ms
64 bytes from 3.2.1.1: icmp_seq=388 ttl=252 time=190.316 ms
64 bytes from 3.2.1.1: icmp_seq=389 ttl=252 time=190.309 ms


Obviously, I did not understand enough about the code yet...

Re: gcc4,amd64 - mk.conf?

[Rolf Sommerhalder]

 Does it make any difference having it in mk.conf or not?

At the moment, I am looking into the same question. Yesterday, I went
through the compiler upgrade steps on an i386-current machine.
Probably, I have ended up with a gcc3-compiled gcc4 on my i386 system,
although I had thought I had re-compiled gcc4 with itself as per the
second step of the instructions in the the FAQ.

However, after looking at
 /usr/src/share/mk/bsd.own.mk  (see snipplet below)
it looks to me as if gcc4 is currently only set automagically on
am64 and sparc64. Right now, I am trying to re-compile (on my i386
machine) gcc4 with itself after having set COMPILER_VERSION=gcc4
manually in /etc/mk.conf , as per Marco's instructions.

In an hour or so I should know if this solves the compile error I had
encoutered while building the userland, although the building of the
kernel was fine (still on i386). As per Marco's table, gcc4 is OK also
on i386.

Rolf

...
# gcc3
.if ${MACHINE_ARCH} == m68k || ${MACHINE_ARCH} == m88k || \
${MACHINE_ARCH} == sparc || ${MACHINE_ARCH} == vax
USE_GCC3?=no
COMPILER_VERSION?=gcc2
.elif ${MACHINE_ARCH} == amd64 || ${MACHINE_ARCH} == sparc64
COMPILER_VERSION?=gcc4
.else
USE_GCC3?=yes
COMPILER_VERSION?=gcc3
.endif
...

OpenBSD on Freescale QorIQ ?

[Rolf Sommerhalder]

Is anyone working on moving macppc or socppc to the Freescale QorIQ
(e500 PowerQICC core)?

Although I have no hardware / evaluation board yet myself, I am
looking into supporting this low-power architecture as a hobby
project, in order to brush up my low level programming skills a bit.

Rolf

Re: gcc4,amd64 - mk.conf?

[Rolf Sommerhalder]

 if this solves the compile error I had encoutered while building the userland,

Yes, it did. After setting COMPILER_VERSION=gcc4 in /etc/mk.conf,
re-compiling gcc4 with itself just to be on the safe side, then the
builds of the kernel, userland, and finally xenocara were successful.

This just took longer than one hour, but almost three hours on my Acer
Timeline Aspire 3810T laptop, including the MPLS and mpe kernel
options...

Rolf

Re: Virtual pseudo-device 'vwire()' anyone?

[Rolf Sommerhalder]

On Fri, Dec 25, 2009 at 2:37 PM, Csaba Szip css...@gmail.com wrote:
 OpenBSD has some network virtualization (not yet fully ready?) stuff
 in the tree called rdomain. I reading the current documentation, but i
 dont find any solution to interconnect  two rdomain. I create two
 vether interface in different rdomain and switched them, but it doesnt
 work.  So that would be nice if this vwire (or similar) device will be
 provided and coexist with rdomain.

Hello Csszep, what you need to glue rdomains together is _routing_
(combined eventually with some firewalling by pf) which operates at
network layer-3 level, based on IP addresses etc. in IP packet
headers.

The purpose of vwire  however is to establish a connection between two
bridges which may have ether(4), other pseudo-device such as tunX, and
real physical interfaces as members. Thus vwire glues together two
bridges which become like a large virtual switch with the member
interfaces being switch ports. Note that the bridge and the
interconnecting vwire operate at link layer-2 exclusively, e.g. we
consider _switching_ which looks only at MAC addresses of Ethernet
frames.

Thus, vwire will not even (need to) be aware of the protocols used by
the payload which these switched Ethernet frames encapsulate. vwire
will essentially just be bi-directional pipes which transport bits
between two bridges. In order to make things interesting, these pipes
might introduce some distortion into those bit streams, like loosing
occasionally some bits, delay them, etc.

vwire will be a link layer-2 device, much like a UTP cables with some
bumps in it. It will not know anything about IP nor routing network
layer-3.

Regards,
Rolf

Virtual pseudo-device 'vwire()' anyone?

[Rolf Sommerhalder]

Recently, developers added the pseudo-device vether(4). Such virtual
switch ports can be member of bridges. An additional pseudo-device
'vwire' would come in handy to interconnect two or more switches in a
virtualized environment, without necessarily bridging to a physical
switch port as well.
In addition to providing a simple virtual wire, such a 'vwire'
pseudo-device offers certain properties, such as delay, loss, jitter,
MTU size, etc. Over time, 'vwire' could evolve to a digital channel
simulator or even a link emulator, similar to 'dummynet' for
example which was/is used by m0n0wall and pfSense (primarily to
implement traffic shaping/policing though).

The description
  http://open-mesh.net/wiki/Emulation
comes very close to what I am trying to setup on my OpenBSD laptop as
a physical OpenBSD host, in order to emulate a network with several
virtual OpenBSD machines as guests using qemu (e.g. a bunch of P, PE
and CE routers of a MPLS network that uses lossy wireless links).

Are you aware of anyone who may already work on an equivalent of
'wire_filter' and/or 'dummynet' in OpenBSD which connect bridges over
virtual wires?  Or do you have recommendations which existing
pseudo-device(s) I should study first to get me started in the right
direction with 'vwire'?

Thank you,
Rolf

Re: Virtual pseudo-device 'vwire()' anyone?

[Rolf Sommerhalder]

 Have you ever looked at
 http://vde.sourceforge.net/
 ?

Thanks Chris for your hint, which triggered me to take a look at the
VDE project on Sourceforge.

Before posting, I was actually reading the documentation WIki of
Virtual Square (V^2) at http://wiki.virtualsquare.org . Currently, V^2
and VDE look to me like a very much more comprehensive and complex
project. Still, I am unsure about how much of the VDE code is actually
specific to (qemu under) Linux.

What I am after with vwire is only a tiny subset of that. At the
moment, I study the source of vether(4) and try to derive a simple
cross-over vwire pseudo-device from it to start with.

Which, of course, would be redundant and simply could be eliminated by
bridging all interfaces in a single bridge, unless the capability of
this simple wire is augmented by channel simulation/emulation
features. Then the vwire can link several bridges which run on the
same OpenBSD host and 'distort' transmissions between those bridges at
Link level (layer-2), for example introduce bit errors, cause bit 
frame loss, insert delay, etc.

Regards,
Rolf

Web GUI for named(8) ?

[Rolf Sommerhalder]

Hello list,

Can you recommend any GUI that enables junior IT staff to maintain
basic DNS Resource Records (such as for ex.. A, PTR, CNAME,...) for
BIND 9 running on OpenBSD?

Also, I will consider alternatives to named(8), provided that they
support an authoritative, split DNS server and some simple GUI, all
running on OpenBSD.

So far, I have been looking at webmin, Binder, smbind, ProBIND, DNS
Control, adadns. None of them appears to have a OpenBSD port yet.
Their maturity  development activity appears to vary widely.

Thanks for any hints,
Rolf

OTi Thunderbird USB Bridge in cdce(4)

[Rolf Sommerhalder]

In an attempt to stack ALIX boards using their USB interfaces
(actually to emulate an MPLS core in the lab with three ALIX boards
connected in a triangle as P routers over 480 Mbit/s USB core
links),  I picked up a USB to USB bridge at the local supermarket.

This 20$ USB bridge is branded connection, ednet elecom Group, USB
Easy Datalink, USB 2.0 Link Cable A/A, Art.-No. 84256. I was gambling
that it has a chipset built-in which is supported by cdce(4), such as
the Prolific PL250x. It looks as if I am without luck and its OTi
chipset (OTi002108-G ?) is not (yet) supported.

On i386-current, it appears as a SCSI drive which holds an executable
file for Windows, much like 2G/3G adapters like umsm(4) do:
# dmesg
...
umass1 at uhub1 port 1 configuration 1 interface 0 USB Transfer line
rev 2.00/1.00 addr 3
umass1: using SCSI over Bulk-Only
scsibus2 at umass1: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: OTi, Thunderbird, 1.00 SCSI2 0/direct removable
sd1: 0MB, 512 bytes/sec, 992 sec total
...
# mount /dev/sd1i /mnt
# ls -al /mnt
-rwxr-xr-x   1 root  wheel  409600 Nov 16  2005 EasySuite.exe

# usbdevs -v
...
 port 1 addr 3: high speed, power 250 mA, config 1, Transfer
line(0x2108), USB(0x0ea0), rev 1.00
...

After manually adding the new device to usbdevs, it attaches to cdce0
in the freshly built kernel:
# dmesg
...
cdce0 at uhub0 port 1 configuration 1 interface 0 USB Transfer line
rev 2.00/1.00 addr 2
cdce0: address 2a:cb:05:b8:12:00
...
# ifconfig cdce0 10.8.0.11 netmask 255.255.255.0 up
# ifconfig cdce0
cdce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 2a:cb:05:b8:b3:00
priority: 0
inet6 fe80::28cb:5ff:feb8:b300%cdce0 prefixlen 64 scopeid 0x6
inet 10.8.0.11 netmask 0xff00 broadcast 10.8.0.255

But pinging the peer on the other end of the USB bridge fails, which
has got the link local address 2a:cb:05:b8:12:00 :
# dmesg
...
cdce0: usb error on rx: STALLED
...

Did eventually anyone tried to integrate this USB bridge into cdce(4)
before? Is there anything else I should try before giving up on this
particular USB bridge cable, and to stack ALIX boards using their USB
ports (in order to save the 3 Ethernet NICs to connect more ALIX
boards as PE routers to the MPLS core :-)?

Thanks for any hints,
Rolf

Re: OT: 10GbE Physical Network Taps

[Rolf Sommerhalder]

 I need to collect raw throughput statistics without increasing latency
 or reducing bandwidth on 10GbE fiber links, so most of the typical
 methods are out of the question

After re-reading your post(s) and the thread, I am still unsure what
level of detail you need, e.g. what you mean by collect raw
throughput statistics.
Does that go more in-depth than simple Byte- or packet counts which
you might read by SNMP GETs from a network device in your path?
Or would a NetFlow or sFlow export provide enough level of detail for
those statistics?

Arien Vijn from AMS-IX has given some interesting presentations on
monitoring 10GE, also using the Meta / Force10 Networks programmable
NIC and a photonic cross connect/splitter:
http://events.ccc.de/congress/2006/Fahrplan/events/1640.en.html
(There is/was a voice/video recording if the session, but I can find
it right now.)

Another source for similar special NICs:
http://www.napatech.com

Rolf

Re: OT: 10GbE Physical Network Taps

[Rolf Sommerhalder]

 (There is/was a voice/video recording if the session, but I can find
 it right now.)

Here is the link to the presentation Arien held a year later, and this
one has pointers to videos of his talk:
  10GE monitoring live!  How to find that special one out of millions
  http://events.ccc.de/congress/2007/Fahrplan/events/2285.en.html

Re: Testing in a virtual environment

[Rolf Sommerhalder]

OpenBSD i386-current works fine in VirtualIron
http://www.virtualiron.com/, which is an attractive Xen-based
alternative to VMware ESX.

I have not tried to run amd64 as a guest in VirtualIron yet. Nor have I
checked if VItools have been ported to OpenBSD since I last looked into
its source one year ago.

ldattach dies after gpsd starts

[Rolf Sommerhalder]

Hello,

since a few i386 snapshot, and also in the latest GENERIC#1012 i386, I
observe that
 # /sbin/ldattach -p -s 4800 -t dcd nmea tty00
dies once I start
 # /usr/local/sbin/gpsd -N -D 2 /dev/ttyp1

This was working fine still with GENERIC#936 from mid January, shortly
after mbalmer@ added the '-p' option to ldattach.

I sthere anything I can do to help debugging this? Thanks.

Regards,
Rolf

Re: ldattach dies after gpsd starts

[Rolf Sommerhalder]

 Do you see this as well when you use ldattach on cua00?

Yes the same, no change/improvement.

from /var/log/messages:
ldattach[23199]: eof during read from device: Undefined error: 0
ldattach[20370]: eof during read from device: Input/output error

Setting priority on interface fails in latest snapshot

[Rolf Sommerhalder]

After updating my i386 firewall cluster to the latest snapshot (16 Jul, 22:15)

# ifconfig vr0 priority 2
ifconfig: priority: bad value

Is this a regression, or did the syntax change since my last update
about one week ago? I did re-read the man page and also looked through
the CVS commits, but did not find any obvious hints.

Thanks,
Rolf

Re: Setting priority on interface fails in latest snapshot

[Rolf Sommerhalder]

cjeker wrote:
 This diff got removed from the latest snaps.

Thanks for prompt reply. That's bad news, as I am using it on the
firewall cluster to resolve a problem in connection with default
routes and dhclient, as per your previous recommendation.

Is this removal just a temporary measure until some isse is solved, or
will interface priorities not return at all, e.g. do I need to go back
to ifstated for some crutches?

Rolf

dhcpd sync

[Rolf Sommerhalder]

After updating my home firewall cluster (two ALIX boards) to the i386
snapshot two days ago, I proceeded to try the great new sync feature of
dhcpd. Before, each of the cluster node was running its independent
instance of dhcpd, each dishing out from non-overlapping IP address
ranges, independent of a cluster node being in Master or in Backup state
(currently the cluster is active-passive).

Both nodes have in /etc/rc.conf.local :
dhcpd_flags=-Y vlan20 -y vlan20 vr0   # sync using multicast to
224.0.1.240

and in /etc/pf.conf :
# pfsync
pass log quick on vlan20 proto pfsync keep state (no-sync)
# spmd and dhcpd use multicasts to 224.0.1.240 for their sync
pass log quick on vlan20 proto igmp keep state (no-sync)


While testing dhcpd sync and devising a pf rule for it, looking at
'tcpdump -i vlan20' triggered the following remarks and questions:

a) It might be helpful to document in the SYNCHRONISATION section of
dhcpd(8) that 'proto icmp' is being used. This facilitates the life of
those who must devise an additional pf rule. Symmetrically, the same
would apply to spamd(8).
pfsync(4) states for example: The protocol is IP protocol 240, PF-
 SYNC, and the multicast group used is 224.0.0.240.

b) When dhcpd starts and no /var/db/dhcpd.leases exists, then dhcpd
create an empty lease file. Well, not exactly empty, but there are just
two comment lines in it, which is fine.

However, when a /var/db/dhcpd.leases still holds leases from a previous
session, the starting dhcpd does not clear thoses leases (e.g. leases
are persistent also in my case where an rsny restores the state prior to
reboot to ramdisk from CompactFlash). Nor does it apparently get a bulk
update from the dhcpd instances running on other nodes (which are
supposedly in sync, regardless if in active Master or in passive Backup
state).

pfsync has such a mechanism. Is something similar already in dhcpd's
sync (and spamd's sync), and did I simply miss it?  Or is it on the to
do list?  I guess it would be at least a nice to have to assert coherent
dhcpd (and spamd) state among the nodes, although dhclient (unlike pf)
can cope also while offered incoherent leases...

c) My setup uses the same VLAN for both the multicasts of dhcpd and
spamd (and pfsync as well). Besides potentially different shared keys in
/var/db/dhcpd.key and in /etc/mail/spamd.key, if authentication is used
at all, there is no obvious discriminator to tell the difference between
a dhcpd sync and a spamd sync frame.

Rapid inspection of /usr/src/usr.sbin/dhcpd.(h|c) and
/usr/src/libexec/spamd.(h|c) reveals that apparently the only
differences are
#define DHCPD_SYNC_VERSION  1  in dhcpd.h
#define SPAM_SYNC_VERSION   2  in spamd.h

For situations like mine where both dhcpd and spamd sync over the same
interface, would it be safer/necessary to either add an additional
application protocol flag, or to use different multicast addresses?


I would like to thank the developers for this nice new feature which
simplifies the configuration of the dhcp.conf file on my nodes and makes
them symmetric like most other configuration files in the cluster.

Rolf

memory leak with filtering bridges in i386 snapshot

[Rolf Sommerhalder]

The weekend before the hackaton started, I updated my 2-stage firewall
clusters at home, where the outer stage is setup as a filtering bridge
cluster, and the inner stage is setup as a filtering router cluster.
Both clusters are currently operating in active-passive mode, using
pfsync, carp, ifstated, etc.

After the update to the current snapshop of Saturday June 7, I observed
loosing memory at a rate of about 12 MByte per day, on both the inner
and outer cluster nodes. (I use Cacti to SNMP get memory usage and graph
free memory.)

Two days ago, I updated all four node to the latest snapshot again.
Since, the leak has apparently been plugged on the filtering router
inner firewall nodes. But it persists on the two filtering bridges outer
firewall node. The leak rate is the same for the active and the passive
node, still about 12 MByte per day.

I remember we had such a situation in fall last year. If I recall
correctly, pfsync was the culprit then which required some plumbing
which was done by reyk@ or [EMAIL PROTECTED]

Rolf

Re: asus eee ethernet and 4.3

[Rolf Sommerhalder]

Just found that my previous analysis was flawed. The problem is not
related to the length of the patch cable. lii(4) comes up correctly if
the eeePC is connected to the switch at the time when the eeePC is
powered on. However, if the eeePC is not plugged in to the switch at
powerup, then there seems to be no way to bring the link up later.
Even a reboot does not help. Only cycling power appears to bring up
the link to active state, and independent of the length of the patch
cable.

Will take another look at the startup code in lii(4).

Re: asus eee ethernet and 4.3

[Rolf Sommerhalder]

I have observed the same problem with lii(4) not linking up running
the latest i386 snapshot, and using a 10 meter patch cable to the
switch. However, when trying a short 1 m cable to the same switch port
the link comes up!
A fresh kernel build this past weekend from CVS exhibits the same behaviour.

Interestingly, under Linux/Xandros even the 10 m cable works fine.
Eventually, some MII parameters in lii(4) need to be tweaked to make
link detection work also for longer cables?  I am not afraid to try
and compile a patched driver on a fresh CVS tree, if there are any
suggestions which parameters to tweak.

Rolf

Re: relayd layer 7 http proxy and filtering questions

[Rolf Sommerhalder]

 As a test, the URL or path filtering can allow /, *.html and *.jpg.
 We are unable to figure out how to get relayd to allow only these
types of files, and deny any other access.

Same question here as I was unable to find answers yet either, after
studing the man pages, trial-and-error testing and finally looking at
the source of relayd. But before giving up and returning to Pound, I was
about to contact the authors (reyk@, pyr@) for guidance.

Thus I'd be interested in any hints and working examples, too. Then, for
one outcome, we might try to improve relayd's man page section about
filtering.

Thanks,
Rolf

glxpcib: tiny bug fix

[Rolf Sommerhalder]

Without the fix below, reading back the state of the impulse switch
(GPIO24) on my ALIX always returned '0' (e.g. switch is pressed). Now it
returns '1' if depressed, and '0' only while pressing it, as expected.

As AMD5536_GPIO_READ_BACK was already #defined but so far unused, I
assume it was just a small oversight which crept through testing while
reading back the LEDs' state only. See p. 480ff in the CS4436 Companion
Data Book for a detailed description of the registers in question.

Note: This fix changes the values returned while reading the LEDs' state
(GPIO6, 25 and 27). Before, they alway reflected the last state written
(LED on or off). Now, they always return '0', unless you set 'in' flag,
upon which it returns always '1'.
The LEDs' current state can't be read back anymore this manner because
these GPIOs do not support the 'inout' flag.

Rolf


--- sys/arch/i386/pci/glxpcib.c.origSat Nov 24 09:21:00 2007
+++ sys/arch/i386/pci/glxpcib.c Tue Mar 18 15:55:51 2008
@@ -291,7 +291,7 @@
u_int32_t data;
int reg;

-   reg = AMD5536_GPIO_OUT_VAL;
+   reg = AMD5536_GPIO_READ_BACK;
if (pin  15) {
pin = 0x0f;
reg += AMD5536_GPIOH_OFFSET;

Regression: Latest i386 Snapshot fails to boot on WRAP, OK on ALIX

[Rolf Sommerhalder]

The kernel 4.3 GENERIC#662 i386 from the latest snapshot fails to
boot on WRAP, whereas it boots fine on ALIX and on other i386
machines. Whereas the kernel from the previous snapshot 4.3
GENERIC#661 i386 boots fine on WRAP and others, such as ALIX.


PC Engines WRAP.1C/1D/1E v1.11
640 KB Base Memory
130048 KB Extended Memory

01F0 Master 044A CF 4GB
Phys C/H/S 7866/16/63 Log C/H/S 983/128/63
Using drive 0, partition 3;
Loading;...
probing: pc0 com0 pci mem[640K 127M a20=on]
disk: hd0
 OpenBSD/i386 BOOT 3.01
-
com0: 38400 baud
switching console to com0
 OpenBSD/i386 BOOT 3.01
boot
booting hd0a:/bsd: 5924880+873540=0x67bdc8
entry point at 0x200120


Console output stops here with GENERIC#662 on WRAP and machine appears
to hang until power cycled.

Regards,
Rolf

Re: Regression: Latest i386 Snapshot fails to boot on WRAP, OK on ALIX

[Rolf Sommerhalder]

 I couldn't find a copy of #662 but I don't see this with #663 on my WRAP...

I confirm that #663 also boots on my WRAP (and it also does on ALIX).

The snapshot with #663 has not yet made it to the mirrors in Europe,
thus I pulled just the kernel file bsd from the fan out server.

Thanks for your heads up,
Rolf

reboot(8) fails on Sun Fire X4100 M2 with latest i386.mp snapshot

[Rolf Sommerhalder]

Hello misc,

after a successful  upgrade of a X4100 M2 to the latest snapshot, the
server fails to reboot after having issued the reboot(8) command as
root. This was working fine before with the snapshot which was from
early December (also i386 .mp, ACPI enabled manually back then, which
is now implicit).

Last output on the console is (which is normal):
syncing disks...done
rebooting...

Then nothing happens until I reset the server manually (from remote
via iLOM). I have not touched /etc/rc.shutdown, e.g. powerdown=NO.

Otherwise, I have not observed any regressions yet, although this
firewall/gateway machine runs a comprehensive collection of interfaces
(trunks, vlans, carps), pf rules, and some proxies as peer in a
cluster. But I'll wait with the upgrade from remote of the other,
primary cluster node until the reboot works :-)

Thanks for any hints what I should try first.

Regards,
Rolf


OpenBSD 4.2-current (GENERIC.MP) #546: Tue Jan 15 12:11:19 MST 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Dual-Core AMD Opteron(tm) Processor 2210 (AuthenticAMD
686-class, 1024KB L2 cache) 1.80 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16
real mem  = 2146979840 (2047MB)
avail mem = 2068090880 (1972MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/11/07, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.3 @ 0xfbd50 (70 entries)
bios0: vendor American Megatrends Inc. version 0ABJX039 date 04/11/2007
bios0: Sun Microsystems Sun Fire X4100 M2
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC SPCR SLIT OEMB HPET IPET SRAT SSDT
acpi0: wakeup devices PS2K(S0) PS2M(S0) USB0(S0) USB1(S0) MAC_(S5)
P0P1(S0) P0P2(S0) P0P3(S0) P0P4(S0) P0P5(S0) IO4B(S0) BR5B(S0)
BR5C(S0) BR5D(S0) BR5E(S0) IOB2(S0) BR2B(S0) BR2C(S0) BR2D(S0)
BR2E(S0) PWRB(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199 MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Dual-Core AMD Opteron(tm) Processor 2210 (AuthenticAMD
686-class, 1024KB L2 cache) 1.80 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16
ioapic0 at mainbus0: apid 15 pa 0xfec0, version 11, 24 pins
ioapic1 at mainbus0: apid 16 pa 0xfeafd000, version 11, 7 pins
ioapic1: misconfigured as apic 0, can't remap to apid 16
ioapic2 at mainbus0: apid 17 pa 0xfeafc000, version 11, 7 pins
ioapic2: misconfigured as apic 1, can't remap to apid 17
ioapic3 at mainbus0: apid 14 pa 0xfeaff000, version 11, 24 pins
acpihpet0 at acpi0: 2500 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus 4 (P0P4)
acpiprt3 at acpi0: bus 5 (P0P5)
acpiprt4 at acpi0: bus 128 (PCIC)
acpiprt5 at acpi0: bus 133 (POGA)
acpiprt6 at acpi0: bus 134 (POGB)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0xa000 0xca000/0x1800 0xcb800/0x1000
0xcc800/0x1000 0xcd800/0x5c00 0xd3800/0x1000
ipmi at mainbus0 not configured
cpu0: PowerNow! K8 1796 MHz: speeds: 1800 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
NVIDIA nForce4 DDR rev 0xa3 at pci0 dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0 NVIDIA nForce4 ISA rev 0xa3
nviic0 at pci0 dev 1 function 1 NVIDIA nForce4 SMBus rev 0xa2
iic0 at nviic0
iic1 at nviic0
iic1: addr 0x18 00=01 01=01 02=00 03=00 words 00=0101 01=0101 02=
03= 04= 05= 06= 07= 08= 09= 0a=
0b= 0c= 0d= 0e= 0f=
iic1: addr 0x19 00=01 01=00 02=00 03=01 words 00=0101 01= 02=
03=0101 04= 05= 06= 07= 08= 09= 0a=
0b= 0c= 0d= 0e= 0f=
iic1: addr 0x1a 02=00 03=00 words 00= 01= 02= 03=
04= 05= 06= 07= 08= 09= 0a= 0b=
0c= 0d= 0e= 0f=
iic1: addr 0x1c 02=00 03=00 words 00= 01= 02= 03=
04= 05= 06= 07= 08= 09= 0a= 0b=
0c= 0d= 0e= 0f=
iic1: addr 0x1d 00=0f 01=0f 02=00 03=00 words 00=0f0f 01=0f0f 02=
03= 04= 05= 06= 07= 08= 09= 0a=
0b= 0c= 0d= 0e= 0f=
iic1: addr 0x1e 01=07 02=00 03=f8 words 00= 01=0707 02=
03=f8f8 04= 05= 06= 07= 08= 09= 0a=
0b= 0c= 0d= 0e= 0f=
admcts0 at iic1 addr 0x2c
admcts1 at iic1 addr 0x2d
iic1: addr 0x48 00=ff 01=00 02=ff 03=ff 04=00 05=00 06=ff 07=ff 08=1b
09=00 0a=4b 10=1b 11=00 12=4b 18=1b 19=00 1a=4b 20=1b 21=00 22=4b
28=1b 29=00 2a=4b 30=1b 31=00 32=4b 38=1b 39=00 3a=4b 3e=1b 40=1b
41=00 42=4b 48=1b 49=00 4a=4b 4e=1b 50=1b 51=00 52=4b 58=1b 59=00
5a=4b 60=1b 61=00 62=4b 68=1b 69=00 6a=4b 70=1b 71=00 72=4b 78=1b
79=00 7a=4b 80=1b 81=00 82=4b 88=1b 89=00 8a=4b 90=1b 91=00 92=4b
98=1b 99=00 9a=4b a0=1b a1=00 a2=4b a8=1b a9=00 aa=4b b0=1b b1=00
b2=4b 

Re: reboot(8) fails on Sun Fire X4100 M2 with latest i386.mp snapshot

[Rolf Sommerhalder]

On Jan 19, 2008 5:04 AM, Jonathan Gray [EMAIL PROTECTED] wrote:
 Try this diff:

Great, that fixed it, thank you.

Now, will you commit it so that it will be included in a next snapshot?

Re: GENERIC -current kernel requires modification to boot on ALIX

[Rolf Sommerhalder]

On Jan 12, 2008 9:01 PM, Jan Stary [EMAIL PROTECTED] wrote:
 I was testing the watchdog-enabled kernel on my ALIX.1C in October for
 Marc Balmer ([EMAIL PROTECTED]) - he's the guy you want to contact.
 ...
 basically, the timer got correctly detected, but didn't really work
 - both before and after upgrading the ALIX firmware.

 I will test again when I get me a new ALIX.2C3 some weeks from now.

After running a few tests with the watchdog on two ALIX2C3, I can
confirm that the hardware watchdog works fine using the GENERIC kernel
from the latest -current snapshot with BIOS 0.99.

To test, I have simpley disabled tickling by the kernel:
  sysctl kern.watchdog.auto=0
The watchdog bites within 30 seconds which is the default
kern.watchdog.period=30

Running the userspace tickler watchdogd, which implicitly disables
kern.watchdog.auto, successfully prevents the watchdog from biting, as
it should be. Thanks to marc@ et al. who implemented  extended
glxpcib for ALIX!

Rolf

GENERIC -current kernel requires modification to boot on ALIX

[Rolf Sommerhalder]

Hello,

I found that GENERIC -current (from latest snapshot) fails to boot on
ALIX (see A) below), whereas the same kernel boots fine on WRAP. For
my tests, I simply swap the same 1GB CF card, from the WRAP to ALIX on
which I installed OpenBSD from the latest snapshots.

After disabling 'pciglxb' in the kernel however, the same CF card
boots fine on the ALIX (see B) below) as well as on WRAP:
 config -ef /bsd
 disable glxpcib
 quit
 reboot

Earlier, I have made the same observation while building a custom
kernel using the flashboot enviroment.  As a result, no watchdog time
is available, for example.

I found this while moving my SOHO firewall cluster  from two old Nokia
IP120 which boot OpenBSD from harddisks to two ALIX boards from PC
Engines which boot off solid-state CF cards. In order to preserve the
CF card, I have modified it so that /tmp, /var and /dev are mounted
read-write to RAM (mfs), and the remaining file systems are mounted
read-only (e.g. running from CF card).

I do not yet understand if the problem comes from the timer / watchdog
/ GPIO which glxpcib activates, or if I should try to do a BIOS
upgrade of the ALIX board to the latest revision.

Has anyone experience the same? How did you solve it? Any suggestions
what I should try next?

Thanks,
Rolf


A) Console output when booting unmodified GENERIC -current kernel

PC Engines ALIX.2 v0.98
640 KB Base Memory
261120 KB Extended Memory

01F0 Master 848A SanDisk SDCFH-1024
Phys C/H/S 1986/16/63 Log C/H/S 993/32/63
Using drive 0, partition 3;
Loading;...
probing: pc0 com0 pci mem[640K 255M a20=on]
disk: hd0
 OpenBSD/i386 BOOT 3.01
-
com0: 38400 baud
switching console to com0

[ using 593308 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights
reserved.
Copyright (c) 1995-2008 OpenBSD. All rights reserved.
http://www.OpenBSD.org

OpenBSD 4.2-current (GENERIC) #647: Fri Jan 11 02:06:06 MST 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
RTC BIOS diagnostic error 80clock_battery
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  = 268009472 (255MB)
avail mem = 251240448 (239MB)
RTC BIOS diagnostic error 80clock_battery
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/31/07, BIOS32 rev. 0 @
0xfcdda
acpi at bios0 function 0x0 not configured
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/0xb000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31
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:12:6c:10
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:12:6c:11
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 12,
address 00:0d:b9:12:6c:12
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ral0 at pci0 dev 12 function 0 Ralink RT2561 rev 0x00: irq 9,
address 00:08:a1:9c:32:c4
ral0: MAC/BBP RT2661B, RF RT2527
glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 0,
32-bit 3579545Hz timer


B) dmesg after modification of kernel by running 'config -ef /bsd',
'disable pciglxb', 'quit'

[EMAIL PROTECTED]:root]# dmesg
OpenBSD 4.2-current (GENERIC) #647: Fri Jan 11 02:06:06 MST 2008
[EMAIL PROTECTED]:/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  = 268009472 (255MB)
avail mem = 251240448 (239MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/31/07, BIOS32 rev. 0 @ 0xfcdda
acpi at bios0 function 0x0 not configured
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/0xb000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31
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:12:6c:10
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:12:6c:11
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, 

Re: GENERIC -current kernel requires modification to boot on ALIX

[Rolf Sommerhalder]

On Jan 12, 2008 1:11 PM, Rolf Sommerhalder
[EMAIL PROTECTED] wrote:
 I do not yet understand if the problem comes from the timer / watchdog
 / GPIO which glxpcib activates, or if I should try to do a BIOS
 upgrade of the ALIX board to the latest revision.

The problem seems to occurs while the function glxpcib_attach() in
src/sys/arch/i386/pci/glxpcib.c attaches the watchdog timer.  If I
comment out the lines

/* count in seconds (as upper level desires) */
 // bus_space_write_2(sc-sc_iot, sc-sc_ioh, AMD5536_MFGPT0_SETUP,
 // AMD5536_MFGPT_CNT_EN | AMD5536_MFGPT_CMP2EV |
 // AMD5536_MFGPT_CMP2 | AMD5536_MFGPT_DIV_MASK);
 // wdog_register(sc, glxpcib_wdogctl_cb);
printf(, watchdog);

then all is well, except that the watchdog does not get its hardware
time, of course. The GPIO part attaches fine and I can toggle LEDs
using gpioctl.

Only commenting out the wdog_register() call, but leaving the call to
bus_space_write_2() active makes boot still stop. So the problems
appears to be with the call to bus_space_write_2().

Who is familiar with this function and the AMD5536?

Thanks,
Rolf

Re: GENERIC -current kernel requires modification to boot on ALIX

[Rolf Sommerhalder]

On Jan 12, 2008 5:00 PM, Rolf Sommerhalder
[EMAIL PROTECTED] wrote:
 The problem seems to occurs while the function glxpcib_attach() in
 src/sys/arch/i386/pci/glxpcib.c attaches the watchdog timer.  If I
 comment out the lines

Upgrading the ALIX firmware from 0.98 to the latest BIOS v0.99 solved
the problem!

My appologies for the noise. But maybe the archive may preventing
others to pull their hair out in the future :-)

Also, note that it took me quite a while to figure out why my attempts
to upgrade via the Xmodem procedure failed. According to the readme in
the firmware .zip archive, PC Engines has not ported the Xmodem flash
upgrade option yet.
Thus you need to image a CF card with FreeDOS, as PC Engine's Web page
mentions, boot ALIX under FreeDOS, and then finally run sb.com which
updates the firmware.

Good luck,
Rolf

Re: Need some guidance booting OpenBSD on an ALIX device

[Rolf Sommerhalder]

 Any other suggestion ?
It looks as if your ALIX booted through all stages and successfully
loaded the kernel /bsd, but fails to start this kernel. Maybe check
out http://www.openbsd.org/faq/faq14.html#Boot386 , notably item 4.,
to help with diagnosis and repair.

Are you sure that the kernel /bsd on your CF card is ok?  I would try
and replace it temporarily by /bsd from the current snapshot.

Also, I notice that your ALIX is still running BIOS 0.98. My own
experience from today showed that the GENERIC -current stock kernel
will fail at least ltaer on in the process when glxpcib detects the
AMD5536 PCI bridge and tries to start the hardware timer which is then
assigned to the watchdog. Upgrading the BIOS to the latest version
0.99 solved the problem for me just two hours ago, see my three
consecutive posts from earlier today.

Regards,
Rolf

Re: Need some guidance booting OpenBSD on an ALIX device

[Rolf Sommerhalder]

On Jan 12, 2008 10:44 PM, Limaunion [EMAIL PROTECTED] wrote:
 Well, I finally got it booting. As suggested I upgraded the BIOS to
 release 0.99 and configured the device to work at 9k6bps.
 Now the problem is that it gets stuck just before having the login
 prompt, after printing the date and time, any idea ?

Great - I guess that in your /etc/ttys the line or tty00 does not read yet like:

tty00   /usr/libexec/getty std.9600   vt220on secure

Re: Need some guidance booting OpenBSD on an ALIX device

[Rolf Sommerhalder]

On Jan 12, 2008 10:44 PM, Limaunion [EMAIL PROTECTED] wrote:
 OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007

Also note that you are using a kernel that is over four months old and
it obviously does not yet contain the extensions that were added to
glxpcib(4) to support the hardware timer for watchdogd, and the GPIO
pins (see gpioctl(8) to control the LEDs, for example) , or security
block acceleration glxsb(4).

So maybe you want to upgrade the system on your CF card to the
-current snapshot to be able to use these features.

For reference, here is the dmesg of my ALIX that runs the latest snapshot:

OpenBSD 4.2-current (GENERIC) #647: Fri Jan 11 02:06:06 MST 2008
[EMAIL PROTECTED]:/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  = 268009472 (255MB)
avail mem = 251240448 (239MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2
acpi at bios0 function 0x0 not configured
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
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31
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:12:6c:10
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:12:6c:11
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 12,
address 00:0d:b9:12:6c:12
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ral0 at pci0 dev 12 function 0 Ralink RT2561 rev 0x00: irq 9,
address 00:08:a1:9c:32:c4
ral0: MAC/BBP RT2661B, RF RT2527
glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 0,
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: SanDisk SDCFH-1024
wd0: 4-sector PIO, LBA, 977MB, 2001888 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 15,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 15
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
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1
biomask e1ef netmask ffef ttymask ffef
mtrr: K6-family MTRR support (2 registers)
nvram: invalid checksum
softraid0 at root
root on wd0a swap on wd0b dump on wd0b

Running dhclient on CARP interfaces

[Rolf Sommerhalder]

While trying to transpose a working two-stage active-passive
firewall from an enterprise network with a _fixed_ public Internet
address to a much smaller home setup that must live with a _dynamic_
public IP address assigned by the DHCP server of my ISP, I observe
that running dhclient(8) on carp(4) interface does not work as
expected:

[EMAIL PROTECTED]:root]# ifconfig carp11 carpdev fxp0 vhid 11 up
[EMAIL PROTECTED]:root]# ifconfig carp11
carp11: flags=8803UP,BROADCAST,SIMPLEX,MULTICAST mtu 1500
lladdr 00:00:5e:00:01:0b
carp: INIT carpdev fxp0 vhid 11 advbase 1 advskew 0
groups: carp
inet6 fe80::200:5eff:fe00:10b%carp11 prefixlen 64 scopeid 0x8
[EMAIL PROTECTED]:root]# ifconfig fxp0
fxp0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
lladdr 00:20:e0:68:fe:6c
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::220:e0ff:fe68:fe6c%fxp0 prefixlen 64 scopeid 0x1
inet 10.0.0.201 netmask 0xff00 broadcast 10.0.0.255

[EMAIL PROTECTED]:openvpn]# dhclient carp11
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 2
send_packet: Network is unreachable
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 2
send_packet: Network is unreachable
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 2
send_packet: Network is unreachable
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 2
send_packet: Network is unreachable
^C


It appears that dhclient does not like the fact that carp11 is in INIT
state. Try a naive work-around and bring carp11 into MASTER state by
assigning an fixed alias IP address to it:

[EMAIL PROTECTED]:root]# ifconfig carp11 1.2.3.4 netmask 255.255.255.0 up
[EMAIL PROTECTED]:root]# ifconfig carp11
carp11: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:00:5e:00:01:0b
carp: BACKUP carpdev fxp0 vhid 11 advbase 1 advskew 0
groups: carp
inet6 fe80::200:5eff:fe00:10b%carp11 prefixlen 64 scopeid 0x8
inet 1.2.3.4 netmask 0xff00 broadcast 1.2.3.255

[EMAIL PROTECTED]:root]# dhclient carp11
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 1
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on carp11 to 255.255.255.255 port 67 interval 16
^C

[EMAIL PROTECTED]:root]#  tcpdump -i fxp0 -n port 67 or port 68
tcpdump: listening on fxp0, link-type EN10MB
12:40:57.000270 0.0.0.0.68  255.255.255.255.67: xid:0xf2d76fa5 ether
00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:40:57.031501 10.0.0.2.67  10.0.0.202.68: xid:0xf2d76fa5
Y:10.0.0.202 S:10.0.0.4 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:40:58.011180 0.0.0.0.68  255.255.255.255.67: xid:0xf2d76fa5 secs:2
ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:40:58.019206 10.0.0.2.67  10.0.0.202.68: xid:0xf2d76fa5 secs:2
Y:10.0.0.202 S:10.0.0.4 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:00.017143 0.0.0.0.68  255.255.255.255.67: xid:0xf2d76fa5 secs:4
ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:00.020060 10.0.0.2.67  10.0.0.202.68: xid:0xf2d76fa5 secs:4
Y:10.0.0.202 S:10.0.0.4 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:05.027505 0.0.0.0.68  255.255.255.255.67: xid:0xf2d76fa5 secs:9
ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:05.036755 10.0.0.2.67  10.0.0.202.68: xid:0xf2d76fa5 secs:9
Y:10.0.0.202 S:10.0.0.4 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:13.038056 0.0.0.0.68  255.255.255.255.67: xid:0xf2d76fa5
secs:17 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:13.053316 10.0.0.2.67  10.0.0.202.68: xid:0xf2d76fa5 secs:17
Y:10.0.0.202 S:10.0.0.4 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:24.048927 0.0.0.0.68  255.255.255.255.67: xid:0xf2d76fa5
secs:28 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
12:41:24.057559 10.0.0.2.67  10.0.0.202.68: xid:0xf2d76fa5 secs:28
Y:10.0.0.202 S:10.0.0.4 ether 00:00:5e:00:01:0b [|bootp] [tos 0x10]
^C
218 packets received by filter
0 packets dropped by kernel

The DHCP server (dhcpd) at 10.0.0.2 replies and assigns the dynamic
address 10.0.0.202 to the requesting client. However, dhclient on
carp11 apparently does never get it.

Additional info:
- The firewall clusters at work and at home both run i486-current;
- The setup works fine if a fixed IP address is staically assigned to
the CARP interface;
- Searching the archives showed that others also stumbled across this
difficulty earlier.
  http://archives.neohapsis.com/archives/openbsd/2005-11/2665.html
- Apparently, one solution was to write some scripts that bring
dhclient up and down whenever one of the cluster's external interfaces
goes up or down, eventually using ifstated(8). In response to
 http://undeadly.org/cgi?action=articlesid=20071012140725mode=expanded
someone offered his scripts to what seems to 

Re: Running dhclient on CARP interfaces

[Rolf Sommerhalder]

The really cool combination of CARP and ifstated enabled a nice
work-around. The attached ifstated.conf works great in my
active-passive firewall cluster setup. At least it survived all
violent testing conducted over the past few hours. But it still needs
to prove itself in the longer term.

Actually, this solution does more than simply running dhclient on CARP
would do. With one exception: I could not you figure out how to
transition from a passive-active firewall cluster to an active-active
configuration without having a CARP interface with a dynamic IP
address that connects to the ISP. Therefore, I would still be
interested in getting dhclient to work on a CARP interface.

Also, I welcome your feedback about the solution outlined below.

Thanks,
Rolf


A few remarks on the ifstated.conf shown below:
a) vlan11 is a VLAN bound to the same NIC as carp12. dhclient is run
on vlan11 (Actually, carp12 is bound to vlan11, which in turn is bound
to the physical NIC liniking to upstream).. dhclient assigns the
dynamic IP address to vlan11 whenever a node of a cluster is in master
state. Nodes in backup state kill dhclient, delete the dynamic IP
address from their vlan11, change the default route from the ISP
router to the firewall's virtual cluster address (which is here
carp100 = 10.0.0.1) and kill and restart some daemons with some
modified parameters:
- dhcpd runs only on the master node;
- ntpd pn the backup node(s) get their time reference from the master
node, to avoid doubling the load on external time servers;
- only one ez-ipupdate instance running on the master node takes care
of updating my dynamic DNS service provider;

b) carp12 is a CARP interface on the same NIC that connects to the ISP
modem. carp12 is bound to a fixed IP address. The ifstated
configuration below uses it just for detecting the state(-changes) of
the upstream link, e.g. it is not the CARP interface I would like to
run dhclient on (which would be carp11).

c) You can replace vlan11 by any other vlan, or by a phsyical
interface, such as fxp2 for example. You can replace carp12 by any
other CARP interface as long as it is a reliable state indicator of
each node in the cluster.


[EMAIL PROTECTED]:root]# cat /etc/ifstated.conf
init-state startState

carpUp = carp12.link.up
carpDown = !carp12.link.up

state startState {
 if $carpUp
  set-state masterState
 if $carpDown
  set-state backupState
}

state masterState {
 init {
  # assert services are killed to avoid duplicates in case the were still up,
  # for ex. after a restart of ifstated restart while masterState was never left
  run /usr/bin/pkill -9 ntpd
  run /usr/bin/pkill -9 dhcpd
  run /usr/bin/pkill -9 ez-ipupdate
  run /usr/bin/pkill -9 dhclient

  run /sbin/dhclient vlan11
  run /usr/local/bin/ez-ipupdate -c /etc/ez-ipupdate.conf
  run /usr/sbin/dhcpd
  #run /usr/sbin/ntpd -s -f /etc/ntpd_masterState.conf
  run /usr/sbin/ntpd -f /etc/ntpd_masterState.conf
 }
 if $carpDown set-state backupState
}

state backupState {
 init {
  run /usr/bin/pkill -9 ntpd
  run /usr/bin/pkill -9 dhcpd
  run /usr/bin/pkill -9 ez-ipupdate
  run /usr/bin/pkill -9 dhclient

  run /sbin/ifconfig vlan11 delete
  run /sbin/route change default 10.0.0.1
  #run /usr/sbin/ntpd -s -f /etc/ntpd_backupState.conf
  run /usr/sbin/ntpd -f /etc/ntpd_backupState.conf
 }
 if $carpUp set-state masterState
}

Re: How to track down a suspected memory leak?

[Rolf Sommerhalder]

On Nov 25, 2007 5:22 PM, David Higgs [EMAIL PROTECTED] wrote:
 Is this possibly the same memory leak mentioned below?

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

Thanks for your pointer! Indeed, this patch/errata appears to have
sqashed the memory leak. A patched kernel did not loose memory since
Monday anymore.

Thanks again,
Rolf

Re: How to track down a suspected memory leak?

[Rolf Sommerhalder]

On Nov 25, 2007 5:22 PM, David Higgs [EMAIL PROTECTED] wrote:

 Is this possibly the same memory leak mentioned below?

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

Thanks David for this pointer. It may very well be the same issue.
Even though the two bridged interfaces are em(4) (1 Gb/s), the
Out-of-Band Management (OOBM) interface is fxp(4) that carries two
VLANs, one for pfsync(4), and one for commandcontrol/monitoring.

Interestingly, I observe memory depletion at the same rate on both
nodes of these active-passive filtering bridge clusters (both the
sparc64 and i386), e.g. free memory on the passive bridge depletes at
the same rate as on the one that is active. This may hint that the
problem is rather with the fxp(4) than with the em(4) which are
bridged. Unless it is somehow related to Rapid Spanning Tree (RSTP)
which is running on both the internal and external em(4)s on both the
active and the passive node.

Maybe it's worth mentioning that on the previous sparc64 platforms
(Sun Blade 100), where I observed slow memory depletion first, the
bridging was between two ports of a quad hme(4) NIC, and the OOBM was
on a third port of the same quad NIC.

Still, I will given Henning's patch a try, while waiting for results
of the instrumentation with 'vmstat -m', as suggested by the previous
responder.

Thanks again,
Rolf




[EMAIL PROTECTED]:home]# ifconfig
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33208
groups: lo
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0c:fa:d6
description: brExt_InternetEx
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::210:f3ff:fe0c:fad6%em0 prefixlen 64 scopeid 0x1
em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0c:fa:d7
description: brInt_InternetInt
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::210:f3ff:fe0c:fad7%em1 prefixlen 64 scopeid 0x2
fxp0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0c:fa:d8
media: Ethernet autoselect (none)
status: no carrier
fxp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0c:fa:d9
description: VLAN trunk OOBMgtExt, brSync
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::210:f3ff:fe0c:fad9%fxp1 prefixlen 64 scopeid 0x4
enc0: flags=0 mtu 1536
vlan21: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0c:fa:d9
description: brSync
vlan: 21 priority: 0 parent interface: fxp1
groups: vlan
inet6 fe80::210:f3ff:fe0c:fad9%vlan21 prefixlen 64 scopeid 0x7
inet 192.168.7.13 netmask 0xff00 broadcast 192.168.7.255
vlan71: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0c:fa:d9
description: OOBMgtExt
vlan: 71 priority: 0 parent interface: fxp1
groups: vlan egress
inet6 fe80::210:f3ff:fe0c:fad9%vlan71 prefixlen 64 scopeid 0x8
inet 172.16.71.13 netmask 0xff00 broadcast 172.16.71.255
pfsync0: flags=41UP,RUNNING mtu 1460
description: pfSync
pfsync: syncdev: vlan21 syncpeer: 224.0.0.240 maxupd: 128
groups: carp pfsync
bridge0: flags=41UP,RUNNING mtu 1500
groups: bridge
pflog0: flags=141UP,RUNNING,PROMISC mtu 33208
groups: pflog
[EMAIL PROTECTED]:home]#

bridge0: flags=41UP,RUNNING
priority 28672 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
em1 flags=cbLEARNING,DISCOVER,STP,PTP,AUTOPTP
port 2 ifpriority 128 ifcost 2 forwarding role designated
em0 flags=cfLEARNING,DISCOVER,BLOCKNONIP,STP,PTP,AUTOPTP
port 1 ifpriority 128 ifcost 2 forwarding role root
Addresses (max cache: 100, timeout: 240):
00:00:5e:00:01:0b em1 1 flags=0
00:11:20:2f:09:54 em0 1 flags=0
00:1d:46:97:5f:0d em1 1 flags=0
00:1d:46:97:5f:03 em0 1 flags=0
[EMAIL PROTECTED]:home]#

[EMAIL PROTECTED]:home]# dmesg
OpenBSD 4.2-current (GENERIC) #476: Fri Nov  2 14:41:26 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.80 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,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 1072197632 (1022MB)
avail mem = 1028968448 (981MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/29/06, BIOS32 rev. 0 @
0xfb250, SMBIOS rev. 2.2 @ 0xf0800 (34 entries)
bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 06/29/2006
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery 

IP over Simulated Radio/Satellite Channels

[Rolf Sommerhalder]

In an effort to port a Performance Enhancing Proxy (PEP, see scps.org)
to OpenBSD, I am looking at ways to simulate radio channels at IP
level with loss rate, delay and jitter. Has anyone worked on, for
example, extending ALTQ to add delay and/or jitter capability to
OpenBSD?  Would I waste my time diving into the source of ALTQ?

Two years back, I wrote an extension plugin for m0n0wall.ch which uses
ipfw and dummynet in FreeBSD for traffic shaping. Actually, dummynet
started off as an IP channel simulator that provides delay and jitter
options besides loss rate, and then was also used for shaping/queuing.

A search of the archives revealed that others asked also about
extended IP channel simulation in OpenBSD. But I could not find
anything ready to use yet. OpenBSD's IP stack parameter setting for
high bandwidth-delay satellite channels were apparently tested using
externally supplied simulation data.

Apparently, others also worked on porting the SCPS (TP?) PEP to
OpenBSD, but I am unclear if they ever succeeded to make it work, and
if they published their work.

I am grateful for any pointers towards IP channel simulation and/or
PEPs such as SCPS TP in OpenBSD.

Thanks,
Rolf

How to track down a suspected memory leak?

[Rolf Sommerhalder]

Hello list,

I am looking for suggestions how to identify the source(s) of what
appears to be a memory leak of approx. 10 MByte/day on a clustered
pair of filtering bridges. These bridges are running i386 -current
snapshot from Nov 2nd. They form outer, Internet-facing stage of a two
stage firewall in an enterprise setup.

Before we received two new i386 servers, the same setup was running on
two sparc64 servers with a snapshot about one month old. Back then, I
observed the same steady decrease of memory, graphing trends using
net-snmp and Cacti. Those old sparc64 servers only had 192 MByte of
RAM, they ran out of memory and stopped working after 10 days or so.
As I had some difficulties to get net-snmp to run at all on sparc64
(see patch posted to this list earlier), I was hoping to get away from
this apparent memory leak once I migrate to to newer i386 servers.

After the migration from sparc64 to i386, indeed the memory consumed
during the first few days remained constant. Thereafter however, the
steady decrease of free memory also started to appear on the i386 much
like with the sparc64. I disabled all SNMP GET operations for a few
hours, just to see if the leak might be caused by net-snmp, but the
leakage continues during this time too. Staring at the output of
'systat vmstat' etc. did not help either.

The pragmatic work-around for the moment is cron job that reboots each
of the cluster nodes once a week. There is is enough headroom with 1
GByte of RAM on these i386 servers. The two cluster nodes reboot at
different times, so the service is interrupted only for a few seconds
until rapid spanning tree completes fail-over.

At the moment, on a much smaller scale, I replicate such a two stage
clustered firewall setup for home use. based on OpenBSD flashboot,
WRAP / ALIX boards from PCengines and surplus Nokia IP120s which I
converted to OpenBSD. Also because the WRAPs have only 128 MByte of
RAM, I very much like to get to the root cause of that apparent memory
leak in my clustered filtering bridge configuration. I am grateful for
any hints and suggestions how to track it down.

Thanks,
Rolf

Re: hoststated(8): DNS Relay uses unexpected source IP address

[Rolf Sommerhalder]

On Nov 19, 2007 6:35 PM, Reyk Floeter [EMAIL PROTECTED] wrote:
 please try to configure the following:
...
 so the proposed solution is to always use listen on 0.0.0.0 port 53
 with DNS relays for now.

Your proposal indeed solves the problem in my multi-homed setup, and
makes my work-around with source NAT rule obsolete! Thank you very
much.

In the long run, would it be feasible to extend relay_udp_bind() so
that its binds to the IP address of
the interface to which it will relay those DNS UDP packets (while also
observing the default route)?
Could this eliminate the implicit use of spoofed sender IP addresses
by the DNS relay on multi-homed hosts, without adding any knobs?

Rolf

hoststated(8): DNS Relay uses unexpected source IP address

[Rolf Sommerhalder]

Hello list,

using the excellent hoststated(8), I have build a reverse proxy
yellow with the snapshot from around November 3rd on an i386 box
which is connected to white (another OpenBSD host) on the left via
fxp2, and to orange (a Linux host) to its right via fxp3.
(white.fxp3) and (fxp2.yellow) are in subnet 10.1.1.0/24, whereas
(yellow.fxp3) and (eth0.orange) are in 10.2.2.0(24.

...---tun0.white.fxp3---fxp2.yellow.fxp3---eth0.orange

hoststated on yellow has several relays that listen on various ports
on its right (fxp3) and relays them via (fxp2) to left to white,
such as for ex. (fxp3):6000/tcp  (for X11 relaying using the generic
TCP relay), or (fxp3):53/udp (for DNS relaying using the DNS/UDP
relay). When orange issues X11 connections from its (eth0.orange) to
(yellow.fxp3), yellow relays those connections perfectly to white
using (fxp2.yellow) as source and (white.fxp3) as destination
addresses. This also works fine for all other TCP relays that I tried.

However, the UDP/DNS relay behaves slightly different. It relays DNS
request to the left with (yellow.fxp3) (note: fxpTHREE) as source
address, unlike TCP relays and not as I had expected, with
(fxp2.yellow) (note: fxpTWO) as source address.
Yet, I am not sure if this is intended behaviour, or a bug that
surfaces with my particular use of hoststated to insulating two
subnetworks.

This unexpected behaviuor of the DNS/UDP relay then causes routing
problems as the white server is by default unaware of a route for
the source address (yellow.fxp3). So DNS responses from white do not
get routed back to yellow. Of course, I could add a route on white
as a workaround. But it would be more elegant if the DNS/UDP relay
would behave the same way as the TCP relays do. In order to figure out
if I misunderstand this, I have started to read the source of
relay_dns_request() in /src/usr.sbin/hoststated/relay_udp.c of
-current. I am grateful for any hints with the cluestick. Also, I am
happy to provide more info, or to apply and test patches.

Thanks,
Rolf

P.S. For those who wonder what this is all about, orange is an
application server in a secure zone, and we need to get data across
two security boundaries safely to white, which is in fact a VPN
tunnel endpoint in a less secure zone. The --- in the figure above
are actually large networks that are separated by firewalls. However,
in my lab setup these are simple cross-over Ethernet cables :-)

[EMAIL PROTECTED]:etc]# dmesg
OpenBSD 4.2-current (GENERIC) #476: Fri Nov  2 14:41:26 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Mobile Intel(R) Celeron(TM) CPU 650MHz (GenuineIntel 686-class) 647 MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem  = 519602176 (495MB)
avail mem = 494592000 (471MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/30/04, BIOS32 rev. 0 @
0xfb470, SMBIOS rev. 2.2 @ 0xf0800 (38 entries)
bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 11/30/2004
bios0: VIA Technologies, Inc. CLE266-8233/5


[EMAIL PROTECTED]:etc]# ifconfig
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33208
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
inet 127.0.0.1 netmask 0xff00
fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0d:32:6d
description: OOBM
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::210:f3ff:fe0d:326d%fxp0 prefixlen 64 scopeid 0x1
inet 172.16.70.31 netmask 0xff00 broadcast 172.16.70.255
fxp1: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0d:32:6e
media: Ethernet autoselect (none)
status: no carrier
fxp2: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0d:32:6f
description: to white/fxp3
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::210:f3ff:fe0d:326f%fxp2 prefixlen 64 scopeid 0x3
inet 10.1.1.31 netmask 0xff00 broadcast 10.1.1.255
fxp3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:10:f3:0d:32:70
description: to orange/eth1
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::210:f3ff:fe0d:3270%fxp3 prefixlen 64 scopeid 0x4
inet 10.2.2.31 netmask 0xff00 broadcast 10.2.2.255
enc0: flags=0 mtu 1536
pflog0: flags=141UP,RUNNING,PROMISC mtu 33208
groups: pflog
[EMAIL PROTECTED]:etc]#


[EMAIL PROTECTED]:etc]# cat /etc/hoststated.conf
# Macros

# proxies listen on
yellow=10.2.2.31

# and relay traffic to VPN Tunnel endpoint
white=10.1.1.30

sshHost=10.2.90.3
dnsHost=10.2.90.1
x11Host=10.2.90.3


# Global Options

log updates
prefork 1
interval 10 # run check every N seconds
timeout 4000 # global timeout in milliseconds 

Re: hoststated(8): DNS Relay uses unexpected source IP address

[Rolf Sommerhalder]

On Nov 17, 2007 4:01 PM, Rolf Sommerhalder
[EMAIL PROTECTED] wrote:

 This unexpected behaviuor of the DNS/UDP relay then causes routing
 problems as the white server is by default unaware of a route for
 the source address (yellow.fxp3). So DNS responses from white do not
 get routed back to yellow. Of course, I could add a route on white
 as a workaround. But it would be more elegant if the DNS/UDP relay
 would behave the same way as the TCP relays do. In order to figure out

As an alternate work-around, I just tried to insert a source NAT rule
in /etc/pf.conf on yellow, which masks/solves the routing problem
locally on the reverse proxy machine:

[EMAIL PROTECTED]:etc]# cat /etc/pf.conf
# source NAT for routing back from white for DNS only
nat log on fxp2 from 10.2.2.31 to 10.1.1.30 port 53 - (fxp2)

Probably, I should add at least static-port to the NAT rule above in
order to prevent white from modifying the source port 53 (see
tcpdump below).

Still, I am unsure if the DNS/UDP relay actually behaves correctly,
and if this work-around does make sense.

Rolf


A) DNS/UDP Example reloaded, now with source NAT on yellow

Output of hoststated -v -d after issuing a DNS lookup on orange:

relay_dns_log: session 1: request id 0xde7 flags 0x1:0x0 qd 1 an 0 ns 0 ar 0
relay_dns_log: session 1: response id 0x9cc flags 0x85:0x80 qd 1 an 1 ns 1 ar 0
relay dnsRelay, session 1 (1 active), 10.2.2.32 - 10.1.1.30:53, session closed

hostated listens on the right NIC fxp3:

[EMAIL PROTECTED]:root]# tcpdump -i fxp3 -n
tcpdump: listening on fxp3, link-type EN10MB
16:45:19.718243 arp who-has 10.2.2.31 tell 10.2.2.32
16:45:19.718274 arp reply 10.2.2.31 is-at 00:10:f3:0d:32:70
16:45:19.718461 10.2.2.32.32768  10.2.2.31.53: 3559+ A? orange. (36) (DF)
16:45:19.720859 10.2.2.31.53  10.2.2.32.32768: 3559* 1/1/0 A 172.16.70.32 (69)

hostated passes on the proxied requets to the left NIC fxp2, using the
source address (fxp2)=10.1.1.31, as forced by source NAT:

[EMAIL PROTECTED]:root]# tcpdump -i fxp2 -n
tcpdump: listening on fxp2, link-type EN10MB
16:48:57.815366 10.1.1.31.51245  10.1.1.30.53: 65223+ A? orange. (36)
16:48:57.816452 10.1.1.30.53  10.1.1.31.51245: 65223* 1/1/0 A 172.16.70.32 (69)

Re: hoststated(8): DNS Relay uses unexpected source IP address

[Rolf Sommerhalder]

On Nov 17, 2007 4:58 PM, Rolf Sommerhalder
[EMAIL PROTECTED] wrote:

 Still, I am unsure if the DNS/UDP relay actually behaves correctly,
 and if this work-around does make sense.

After a deep dive into the sources of hoststated, my current
understanding is that this is not a problem caused by hoststated
itself, but rather how the underlaying IP stack determines the source
IP address of a UDP packet when the server is multi-homed.

relay_dns_request() in src/usr.sbin/hoststated/relay_udp.c calls
sendto() with the correct destination IP. However, the source IP
address can not be passed to sendto().

Are there facilities to set the source address for UDP packets sent
from a multi-homed server?

Re: hoststated(8): DNS Relay uses unexpected source IP address

[Rolf Sommerhalder]

On Nov 18, 2007 8:04 AM, Theo de Raadt [EMAIL PROTECTED] wrote:
 Oh, one does that by calling bind() beforehands, with the specific
 local address one which uses use, instead of 0.0.0.0.  With udp this

Thanks Theo for your hint. I look into this in the context of hoststated.

What still puzzles me is that my multi-homed server sends out UDP
packets on interface fxp2=10.1.1.31 with source IP address of another
interface, e.g. fxp3=10.2.2.31.  Therefore, I'll take a look at
bind(2) and sendto(2) now, maybe this helps to solve my confusion
(poured too much Kirsch into the cheese fondue last night ;-).

By the way, googling with Set source address for UDP packets from
multihomed server brought up some interesting discussions in other
contexts, such as OpenVPN, bind or ntpd.

Re: iSCSI

[Rolf Sommerhalder]

 A quick Google search shows some people having success in porting NetBSD's
 iSCSI to OpenBSD.

perhaps Marco will chime in on this.

diana

If testers for an iSCSI initiator on OpenBSD should be needed, I am
glad to help out. I run i386.mp-current and sparc64-current on servers
that can access two iSCSI IP arrays from EqualLogic (3 and 7 TB), and
a homebrew iSCSI target array (2.3 TB) running FreeNAS, over
GigEthernet with Jumbo frame and (partial) multipath I/O support..

Rolf

hoststated: throws Undefined error: 0 in i386 -current

[Rolf Sommerhalder]

This simple configuration file for hoststated below is syntactically
correct (and semantically, too), however apparently only if its file
mode bits are 600 (which makes sense).

Somehow, I ended up with mode bits being set to 644, upon which
hoststated refused to accept it but throws an Undefined error: 0.
It took me a while to figure out that it occurs due to mode bits being
set somewhat too liberal because the error does not provide any hint.
Also, I only upgraded to -current last night, and the same
configuration file was accepted with mode bits 644 by the latest
available snapshot without complaint before upgrading.

Actually, I just tried 'hoststated -d -f /etc/hoststated.rs' which
throuws the same error, but only after hinting about the mode bits
being wrong. So it might be helpful to just add the same hint output
to the -n option as well.

I had no opportunity to crosscheck on sparc64 -current yet, or to
propose a small diff, sorry for that.

Thanks,
Rolf


[EMAIL PROTECTED]:root]# cat /etc/hoststated.rs
extAddr=1.2.3.4

table rsHosts {
 real port http
 check icmp
 host 10.2.90.3
}

service rsService {
 virtual host $extAddr port 80 interface carp11
 table rsHosts
}
[EMAIL PROTECTED]:root]# ls -al /etc/hoststated.rs
-rw---  1 root  wheel  170 Oct 18 20:42 /etc/hoststated.rs
[EMAIL PROTECTED]:root]# hoststated -n -f /etc/hoststated.rs
configuration OK
[EMAIL PROTECTED]:root]# chmod 644 /etc/hoststated.rs
[EMAIL PROTECTED]:root]# hoststated -n -f /etc/hoststated.rs
hoststated: /etc/hoststated.rs: Undefined error: 0
[EMAIL PROTECTED]:root]# hoststated -d -f /etc/hoststated.rs
/etc/hoststated.rs: group/world readable/writeable
hoststated: /etc/hoststated.rs: Undefined error: 0
[EMAIL PROTECTED]:root]# dmesg
OpenBSD 4.2-current (GENERIC.MP) #5: Thu Oct 18 06:00:11 CEST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Dual-Core AMD Opteron(tm) Processor 2210 (AuthenticAMD
686-class, 1024KB L2 cache) 1.80 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16
real mem  = 2146979840 (2047MB)
avail mem = 2068201472 (1972MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/11/07, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.3 @ 0xfbd50 (70 entries)
bios0: vendor American Megatrends Inc. version 0ABJX039 date 04/11/2007
bios0: Sun Microsystems Sun Fire X4100 M2
...

dmesg of i386 on Virtual Iron 4.0.5

[Rolf Sommerhalder]

Virtual Iron (VI) is a commercial virtualisation product based on Xen
3.1 dom0 which boots unmodified bsd.rd i386 and installs in a domU. As
you can see from the dmesg below, it occasionally complains about
timeouts on re0, and the virtual console gets cluttered in the later
stages of the install. Other than that, login into sshd on the virtual
OpenBSD box works, although I have not done exhaustive tests regarding
stability nor performance.

So far, I had no success in booting bsd.mp, however. Even after
 set image bsd.mp
 boot -c
 disable apm
 enable acpi
 exit
bsd.mp stops after printing nvram: invalid checksum.

When leaving the defaults (e.g. apm enabled and acpi disabled), bsd.mp
stops just after printing this, followed by
apm0: APM system defaults failed: unknown error code? (83)
apm0: disconnected

If someone is interested in having a closer look, then I will try to
make transcripts from the virtual console (or screenshots).

VI 4.0 was released last week. Even if it officially supports only a
handful of selected guest OS as of now, and there no VI Tools
available for OpenBSD (yet - source is available), I gave it a try on
virtualized Sun Fire X4600 M2 servers with iSCSI IP SAN arrays from
EqualLogic in a pre-prod lab. VI is an interesting alternative to ESX
from VMware, and it also competes with XenSource.

Regards,
Rolf


# dmesg
OpenBSD 4.2-current (GENERIC) #405: Thu Sep 13 16:06:09 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Dual-Core AMD Opteron(tm) Processor 8220 (AuthenticAMD
686-class, 1024KB L2 cache) 2.81 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16
real mem  = 536416256 (511MB)
avail mem = 510992384 (487MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @
0xfa3b0, SMBIOS rev. 2.4 @ 0xe901f (11 entries)
bios0: vendor Xen version 3.1-070908
bios0: Xen HVM domU
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 @ 0xf/0x0
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfa650/128 (6 entries)
pcibios0: PCI Interrupt Router at 000:01:0 (Intel 82371SB ISA rev 0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: QEMU HARDDISK
wd0: 16-sector PIO, LBA48, 9536MB, 19529728 sectors
wd0(pciide0:0:0): using PIO mode 0, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU CD-ROM, 0.8. SCSI0 5/cdrom removable
cd0(pciide0:1:1): using PIO mode 0, DMA mode 2
piixpm0 at pci0 dev 1 function 2 Intel 82371AB Power rev 0x01: SMBus disabled
vga1 at pci0 dev 2 function 0 Cirrus Logic CL-GD5446 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
unknown vendor 0x5853 product 0x0001 (class undefined unknown subclass
0x80, rev 0x01) at pci0 dev 3 function 0 not configured
re0 at pci0 dev 4 function 0 Realtek 8139 rev 0x20: RTL8139C+
(0x7480), irq 5, address 00:0f:4b:16:fd:0f
rlphy0 at re0 phy 0: RTL internal PHY
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
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: density unknown
fd1 at fdc0 drive 1: density unknown
biomask efdd netmask effd ttymask 
pctr: user-level cycle counter enabled
mtrr: Pentium Pro MTRR support
nvram: invalid checksum
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a swap on wd0b dump on wd0b
clock: unknown CMOS layout
re0: watchdog timeout
re0: watchdog timeout
re0: watchdog timeout
re0: watchdog timeout
re0: watchdog timeout
#

Re: unstable and multiple reboot for 4.2 on Sun X4100 M2 with ACPI enable on AMD64 bsd.mp with SAS RAID 1 setup.

[Rolf Sommerhalder]

The latest snapshot (13. Sept). of amd64 bsd.mp with ACPI enabled runs
stable on two X4100 M2 which are identically configured (single SAS
disk only, no RAID-1 yet, with current BIOS/SP/SAS Firmware from Sun).

As  Daniel already observed with a snapshot that is two days older,
booting is much faster than with previous shapshots, no long dalys
around IPMI startup.

Keeping an eye on stability over the next few days while putting this
firewall cluster into pre-production (it runs pf, pfsync, a bunch of
VLANs with CARP on almost every VLAN, named, sendmail, OpenVPN, Squid,
and some other application-level gateway/proxies).
Next wekk, I also intend to insert a second SAS disk and add RAID-1.


# dmesg
OpenBSD 4.2-current (GENERIC.MP) #1388: Thu Sep 13 14:31:22 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2147012608 (2047MB)
avail mem = 2073640960 (1977MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbd50 (70 entries)
bios0: vendor American Megatrends Inc. version 0ABJX039 date 04/11/2007
bios0: Sun Microsystems Sun Fire X4100 M2
acpi0 at mainbus0: rev 2
acpi0: tables DSDT FACP APIC SPCR SLIT OEMB HPET IPET SRAT SSDT
acpitimer at acpi0 not configured
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Dual-Core AMD Opteron(tm) Processor 2210, 1795.44 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Dual-Core AMD Opteron(tm) Processor 2210, 1795.23 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
ioapic0 at mainbus0 apid 15 pa 0xfec0, version 11, 24 pins
ioapic1 at mainbus0 apid 16 pa 0xfeafd000, version 11, 7 pins
ioapic1: misconfigured as apic 0, can't remap to apid 16
ioapic2 at mainbus0 apid 17 pa 0xfeafc000, version 11, 7 pins
ioapic2: misconfigured as apic 1, can't remap to apid 17
ioapic3 at mainbus0 apid 14 pa 0xfeaff000, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus 4 (P0P4)
acpiprt3 at acpi0: bus 5 (P0P5)
acpiprt4 at acpi0: bus 255 (PCIB)
acpiprt5 at acpi0: bus -1 (POGA)
acpiprt6 at acpi0: bus -1 (POGB)
acpiprt7 at acpi0: bus -1 (BR5D)
acpiprt8 at acpi0: bus -1 (BR5E)
acpiprt9 at acpi0: bus 128 (PCIC)
acpiprt10 at acpi0: bus 133 (POGA)
acpiprt11 at acpi0: bus 134 (POGB)
acpicpu at acpi0 not configured
acpicpu at acpi0 not configured
acpicpu at acpi0 not configured
acpicpu at acpi0 not configured
acpibtn at acpi0 not configured
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca4/2 spacing 1
pci0 at mainbus0 bus 0: configuration mode 1
NVIDIA nForce4 DDR rev 0xa3 at pci0 dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0 NVIDIA nForce4 ISA rev 0xa3
nviic0 at pci0 dev 1 function 1 NVIDIA nForce4 SMBus rev 0xa2
iic0 at nviic0: disabled to avoid ipmi0 interactions
iic1 at nviic0: disabled to avoid ipmi0 interactions
ohci0 at pci0 dev 2 function 0 NVIDIA nForce4 USB rev 0xa2: apic 15
int 11 (irq 11), version 1.0, legacy support
ehci0 at pci0 dev 2 function 1 NVIDIA nForce4 USB rev 0xa3: apic 15
int 5 (irq 5)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1
pciide0 at pci0 dev 6 function 0 NVIDIA nForce4 IDE rev 0xf2: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 ignored (disabled)
ppb0 at pci0 dev 9 function 0 NVIDIA nForce4 PCI-PCI rev 0xa2
pci1 at ppb0 bus 1
vga1 at pci1 dev 3 function 0 ATI Rage XL rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
nfe0 at pci0 dev 10 function 0 NVIDIA CK804 LAN rev 0xa3: apic 15
int 15 (irq 15), address 00:14:4f:8e:14:aa
eephy0 at nfe0 phy 1: Marvell 88E Gigabit PHY, rev. 2
ppb1 at pci0 dev 11 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci2 at ppb1 bus 2
ppb2 at pci0 dev 12 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci3 at ppb2 bus 3
ppb3 at pci0 dev 13 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci4 at ppb3 bus 4
ppb4 at pci0 dev 14 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci5 at ppb4 bus 5
pchb0 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev
0x00pci6 at pchb0 bus 128
NVIDIA nForce4 DDR rev 0xa3 at pci6 

Re: unstable and multiple reboot for 4.2 on Sun X4100 M2 with ACPI enable on AMD64 bsd.mp with SAS RAID 1 setup.

[Rolf Sommerhalder]

I did observe similar behaviour on four X4100 M2 as well (two with one
socket dual-core, two with two sockets dual-core Opterons) using amd64
bsd.mp snapshots from 23 and 28 Aug..

Currently, amd64 bsd.mp snapshot 28. Aug is running stable on those
four servers, although using a single SAS disk without RAID.

Several days ago, there was a commit in kernel CVS about delaying
start of IPMI which is causing annoying delays at startup of amd64.
Eventually, a more recent snapshot becomes available which includes
this modification, before I get around to build a -current kernel.

Rolf

dmesg amd64-current with ACPI on Sun Fire X4200 M2

[Rolf Sommerhalder]

Currently, this brand new X4200 M2 only has one of its two sockets
equipped with a dual-core Opteron.

Some observations:
1.  amd64 bsd-snapshot of 28. Aug (single core, without ACPI) appears
to run stable;
2. amd64 bsd.mp-.snapshot of 28. Aug (dual core, without ACPI) crashes
during/shortly after boot;
3. amd64 bsd.mp-.snapshot of 28. Aug (dual core, ACPI enabled) appears
to run stable, although it was running only for a few hours so far.

Before installing OpenBSD, the firemares of the BIOS, IPMI and RAID
controllers were updated to the current release (v1.2).


# sysctl hw
hw.machine=amd64
hw.model=Dual-Core AMD Opteron(tm) Processor 2210
hw.ncpu=2
hw.byteorder=1234
hw.physmem=2147012608
hw.usermem=2147004416
hw.pagesize=4096
hw.disknames=sd0,cd0,sd1
hw.diskcount=3
hw.sensors.ipmi0.temp0=33.00 degC (mb.t_amb), OK
hw.sensors.ipmi0.temp1=27.00 degC (fp.t_amb), OK
hw.sensors.ipmi0.temp2=29.00 degC (pdb.t_amb), OK
hw.sensors.ipmi0.temp3=26.00 degC (io.t_amb), OK
hw.sensors.ipmi0.temp4=23.00 degC (p0.t_core), OK
hw.sensors.ipmi0.fan0=8800 RPM (ft0.fm0.f0.speed), OK
hw.sensors.ipmi0.fan1=9300 RPM (ft0.fm2.f0.speed), OK
hw.sensors.ipmi0.fan2=9000 RPM (ft0.fm1.f0.speed), OK
hw.sensors.ipmi0.fan3=1 RPM (ft1.fm0.f0.speed), OK
hw.sensors.ipmi0.fan4=10200 RPM (ft1.fm1.f0.speed), OK
hw.sensors.ipmi0.fan5=9500 RPM (ft1.fm2.f0.speed), OK
hw.sensors.ipmi0.fan6=8600 RPM (ft0.fm0.f1.speed), OK
hw.sensors.ipmi0.fan7=8800 RPM (ft0.fm1.f1.speed), OK
hw.sensors.ipmi0.fan8=9200 RPM (ft0.fm2.f1.speed), OK
hw.sensors.ipmi0.fan9=9900 RPM (ft1.fm0.f1.speed), OK
hw.sensors.ipmi0.fan10=10200 RPM (ft1.fm1.f1.speed), OK
hw.sensors.ipmi0.fan11=9100 RPM (ft1.fm2.f1.speed), OK
hw.sensors.ipmi0.volt0=2.91 VDC (mb.v_bat), OK
hw.sensors.ipmi0.volt1=3.18 VDC (mb.v_+3v3stby), OK
hw.sensors.ipmi0.volt2=3.32 VDC (mb.v_+3v3), OK
hw.sensors.ipmi0.volt3=5.04 VDC (mb.v_+5v), OK
hw.sensors.ipmi0.volt4=12.16 VDC (mb.v_+12v), OK
hw.sensors.ipmi0.volt5=-12.42 VDC (mb.v_-12v), OK
hw.sensors.ipmi0.volt6=2.56 VDC (mb.v_+2v5core), OK
hw.sensors.ipmi0.volt7=1.52 VDC (mb.v_+1v5core), OK
hw.sensors.ipmi0.volt8=1.22 VDC (mb.v_+1v2core), OK
hw.sensors.ipmi0.volt9=1.33 VDC (p0.v_vdd), OK
hw.sensors.ipmi0.volt10=1.84 VDC (p0.v_vddio), OK
hw.sensors.ipmi0.volt11=0.91 VDC (p0.v_vtt), OK
hw.sensors.ipmi0.indicator0=Off (sys.intsw), OK
hw.cpuspeed=1795
hw.vendor=Sun Microsystems
hw.product=Sun Fire X4100 M2
hw.serialno=0730AL5C58
hw.uuid=----00144f9ef0a1
#


# dmesg
OpenBSD 4.2 (GENERIC.MP) #1378: Tue Aug 28 10:48:58 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2147012608 (2047MB)
avail mem = 2073706496 (1977MB)
User Kernel Config
UKC enable acpi
266 acpi0 enabled
UKC exit
Continuing...
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbd50 (70 entries)
bios0: vendor American Megatrends Inc. version 0ABJX039 date 04/11/2007
bios0: Sun Microsystems Sun Fire X4100 M2
acpi0 at mainbus0: rev 2
acpi0: tables DSDT FACP APIC SPCR SLIT OEMB HPET IPET SRAT SSDT
acpitimer at acpi0 not configured
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Dual-Core AMD Opteron(tm) Processor 2210, 1795.44 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Dual-Core AMD Opteron(tm) Processor 2210, 1795.23 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
ioapic0 at mainbus0 apid 15 pa 0xfec0, version 11, 24 pins
ioapic1 at mainbus0 apid 16 pa 0xfeafd000, version 11, 7 pins
ioapic1: misconfigured as apic 0, can't remap to apid 16
ioapic2 at mainbus0 apid 17 pa 0xfeafc000, version 11, 7 pins
ioapic2: misconfigured as apic 1, can't remap to apid 17
ioapic3 at mainbus0 apid 14 pa 0xfeaff000, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus 4 (P0P4)
acpiprt3 at acpi0: bus 5 (P0P5)
acpiprt4 at acpi0: bus 255 (PCIB)
acpiprt5 at acpi0: bus 255 (POGA)
acpiprt6 at acpi0: bus 255 (POGB)
acpiprt7 at acpi0: bus 255 (BR5D)
acpiprt8 at acpi0: bus 255 (BR5E)
acpiprt9 at acpi0: bus 128 (PCIC)
acpiprt10 at acpi0: bus 133 (POGA)
acpiprt11 at acpi0: bus 134 (POGB)
acpicpu at acpi0 not configured
acpicpu at acpi0 not configured
acpicpu at acpi0 not 

dmesg amd64-current on Sun Fire X4600 M2

[Rolf Sommerhalder]

Thanks for all posts with dmesgs from Sun Fire X2100 / X4100 / X4200
(although most without M2 suffix). They helped us in our purchasing
decision of several such servers with M2 suffix.

Please find below the dmesg of amd64.mp-current (snapshot 23-Aug-2007)
on a Sun Fire X4600 M2 which is equipped with four dual-core Opteron
8220 CPU, 32 GB of RAM and four built-in NICs.

Currently, Sun has a special where you get three X4600 M2s for the
price of two. We purchased such a multipack to run a large,
demanding application related to network security in a virtualised
environment. The host OS is Virtual Iron (e.g. a Xen hypervisor) and
the guest OSes are RHEL or CentOS respectively. We use two iSCSI SAN
disk arrays from EqualLogic to virtualise storage.

Unfortunately, our large application does not (yet) run on OpenBSD.
However, our firewall cluster is amd64 (pf, pfsync, CARP, pfflowd,
etc.) on a pair of relatively cheap single dual-core Sun Fire X4100
M2 (will post dmesg later). This cluster also provides a number of
infrastructure services, such as for ex. DNS, caching HTTP proxy,
reverse proxy (Pound), SSL VPN concentrator (OpenVPN), mail relay,
etc.

OpenBSD i386-current boots and runs as a guest within Virtual Iron
3.7.4. I intend to post a dmesg as soon as I manage to resolve some
weird problem which still prevents me from siphon it to another
machine.

Regards,
Rolf


'top' shows an impressive 8 cores:

load averages:  0.19,  0.15,  0.09
19:37:16
20 processes:  19 idle, 1 on processor
CPU0 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU1 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU2 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU3 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU4 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU5 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU6 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU7 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Memory: Real: 10M/57M act/tot  Free: 3427M  Swap: 0K/1643M used/tot

  PID USERNAME PRI NICE  SIZE   RES STATEWAIT  TIMECPU COMMAND
28463 root  180  672K  644K idle pause 0:00  0.00% ksh
12385 root   20 3220K 2932K sleep/0  select0:00  0.00% sshd
24344 root   20  844K 1896K sleep/0  poll  0:00  0.00% top
 3727 root   20 1144K 1668K sleep/0  select0:00  0.00% sendmail
  526 root   20  792K 1376K idle select0:00  0.00% sshd
28736 _syslogd   20  384K  832K sleep/0  poll  0:00  0.00% syslogd
 3009 root   20  712K  920K sleep/0  select0:00  0.00% cron
1 root  100  464K  384K idle wait  0:00  0.00% init
27387 root   20  516K  820K idle poll  0:00  0.00% ntpd
19725 root   20 3352K 2932K sleep/5  select0:00  0.00% sshd
23584 _ntp   20  520K  844K idle poll  0:00  0.00% ntpd
 7005 root   30  284K  840K idle ttyin 0:00  0.00% getty
 4465 root   30  252K  828K idle ttyin 0:00  0.00% getty
32174 root   30  440K  836K idle ttyin 0:00  0.00% getty



OpenBSD 4.2 (GENERIC.MP) #1377: Thu Aug 23 10:52:45 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3757617152 (3583MB)
avail mem = 3635957760 (3467MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbf20 (83 entries)
bios0: vendor American Megatrends Inc. version 080012  date 04/19/2007
bios0: Sun Microsystems Sun Fire X4600 M2
acpi at mainbus0 not configured
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca4/2 spacing 1
mainbus0: Intel MP Specification (Version 1.4)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Dual-Core AMD Opteron(tm) Processor 8220, 2800.33 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE
,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Dual-Core AMD Opteron(tm) Processor 8220, 2801.17 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE
,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Dual-Core AMD Opteron(tm) 

Q: Threads Support in ssl(8)?

[Rolf Sommerhalder]

Hello list,

Is there any specific reason, such as for example concerns about
security or about stability, why THREADS support is not turned on in
OpenBSD's OpenSSL by default?  (Apparently, it isn't neither in
FreeBSD nor in NetBSD.) Or, was there so far simply no need for
THREADS support to be provided by ssl(8)?

A project has an urgent need for a compact reverse HTTP/HTTPS proxy.
Therefore I updated my earlier port of Pound to its latest stable
-2.3.2, which I derived from work done by Pete Vickers et al.
http://permalink.gmane.org/gmane.os.openbsd.misc/126141

On sparc64, this port fails to build a secondary OpenSSLin a temporary
directory with THREADS support enabled, due to some obscure problem
with assembly code and UltraSPARC (I tried both the current stable
0.9.8e and 0.9.7j which is used by 4.2-current). The recommended
workaround of configuring OpenSSL with the 'no-asm' option also failed
miserably at the 'make test' stage later, although it resolved the
compilation/assmbler issue.

The solution was to enable THREADS support in OpenSSL of OpenBSD's
source tree and to rebuild ssl(8). The resulting Pound port gets much
leaner (no hack required with parallel installation of OpenSSL in
temporary install directory), builds rapidly and installs cleanly.. So
far, Pound-2.3.2 as well as vpnc-0.4.0 and OpenVPN-2.0.9 run fine on
both i386 and sparc64 of 4.2-current using ssl(8) with THREADS
enabled.

I am aware that the project is currently in release lock. Once
unlocked, is there any chance that enabling THREADS support per
default would gain some traction? This would facilitate the building
of a clean port for Pound considerably.

If there is any interest, I can make available my updated Pound-2.3.2
port available.

Thanks,
Rolf

Slides of Talk about OpenBGPD at DE-CIX

[Rolf Sommerhalder]

Bernhard Krvnung of DE-CIX recently gave a talk about OpenBGPd at SwiNOG 14:
 http://www.swinog.ch/meetings/swinog14/070530-openbgpd-swinog-bk-en.pdf

A comitter might want to add it to the collections in events.html
and/or in papers/index.html .

Thanks,
Rolf

Re: ath(4) testers needed: AR2413, AR5413, AR5424 and AR5212 11a mode

[Rolf Sommerhalder]

My new miniPCI with AR2413 in 11b mode is recognized under  -current
on a WRAP, but it fails to associate and sometimes locks up the entire
system, as implictly warned by Reyk in his commit for
src/sys/dev/ic/ath.con 19 Sept 2006.

This ath(4) device is a  wlm54g23  Compex WLM54G 200mW Atheros
802.11b/g miniPCI wireless card from PCEngines.

Please find some debug output below, as suggested by Reyk. I am happy
to provide more information, and to test patches against -current, in
the hope to assist getting these newer ath chip sets to transmit also
in 11b mode.

Thanks,
Rolf


[EMAIL PROTECTED] root]# ifconfig ath0 up
[EMAIL PROTECTED] root]# ifconfig ath0
ath0: flags=8863UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:80:48:7e:b4:e5
   groups: wlan
   media: IEEE802.11 autoselect (DS1 mode 11b)
   status: no network
   ieee80211: nwid FON_crosscom chan 3 bssid 00:18:84:10:62:1d 92%
   inet6 fe80::280:48ff:fe7e:b4e5%ath0 prefixlen 64 scopeid 0x1
[EMAIL PROTECTED] root]# ifconfig ath0
ath0: flags=8863UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:80:48:7e:b4:e5
   groups: wlan
   media: IEEE802.11 autoselect (DS1)
   status: no network
   ieee80211: nwid 
   inet6 fe80::280:48ff:fe7e:b4e5%ath0 prefixlen 64 scopeid 0x1
[EMAIL PROTECTED] root]#


[EMAIL PROTECTED] root]# ifconfig -M ath0
ath0: flags=8863UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:80:48:7e:b4:e5
   groups: wlan
   media: IEEE802.11 autoselect (DS1)
   status: no network
   ieee80211: nwid 
   nwid FON_crosscom chan 3 bssid 00:18:84:10:62:1d 87%
54M short_preamble,short_slottime
   inet6 fe80::280:48ff:fe7e:b4e5%ath0 prefixlen 64 scopeid 0x1
[EMAIL PROTECTED] root]# ifconfig -M ath0


[EMAIL PROTECTED] root]# dmesg
OpenBSD 4.1-current (WRAP12) #0: Sun Jun  3 11:15:57 CEST 2007
   [EMAIL PROTECTED]:/home/rs/downloads/OpenBSD/flashboot/flashboot/obj/WRAP12
RTC BIOS diagnostic error 80clock_battery
cpu0: Geode(TM) Integrated Processor by National Semi (Geode by NSC
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem  = 133791744 (127MB)
avail mem = 109572096 (104MB)
RTC BIOS diagnostic error 80clock_battery
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/08/05, BIOS32 rev. 0 @ 0xfc622
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/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Cyrix GXm PCI rev 0x00
ath0 at pci0 dev 13 function 0 Atheros AR2413 rev 0x01: irq 12
ath0: AR2413 7.8 phy 4.5 rf 5.6, FCC2A*, address 00:80:48:7e:b4:e5
sis0 at pci0 dev 14 function 0 NS DP83815 10/100 rev 0x00, DP83816A:
irq 10, address 00:0d:b9:01:a0:a0
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 15 function 0 NS DP83815 10/100 rev 0x00, DP83816A:
irq 9, address 00:0d:b9:01:a0:a1
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 16 function 0 NS DP83815 10/100 rev 0x00, DP83816A:
irq 11, address 00:0d:b9:01:a0:a2
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
gscpcib0 at pci0 dev 18 function 0 NS SC1100 ISA rev 0x00
gpio0 at gscpcib0: 64 pins
NS SC1100 SMI rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 NS SCx200 IDE rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: CF 128MB
wd0: 1-sector PIO, LBA, 125MB, 256512 sectors
wd0(pciide0:0:0): using PIO mode 4
NS SCx200 AUDIO rev 0x00 at pci0 dev 18 function 3 not configured
geodesc0 at pci0 dev 18 function 5 NS SC1100 X-Bus rev 0x00: iid 6
revision 3 wdstatus 0
isa0 at gscpcib0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
midi0 at pcppi0: PC speaker
gscsio0 at isa0 port 0x2e/2: SC1100 SIO rev 1: ACB1 ACB2
iic0 at gscsio0
iic1 at gscsio0
lmtemp0 at iic1 addr 0x48: lm77
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
biomask e1ef netmask ffef ttymask ffef
rd0: fixed, 30720 blocks
dkcsum: wd0 matches BIOS drive 0x80
root on rd0a swap on rd0b dump on rd0b
clock: unknown CMOS layout
WARNING: clock time much less than file system time
WARNING: using file system time
WARNING: CHECK AND RESET THE DATE!
[EMAIL PROTECTED] root]#


Filtered output to avoid dumping other WLAN traffic than the two MACs
of interest.  ':b4:e5' is my ath0, ':62:1d' is my public FONera access
point, see output of 'ifconfig -M ath0' above:

[EMAIL PROTECTED] root]#  tcpdump -y ieee802_11_radio -eni ath0 | grep -e
':b4:e5' -e ':62:1d'
tcpdump: listening on ath0, link-type IEEE802_11_RADIO
10:02:43.791541 0:18:84:10:62:1d  ff:ff:ff:ff:ff:ff, bssid
0:18:84:10:62:1d: 802.11: beacon[|802.11], radiotap v0, chan 3, 

OpenBSD-style Templates for MagicPoint Presentations

[Rolf Sommerhalder]

Hello list,

so far I have been unsuccessful in locating templates (and fonts?) for
MagicPoint presentations in OpenBSD-style, such as used in for
example:

http://openbsd.org/papers/ven05-henning/index.html
http://openbsd.org/papers/opencon06-network/index.html
http://openbsd.org/papers/opencon06-drivers/index.html
http://openbsd.org/papers/linuxtag06-network/index.html

Can someone point me to those templates and fonts, and/or provide
source of sample slides, provided that they are open?

I am thinking about ging a talk about OpenBSD (with some applied
examples) targeted to fellow ICT staff of international humanitarian
organisations who provide IT and Communication services to emergency
and relief operations.
There, I believe, OpenBSD has great potential, as it provides a robust
and cost-efficient platform (also on legacy hardware) that can cover
several pressing needs, such as dynamic routing, redundant firewals,
VPN over public networks such as wireless links (Wireless LAN,
satellite, Internet, etc.), network  system monitoring and SLA
verification, spam filtering to protect low-capacity links from
transporting expensive rubbish, etc.
Currently, this field is still largely dominated by commercial
software and solution providers. However, as Open Source Software is
gaining more and more attention among governmental organisations,
those governments as major donors of international aid agencies will
sooner or later start to ask questions why aid agencies spend the
donors' money on software and licenses.

It would be nice to prepare and to give the talk with MagicPoint
slides in OpenBSD-style using my old Dell Inspiron 4000 laptop that
happily runs i386-current :-)

Thanks for your help,
Rolf

Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type

[Rolf Sommerhalder]

Hi Mark

On 2/3/07, Mark Kettenis [EMAIL PROTECTED] wrote:

Regarding the high interrupt load on the v210; try disconnecting the 
CD-ROM/DVD-ROM.


Removing the CD drives silenced the interrupts, and the CPU load
dropped to 0%, thanks.


Can you try the attached diff?  It has some debug printf's in there,
so please send me a dmesg.


After CVSupdating last night and applying your patch, the fiber NICs
worked for a few pings, but since they changed their status from
active to no carrier.
Please find some debug output below.

By the way, the large Marvell chip on the SK-9S91 NIC is labelled 88E8021.

Thanks,
Rolf

# ifconfig
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33192
   groups: lo
   inet 127.0.0.1 netmask 0xff00
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:14:4f:64:0c:52
   groups: egress
   media: Ethernet autoselect (100baseTX full-duplex)
   status: active
   inet 10.7.91.218 netmask 0xff80 broadcast 10.7.91.255
   inet6 fe80::214:4fff:fe64:c52%bge0 prefixlen 64 scopeid 0x1
bge1: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:14:4f:64:0c:53
   media: Ethernet autoselect (1000baseT full-duplex)
   status: active
bge2: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:14:4f:64:0c:54
   media: Ethernet autoselect (none)
   status: no carrier
bge3: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:14:4f:64:0c:55
   media: Ethernet autoselect (none)
   status: no carrier
msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:00:5a:72:fc:59
   media: Ethernet autoselect (none)
   status: no carrier
   inet6 fe80::200:5aff:fe72:fc59%msk0 prefixlen 64 scopeid 0x5
   inet 10.20.0.218 netmask 0xff00 broadcast 10.20.0.255
pflog0: flags=0 mtu 33192
enc0: flags=0 mtu 1536
#
# ifconfig -m msk0
msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:00:5a:72:fc:59
   media: Ethernet autoselect (none)
   status: no carrier
   supported media:
   media none
   media 1000baseSX
   media 1000baseSX mediaopt full-duplex
   media autoselect
   inet6 fe80::200:5aff:fe72:fc59%msk0 prefixlen 64 scopeid 0x5
   inet 10.20.0.218 netmask 0xff00 broadcast 10.20.0.255
#

# dmesg
console is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],3f8
Copyright (c) 1982, 1986, 1989, 1991, 1993
   The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.0-current (GENERIC) #0: Mon Feb  5 02:19:55 CET 2007
   [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 1073741824
avail memory = 969416704
using 6553 buffers containing 53682176 bytes of memory
bootpath: /[EMAIL PROTECTED],60/[EMAIL PROTECTED],0/[EMAIL PROTECTED],0
mainbus0 (root): Sun Fire V210
cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1336 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K
external (64 b/l)
memory-controller at mainbus0 not configured
schizo0 at mainbus0: Tomatillo, version 4, ign 7c0, bus B 0 to 0
schizo0: dvma map c000-dfff, iotdb 4d16000-4d96000
pci0 at schizo0
bge0 at pci0 dev 2 function 0 Broadcom BCM5704C rev 0x00, BCM5704 B0
(0x2100): ivec 0x7c8, address 00:14:4f:64:0c:52
brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
bge1 at pci0 dev 2 function 1 Broadcom BCM5704C rev 0x00, BCM5704 B0
(0x2100): ivec 0x7c9, address 00:14:4f:64:0c:53
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
schizo1 at mainbus0: Tomatillo, version 4, ign 780, bus A 0 to 0
schizo1: dvma map c000-dfff, iotdb 547e000-54fe000
pci1 at schizo1
ebus0 at pci1 dev 7 function 0 Acer Labs M1533 ISA rev 0x00
flashprom at ebus0 addr 0-f, 290-290 not configured
rtc0 at ebus0 addr 70-71: m5819p
pcfiic0 at ebus0 addr 320-321 ipl 46
iic0 at pcfiic0
SUNW,i2c-imax at iic0 addr 0xb not configured
SUNW,i2c-imax at iic0 addr 0xc not configured
at24c64 at iic0 addr 0x51 not configured
at24c64 at iic0 addr 0x54 not configured
at24c64 at iic0 addr 0x58 not configured
at34c02 at iic0 addr 0x5b not configured
at34c02 at iic0 addr 0x5c not configured
at34c02 at iic0 addr 0x5d not configured
at34c02 at iic0 addr 0x5e not configured
ds1307 at iic0 addr 0x68 not configured
at24c64 at iic0 addr 0x28 not configured
pca9555 at iic0 addr 0x22 not configured
pca9555 at iic0 addr 0x23 not configured
pca9555 at iic0 addr 0x34 not configured
pca9556 at iic0 addr 0x38 not configured
power0 at ebus0 addr 800-82f ipl 32: can't map register space
com0 at ebus0 addr 3f8-3ff ipl 44: ns16550a, 16 byte fifo
com0: console
com1 at ebus0 addr 2e8-2ef ipl 44: ns16550a, 16 byte fifo
rmc-comm at ebus0 addr 3e8-3ef ipl 44 not configured
Acer Labs 

Re: High Interrupt Load cased by pciide with sparc64 on SUN V210

[Rolf Sommerhalder]

The high interrupt load vanished after removing the CD-ROM drives from
both V210, as suggested by Mark Kettenis.

Now the CPU load is down to 0%, as one expects, and the systems are
much more performant and responsive than before :-)

# iostat -w 1
 ttycd0 sd0 cpu
tin tout  KB/t t/s MB/s   KB/t t/s MB/s  us ni sy in id
  0   21  0.00   0 0.00   8.18   2 0.01   3  0  0 36 61
  0  172  0.00   0 0.00   0.00   0 0.00   0  0  0  0100
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0  0100
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0  0100
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0  0100
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0  0100
  0   57  0.00   0 0.00  16.00   2 0.03   0  0  0  0100
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0  0100
^C
#

Thanks to Mark for his suggestion,
Rolf

Re: vpn bridge misbehavior

[Rolf Sommerhalder]

Hi,

On 2/2/07, Jonathan Whiteman [EMAIL PROTECTED] wrote:

I'd like to get into a detailed explanation of the network
topology I'm working with here but I don't want to scare off
anyone by opening with a 3 page email.


Your subject implies that you built a layer-2 LAN-to-LAN bridge over
an (IPSec or OpenVPN?) VPN tunnel.
Not beening a OpenBSD nor VPN specialist yet, still I would love to
see your detailed three page description, as I am currently
experimenting with a similar setup (and got a prototype to work last
night in the lab).

Rolf

Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type

[Rolf Sommerhalder]

Both boxes and fiber NICs work fine under Solaris 9 using Syskonnect's
proprietary skge driver and a short cross-over fiber patch.
So it is definitely not an issue with with the hardware setup, but with OpenBSD.

I'll have the fiber NICs for another 10 days before I'll deploy them
in a customer's setup. Until then, I would be happy to apply any diffs
and retest.

Thanks,
Rolf

High Interrupt Load cased by pciide with sparc64 on SUN V210

[Rolf Sommerhalder]

Hello misc,

After having installed 4.0-current on two identically configured SUN
V210 (see dmesg below), I found that their performance was unusually
bad, notably with disk I/O.

top reveals a permanent interrupt load of between 30 to over 50% !?

# top
load averages:  0.09,  0.17,  0.08
19:52:16
13 processes:  12 idle, 1 on processor
CPU states:  1.9% user,  0.0% nice,  1.6% system, 39.0% interrupt, 57.5% idle
Memory: Real: 11M/122M act/tot  Free: 880M  Swap: 0K/487M used/tot

 PID USERNAME PRI NICE  SIZE   RES STATEWAIT TIMECPU COMMAND
1643 root   20  832K 2360K idle select   0:02  0.00% sshd
30242 root   20 3544K 3504K sleepselect   0:01  0.00% sshd
24667 root   20  480K 1072K idle select   0:00  0.00% inetd
2435 root   20 1592K 2136K sleepselect   0:00  0.00% sendmail
20073 root  180  824K  616K sleeppause0:00  0.00% ksh
24745 root   20  536K 1056K idle poll 0:00  0.00% ntpd
29783 root   20  664K 1184K sleepselect   0:00  0.00% cron
25532 root   30  352K 1104K idle ttyin0:00  0.00% getty
21605 _syslogd   20  544K 1000K idle poll 0:00  0.00% syslogd
   1 root  100  536K  424K idle wait 0:00  0.00% init
24060 root   20  520K  976K idle netio0:00  0.00% syslogd
3809 _ntp   20  408K 1056K idle poll 0:00  0.00% ntpd
24849 root  310  504K 1648K onproc   -0:00  0.00% top


vmstat hints that pciide0 generates interrupts with a very high rate,
although there is hardly anything running on the boxes:

# vmstat -i
interrupt   total rate
bge0  5143
com0   820
pciide0 134564203   879504
siop02158   14
siop1   10
clock   15327  100
Total   134582285   879622
# uptime
7:50PM  up 3 mins, 1 user, load averages: 0.27, 0.21, 0.09
#

# iostat -w 1
 ttycd0 sd0 cpu
tin tout  KB/t t/s MB/s   KB/t t/s MB/s  us ni sy in id
  0   29  0.00   0 0.00  15.09   1 0.01   0  0  0 36 64
  0  171  0.00   0 0.00   0.00   0 0.00   0  0  0 38 62
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 33 67
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 38 62
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 28 72
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 34 66
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 27 73
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 40 60
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 31 69
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 36 64
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 29 71
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 31 69
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 34 66
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 37 63
  0   57  0.00   0 0.00   0.00   0 0.00   0  0  0 32 68

Maybe I shoud mention that I was lazy and installed everything under /
into a single partition because it's only a lab setup.
Also, in both boxes, I installed a SK-9S91 PCI 1 Gbit/s fiber NIC, in
addition to the four on-board bge NICs.

Rebooting multiple times of both boxes did not cure the high interrupt
rate, and enabling softupdates on /dev/sd0a did not help either.

The third-lat line in the output of dmesg below is somewhat intrigueing:
No counter-timer -- using %tick at 1336MHz as system clock. root on sd0a
But according to other dmesg from the archives, this seems to be
common among sparc64 installs.

In the archives, I found postings regarding a similar problem on an
Ultra 5. Apparently, the only recommendation there was to enable
softupdates. I remember having observed similar performance problems
on my own Ultra 5 some months ago under OpenBSD 3.9, which I was
unable to resolve.

Shall I try a re-install with more partitions, respectively to add
more partitions for the usual mount points?
Anything to do from with OpenBoot in order to avoid interrupt
conflicts between pciide0 and the SK-9S91 PCI NIC, for example?
Is there anything else that I should try in order to silence that
interrupt source?
I am happy to rebuild the kernel after patching and to re-test.

Thanks for your attention and any suggestions,
Rolf


# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: SUN72G cyl 14087
flags:
bytes/sector: 512
sectors/track: 424
tracks/cylinder: 24
sectors/cylinder: 10176
cylinders: 14087
total sectors: 143349312
rpm: 10025
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0   # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

16 partitions:
# sizeoffset  fstype [fsize bsize  cpg]
 a:  7704 0  4.2BSD   2048 16384   16 # Cyl 0 -  6878
 b:997248  7704swap   # Cyl  6879 -  6976
 c:  

msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type

[Rolf Sommerhalder]

Hello misc,

Two identically configured SUN V210, each equipped with a SK-9S91 PCI
NIC (single port, single mode fiber 1 Gbit/s), run -current snapshot
dated 20 Jan 07
The kernel detects those fiber NICs, besides the four on-board bge,
see dmesg below. After boot, the msk0 come up in autoselect media
type, but the two fiber NICs' link status remains at no carrier,
despite having connected the two NIC with a cross-over fiber patch
cable and forcing them up.

Forcing the  media type 1000baseSX according to msk(4) fails:
# ifconfig msk0 media 1000baseSX
ifconfig: SIOCSIFMEDIA: Invalid argument
#

Indeed, this option is missing in the list of media types and options
supported by the card:
# ifconfig -m msk0
msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:00:5a:72:fc:58
   media: Ethernet autoselect (100baseTX half-duplex)
   status: no carrier
   supported media:
   media none
   media 10baseT
   media 10baseT mediaopt full-duplex
   media 100baseTX
   media 100baseTX mediaopt full-duplex
   media 1000baseT
   media 1000baseT mediaopt full-duplex
   media autoselect
   inet6 fe80::200:5aff:fe72:fc58%msk0 prefixlen 64 scopeid 0x5
   inet 10.10.0.218 netmask 0xff00 broadcast 10.10.0.255
#

Maybe I am mistaken by assuming that 1000baseSX should be accepted
by msk() for these NICs?

After taking a look at the msk() and eephy() driver sources, I still
can not figure out if I have a misconception about the use of msk(),
or the fiber NICs features, or even if there is a problem with the
driver(s) and Gig fiber support.
Both fiber NICs are new out-of-the-box. To exclue any hardware
problem, I might test them under Solaris 8, According to prior
experience, I know that they should work after installing a suitable
driver.

I can patch and re-test, if this should be of interest. Thanks for any
hints and suggestions,
Rolf

# dmesg
console is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],3f8
Copyright (c) 1982, 1986, 1989, 1991, 1993
   The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.0-current (GENERIC) #1049: Fri Jan 19 18:36:23 MST 2007
   [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 1073741824
avail memory = 969416704
using 6553 buffers containing 53682176 bytes of memory
bootpath: /[EMAIL PROTECTED],60/[EMAIL PROTECTED],0/[EMAIL PROTECTED],0
mainbus0 (root): Sun Fire V210
cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1336 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K
external (64 b/l)
memory-controller at mainbus0 not configured
schizo0 at mainbus0: Tomatillo, version 4, ign 7c0, bus B 0 to 0
schizo0: dvma map c000-dfff, iotdb 4d16000-4d96000
pci0 at schizo0
bge0 at pci0 dev 2 function 0 Broadcom BCM5704C rev 0x00, BCM5704 B0
(0x2100): ivec 0x7c8, address 00:14:4f:64:0c:52
brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
bge1 at pci0 dev 2 function 1 Broadcom BCM5704C rev 0x00, BCM5704 B0
(0x2100): ivec 0x7c9, address 00:14:4f:64:0c:53
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
schizo1 at mainbus0: Tomatillo, version 4, ign 780, bus A 0 to 0
schizo1: dvma map c000-dfff, iotdb 547e000-54fe000
pci1 at schizo1
ebus0 at pci1 dev 7 function 0 Acer Labs M1533 ISA rev 0x00
flashprom at ebus0 addr 0-f, 290-290 not configured
rtc0 at ebus0 addr 70-71: m5819p
pcfiic0 at ebus0 addr 320-321 ipl 46
iic0 at pcfiic0
SUNW,i2c-imax at iic0 addr 0xb not configured
SUNW,i2c-imax at iic0 addr 0xc not configured
at24c64 at iic0 addr 0x51 not configured
at24c64 at iic0 addr 0x54 not configured
at24c64 at iic0 addr 0x58 not configured
at34c02 at iic0 addr 0x5b not configured
at34c02 at iic0 addr 0x5c not configured
at34c02 at iic0 addr 0x5d not configured
at34c02 at iic0 addr 0x5e not configured
ds1307 at iic0 addr 0x68 not configured
at24c64 at iic0 addr 0x28 not configured
pca9555 at iic0 addr 0x22 not configured
pca9555 at iic0 addr 0x23 not configured
pca9555 at iic0 addr 0x34 not configured
pca9556 at iic0 addr 0x38 not configured
power0 at ebus0 addr 800-82f ipl 32: can't map register space
com0 at ebus0 addr 3f8-3ff ipl 44: ns16550a, 16 byte fifo
com0: console
com1 at ebus0 addr 2e8-2ef ipl 44: ns16550a, 16 byte fifo
rmc-comm at ebus0 addr 3e8-3ef ipl 44 not configured
Acer Labs M7101 Power rev 0x00 at pci1 dev 6 function 0 not configured
ohci0 at pci1 dev 10 function 0 Acer Labs M5237 USB rev 0x03: ivec
0x7a7, version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Acer Labs OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
pciide0 at pci1 dev 13 function 0 Acer Labs M5229 UDMA IDE rev 0xc4:
DMA, channel 0 configured to native-PCI, channel 1 configured to
native-PCI
pciide0: 

Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type

[Rolf Sommerhalder]

On 1/30/07, Siegbert Marschall [EMAIL PROTECTED] wrote:


try media 1000baseT mediaopt full-duplex , 1G fiberlinks should be
always fullduplex, rest ist not relevant since it's purely a hardware-
question. wonder how the thing got it's head on 100BaseTX...

apart from that it's a good idea to test them with something else,
to make sure the fibers are crossed and signal-levels are okay.

with single-mode fiber and short cables sometimes you need to insert
a dampening-block since the signal can be too strong for the receiver,
don't think it's the case here though.



Thanks for your quick reply. Unfortunately, this does not activate the
link either:

# ifconfig msk0 media 1000baseT mediaopt full-duplex
# ifconfig -m msk0
msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
   lladdr 00:00:5a:72:fc:58
   media: Ethernet 1000baseT full-duplex (none)
   status: no carrier
   supported media:
   media none
   media 10baseT
   media 10baseT mediaopt full-duplex
   media 100baseTX
   media 100baseTX mediaopt full-duplex
   media 1000baseT
   media 1000baseT mediaopt full-duplex
   media autoselect
   inet6 fe80::200:5aff:fe72:fc58%msk0 prefixlen 64 scopeid 0x5
   inet 10.10.0.218 netmask 0xff00 broadcast 10.10.0.255
#

Three months ago I used the exact same fiber patch cable with two
other SK-9S91 under Solaris 8 in some other V210 or V240, and the
fiber link worked fine back then. Thus, the fiber should be OK
(crossover, attenuation, etc.). But will cross-check that by
installing Solaris again.

Further, I noticed ifmedia(4) differentiates between 1000baseT, SX and
LX. From this I actually realize that I should be able to set
1000baseLX for single mode fiber, not SX which is for multi mode
fiber.

Or, are you saying that the Marvell PHY 88112 does not really care
about if T, SX or LX is set, because for the optical GBIC
electrically all is the same?

Rolf

Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type

[Rolf Sommerhalder]

Hi Mark


Most likely something is not quite right with the eephy(4) driver.

eephy_status() in sys/dev/mii/eephy.c seems to be a candidate for
closer examination. It appears to fall through the if() clause and
does the else part, although we have a NIC with MIIF_IS_1000X :

319:if (sc-mii_flags  MIIF_IS_1000X) {
320:if (ssr  E1000_SSR_1000MBS)
321:
mii-mii_media_active |= IFM_1000_SX;
322:} else {
323:if (ssr  E1000_SSR_1000MBS)
324:
mii-mii_media_active |= IFM_1000_T;
325:else if (ssr  E1000_SSR_100MBS)
326:
mii-mii_media_active |= IFM_100_TX;
327:else
328:
mii-mii_media_active |= IFM_10_T;
329:}



Could you test some diffs for me on that machine?

Yes, I am happy to do that - I hope that I can continue to use those
two machines over the next few days. Just preparing them with CVSupped
source tree.

Rolf

Re: No Watchdog with Current snapshot/i386/ on Nokia IP120

[Rolf Sommerhalder]

On 9/17/06, Stuart Henderson [EMAIL PROTECTED] wrote:

Reboot may be easier. Looking at /usr/src/sys/arch/i386/i386/machdep.c,
there's a Geode-specific reset operation used, but there's a chance it
is an SC1100-only function that won't work on a plain Geode system.
If that's the case, and seeing as you appear to have a standard PC
keyboard controller (which is used to reset normal systems but is
absent from some Geode boards, notably WRAP, hence the alternative
function), you can try editing this file and commenting-out
cpuresetfn = natsem6x86_cpureset; from natsem6x86_cpu_setup()
and rebuilding the kernel; this way it will use the normal PC methods
instead.

If this does the trick, the outl/outb are probably hanging your
system, in which case the natsem6x86_cpu_setup needs to do additional
CPU detection and only use the alternative reset function on SC1100
systems.


As pointed out earlier, this does the trick. Now, I try to contribute
a proper patch which discriminates between Geode CPUs in Nokia and
WRAP  Soekris boards in order to call an appropriate reset function.

Using debug kernels customized with 'option CPUDEBUG' does not show an
obvious difference within the '/src/sys/arch/i386/i386/machdep.c'
module between a Nokia (booting from hard disk) and a WRAP (network
booting using PXEboot), see dmesg below.

Would it be acceptable to somehow use the 'bios0' string within
machdep.c to setup 'cpuresetfn' at boot time, or within 'cpu_reset()'
later at run time in order to discriminate Nokia motherboards from
WRAPs and Soekris' ?

Or, do I overlook some parameter that would allow to discriminate
those motherboards within machdep.c?

Or finally, more radical, should the setting of the global variable
'cpuresetfn' be postponed to where the motherboard / BIOS is detected,
and not prematurely in the CPU detection stage in machdep.c?

Thanks in advance for your guidance,
Rolf


dmesg from Nokia IP120, 'GENERIC' kernel built with 'option CPUDEBUG':

OpenBSD 4.0-current (GENERIC) #14: Fri Oct  6 13:34:12 CEST 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: family 5 model 4 step 0
cpu0: cpuid level 2 cache eax 7001 ebx 0 ecx 0 edx 80
cpu0: Geode(TM) Integrated Processor by National Semi (Geode by NSC
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem  = 133787648 (130652K)
avail mem = 114634752 (111948K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(05) BIOS, date 07/17/00, BIOS32 rev. 0 @
0xeb0a0, SMBIOS rev. 2.3
@ 0xe
d2a8 (32 entries)
bios0: Jabil/Nokia IP110
pcibios0 at bios0: rev 2.1 @ 0xe8000/0x669
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4fb0/80 (3 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x1078 product 0x0100
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe8000/0x4000! 0xec000/0x4000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Cyrix GXm PCI rev 0x00
fxp0 at pci0 dev 14 function 0 Intel 82559ER rev 0x09, i82559S: irq
11, address 00:a0:8e:21:88:98
...


dmesg from WRAP1C, PXE-booting over network 'RAMDISK_CD' kernel built
with 'option CPUDEBUG':


PC Engines WRAP.1C/1D/1E v1.11
640 KB Base Memory
130048 KB Extended Memory

01F0 - no drive found !
ROM segment 0xe000 length 0x8000 reloc 0x
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP NFS TFTM HTTP DNS
Relocating _text from: [00088f80,0009fd60) to [07ee9220,07f0)
Boot from (N)etwork or (Q)uit?

Probing pci nic...
[dp83815]
natsemi_probe: MAC addr 00:0D:B9:01:A0:A0 at ioaddr 0X1000
natsemi_probe: Vendor:0X100B Device:0X0020
dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex.
dp83815: Transceiver status 7869 advertising 05E1
dp83815: Setting half-duplex based on negotiated link capability.
Searching for server (DHCP)...\
Me: 10.0.0.21, DHCP: 10.0.0.3, TFTP: 10.0.0.3, Gateway 10.0.0.1,
Nameserver 10.0.0.1
Loading 10.0.0.3:pxeboot (0049K done
probing: pc0 com0 pci pxe![2.1] mem[640K 125M a20=on]
disk:
net: mac 00:0d:b9:01:a0:a0, ip 10.0.0.21, server 10.0.0.3

OpenBSD/i386 PXEBOOT 1.07

switching console to com0

OpenBSD/i386 PXEBOOT 1.07

com0: changing speed to 38400 baud in 5 seconds, change your terminal to match!

com0: 38400 baud
booting tftp:/bsdCPUDEBUG.rd: 5034740+740164 [52+164384+150221]=0x5cecd0
dp83815: Setting half-duplex based on negotiated link capability.
entry point at 0x200120

Copyright (c) 1982, 1986, 1989, 1991, 1993
   The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2006 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.0-current (RAMDISK_CD) #0: Fri Oct  6 13:54:24 CEST 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: family 5 model 4 step 0
cpu0: cpuid level 2 cache eax 7001 ebx 0 ecx 0 edx 80
cpu0: Geode(TM) Integrated Processor by National Semi (Geode by 

No Watchdog with Current snapshot/i386/ on Nokia IP120

[Rolf Sommerhalder]

Hello,

The current snapshot/i386 installed and runs successfully on a Nokia
IP120 appliance with a 10 GB harddisk where I have overwritten its
original IPSO/Checkpoint firewall image, see dmesg below.

However, I find that no watchdog is available, as geodesc (Geode
SC1100/SCx200 IAOC driver) does not get loaded, although it is in the
default GENERIC kernel config.

While comparing with dmesg of WRAP plattforms, I notice that on Nokia
lines such as the following are missing:
...
gscpcib0 at pci0 dev 18 function 0 NS SC1100 ISA rev 0x00
...
geodesc0 at pci0 dev 18 function 5 NS SC1100 X-Bus rev 0x00: iid 6
revision 3 wdstatus 0
...

Does gscpcib* not get loaded on Nokia because there is a Cyrix device
sitting on the PCI bus? Consequently, does geodesc* not get loaded
because gscpcib* is absent?


One motivation for me trying to use
 'sysctl kern.watchdog.auto=1',
 'sysctl kern.watchdog.period=30', and
 start 'watchdogd'
is the problem that 'reboot' on the Nokia plattform hangs indefinitely
after OpenBSD shuts down and successfully synced disks. This problem
has been reported earlier by others, and I just attempted to create a
workaround using Geode's hardware watchdog.

Can anyone please provide me guidance how I could debug the watchdog
(and eventually the reboot) problems further?  I have some experience
in building custom kernels, if that should be necessary. But I do not
yet know enough about PCI devices and drivers in order to interpret
the dmesg output correctly.

Thanks,
Rolf

#
# sysctl kern.watchdog.auto
sysctl: kern.watchdog.auto: value is not available
# sysctl kern.watchdog.period
sysctl: kern.watchdog.period: value is not available
#
# sysctl -a | grep watchdog
# (-- no output, e.g. there is no watchdog stuff)
#
# watchdogd
watchdogd: no watchdog timer available
#

#
# dmesg
OpenBSD 4.0 (GENERIC) #1104: Fri Sep  1 11:54:27 MDT 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi (Geode by NSC
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem  = 133787648 (130652K)
avail mem = 114688000 (112000K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(05) BIOS, date 07/17/00, BIOS32 rev. 0 @
0xeb0a0, SMBIOS rev. 2.3 @ 0xed2a8 (32 entries)
bios0: Jabil/Nokia IP110
pcibios0 at bios0: rev 2.1 @ 0xe8000/0x669
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4fb0/80 (3 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x1078 product 0x0100
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe8000/0x4000! 0xec000/0x4000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Cyrix GXm PCI rev 0x00
fxp0 at pci0 dev 14 function 0 Intel 82559ER rev 0x09, i82559S: irq
11, address 00:a0:8e:21:88:98
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
fxp1 at pci0 dev 15 function 0 Intel 82559ER rev 0x09, i82559S: irq
10, address 00:a0:8e:21:88:99
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
fxp2 at pci0 dev 16 function 0 Intel 82559ER rev 0x09, i82559S: irq
5, address 00:a0:8e:21:88:9a
inphy2 at fxp2 phy 1: i82555 10/100 PHY, rev. 4
pcib0 at pci0 dev 18 function 0 Cyrix Cx5530 South rev 0x30
Cyrix Cx5530 SMI rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 Cyrix Cx5530 IDE rev 0x00: no DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 ignored (other hardware responding at addresses)
pciide0: channel 1 ignored (not responding; disabled or no drives?)
Cyrix Cx5530 XpressAUDIO rev 0x00 at pci0 dev 18 function 3 not configured
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
wdc0 at isa0 port 0x1f0/8 irq 14
wd0 at wdc0 channel 0 drive 0: IC25N010ATDA04-0
wd0: 16-sector PIO, LBA, 9590MB, 19640880 sectors
wd0(wdc0:0:0): using BIOS timings
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
biomask f3c5 netmask ffe5 ttymask ffe7
pctr: no performance counters in CPU
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
#

OpenBGP / OpenBSD 3.8 on WRAP and VMware 5.5.1

[Rolf Sommerhalder]

OpenBGP really rocks - shall send a few six packs to Sechelt rapids
for your next Hackaton  there - thanks guys!  My upstream IP transit
provider was a bit surprised when he learned that his shining Cisco
7xxx is eBGP peering - incl. MD5 sums! - since about one month to a
mighty old Compaq desktop with a Pentium-III 450 MHz and 256 MByte
RAM...

Today, I tried to setup a iBGP peering session to that PC running
OpenBSD 3.8. I started with a virtual machine also using OpenBSD 3.8
as guest OS in VMware 5.5.1 on a SuSE 10.0 host. The iBGP peering
sessions come up nicely, but always die after the Holdtime expires.
tcpdump shows that from the VMware machine no BGP Keepalives are
originated nor answered. Which causes the BGP peering sessions to go
down while, or shortly after (depending on the Holdtime setting),
receiving the full feed updates.
However, it looks like this problem is not specific to OpenBGP.
Because I observe that 'top' does not update the display at all, even
though it accepts keyboard commands. So far I was unable to determine
the cause for this behaviour, nor find any other problem reports about
such problems running OpenBSD in VMware.

So I moved my /etc/bgp.conf over to a WRAP1E (Geode 266 MHz, 128 MByte
RAM) which runs OpenBSD 3.8 too. Amazing, bgpd runs now since a few
hours on this plattform. Like you documented before for Soekris
boards, a full feed with about 172k prefixes uses not more than 7
MByte RAM, and the CPU load is close to 0% once the initial updates
were received after startup.

Is there anyone out there who is willing to provide me with a second
BGP4 full feed for a few weeks?  I'd love to see the RIB selection in
action and document some measurements!  In exchange, I can offer a
full feed from AS8220 out of Switzerland (filtered to provde
read-only updates, of course, with or without MD4 sum).

Thanks,
Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

Another OpenBSD on WRAP user wrote to me saying that pxeboot works.
Also, I found http://www.ultradesic.com/?section=43 which descripbes
PXE booting OpenBSD for the Soekris plattform which is very similar to
WRAP.

Both encouraged me to dig deeper:
a) pxeboot finds both labels '!PXE' and 'PXENV' in the BIOS code;
b) the checksums of both those BIOS section are OK, e.g. PXE code in
the BIOS appears to be intact;
c) forcing pxeboot to use the legacy PXENV (instead of the !PXE v2.1)
API results in pxe_call()  to return OK. (forced by commenting out the
line   bang = 1;in /sys/arch/i386/stand/libsa/pxe.c)
However, it appears that result fields of those calls are filled with
zero. Because calls of pxeinfo() returns with IP addresses and netmask
as 0.0.0.0, instead of DHCP client  server addresses.
d) Upgrading WRAP's BIOS from 1.08 to 1.10 did not make any difference.

Notably finding c) encouraged me to also question my DHCP server
configuration, which currently is:

host wrap {
 hardware ethernet 00:0d:b9:01:a0:a4;
 option host-name wrapobsd;
 fixed-address 10.0.0.20;
 next-server 10.0.0.3;
 option root-path 10.0.0.3:/tftpboot;
 filename /pxeboot;
}

Just to crosscheck the PXE capability of WRAP's BIOS, I also tried to
load pxegrub from GRUB as 2nd stage boot loader, instead of pxeboot
from OpenBSD.  So far, pxegrub gets loaded, but I do not get any GRUB
prompt yet (something with serial console port parameters might still
be wron in my GRUB configure).

Any suggestions warmly welcome,
Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

Good news - my WRAPs now pxeboot OpenBSD as expected!  The culprit was
not pxeboot, but the etherboot PXE code 5.3.12 in BIOS 1.08 and 1.10,
as supplied by PCengines.

After building an etherboot 5.4.1 binary on rom-o-matic.org, merging
it into the BIOS and flashing the WRAPs, network boot of OpenBSD now
works very nicely :-)

I'll document that a bit more in detail in order to wrap up this
thread, and to inform PCengines that OpenBSD can easily network boot.

Thanks to all who replied, notably to Marc who triggered me to try
replacing the etherboot code in the BIOS,
Rolf

Debugging pxeboot on WRAP

[Rolf Sommerhalder]

pxeboot from OpenBSD3.8 (but also from 3.5, 3.6. and 3.7) fails to PXE
boot WRAP appliances with BIOS 1.08 which supports PXE using etherboot
(see www.pcengines.ch):


PC Engines WRAP.1C/1D/1E v1.08
640 KB Base Memory
130048 KB Extended Memory

01F0 - no drive found !
ROM segment 0xe000 length 0x8000 reloc 0x0002
Etherboot 5.3.12 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI PXE   Exports: PXE
Relocating _text from: [00089370,0009b230) to [07eee140,07f0)
Boot from (N)etwork (D)isk or (Q)uit? N

Probing pci nic...
[dp83815]
natsemi_probe: MAC addr 00:0D:B9:01:A0:A4 at ioaddr 0X1000
natsemi_probe: Vendor:0X100B Device:0X0020
dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex.
dp83815: Transceiver status 7869 advertising 05E1
dp83815: Setting half-duplex based on negotiated link capability.
Searching for server (DHCP)...
Me: 10.0.0.20, Server: 10.0.0.3, Gateway 10.0.0.1
Loading 10.0.0.3:pxeboot (PXE)done
probing: pc0 com0 pci pxe![2.1]  --- the cursor stays here


Searching the Web also for Soekris (which is similar to WRAP) hints
that the A20 gate hack may be the culprit for this halt.

Therefore tried to patch
 /sys/arch/i386/stand/libsa/gateA20.c
so that it leaves the A20 gate alone, even though it seems to be
already patched as outlined in
 http://blog.gmane.org/gmane.os.netbsd.devel.embedded/month=20050601
and in NetBSD3
 http://releng.netbsd.org/cgi-bin/req-3.cgi?show=504
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/stand/lib/gatea20.c

Then I rebuilt pxeboot:
 cd /sys/arch/i386/stand
 make
 scp /usr/src/sys/arch/i386/stand/pxeboot/pxeboot  [EMAIL PROTECTED]/tftpboot/

Still, the boot process halts in the 'probing' line, right after 'pxe![2.1]'

My /tftpboot/bsd should be ok as the same kernel file boot ok from a
CompactFlash card.

My /tftpboot/etc/boot.conf is:
 set tty com0
 stty com0 38400
 boot tftp:/bsd


Do you have any suggestion how I could debug or prevent this freeze,
for example by using debug compile flags in the Makefile, etc.?

Thanks for any suggestions,
Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

On 12/26/05, J.C. Roberts [EMAIL PROTECTED] wrote:
 01F0 - no drive found !
 
 snip
 My /tftpboot/bsd should be ok as the same kernel file boot ok from a
 CompactFlash card.

 Should we assume you have removed the CompactFlash device?

Yes, the CF card is removed, as someone trying PXE on Soekris
experienced problems when there was a such drive. But, although the
01F0 - no drive found ! error disappears after inserting a bootable
CF card, the pxeboot process still freezes.


 Have you tried bsd.rd ?

No, not yet. Will try that now, even though I expect that it might not
work as it was probably built for GENERIC machine and not for a WRAP
that uses an National SC1100 'Geode' ?

Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

On 12/26/05, J.C. Roberts [EMAIL PROTECTED] wrote:
 Have you tried bsd.rd ?

Just tried it, but pxeboot does not continue to boot either.

tcpdump on the TFTP server reveals that the WRAP's PXE client actually
requests and loads the pxeboot file, but does not get that far where
it would request the kernel file bsd or bsd.rd.

Now trying to understand the various debug switches in the Makefile,
hoping that they will reveal more output before the WRAP freezes.

Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

After inserting some printf() debug statements into
 /sys/arch/i386/stand/libsa/pxe.c
I found that the call to the assembler subroutine
 pxe_call(PXENV_GET_CACHED_INFO);
never returns.

It looks like either there is something wrong with that call, or with
the PXE code from Etherboot.

Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

The posting
 http://www.monkey.org/openbsd/archive2/bugs/200503/msg1.html
is interesting, as it points out that there has already been a problem
with pxe_call.

 single-stepping back into pxeboot.  Five instructions later, I hit the
 lockup point at 4012:403c.  The instruction causing the problem is:

   addrsize opsize lgdt [ds:0x45e80]

 which is the line marked Load the GDT in the following code from
 pxe_call.S in the OpenBSD source:

   /*
* real_to_prot()
*
* Switch the processor back into protected mode.
*/
 .globlreal_to_prot
   real_to_prot:
 .code16

 xorw  %ax, %ax
 movw  %ax, %ds/* Load %ds so we can get at Gdtr */
 data32 addr32 lgdt Gdtr   /* Load the GDT */
   ...

 Note the address [ds:0x45e80] that this resolves to in the pxeboot binary.
 In particular, note that the offset contains five hexadecimal digits.
 We're allegedly in real-mode at this point.  We can't access more than 64k
 in each segment, yet this instruction is trying to access data at an
 offset of approximately 279k.  The CPU doesn't like this.


Not sure whether this issue was fixed in OpenBSD yet. That code in OpenBSD3.8 is
/sys/arch/i386/stand/libsa/pxe_call.S
...
/*
 * real_to_prot()
 *
 * Switch the processor back into protected mode.
 */
.globl  real_to_prot
real_to_prot:
.code16

movw$LINKADDR  4, %ax /* We're linked to LINKADDR/16: */
movw%ax, %ds
data32 addr32 lgdt (Gdtr - LINKADDR)/* Reload the GDT */

movl%cr0, %eax  /* Enable protected mode */
orl $CR0_PE, %eax
movl%eax, %cr0

data32 ljmp $S32TEXT, $r2p32 /* Reload %cs, flush pipeline */
r2p32:
.code32
/* Reload 32-bit %ds, %ss, %es */
movl$S32DATA, %eax
mov %ax, %ds
mov %ax, %ss
mov %ax, %es
...

Ah yes, according to CVS log
 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/pxe_call.S
that real/protected mode problem should be patched since v1.2.

But did current v1.3 eventually break it again?

Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

 Ah yes, according to CVS log
  
 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/pxe_call.S
 that real/protected mode problem should be patched since v1.2.

 But did current v1.3 eventually break it again?

Replacing pxe_call.S v1.3 by v1.2 does unfortunately not solve the
problem of pxe_call() never returning.

Rolf

Re: Debugging pxeboot on WRAP

[Rolf Sommerhalder]

On 12/26/05, Tom Cosgrove [EMAIL PROTECTED] wrote:

 You could find out if pxe_call works at all on the WRAP in its current
 implementation by putting a printf() after it, and seeing if there'
 any output.  Look in pxe.c:pxe_init().

Thanks, did that and definitely pxe_call() never returns. And it is
not specific to pxe_call(PXENV_GET_CACHED_INFO), because I also called
pxeinfo() which does a pxe_call(PXENV_UNDI_GET_NIC_TYPE) which never
returns neither!

As you say, it looks like I might have to refresh rusty gdb skills
now, and figure out what 'boch' does (as I am totally inexperienced
with baby sitting ;-)

Rolf