Good SMTP and POP proxy for OpenBSD

[Siju George]

Hi all,

Till now I have been Simply NATing SMTP and POP connections form the
LAN through the OpenBSD 3.8 Firewall.

I would like to have some finer control of mails comming in and going
out and would like to install a SMTP Proxy and also a POP proxy on my
OpenBSD Firewall.

Messagewall doesnot seem to be in ports.

Could some one recommend a good Software for me in these two
categories available for OpenBSD?

Thankyou so much :-)

Kind Regards

Siju

Re: isakmpd cannot teardown Phase1 SA

[Matthew Closson]

I was given some info off list and checked the webcvs, indeed this feature 
has been added to -current.  Thanks.


On Sun, 5 Feb 2006, Matthew Closson wrote:


http://archives.neohapsis.com/archives/openbsd/2005-09/0007.html

In summary, a user reported that isakmpd will not current teardown a Phase1 
SA when recieving a 't ' command via the fifo user interface. Hans 
replies that there is a patch for it, but it won't make 3.8 release.


Has this been implemented in -current or if not could anyone send me the
patch?  Thanks,

-Matt-

Re: kernel debugging when booted off install cd

[Charles Sprickman]

On Sun, 5 Feb 2006, Nick Holland wrote:


Charles Sprickman wrote:

Hello all,

I'm still not able to get OpenBSD 3.4->3.8 loaded on my old firewall box. 
It either freezes or panics when probing (or creating?) "rd0", which I 
assume is the ramdisk used in the install.  It runs 3.3 fine.


So rather than just asking some random questions, I'd like to know how to 
save a dump when booting off of the install CD.  I do have a serial console 
available (set tty com0).  If getting a dump isn't possible, I'd then like 
to know how to get into the kernel debugger.


I figure that I can gather information that's more helpful this way.


You aren't going to get nor save a dump when booting off the install CD. 
You really don't want a panicked kernel writing to your good data disks, do 
you?


In this case, I don't mind.  I've got another box in it's place so I'm 
prepared to do anything I need to do to get this running a current version 
of OBSD.


The install kernels don't have all the bells and whistles of the production 
kernel, that's how they fit on floppies and such.


Got it, so there's absolutely no way to dump to a disk?  It looks like it 
tries to...  I also don't have another box handy to build a custom 3.8 
kernel on.  And I also wonder if a non-rd kernel would panic, as the panic 
happens as it tries to deal with the ramdisk...


Use your serial cable to capture the output of the boot process.  THAT will 
tell us much more about your hardware.


I've got a thread here:

http://marc.theaimsgroup.com/?t=11366659953&r=1&w=2

I reposted since I just wanted to get the basics on getting a dump in 
OBSD.  I figured once I had that, I could actually file a PR or something.


A completely Wild A..ed Guess, based on the symptoms, you may have way too 
little RAM for the newer kernels (16M will get you running still, but 32M is 
a practical minimum) and floating point emulation broke after 3.3 on i386 
(translation: no more 486sx or 80386 w/o 80387 support).  If I were to bet, 
I'd say you probably have no FPU on your machine.


It's old, but not that old.  I've got 128MB of RAM.  Processor is an AMD 
K6-2/500 clocked down to 300.  VIA chipset.  I've had memtest86+ go 
through about a dozen runs with no errors.  3.3 works flawlessly.


Not sure where to go from here...

Thanks,

Charles


Nick.

Re: httpd question - solved

[Keith Richardson]

I will have to update ServerName each time I get a new IP address.

Dave Feustel 
   



i have been running apache on openbsd since 2.9 on a dynamic IP and have
never had to do any of this. 


#grep ServerName /var/www/conf/httpd.conf
ServerName neotrance.dyndns.org


 

If you get your IP dynamically from you ISP, your IP can potentially 
change every max-lease-time


This will handle the pesty case of your IP changing.

1. dyndns.org - get a free subdomain to map to your IP. 
2. ddclient package - updates your DNS whenever your IP changes. 

Although the package just copies over the perl script, I add a 
user/group _ddclient.  If you are still running 3.8-release, consider 
creating a folder /etc/ddclient, chown / chgrp and move the conf , cache 
and pid file to that folder.  -current already does this for you (at 
least, the folder part.  I don't think the @newuser, @newgroup will be 
added since people not running in daemon mode don't need it)


before you ask, -current's dhclient does not support hooks. 


-Keith Richardson

Re: Windows CLI FTP and OBSD 3.9 ftp-proxy

[Karl Kopp]

BINGO - Dissable the Windows firewall and we have proper FTP connectivity!
Thanks for your help - knew it wasn't OBSD ;)

Karl

On 2/2/06, Daniel Hamlin <[EMAIL PROTECTED]> wrote:
>
> Joachim Schipper wrote:
> > On Thu, Feb 02, 2006 at 11:21:02AM +1100, Karl Kopp wrote:
> >
> >> Hi Everyone!
> >>
> >> I just upgraded one of our firewalls from 3.0 OBSD (I know, I know,
> I've
> >> been busy, for 4 years :) to 3.8 (which took 30 mins - LOVE that!).
> I've
> >> also added ftp-proxy from current to handle all our FTP connections.
> Things
> >> are working MUCH better now (browsers can hit FTP servers on the
> outside
> >> world) but I'm still having problems with the ftp cmd in Windows (XP
> for
> >> example). BSD / Linux boxes can use their CLI FTP command no probs
> (seem to
> >> default to PASV), but Windows just wont connect. I've used the info
> from
> >> here 
> and
> >> here  but still can't
> seem
> >> to connect. ftp-proxy is running, and I have the following lines in my
> >> pf.conf:
> >>
> >> scrub in all
> >>
> >> ##
> >> # FTP bits
> >> nat-anchor "ftp-proxy/*"
> >> rdr-anchor "ftp-proxy/*"
> >> rdr pass on $int_if proto tcp from $internal_net to any port 21 ->
> >> 127.0.0.1por
> >> t 8021
> >>
> >>
> >> ...
> >>
> >>
> >> ###
> >> # Begin filtering ruleset
> >>
> >> # For FTP
> >> anchor "ftp-proxy/*"
> >> pass out proto tcp from $external_addr to any port 21 keep state
> >>
> >
> > Well, as you noted, all FTP clients you used use PASV, but the Windows
> > CLI ftp client doesn't support that (and a lot of other things, BTW).
> >
> > I'm not up to speed on the new ftp-proxy, but try setting a
> > non-Windows-CLI client to use active FTP and see if the same thing
> > happens - it'll at least isolate the error.
> >
> >   Joachim
> >
> >
> I spent hours working on this problem one day.  I could be wrong, but my
> guess it's related to the mighty Windows firewall.  When the Windows
> firewall was disabled, the FTP client would connect fine through the FTP
> proxy.
>
> My guess is that the Windows firewall is expecting the response to come
> from the site that you are FTP'ing from, but the response is actually
> coming back from the FTP proxy, prompting the Windows firewall to drop
> the incoming packets.
>
>
> Dan

Re: error on ifconfig, bssid

[Lucas Reddinger]

one more question about the same thing. i got my access point i wish
to use on a NWID that noone else uses. i specify this nwid using
ifconfig on my clients. however, as soon as i get a better signal from
another access point on a different NWID, my card switches, and my
clients lose their connection. here's what it looks like:

=
$ ifconfig wi0
wi0: flags=8843 mtu 1500
lladdr 00:80:c6:e3:1c:ff
description: "dhcp
groups: egress
media: IEEE802.11 autoselect (DS11)
status: active
ieee80211: nwid linksys_9f 2dBm (auto)
inet6 fe80::280:c6ff:fee3:1cff%wi0 prefixlen 64 scopeid 0x2
inet 192.168.1.75 netmask 0xff00 broadcast 192.168.1.255
$ wicontrol
NIC serial number:  [ 3841 ]
Station name:   [ WaveLAN/IEEE node ]
SSID for IBSS creation: [ IBSS ]
Current netname (SSID): [ greenmonster ]
Desired netname (SSID): [ linksys_9f ]
Current BSSID:  [ 00:0c:41:68:70:f8 ]
Channel list:   [ 2047 ]
IBSS channel:   [ 1 ]
Current channel:[ 4 ]
Comms quality/signal/noise: [ 36 67 4 ]
Promiscuous mode:   [ Off ]
Process 802.11b Frame:  [ Off ]
Port type (1=BSS, 3=ad-hoc, 6=Host AP): [ 1 ]
MAC address:[ 00:80:c6:e3:1c:ff ]
TX rate (selection):[ 3 ]
TX rate (actual speed): [ 11 ]
Maximum data length:[ 2304 ]
RTS/CTS handshake threshold:[ 2347 ]
Create IBSS:[ Off ]
Antenna diversity (0=auto,1=pri,2=aux): [ ]
Microwave oven robustness:  [ On ]
Roaming mode(1=firm,3=disable): [ 1 ]
Access point density:   [ 1 ]
Power Management:   [ Off ]
Max sleep time: [ 100 ]
Enhanced Security mode: [ ]
Intersil Prism2-based card: [ 1 ]
Card info:  [ PRISM2 HWB3163 rev.B, Firmware 1.4.9 ]
Encryption: [ Off ]
Encryption algorithm:   [ Firmware WEP ]
Authentication type
(1=OpenSys, 2=Shared Key):  [ 1 ]
TX encryption key:  [ 1 ]
Encryption keys:[  ][  ][  ][  ]
$ sudo wicontrol -L
AP Information
ap[0]:  netname (SSID): [ greenmonster ]
BSSID:  [ 00:0c:41:68:70:f8 ]
Channel:[ 4 ]
Beacon Interval:[ 100 ]
Quality/Signal/Noise [signal]:  [ 12 / 22 / 10 ]
Capinfo:[ ESS PRIV ]
DataRate [Mbps]:[ 11.0 ]
AvailableRates [Mbps]:  [ 1.0 5.5 11.0 11.0 ]
ap[1]:  netname (SSID): [ linksys_9f ]
BSSID:  [ 00:13:10:e8:9f:44 ]
Channel:[ 6 ]
Beacon Interval:[ 100 ]
Quality/Signal/Noise [signal]:  [ 11 / 21 / 10 ]
Capinfo:[ ESS ]
DataRate [Mbps]:[ 11.0 ]
AvailableRates [Mbps]:  [ 1.0 2.0 5.5 11.0 18.0 24.0 36.0 54.0 ]
$
=

notice the:
> Current netname (SSID): [ greenmonster ]
> Desired netname (SSID): [ linksys_9f ]
but "wicontrol -L" proves that the other access point is still there.
this just happens when greenmonster's signal is stronger than
linksys_9f's.
sorry, but this is so frustrating to me, i can tell ifconfig to use a
certain nwid, channel, &c; but as soon as it gets a better signal from
another access point, it's game over.

any help is _much_ appreciated.

lucas reddinger

Re: nmap Issue on 3.8-release?

[Melameth, Daniel D.]

Joachim Schipper wrote:
> On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. wrote:
> > I don't get it--it appears nmap is broken.  Perhaps I'm overlooking
> > something obvious, but any thoughts appreciated...
> > 
> > 
> > An nmap scan gives me this:
> > 
> > $ sudo nmap 208.139.x.x
> > 
> > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-03
> > 19:45 MST Note: Host seems down. If it is really up, but blocking
> > our ping probes, try -P0 Nmap finished: 1 IP address (0 hosts up)
> > scanned in 2.109 seconds 
> > 
> > Which I follow up with a:
> > 
> > $ ping -c 5 208.139.x.x
> > PING 208.139.x.x (208.139.x.x): 56 data bytes
> > 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms
> > 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=84.497 ms
> > 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=82.354 ms
> > 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=87.825 ms
> > 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=85.699 ms
> > --- 208.139.x.x ping statistics ---
> > 5 packets transmitted, 5 packets received, 0.0% packet loss
> > round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 ms
> > 
> > Running while the above is happening, tcpdumps yield:
> > 
> > $ sudo tcpdump -nqi pppoe0 src host 208.139.x.x and dst host
> > 209.180.x.x tcpdump: listening on pppoe0, link-type PPP_ETHER
> > 19:45:49.671358 208.139.x.x > 209.180.x.x: icmp: 0 0
> > 19:45:49.674068 208.139.x.x.80 > 209.180.x.x.57989: tcp 0 (DF)
> > 19:45:50.683407 208.139.x.x > 209.180.x.x: icmp: 0 0
> > 19:45:50.691346 208.139.x.x.80 > 209.180.x.x.57985: tcp 0 (DF)
> > 19:46:00.565862 208.139.x.x > 209.180.x.x: icmp: 0 0
> > 19:46:01.565834 208.139.x.x > 209.180.x.x: icmp: 0 0
> > 19:46:02.573631 208.139.x.x > 209.180.x.x: icmp: 0 0
> > 19:46:03.589132 208.139.x.x > 209.180.x.x: icmp: 0 0
> > 19:46:04.596986 208.139.x.x > 209.180.x.x: icmp: 0 0
> > 
> > $ sudo tcpdump -qni pflog0
> > tcpdump: WARNING: pflog0: no IPv4 address assigned
> > tcpdump: listening on pflog0, link-type PFLOG
> > 
> > 
> > I'm not certain where to look next.
> 
> Look into what the return packets actually contain. If, for instance,
> the remote end is a OpenBSD firewall that has been configured
> explicitly to drop nmap (using pf's passive OS recognition feature,
> for instance), you'd see exactly what you see now.
> (Discarding OpenBSD for a while, almost any decent firewall can be
> configured to drop traffic that looks like it came from nmap.)
> 
> And the return packets are not too useful - is that first icmp packet
> an echo reply or a destination-unreachable notice? And the TCP packet
> - is it a SYN/ACK or RST packet?

The remote end is an OpenBSD machine that has not been configured to
drop nmap packets and allows incoming ssh and http connections.

On second thought, I'd not certain why I made tcpdump quiet--habit
perhaps.  Here is the same test with more verbosity:


$ sudo nmap 208.139.x.x

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-02-05 19:43
MST
Note: Host seems down. If it is really up, but blocking our ping probes,
try -P0
Nmap finished: 1 IP address (0 hosts up) scanned in 2.163 seconds

$ ping -c 5 208.139.x.x
PING 208.139.x.x (208.139.x.x): 56 data bytes
64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=85.137 ms
64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=83.103 ms
64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=90.038 ms
64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=86.490 ms
64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=92.098 ms
--- 208.139.x.x ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 83.103/87.373/92.098/3.274 ms

$ sudo tcpdump -ni pppoe0 host 208.139.x.x
tcpdump: listening on pppoe0, link-type PPP_ETHER
19:43:01.507785 209.180.x.x > 208.139.x.x: icmp: echo request
19:43:01.507980 209.180.x.x.60199 > 208.139.x.x.80: . ack 2409580574 win
1024
19:43:01.595748 208.139.x.x > 209.180.x.x: icmp: echo reply
19:43:01.600100 208.139.x.x.80 > 209.180.x.x.60199: R
2409580574:2409580574(0) win 0 (DF)
19:43:02.520065 209.180.x.x > 208.139.x.x: icmp: echo request
19:43:02.520244 209.180.x.x.60200 > 208.139.x.x.80: . ack 2829011038 win
1024
19:43:02.609989 208.139.x.x > 209.180.x.x: icmp: echo reply
19:43:02.611334 208.139.x.x.80 > 209.180.x.x.60200: R
2829011038:2829011038(0) win 0 (DF)
19:43:37.650310 209.180.x.x > 208.139.x.x: icmp: echo request
19:43:37.735247 208.139.x.x > 209.180.x.x: icmp: echo reply
19:43:38.660020 209.180.x.x > 208.139.x.x: icmp: echo request
19:43:38.743035 208.139.x.x > 209.180.x.x: icmp: echo reply
19:43:39.669973 209.180.x.x > 208.139.x.x: icmp: echo request
19:43:39.759944 208.139.x.x > 209.180.x.x: icmp: echo reply
19:43:40.679970 209.180.x.x > 208.139.x.x: icmp: echo request
19:43:40.766399 208.139.x.x > 209.180.x.x: icmp: echo reply
19:43:41.689986 209.180.x.x > 208.139.x.x: icmp: echo request
19:43:41.781991 208.139.x.x > 209.180.x.x: icmp: echo reply

$ sudo tcpdump 

Re: Need for a benchmark recommendation

[Damien Miller]

On Sat, 4 Feb 2006, Andris Delfino wrote:

> I need to run a benchmark for testing the temperature of my system,
> which of these
(http://www.openbsd.org/cgi-bin/cvsweb/ports/benchmarks/?only_with_tag=OPENBS
D_3_8)
> do you recommend?

If you just want to make your CPU hot, then running "openssl speed" a couple
of time should be sufficient.

-d

Re: Any conclusions on the uvisor STALLED status with CLIE devices?

[Andrew Smith]

OK, after playing with uvisor and USB sniffer software for the weekend I
have fixed this for me... *sigh* there is a lot of stuff going on in the
CLIE Windows driver that the CLIE doesn't like and it seems the driver
filters all the nastiness out.

After struggling with stalled commands, timeouts etc. etc. I found that the
CLIE PEG-T625 (which identifies as USB_PRODUCT_SONY_CLIE_40) actually
returns it's pipes on command 03 like a Visor. Simply switching the table
doesn't fix it though because when the call to get the Free Space at the end
of the init function times out it puts the CLIE end of the USB serial to
sleep :(... this wasn't obvious and I wasted a lot of time finding this out.
One simple fix is to disable that part of the function.

Here is a little patch that you can try if you have a device that is
returning STALLED on the init part of uvisor, it's only flagged to turn off
the Free Space call on the USB_PRODUCT_SONY_CLIE_40 device (also changes it
to use the Visor hooks rather than the Palm 4 hooks which stall the device).

Apply patch to /sys/dev/usb/uvisor.c 

170a171
> #define NOFRE 0x0004
186c187
<   {{ USB_VENDOR_SONY, USB_PRODUCT_SONY_CLIE_40 }, PALM4 },
---
>   {{ USB_VENDOR_SONY, USB_PRODUCT_SONY_CLIE_40 }, VISOR | NOFRE },
446a448,450
>   /* Skip the free bytes check.. this hangs some sony CLIE devices */
>   if (sc->sc_flags & NOFRE) return (err);
>   
457d460
<

Then make yourself a Kernel.

It's hardly a patch really it simply adds another device bitmap, sets that
on the device that you want to skip the free space check and in the init
function returns before the free space check if the flag is set.

To enable on other devices simply replace PALM4 with VISOR | NOFRE.

I'm now curious if anyone actually has a CLIE model that identifies as this
entry and actually works with the current driver... please tell me if you
do.

This patch has been tested on 3.8 -release on i386 and 3.9 -current on ARM -
ahem yes I have had my CLIE syncing with my Sharp Zaurus :)

- Andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Smith
Sent: 04 February 2006 14:00
To: misc@openbsd.org
Subject: Any conclusions on the uvisor STALLED status with CLIE devices?

I have an old CLIE PEG-T625C device that I have been trying to make work
with the uvisor driver to get ucom endpoints mapped to cuaUx with a USB
cable.

 

The device IDs itself to the driver (based upon the standard table in the
driver) as USB_PRODUCT_SONY_CLIE_40 which is mapped to the PALM4 handler,
however, when the usbd_do_request_flags call is made in the PALM4 section of
the uvisor_init function I always get back USBD_STALLED as status.

 

I have been down two routes to try to fix this (although I am not familiar
with the kernel debug features of OpenBSD yet).

 

i. I have set up a VMWare machine running Windows XP, CLIE
Palmdesktop and installed 'snoopypro' from http://usbsnoop.sourceforge.net
  with this I have examined the USB
conversation that the commercial Sony driver has with the CLIE. - not
particularly different from the uvisor init but some extra vendor endpoint
stuff.

ii.I have compared the working Linux 2.6 visor driver (I
have a Gentoo system running this driver and it works well) - I have made
the minimal changes to the uvisor driver necessary to change the 03 command
that is normally used to 04 as used by this driver and checked that the data
structures are the same as the ones used in the Linux driver. They are byte
for byte the same (unless there is a packing issue of course).

 

Both experiments still result in the call to usbd_do_request_flags returning
the STALLED status - where I was previously convinced that the device was
stalling because it was being sent a command it didn't recognise now I am
not so sure.. I'm beginning to speculate that something in the USB transfer
handler is fouling up.

 

The question is, has anybody else tried this with this model or any other
model showing the STALLED status on init and what conclusions/speculations
did you come to if you didn't fix it?

 

- Andy

Re: kernel debugging when booted off install cd

[Nick Holland]

Charles Sprickman wrote:

Hello all,

I'm still not able to get OpenBSD 3.4->3.8 loaded on my old firewall 
box. It either freezes or panics when probing (or creating?) "rd0", 
which I assume is the ramdisk used in the install.  It runs 3.3 fine.


So rather than just asking some random questions, I'd like to know how 
to save a dump when booting off of the install CD.  I do have a serial 
console available (set tty com0).  If getting a dump isn't possible, I'd 
then like to know how to get into the kernel debugger.


I figure that I can gather information that's more helpful this way.


You aren't going to get nor save a dump when booting off the install CD. 
   You really don't want a panicked kernel writing to your good data 
disks, do you?


The install kernels don't have all the bells and whistles of the 
production kernel, that's how they fit on floppies and such.


Use your serial cable to capture the output of the boot process.  THAT 
will tell us much more about your hardware.


A completely Wild A..ed Guess, based on the symptoms, you may have way 
too little RAM for the newer kernels (16M will get you running still, 
but 32M is a practical minimum) and floating point emulation broke after 
3.3 on i386 (translation: no more 486sx or 80386 w/o 80387 support).  If 
I were to bet, I'd say you probably have no FPU on your machine.


Nick.

Re: sunfire v120 net installation problem

[Miod Vallat]

> Hi all,
> I'm trying to install 3.8 on a sunfire v120
> 
> I am able to net boot it from an i386 using linux and openbsd38.
> Things seem ok up to booting bsd.rd, but then output stops after:
> ..
> rd0: fixed, 6144 blocks
> root on rd0a
> rootdev=0x500 rrootdev=0x3d00 rawdev=0x3d02
> (note that the last 2 lines take a long time to come up)

[...]

> The only output i can provide is the serial console log:
> ==
> lom>poweron
> lom>
> LOM event: +2h14m38s host power on

Isn't your serial cable connected to the LOM port? This is not supported
once OpenBSD is booting, you need to connect your console to the regular
serial port of the machine.

Miod

Re: Using OpenBGPD, some advice or words of wisdom

[Claudio Jeker]

On Sun, Feb 05, 2006 at 01:22:03PM -0800, Edward Ray wrote:
> I have been toying with the idea of using OpenBGPD because my PoS 3640 route
> does not have enough RAM to support full routing tables.  I am still stuck
> with the 3640 as the gateway for the 4-bonded-T1s coming into my network,
> but I would like to put a OpenBSD machine between it and my hardware
> firewall(s) so that I can get the full routing tables and eventually
> multi-home with another ISP.
> 
> I have read the presentations by Henning Brauer at
> http://www.openbgpd.org/papers.html; it seems pretty straightforward to set
> up.  I would appreciate any advice or words of wisdom from those people who
> use OpenBGPD.  I plan to use a PIII 1GHz or better with 1 GB of RAM; should
> be enough for full routing tables and enough room for routing table
> expansion as the Internet grows.
> 

A PIII 1GHz with 1GB of RAM should be sufficent. I'm toying with a Via C3
with 512MB RAM that has more or less 10 full feeds. The RDE uses about
200MB of RAM. Even soekrises where used to do BGPD testing but then we
limited us to not more than 2 full feeds.

-- 
:wq Claudio

Re: Preventing breaks on Sparc's

[Jasper Lievisse Adriaanse]

On Sun, 05 Feb 2006 13:46:02 -0700
Chris Cameron <[EMAIL PROTECTED]> wrote:

> Bryan Irvine wrote:
> >
> >
> > If I unplug both drives, set bootmode to reset_nvram in LOM and boot
the
> > machine I can use break to get to an ok prompt. However if I plug the
> > drives back in, the instant the OpenBSD boot loader comes up, I again
> > can't get back to an ok prompt. This is while OpenBSD is loaded (or
> > loading), or while the machine is coming up, but before the boot
loader
> > has started.
> >
> >
> > I hit stop-a before the boot loader comes up. :-)
> >
>
>
> Right, doesn't work. From the instant I hit the power button, I can send
> breaks till I'm blue in the face. It ignores them.
Are you sure your keys aren't defect :-)

cheers,
Jasper

>
>
> Chris
>


--
"Security is decided by quality" -- Theo de Raadt

[demime 1.01d removed an attachment of type application/pgp-signature]

Using OpenBGPD, some advice or words of wisdom

[Edward Ray]

I have been toying with the idea of using OpenBGPD because my PoS 3640 route
does not have enough RAM to support full routing tables.  I am still stuck
with the 3640 as the gateway for the 4-bonded-T1s coming into my network,
but I would like to put a OpenBSD machine between it and my hardware
firewall(s) so that I can get the full routing tables and eventually
multi-home with another ISP.

I have read the presentations by Henning Brauer at
http://www.openbgpd.org/papers.html; it seems pretty straightforward to set
up.  I would appreciate any advice or words of wisdom from those people who
use OpenBGPD.  I plan to use a PIII 1GHz or better with 1 GB of RAM; should
be enough for full routing tables and enough room for routing table
expansion as the Internet grows.


Thanks in advance

Edward Ray
CISSP, GCIA, GCIH, MCSE:Security, PE
Netsec Design, Inc.
http://www.netsecdesign.com

isakmpd cannot teardown Phase1 SA

[Matthew Closson]

http://archives.neohapsis.com/archives/openbsd/2005-09/0007.html

In summary, a user reported that isakmpd will not current teardown a 
Phase1 SA when recieving a 't ' command via the fifo user interface. 
Hans replies that there is a patch for it, but it won't make 3.8 release.


Has this been implemented in -current or if not could anyone send me the
patch?  Thanks,

-Matt-

Re: Preventing breaks on Sparc's

[Chris Cameron]

Bryan Irvine wrote:



If I unplug both drives, set bootmode to reset_nvram in LOM and boot the
machine I can use break to get to an ok prompt. However if I plug the
drives back in, the instant the OpenBSD boot loader comes up, I again
can't get back to an ok prompt. This is while OpenBSD is loaded (or
loading), or while the machine is coming up, but before the boot loader
has started.


I hit stop-a before the boot loader comes up. :-)




Right, doesn't work. From the instant I hit the power button, I can send 
breaks till I'm blue in the face. It ignores them.



Chris

Re: Preventing breaks on Sparc's

[Bryan Irvine]

> If I unplug both drives, set bootmode to reset_nvram in LOM and boot the
> machine I can use break to get to an ok prompt. However if I plug the
> drives back in, the instant the OpenBSD boot loader comes up, I again
> can't get back to an ok prompt. This is while OpenBSD is loaded (or
> loading), or while the machine is coming up, but before the boot loader
> has started.


I hit stop-a before the boot loader comes up. :-)

--Bryan

Preventing breaks on Sparc's

[Chris Cameron]

What is it OpenBSD does to prevent breaks/Stop+A from working?

Did a net install of 3.8 on a V100 and was playing with RAIDFrame. 
Trying to get it to boot off the second disk, it refuses to go to an ok 
prompt.


If I unplug both drives, set bootmode to reset_nvram in LOM and boot the 
machine I can use break to get to an ok prompt. However if I plug the 
drives back in, the instant the OpenBSD boot loader comes up, I again 
can't get back to an ok prompt. This is while OpenBSD is loaded (or 
loading), or while the machine is coming up, but before the boot loader 
has started.


For now I've just set it not to auto-boot, but ideally break would work 
outside of OpenBSD, and be disabled only while it's running.



Anyone know what's going on?

Thanks,
Chris

Re: x11 problem in current: "The XKEYBOARD keymap compiler (xkbcomp) reports..."

[Didier Wiroth]

Oups ... sorry!!! submitted the dmesg a few times ...
Here is my Xorg.0.log

(--) checkDevMem: using aperture driver /dev/xf86
(--) Using wscons driver in pcvt compatibility mode (version 3.32)
(WW) GARTInit: AGPIOC_INFO failed (Device not configured)

X Window System Version 6.9.0 (for OpenBSD)
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 6.9
Build Operating System: OpenBSD 3.9 i386 [ELF] 
Current Operating System: OpenBSD nc6000.internal.local 3.9 GENERIC#8 i386
Build Date: 04 February 2006
Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb  5 17:13:39 2006
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) FontPath set to 
"/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(**) ModulePath set to "/usr/X11R6/lib/modules"
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.2
X.Org Video Driver: 0.8
X.Org XInput driver : 0.5
X.Org Server Extension : 0.2
X.Org Font Renderer : 0.4
(II) Loader running on openbsd
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.so
(II) Module bitmap: vendor="X.Org Foundation"
compiled for 6.9.0, module version = 1.0.0
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
compiled for 6.9.0, module version = 1.0.0
ABI class: X.Org Video Driver, version 0.8
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,3340 card 103c,0890 rev 03 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 8086,3341 card , rev 03 class 06,04,00 hdr 01
(II) PCI: 00:1d:0: chip 8086,24c2 card 103c,0890 rev 03 class 0c,03,00 hdr 80
(II) PCI: 00:1d:1: chip 8086,24c4 card 103c,0890 rev 03 class 0c,03,00 hdr 00
(II) PCI: 00:1d:2: chip 8086,24c7 card 103c,0890 rev 03 class 0c,03,00 hdr 00
(II) PCI: 00:1d:7: chip 8086,24cd card 103c,0890 rev 03 class 0c,03,20 hdr 00
(II) PCI: 00:1e:0: chip 8086,2448 card , rev 83 class 06,04,00 hdr 01
(II) PCI: 00:1f:0: chip 8086,24cc card , rev 03 class 06,01,00 hdr 80
(II) PCI: 00:1f:1: chip 8086,24ca card 103c,0890 rev 03 class 01,01,8a hdr 00
(II) PCI: 00:1f:5: chip 8086,24c5 card 103c,0890 rev 03 class 04,01,00 hdr 00
(II) PCI: 00:1f:6: chip 8086,24c6 card 103c,0890 rev 03 class 07,03,00 hdr 00
(II) PCI: 01:00:0: chip 1002,4e50 card 103c,0890 rev 00 class 03,00,00 hdr 00
(II) PCI: 02:04:0: chip 168c,0013 card 0e11,00e6 rev 01 class 02,00,00 hdr 00
(II) PCI: 02:06:0: chip 1217,7223 card fffd, rev 00 class 06,07,00 hdr 82
(II) PCI: 02:06:1: chip 1217,7223 card fffd, rev 00 class 06,07,00 hdr 82
(II) PCI: 02:06:2: chip 1217,7110 card 103c,0890 rev 00 class 08,80,00 hdr 80
(II) PCI: 02:06:3: chip 1217,7223 card fffd, rev 00 class 06,07,00 hdr 82
(II) PCI: 02:0e:0: chip 14e4,165e card 103c,0890 rev 03 class 02,00,00 hdr 00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,5), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
[0] -1  0   0x - 0x (0x1) IX[B]
(II) Bus 0 non-prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set)
(II) Bus 1 I/O range:
[0] -1  0   0x2000 - 0x20ff (0x100) IX[B]
[1] -1  0   0x2400 - 0x24ff (0x100) IX[B]
[2] -1  0   0x2800 - 0x28ff (0x100) IX[B]
[3] -1  0   0x2c00 - 0x2cff (0x100) IX[B]
(II) Bus 1 non-prefetchable memory range:
[0] -1  0   0x9030 - 0x903f (0x10) MX[B]
(II) Bus 1 prefetchable memory range:
[0] -1  0   0x9800 - 0x9fff (0x800) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 2: bridge is at (0:30:0), (0,2,5), BCTRL: 0x0006 (VGA_EN is cleared)
(II) Bus 2 non-prefetchable memory range:
[0] -1  0   0x9000 - 0x902f (

x11 problem in current: "The XKEYBOARD keymap compiler (xkbcomp) reports..."

[Didier Wiroth]

Hi,

(Actually I'm running current on a few boxes without problem).
I decided to install it on my laptop a hp nc6000 (see dmesg and  Xorg.0.log 
below).

Unfortunately I can't load my correct keyboard layout, swiss french:
Section "InputDevice"
Identifier  "Keyboard0"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "fr_CH"
EndSection

I tried different other keyboard mappings like de, us etc, they all did work!

Here is the error that appears, while using "XkbLayout "fr_CH", and when 
exiting X11:

(==) Using config file: "/etc/X11/xorg.conf"
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:Can't find file "pc/fr_CH" for symbols include
>   Exiting
>   Abandoning symbols file "default"
Errors from xkbcomp are not fatal to the X server
Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from li
st!
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"
waiting for X server to shut down .FreeFontPath: FPE "/usr/X11R6/lib/X11/fonts/m
isc/" refcount is 2, should be 1; fixing.

I made a new make build of /usr/src and my /usrXF4 sources, but that didn't 
help I'm not able to use this mapping.

What can I do to solve the problem?

In advance, thanks a lot!!!
Regards
Didier

Here is my dmesg and Xorg.0.log, if you would like to get my entire xorg.conf, 
please let me know.
OpenBSD 3.9-beta (GENERIC) #8: Sun Feb  5 17:00:47 CET 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) M processor 1600MHz ("GenuineIntel" 686-class) 1.60 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,EST,TM2
cpu0: Enhanced SpeedStep 1600 MHz (1484 mV): speeds: 1600, 1400, 1200, 1000, 
800, 600 MHz
real mem  = 1073127424 (1047976K)
avail mem = 972496896 (949704K)
using 4278 buffers containing 5376 bytes (52500K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(c3) BIOS, date 06/23/05, BIOS32 rev. 0 @ 0xf
apm0 at bios0: Power Management spec V1.2 (BIOS managing devices)
apm0: AC on, battery charge unknown
apm0: flags 130102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x2000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0840/160 (8 entries)
pcibios0: bad IRQ table checksum
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf6360/160 (8 entries)
pcibios0: PCI Exclusive IRQs: 5 10 11
pcibios0: no compatible PCI ICU found: ICU vendor 0x8086 product 0x24cc
pcibios0: PCI bus #5 is the last bus
bios0: ROM list: 0xc/0x1
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82855PE Hub" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82855PE AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M10 NP" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x03: irq 10
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x03: irq 10
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x03: irq 10
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x03: irq 10
usb3 at ehci0: USB revision 2.0
uhub3 at usb3
uhub3: Intel EHCI root hub, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x83
pci2 at ppb1 bus 2
ath0 at pci2 dev 4 function 0 "Atheros AR5212" rev 0x01: irq 11
ath0: AR5213 5.6 phy 4.1 rf5111 1.7 rf2111 2.3, WOR0W, address 00:0f:20:94:99:e5
cbb0 at pci2 dev 6 function 0 "O2 Micro OZ711E0 CardBus" rev 0x00: irq 10
cbb1 at pci2 dev 6 function 1 "O2 Micro OZ711E0 CardBus" rev 0x00: irq 10
"O2 Micro OZ711Mx CardBus" rev 0x00 at pci2 dev 6 function 2 not configured
cbb2 at pci2 dev 6 function 3 "O2 Micro OZ711E0 CardBus" rev 0x00: irq 10
bge0 at pci2 dev 14 function 0 "Broadcom BCM5705M_ALT" rev 0x03, BCM5705 A3 
(0x3003): irq 11, address 00:0d:9d:8c:12:85
brgphy0 at bge0 phy 1: BCM5705 10/100/1000baseT PHY, rev. 2
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 3 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 4 device 0 cacheline 0x0, lattimer 0x20
pcmcia1 at cardslot1
cardslot2 at cbb2 slot 2 flags 0
cardbus2 at cardslot2: bus 5 device 0 cacheline 0x0, lattimer 0x20
pcmcia2 at cards

Re: RAIDframe stability and reliability

[Joakim Roubert]

On 30/01/06 08:32, Joachim Schipper wrote:

> that a dying drive on a IDE bus is likely to confuse the bus
> sufficiently that the other drive on the bus (if there is one) goes down
> as well. 

I guess this would be avoided when the drives are on different buses, if
 there is space for using only one drive per bus?

Regards,

/Joakim
-- 
 http://www.df.lth.se/~jokke/

Re: OpenBSD { future=PIM (DM-SM) } support or { only=XORP } ?

[Claudio Jeker]

On Sun, Feb 05, 2006 at 08:29:12AM -0500, Dave Diller wrote:
> > Step one would probably be a PIM-DM, later on it can be expanded to support
> > PIM-SM.
> 
> Hmm - is there still a userbase for DM that would warrant supporting it first
> from a practical standpoint, or is it simply that it is much easier to code 
> and
> lays the groundwork for SM without diverting resources from SM too much?
> 

Those who designed SM had serious mental problems. The protocol is insanly
complex. Doing DM first is the only way to go.

> My only frame of reference is the advanced higher-ed community, where only the
> "opt-in" explicit-join paradigm of SM is in use.  Flood-and-prune ("opt-out")
> is explicitly NOT recommended for use in a production environment at this
> point.
> 

Depends on your multicast need. In some situations doing a flood-and-prune
setup is far better than the added complexity of SM. If bandwith does not
matter I would go for simple and robust but inefficent instead of hype
super-duper complex but more efficent.

> RFC2362 has been obsoleted by draft-ietf-pim-sm-v2-new-11.txt, FWIW. Since 
> it's
> an expired draft and could well evolve further, I don't know if you would want
> to use it - but its the current thinking by the WG:
> 
>   PIM-SM version 2 was originally specified in RFC 2117, and revised in
>   RFC 2362.  This document is intended to obsolete RFC 2362, and to
>   correct a number of deficiencies that have been identified with the way
>   PIM-SM was previously specified.  As far as possible, this document
>   specifies the same protocol as RFC 2362, and only diverges from the
>   behavior intended by RFC 2362 when the previously specified behavior
>   was clearly incorrect.  Routers implemented according to the
>   specification in this document will be able to successfully
>   interoperate with routers implemented according to RFC 2362.
> 

Where does it stand that RFC2362 has been obsoleted.
The draft does not matter because well it's a draft.

-- 
:wq Claudio

Re: OpenBSD { future=PIM (DM-SM) } support or { only=XORP } ?

[Dave Diller]

> Step one would probably be a PIM-DM, later on it can be expanded to support
> PIM-SM.

Hmm - is there still a userbase for DM that would warrant supporting it first
from a practical standpoint, or is it simply that it is much easier to code and
lays the groundwork for SM without diverting resources from SM too much?

My only frame of reference is the advanced higher-ed community, where only the
"opt-in" explicit-join paradigm of SM is in use.  Flood-and-prune ("opt-out")
is explicitly NOT recommended for use in a production environment at this
point.

RFC2362 has been obsoleted by draft-ietf-pim-sm-v2-new-11.txt, FWIW. Since it's
an expired draft and could well evolve further, I don't know if you would want
to use it - but its the current thinking by the WG:

PIM-SM version 2 was originally specified in RFC 2117, and revised in
RFC 2362.  This document is intended to obsolete RFC 2362, and to
correct a number of deficiencies that have been identified with the way
PIM-SM was previously specified.  As far as possible, this document
specifies the same protocol as RFC 2362, and only diverges from the
behavior intended by RFC 2362 when the previously specified behavior
was clearly incorrect.  Routers implemented according to the
specification in this document will be able to successfully
interoperate with routers implemented according to RFC 2362.

-dd

Re: pf sunfire v120 and iperf poor performance

[Alexandre Anriot]

> I meant check the CPU usage while measuring, it could be the same
> issue. I have an Ultra 5 on my desk but I still didn't have to time
> to install obsd and test iperf. 
> 
> Besides, in order for someone else more knowledgeable to respond 
> you should atleast include a dmesg. And some more info, like specs 
> of the box that's running iperf server.

And reyk@ reported a few issues with gigabit links as well. I'm looking
at things.

OpenBSD security could be tightened up easily

[Dave Feustel]

OpenBSD's handling of file permissions needs work.

Good security practice requires that root's default permission
set by umask should be 077. But setting root's umask to this
value breaks the package install mechanism since all files
installed by root with umask 077 are unavailable to users.

Also, all x11 and kde sockets are created with permissions up to and
including 777 that can be restricted with no loss of functionality. I now
routinely chmod all sockets in /tmp and $TMPDIR to 600 immediately
upon starting up kde and have seen no errors generated by this.

The problem with insecure [tp]ty allocation in kde is still not fixed
as far as I know, although I see a new kdelibs in errata.
(this problem occurs only in OpenBSD so far as I know),

It might also be a good idea to run pf by default with the
rule "block all in" to prevent intruders taking advantage of undiagnosed
security problems in kde or x11.  ALL of my strange problems with kde 
have ceased since I started running pf with this rule.

Having said this, I would like to add that OpenBSD looks better
than ever to me now and I recommend it highly to people I talk to.
OpenBSD is the Rock upon which I build everything else.

Dave Feustel
-- 
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"

Re: unwanted key repeating in X

[Alexandre Anriot]

> Hello,
> 
> sometimes when i type a key under x, it gets repeated and repeated and
> so on. Sometimes i can stop this repeating by pressing the key again.
> But then there will be another key that gets repeated in the next
> seconds. If i can not stop it by pressing it again, it will be repeated
> till i power off my computer manually (i waited 12 houres and i still
> gets repeated). i can't quit X or something else
> because the repeated key blocks all other keys.
> 
> If i manage to stop the key repeating by pressing the key again and
> leave x, there will be no problem until i start x again. i never saw
> this behaver when not using x11.
> 
> i changed my xorg.conf and i already tried to delete it and then use x
> but the result was the same. I experienced the problem with severeal
> window manangers, so i don't think that the problem lies there.
> 
> I dont thing it's a hardware problem because it only occurs in x11.
> 
> The problem don't seems to be a known issue because i didn't found
> anything in openbsd's or x11's bug tracking system.
> 
> Any help would be appreciated,
> Jonathan

What version of X are you running?

I saw the same issue on Zaurus a few months ago, but it disappeared
immediately after rebuilding -current X.

Re: sysctl hw.sensors question

[Denny White]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Today Stuart Henderson spake forth boldly:


On 2006/02/04 20:43, Denny White wrote:

hw.sensors.11=lm0, Temp3, temp, 127.50 degC / 261.50 degF

hw.sensors.0=nsclpcsio0, TSENS1, temp, 127.00 degC / 260.60 degF
hw.sensors.1=nsclpcsio0, TSENS2, temp, 127.00 degC / 260.60 degF


Thanks for the reply. Felt around inside the box. Nothing very
warm at all.


I think that you often see the maximum possible value reported where the
chip isn't actually hooked up to a physical sensor. I guess you would
be seeing, at the very least, raised values on the other temps if the
127C was genuine.


Thanks for the reply. I had wondered that, too. I've read some
on the mobo, but maybe not enough yet. It wasn't my first choice,
but I picked it up, with install, for next to nothing, along with
a new power supply, at a local shop. I'll keep digging around in
the archives, googling, so forth. Nothing inside the box feels
very warm. Fans are working fine, too.
Denny White

Please do not CC me. Already subscribed to mailing list.

GnuPG key  : 0x1644E79A  |  http://wwwkeys.nl.pgp.net
Fingerprint: D0A9 AD44 1F10 E09E 0E67  EC25 CB44 F2E5 1644 E79A
iD8DBQFD5Z92y0Ty5RZE55oRAo8MAKCbxfoH1/YaUipBgd5xrtDgFjCJKQCeKfqE
tlxjnnCQEmwYuNIj2yFMElc=
=hvmV
-END PGP SIGNATURE-

Re: OpenBSD { future=PIM (DM-SM) } support or { only=XORP } ?

[Esben Norby]

On Friday 03 February 2006 18:12, Jason Houx wrote:

> I know you guys are busy working on what will become OpenBSD 3.9 so in no
> way do I mean to distract, but is anyone working on a OpenPIMd concept on
> the side (like you guys really need more side projects) or is there any
> hope for a OpenPIMd in the future (similar to a OpenOSPFd and OpenBGPd).

Yes, tiny baby steps has been taking in order to startup a OpenPIMD project, 
but don't hold your breath...

Step one would probably be a PIM-DM, later on it can be expanded to support 
PIM-SM.

If any one are interested in this sort of thing please chip in.

> I'm going to start playing with DVMRP now that I see I can use mrouted
> with our current PIM routers and hopefull get a tunnel up to transport the
> multicast traffic to a OpenBSD gateway.  This doesn't create a PIM router
> but it does give me more features to learn/play with on OpenBSD which is
> always a goal of mine.
>

I use mrouted myself on OpenBSD routers, and I really really want to replace 
them.

If you want to play, mrouted is good enough - I mainly use it for multicast 
video streaming, and IPerf multicast test streams.

/Esben

Re: help in xmms

[Bachman Kharazmi]

It's been like that since I installed obsd. Since it's a cosmetic
issume with xmms so I don't care. Remember that obsd doesn't support
GL, if that's can be a reason...
if you come up with a solution, share it.
/bkw
On 05/02/06, K P <[EMAIL PROTECTED]> wrote:
> hello...
> i use openbsd 3.8, i installed xmms but i have 2 problem with it. 1st the 
> equalizer don't work and visualization is not correct, actuallt it's not 
> smooth and according to music.
>
> thanks for ur help.
>
> --
> ___
> Play 100s of games for FREE! http://games.mail.com/
>
>


--
##
BKW - Bachman Kharazmi
bahkha AT gmail DOT com
uin: #24089491
SWEDEN
##