Re: a stupid question, and OT to boot
On 12/26/05, Julesg [EMAIL PROTECTED] wrote: I am modem'ed into a remote box, (call it box REMOTE,) while I am at box LOCAL. I know my IP number (at LOCAL) I don't know the IP number at REMOTE So I am telling the REMOTE system to ping me. How can I look at who is pinging me on the LOCAL box?? Because I want to discover the IP address at box REMOTE. tcpdump and look for the ping. probably easier and doesn't require root to run something like nc -l -p 12345 on local, then nc local 12345 on remote, then netstat on local and see who connected.
Re: erratic networking problem
On 12/23/05, Han Boetes [EMAIL PROTECTED] wrote: tcp: 860321 packets received 229685 acks (for 489089407 bytes) 16982 duplicate acks 0 acks for unsent data 0 acks for old data 469932 packets (416700992 bytes) received in-sequence 18457 completely duplicate packets (12118924 bytes) 44 old duplicate packets 1566 packets with some duplicate data (175713 bytes duplicated) 200639 out-of-order packets (153176788 bytes) the out of order number seems really high.
ip_forward() function
Where is the code for the ip_forward() function in 3.8? I found the prototype in: /usr/src/sys/netinet/ip_var.h voidip_forward(struct *mbuf, int); but no function definition. I also did a grep -sR ip_forward /usr/src and all I found was the function being called several times from /usr/src/sys/netinet/ip_input.c, but no actual code showing how the function works. I'm probably looking for this in the wrong way, any ideas? Thanks, -Matt-
Re: OpenBGP+CARP : OpenBGP does not see CARP going into master state
Hi Sylvain OpenBGPd looks fine for eBGP and iBGP links as long as it does not depend on carp. I think this depend on is a nice feature - but I would not use for 100% fail save connections. You must take into account, that the session will go down if you trigger a failover. This might be acceptable for some kind of sessions (peerings, backup links) but may be undesirable for main (transit) links. Unfortunately, I had not the possibility to play with this feature so far, so I can't tell if there is a bug. Regards, Reto
ip_forward() function
Never mind on my previous post. ip_forward() definition is in: /usr/src/sys/netinet/ip_input.c it's late, I missed it. -Matt-
Re: Yet Another PF (authpf) Question.
Quick background: I have a wandering, disorganized, computer-illiterate boss who needs to send mail from his laptop from any network, without changing any of his computer's settings. I've set up postfix to handle this, but it's on a local 192.168.0.0/24 net behind our firewall. One of the networks he needs to be able to send mail from is our local wireless network, same subnet. So, he's directly on 192.168.0/24, and so is the mail server.. I guess he's trying to access the mail server on it's external address, am I right? You can't redirect a packet back out the interface it was received on, so that won't work. Either he'll need to use a different address for each location (which can sometimes be handled by having the name server hand out different addresses to queries from different subnets, some popular desktop OS will cache the lookups for longer than you'd like, partly mitigated by stopping 'DNS Client' service), or the mail server could be moved to a different nic on the firewall, or nc can be used to forward connections as described in PF FAQ. authpf doesn't come into the equation here - the same would happen with ordinary firewall rules.
Re: Debugging pxeboot on WRAP
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: ip_forward() function
Matthew Closson wrote: Where is the code for the ip_forward() function in 3.8? I found the prototype in: /usr/src/sys/netinet/ip_var.h void ip_forward(struct *mbuf, int); but no function definition. I also did a grep -sR ip_forward /usr/src and all I found was the function being called several times from /usr/src/sys/netinet/ip_input.c, but no actual code showing how the function works. I'm probably looking for this in the wrong way, any ideas? Thanks, Look again, it is in sys/netinet/ip_input.c.
Re: OpenBGP+CARP : OpenBGP does not see CARP going into master state
Hi, I think this depend on is a nice feature - but I would not use for 100% fail save connections. Why not ? It has been coded for this purpose ... You must take into account, that the session will go down if you trigger a failover. Of course, this is the basic of a failover between two routers. This might be acceptable for some kind of sessions (peerings, backup links) but may be undesirable for main (transit) links. This is *highly* desirable in any situation where one router goes down for any reason. Look, we're in a *failover* case. Session going down for 10 seconds is better than session going down until someone brings it back up ... Regards, -- Sylvain COUTANT ADVISEO http://www.adviseo.fr/ http://www.open-sp.fr/
Re: Debugging pxeboot on WRAP
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
Re: OpenBGP+CARP : OpenBGP does not see CARP going into master state
On Tue, Dec 27, 2005 at 12:27:52PM +0100, Sylvain Coutant wrote: Hi, I think this depend on is a nice feature - but I would not use for 100% fail save connections. Why not ? It has been coded for this purpose ... No. It is a hack to make it possible to use two routers at an IX where you only get one IP. If your master router goes belly up all sessions are dropped and opened on the backup box. This results in a route flap. You must take into account, that the session will go down if you trigger a failover. Of course, this is the basic of a failover between two routers. By using two IPs you can do failover without losing all routes on failover. This is in my opinion the prefered way of doing it. This might be acceptable for some kind of sessions (peerings, backup links) but may be undesirable for main (transit) links. This is *highly* desirable in any situation where one router goes down for any reason. If you are using bgpd you can add redundancy to your network in a more flexible way than via carp. Terminate your upstreams on multiple boxes run an IBGP mesh and you get failover too. Look, we're in a *failover* case. Session going down for 10 seconds is better than session going down until someone brings it back up ... The session probably down for more than 10 seconds. Even two bgpd take a bit more than 10 seconds to sync the RIB. -- :wq Claudio
Re: A Little Tip for OpenBSD Users of KDE
On Monday 26 December 2005 22:12, J.C. Roberts wrote: On Mon, 26 Dec 2005 11:39:22 -0500, Dave Feustel [EMAIL PROTECTED] wrote: Don't use sudo in any konsole session. Dave, I don't think you're nuts but the fear mongering without providing any proof or details of a compromise is questionable at best. If you really were compromised while running OpenBSD, you aren't the first and probably won't be the last. As for leaving a terminal window open with root privs, sudo or su, it has *always* been a bad idea: I never run root any more. Just long enough to install, add a user or two, and set up sudo. I have added a large number of packages and also compiled and installed other software not in the OpenBSD package collection. So I may have introduced a few holes at the user level myself. I have constantly been looking for signs of changes only possible via root. So far I have almost been able to convince myself that the intruder is doing whatever with my user privileges only. I am prepared to reinstall OpenBSD from scratch without Xorg and KDE if I become convinced that root access has been compromised. My respect for OpenBSD's security has increased substantially during the past few days. I think the security problems I am experiencing are in Xorg and KDE sockets. Rm'ing all the files in /tmp and Tmp (I have TMPDIR=/home/daf/Tmp) and then exiting and restarting KDE seems to disable the intruder temporarily. There also is some problem with DCOPserver, but again, restarting KDE seems to fix that. http://seclists.org/lists/bugtraq/2002/May/0294.html As you can see from what happened to Dug Song and monkey.org, the problem may not be konsole itself, instead, your sudo-enabled konsole session could have been taken over via an exploit in some other application you are running. I'm not familiar with what happened to Dug Song, The problem with using Sudo in a Konsole session is that either the sudo password may be captured for use in subsequent login, or (and I don't know whether this is possible) an eavesdropper might inject sudo commands during the 5-minute window that sudo remains enabled. The remedy for this is to always switch back to your login console when typing in passwords and using sudo since the login console is secure. This is possible by executing startkde . This problem exists because the kde pty allocation program shipped with KDE was not ported to OpenBSD, the result being that all the OpenBSD [pt]typ's allocated to konsole sessions by KDE are root-owned and world rw. There is also a problem with the socket /tmp/.X11-unix/X0. This is documented on the web and even in an OpenBSD presentation on XFree86 from about 2002. jcr I have learned a lot about OpenBSD, Xorg and KDE in the last week dealing with this problem. If I weren't an OpenBSD diehard before, I certainly am now. Dave Feustel -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
x11 forwarding does not work until pf is disabled
Hello,
I'm running current (built a few hours ago) on a test machine.
I'm connecting via ssh (from a windows box) and I try to launch an X
application.
X forwarding fails, here is a sample output:
~ $ xclock
[1] 10951
[EMAIL PROTECTED]
~ $ Error: Can't open display: localhost:11.0
Unfortunately, as you see, I'm not able to forward X11 until I disable
pf (pfctl -d).
After disabling pf, forwarding works well and I'm able to forward any X
application.
Did I miss something, what is my problem?
Thank you very much
Didier
Here is the (simple) pf.conf of the ssh server:
ext_if=bge0
table friends persist
table hostile persist
#OPTIONS
set loginterface $ext_if
#NORMALIZE
scrub in on $ext_if fragment reassemble
#REDIRECTING
#DEFAULT BLOCK
block log quick inet from hostile
block quick inet6
block log (all) all
pass quick on lo0
pass in quick on $ext_if inet proto tcp from friends to $ext_if\
port 22 modulate state label ssh
pass out quick on $ext_if inet proto { tcp, udp } from $ext_if to any \
keep state label out_traffic
Re: x11 forwarding does not work until pf is disabled
On Tue, Dec 27, 2005 at 02:43:48PM +0100, Didier Wiroth wrote:
Hello,
I'm running current (built a few hours ago) on a test machine.
I'm connecting via ssh (from a windows box) and I try to launch an X
application.
X forwarding fails, here is a sample output:
~ $ xclock
[1] 10951
[EMAIL PROTECTED]
~ $ Error: Can't open display: localhost:11.0
Unfortunately, as you see, I'm not able to forward X11 until I disable
pf (pfctl -d).
After disabling pf, forwarding works well and I'm able to forward any X
application.
Did I miss something, what is my problem?
Thank you very much
Didier
Here is the (simple) pf.conf of the ssh server:
ext_if=bge0
table friends persist
table hostile persist
#OPTIONS
set loginterface $ext_if
#NORMALIZE
scrub in on $ext_if fragment reassemble
#REDIRECTING
#DEFAULT BLOCK
block log quick inet from hostile
block quick inet6
you can debug this kind of stuff using tcpdump(8).
try passing inet6 on lo0.
block log (all) all
pass quick on lo0
pass in quick on $ext_if inet proto tcp from friends to $ext_if\
port 22 modulate state label ssh
pass out quick on $ext_if inet proto { tcp, udp } from $ext_if to any \
keep state label out_traffic
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: x11 forwarding does not work until pf is disabled
On Tue, 27 Dec 2005, Didier Wiroth wrote:
Did I miss something, what is my problem?
Try a set skip on { lo } instead of the pass quick on.
--
Signing off,
Joseph C. Bender
[EMAIL PROTECTED]
Does the government fear us? Or do we fear the government? When the
people fear the government, tyranny has found victory. The federal
government is our servant, not our master. ---Thomas Jefferson
Re: x11 forwarding does not work until pf is disabled
Great, thanks a lot, this solved the problem!
Didier
-Original Message-
From: Joseph C. Bender [mailto:[EMAIL PROTECTED]
Sent: mardi 27 dicembre 2005 15:56
To: Didier Wiroth
Cc: misc@openbsd.org
Subject: Re: x11 forwarding does not work until pf is disabled
On Tue, 27 Dec 2005, Didier Wiroth wrote:
Did I miss something, what is my problem?
Try a set skip on { lo } instead of the pass quick on.
--
Signing off,
Joseph C. Bender
[EMAIL PROTECTED]
Does the government fear us? Or do we fear the government? When the
people fear the government, tyranny has found victory. The federal
government is our servant, not our master. ---Thomas Jefferson
Re: OpenBGP+CARP : OpenBGP does not see CARP going into master state
while everybody else is busy discussing opinions I'll bother with the real question... * Sylvain Coutant [EMAIL PROTECTED] [2005-12-26 11:29]: OpenBGPd looks fine for eBGP and iBGP links as long as it does not depend on carp. definately works for me, and I can't imagine where it could break right now. When a bgp peer depends on a carp interface, OpenBGP does not see the interface going master and does not trigger connections up. I tried to bgpctl reload manually, but this does nothing. nom config reload won't help. bgpctl show interfaces always show that carp devices never come back master once they entered backup state. that is the problem. My config does just include depend on carp3 for one eBGP neighbour in this case. Is this kind of a bug or do I miss something ? something is strange in any case. can you run route monitor in parallel when the failover happens and show the output. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: A Little Tip for OpenBSD Users of KDE
On Tue, 27 Dec 2005, Dave Feustel wrote: by KDE are root-owned and world rw. There is also a problem with the socket /tmp/.X11-unix/X0. This is documented on the web and even in an OpenBSD presentation on XFree86 from about 2002. Dunno about KDE but can you elaborate or give refs why having a world writable unix domain socket is considered a problem? The references I've found talk about a missing sticky bit on the /tmp/.X11-unix dir, which is something different. -Otto
packet filter questions
Hello I have a box with OpenBSD 3.8 and packet filter
I have these questions about syntax of pf:
1.- May I use this syntax:
table serial_1{ 10.1.1.0/24 }
table serial_2{ 10.2.1.0/24 }
table serial_3{ 10.3.1.0/24 }
router_one = 192.168.1.1
and then
group_ping = { $router_one serial_1 serial_2 serial_3 }
Is posible the syntax to mix macros an tables? and if is possible the
syntax that i used is right or wrong? or what is the rigsht syntax ?
2.- If I have to join these range networks:
10.10.151.0 to 10.10.190.255
can I use the following syntax?:
table nets { 10.10.150-190 }# like qmail tcp.smtp file sintax
I know that I can use these 2 syntax but i dont want to use them if the
first one will work
table nets { 10.10.128.0/18 } # will
work fine but the range will be more than i wish
or
table nets { 10.10.150.0/24, 10.10.151.0/24, .} # one by one but
will be a huge table
thanks in advance
Mario
Login shell chroot implementation - unofficial chrsh openbsd port issues
This is in response to an email awhile back: http://www.monkey.org/openbsd/archive/misc/0208/msg00558.html Friday, July 19, 2002, 9:01:11 AM, you wrote: I have used many softwares like chrsh (Aaron Grifford) on a port from Ben Goren but didn't get it to work. I've done *everything* Aaron and Ben told me to do, but chrsh insisted to report me an error like: User='' (2000) Group='' (2000): Unable to obtain root permission in \ order to perform chroot() function. After several tryes, I finally quit it and decided to implement The reason you could not get Ben Goren's port of chrsh to work is that the port does not do everything for you, in particular two things that will prevent it from working on OpenBSD 3.8: It does not install setgid and setuid, and the settings in the compiled chrsh.c check for it to install /bin/chrsh but the package installs /usr/local/bin/chrsh And to be honest if we can't figure out that pare, we are likely to also put something in the jail that would allow a security break out... NOTE - DON't even try to use chroot to limit users accounts unless you understand it can be trivial to overcome: http://www.bpfh.net/simes/computing/chroot-break.html It is perhaps very dangerous to chroot ssh except in special situations, but the truth is a lot of servers try to do this, - especially in linux and freebsd implementations. Many seem to patch the openssh direct - not to happy about that, others use a shell. some approach examples: http://chrootssh.sourceforge.net/index.php http://www.adg.us/computers/chrsh.html http://olivier.sessink.nl/jailkit/ - - details and notes -- read no further unless need to know - the reason of this post is that google did not easily find answers about chrsh and openbsd beyond the helpful start by Ben Goren: http://www.trumpetpower.com/OpenBSD/chrsh His port almost works, but does not install the binary so that it can chroot, and the binary fails check because it is defined with wrong path. An approach is that you could use his port then edit the chrsh.c inside the port make area, edit ./chrsh/w-chrsh-1.0b2/chrsh/chrsh.c changing #define CHRSHPATH /bin/chrsh to #define CHRSHPATH /usr/local/bin/chrsh rm ./chrsh/w-chrsh-1.0b2/chrsh/chrsh.c cd ./chrsh/w-chrsh-1.0b2/chrsh/ make cp chrsh /usr/local/bin/chrsh --- however, the package did not install setuid nor setgid --- which probably is good because it forces you --- --- to think or at least google -- ls -al /usr/local/bin/chrsh -r-xr-xr-x 1 root wheel 18340 Dec /usr/local/bin/chrsh chmod u+s,g+s /usr/local/bin/chrsh ls -al /usr/local/bin/chrsh -r-sr-sr-x 1 root wheel 18340 Dec /usr/local/bin/chrsh --- and then you have to do all the steps for making the jail --- and the special path for the shell -- which is documented --- and sometimes scripted elsewhere like it says on Aaron D. Gifford's website: That's all the documentation ya get, folks! :)
Re: RELEASE BUG - ami0: timeout ccb 1
Strip a single RAID 5 set across channels to speed up the SCSI backend. Then slice it up using disklabel. That should do the trick. On Dec 26, 2005, at 9:09 PM, bofh wrote: Hi, I have one megaraid i4, but with two channels set up. One raid1 for the OS, and one raid5 with 4x250G hard drives. Currently, my 3 options are: 1) use the older motherboard, P3-450Mhz with 3.8-release which supports both channels. 2) use the newer motherboard, P3-1.4Ghz, with 3.8-stable or - current, but only one channel. Need to acquire another i4, obviously. 3) use 3.7 with the newer motherboard, P3-1.4Ghz which supports both channels. Any recommendations of one over the other? And your source for cheap i4 still open? :) -Tai
unzip path for f-prot update problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When f-prot tries to update in root's cron, it reports fatal error, can't find unzip. Unzip is located in /usr/local/bin which is in root's path env: PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin: /usr/local/bin Have tried unzip from deep into directory structure and it works, comes up fine. Just wondering what I'm doing wrong. Works fine on my old hp netserver running fbsd_5_4. Can't find any major differences in the setups. Thanks for any all help advice. 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 iD8DBQFDsXivy0Ty5RZE55oRArx8AJ9iOGi3pt7R5gsDxrKCQb5G2LKt1wCdHOQg zj3saLxLUnEuoMUObo3gWgI= =x9xe -END PGP SIGNATURE-
ccd mirroring and ccdxc
A few questions in regards to the discussion between Robert Haarman and mickey around Nov 24 on ccd mirroring. The conclusion is don't use c for a usable partition in a ccd device. This sounds fine until I try to recover from a disk failure. When I use the c partition in a ccd mirror device I can unconfigure the ccd and mount each half of the mirror seperately. So if a hard disk were to fail I could edit my fstab and the server could be back up quickly. With any other partition scheme this seems impossible, and would require a dd before the filesystem could be mounted. Mickey's reasoning behind not using c is that the real disk's label will get trashed. I don't see how this is possible if the real disks are setup properly. My real disks are setup with a small unused a partition, with d and e setup for the ccd mirrors. c is then used inside each ccd for the main filesystem. Bobby Johnson
Re: A Little Tip for OpenBSD Users of KDE
On 12/27/05, Dave Feustel [EMAIL PROTECTED] wrote: On Monday 26 December 2005 22:12, J.C. Roberts wrote: On Mon, 26 Dec 2005 11:39:22 -0500, Dave Feustel [EMAIL PROTECTED] wrote: Don't use sudo in any konsole session. Dave, I don't think you're nuts but the fear mongering without providing any proof or details of a compromise is questionable at best. If you really were compromised while running OpenBSD, you aren't the first and probably won't be the last. As for leaving a terminal window open with root privs, sudo or su, it has *always* been a bad idea: I never run root any more. Just long enough to install, add a user or two, and set up sudo. I have added a large number of packages and also compiled and installed other software not in the OpenBSD package collection. So I may have introduced a few holes at the user level myself. I have constantly been looking for signs of changes only possible via root. So far I have almost been able to convince myself that the intruder is doing whatever with my user privileges only. Have you done any intrusion detection beyond this? What's your network topology? What is your first impression of how the intruder is getting in? Is it another local user, i.e. one who already has an account on your box? If there are no other local users on your box are you monitoring connections to the possibly exploited system from another system? Greg
Re: A Little Tip for OpenBSD Users of KDE
On Tuesday 27 December 2005 11:05, Otto Moerbeek wrote: On Tue, 27 Dec 2005, Dave Feustel wrote: by KDE are root-owned and world rw. There is also a problem with the socket /tmp/.X11-unix/X0. This is documented on the web and even in an OpenBSD presentation on XFree86 from about 2002. Dunno about KDE but can you elaborate or give refs why having a world writable unix domain socket is considered a problem? Here is a presentation of XFree86 security issues that I found yesterday that seems to be relevant. X0 permissions are specifically addressed. I am definitely having fewer (if any) problems after several times rm'ing the tmp files associated with Xorg and KDE. I've done it with no problems except when I do it while KDE is running. Then DCOP dies. The most reliable way of reactivating DCOP correctly is (right now) to reboot KDE. http://www.openbsd.org/papers/xf86-sec.pdf -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
Re: Login shell chroot implementation - unofficial chrsh openbsd port issues
- - details and notes -- read no further unless need to know - . rm ./chrsh/w-chrsh-1.0b2/chrsh/chrsh.c oops thats my very bad, should be rm ./chrsh/w-chrsh-1.0b2/chrsh/chrsh
Re: How to log all entered commands?
MK try it now. http://www.linbsd.org/log_execve.38.patch Thanks to Ted for pointing out the not so obvious mistakes in it. Thanks. -Ober On Mon, 26 Dec 2005, Ted Unangst wrote: On 12/25/05, ober [EMAIL PROTECTED] wrote: Here is a patch, probably something want to test before using on a production box. http://www.linbsd.org/log_execve.38.patch It logs commands to syslog like this: EXECVE: uid:1000 fullpath:/bin/ls command:ls foo EXECVE: uid:1000 fullpath:/sbin/dmesg command:dmesg EXECVE: uid:1000 fullpath:/usr/bin/touch command:touch fff accessing a user pointer from kernel is an easy denial of service attack.
Re: erratic networking problem
Ted Unangst wrote: On 12/23/05, Han Boetes [EMAIL PROTECTED] wrote: tcp: 860321 packets received 229685 acks (for 489089407 bytes) 16982 duplicate acks 0 acks for unsent data 0 acks for old data 469932 packets (416700992 bytes) received in-sequence 18457 completely duplicate packets (12118924 bytes) 44 old duplicate packets 1566 packets with some duplicate data (175713 bytes duplicated) 200639 out-of-order packets (153176788 bytes) the out of order number seems really high. tcp: 2951714 packets received 1407498 acks (for 2220503854 bytes) 77078 duplicate acks 0 acks for unsent data 0 acks for old data 1548640 packets (1206942891 bytes) received in-sequence 5516 completely duplicate packets (3386034 bytes) 168 old duplicate packets 728 packets with some duplicate data (280080 bytes duplicated) 80204 out-of-order packets (82444919 bytes) With the rtl8139 I also get high numbers, but the networkproblem is gone. # Han
Re: A Little Tip for OpenBSD Users of KDE
On Tue, 27 Dec 2005, Dave Feustel wrote: On Tuesday 27 December 2005 11:05, Otto Moerbeek wrote: On Tue, 27 Dec 2005, Dave Feustel wrote: by KDE are root-owned and world rw. There is also a problem with the socket /tmp/.X11-unix/X0. This is documented on the web and even in an OpenBSD presentation on XFree86 from about 2002. Dunno about KDE but can you elaborate or give refs why having a world writable unix domain socket is considered a problem? Here is a presentation of XFree86 security issues that I found yesterday that seems to be relevant. X0 permissions are specifically addressed. I am definitely having fewer (if any) problems after several times rm'ing the tmp files associated with Xorg and KDE. I've done it with no problems except when I do it while KDE is running. Then DCOP dies. The most reliable way of reactivating DCOP correctly is (right now) to reboot KDE. http://www.openbsd.org/papers/xf86-sec.pdf Indeed this paper mentions problems withg unix domain sockets. But it is talking about socket _creation_, not _using_ the a unix domain socket. So far you only have given very vague, circumstantial evidence. -Otto
Re: A Little Tip for OpenBSD Users of KDE
On 12/27/05, Otto Moerbeek [EMAIL PROTECTED] wrote: On Tue, 27 Dec 2005, Dave Feustel wrote: by KDE are root-owned and world rw. There is also a problem with the socket /tmp/.X11-unix/X0. This is documented on the web and even in an OpenBSD presentation on XFree86 from about 2002. Dunno about KDE but can you elaborate or give refs why having a world writable unix domain socket is considered a problem? this is obviously a source of confusion. the permissions on a socket mean *nothing*. anyone can open any socket regardless of permissions, so long as they have necessary directory permissions to find it.
Re: Login shell chroot implementation - unofficial chrsh openbsd port issues
On 12/27/05, Paul Pruett [EMAIL PROTECTED] wrote: NOTE - DON't even try to use chroot to limit users accounts unless you understand it can be trivial to overcome: http://www.bpfh.net/simes/computing/chroot-break.html yes, if you're root. why are all your users logging in with root privs? you should fix that.
Re: A Little Tip for OpenBSD Users of KDE
Marc Espie and Dirk at kde have acknowledged the security problem OpenBSD has with kde kgrantpty. The problem with /tmp/.X11-unix/X0 addressed by the 2003 paper on XFree86 still exists today with Xorg. If the rest of you fail to see the problem, even when the evidence is available to you on your respective systems, so be it. On Tuesday 27 December 2005 14:56, Daniel Ouellet wrote: Dave, I keep reading your emails and many answer to them as well. So far, nothing is evidence or anything yet. Also, based on some of your latests emails, look like the intruder is still coming back to your box still and you reboot the KDE to kick him/here out. Look like you are saying there is a security problem, but yet you still provide no details what so ever on your setup, what you do, what's install, how he/she may get into, etc. If there is really a problem, then provide the informations, all of it. If the intruder is still coming in, then the entry door is still open then. So, I am not saying this should be done, but either provide all the details, or may be even better if someone from the project want to look at it as it is happening, then let them do so, if they want to obviously. If there is any security problem in OpenBSD of any kind, I am sure many developers would be all over it by now, but it doesn't look to me that there is one, project related anyway, or if it is from some packages provided by the project as well, I am sure they would love to know that and address it! After all they live for that, way of speaking anyway! With all due respect to you and I intend no disrespect what so ever, it really start to be annoying more then helping. Please provide details, ALL of it so that better mind can look at it seriously and if there is a problem, address it ASAP. Quite frankly, it is becoming clear to me that I'm better off to keep quiet about things I become aware of. And not just wrt computers. I'm perhaps relearning that lesson quite late in life. I was told in 7th Grade by an exasperated history teacher you don't let people *know* that(what?) you know! One of my survival skill perhaps? :-) If instead you try to keep the informations for yourself, for what ever reason, then so do it. But in all fairness what you do now is very much annoying at best. Again, believe me, I mean no offense to you or anyone else, but it is just how it is from my side. SO, if there is a real problem, put it under the spotlight and let get it fix, or else. Just an idea and that was my first and last email on that one. Daniel Your comments are taken in the spirit in which they are offered. I'll try hard in the future to let sleeping dogs lay. Happy New Year, Dave -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
Re: a stupid question, and OT to boot
On Mon, 26 Dec 2005 22:34:28 -0600, Julesg wrote: Because I want to discover the IP address at box REMOTE. Probably the easiest way is to run tcpdump. You'll want options to limit the output to ICMP traffic. man tcpdump for details. If, however, REMOTE's IP address is in a network address translation scheme, and LOCAL is outside that network address translation scheme, you will only be able to discover the IP address that REMOTE's router assigns to it. Sorry, I will try to keep OT stuff to a bare minimum, and if I get complaints I will stop. Why is this off topic? -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
Re: A Little Tip for OpenBSD Users of KDE
On Tue, 27 Dec 2005, Ted Unangst wrote: On 12/27/05, Otto Moerbeek [EMAIL PROTECTED] wrote: On Tue, 27 Dec 2005, Dave Feustel wrote: by KDE are root-owned and world rw. There is also a problem with the socket /tmp/.X11-unix/X0. This is documented on the web and even in an OpenBSD presentation on XFree86 from about 2002. Dunno about KDE but can you elaborate or give refs why having a world writable unix domain socket is considered a problem? this is obviously a source of confusion. the permissions on a socket mean *nothing*. anyone can open any socket regardless of permissions, so long as they have necessary directory permissions to find it. That used to be the case. But since quite some time, you'll need write permission to open a unix domain socket. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_usrreq.c?rev=1.2content-type=text/x-cvsweb-markup -Otto
Re: A Little Tip for OpenBSD Users of KDE
Dave, I keep reading your emails and many answer to them as well. So far, nothing is evidence or anything yet. Also, based on some of your latests emails, look like the intruder is still coming back to your box still and you reboot the KDE to kick him/here out. Look like you are saying there is a security problem, but yet you still provide no details what so ever on your setup, what you do, what's install, how he/she may get into, etc. If there is really a problem, then provide the informations, all of it. If the intruder is still coming in, then the entry door is still open then. So, I am not saying this should be done, but either provide all the details, or may be even better if someone from the project want to look at it as it is happening, then let them do so, if they want to obviously. If there is any security problem in OpenBSD of any kind, I am sure many developers would be all over it by now, but it doesn't look to me that there is one, project related anyway, or if it is from some packages provided by the project as well, I am sure they would love to know that and address it! After all they live for that, way of speaking anyway! With all due respect to you and I intend no disrespect what so ever, it really start to be annoying more then helping. Please provide details, ALL of it so that better mind can look at it seriously and if there is a problem, address it ASAP. If instead you try to keep the informations for yourself, for what ever reason, then so do it. But in all fairness what you do now is very much annoying at best. Again, believe me, I mean no offense to you or anyone else, but it is just how it is from my side. SO, if there is a real problem, put it under the spotlight and let get it fix, or else. Just an idea and that was my first and last email on that one. Daniel
OpenBSD on D-Link Access Points
This past week I was having to play tech support for a family member and realized the firmware image on his dlink DI-614+ was corrupt. After a quick upload of a new image, it was working again. During this time I was reading through the documentation and realized there's just an ARM7 processor on the device. I know that some of the linksys devices have one of those other broken unix variant running on them, so would it ever be likely we'd see a port to one of these simple devices for OpenBSD? If so, and barring the obvious issue of resources to do the port, is a hardware donation something that would get people interested in making the port? Again, this is just something I was curious about and obviously expect no commitments :) Thanks. - Eric
Re: How to log all entered commands?
I've installed your patch. Works really great. Thanks very very much for it. Have a nice day MK - Original Message - From: ober [EMAIL PROTECTED] To: Ted Unangst [EMAIL PROTECTED] Cc: MK [EMAIL PROTECTED]; misc@openbsd.org Sent: Tuesday, December 27, 2005 7:33 PM Subject: Re: How to log all entered commands? MK try it now. http://www.linbsd.org/log_execve.38.patch Thanks to Ted for pointing out the not so obvious mistakes in it. Thanks. -Ober On Mon, 26 Dec 2005, Ted Unangst wrote: On 12/25/05, ober [EMAIL PROTECTED] wrote: Here is a patch, probably something want to test before using on a production box. http://www.linbsd.org/log_execve.38.patch It logs commands to syslog like this: EXECVE: uid:1000 fullpath:/bin/ls command:ls foo EXECVE: uid:1000 fullpath:/sbin/dmesg command:dmesg EXECVE: uid:1000 fullpath:/usr/bin/touch command:touch fff accessing a user pointer from kernel is an easy denial of service attack.
Re: Yet Another PF (authpf) Question.
On 12/27/05, Stuart Henderson [EMAIL PROTECTED] wrote: Quick background: I have a wandering, disorganized, computer-illiterate boss who needs to send mail from his laptop from any network, without changing any of his computer's settings. I've set up postfix to handle this, but it's on a local 192.168.0.0/24 net behind our firewall. One of the networks he needs to be able to send mail from is our local wireless network, same subnet. So, he's directly on 192.168.0/24, and so is the mail server.. Yeah, exactly. I guess he's trying to access the mail server on it's external address, am I right? Yep. You can't redirect a packet back out the interface it was received on, so that won't work. Either he'll need to use a different address for each location (which can sometimes be handled by having the name server hand out different addresses to queries from different subnets, some popular desktop OS will cache the lookups for longer than you'd like, partly mitigated by stopping 'DNS Client' service), or the mail server could be moved to a different nic on the firewall, or nc can be used to forward connections as described in PF FAQ. Thanks, I didn't know about nc. Just based on glancing at its man page, it'll probably do the trick. If it doesn't, then connecting the mail server to its own nic on the firewall is a darn good idea that I should've thought of. Thanks. - R.
Re: a stupid question, and OT to boot
David Benfell [EMAIL PROTECTED] wrote: Why is this off topic? Because it is administrivia more suitable for a unix newbies list? man afterboot, then searching for network will point you to ifconfig, which would be the right way to figure out the IP address(es) -- where as the where did that ping come from approach breaks behind NATing (as you already mentioned). And an easier solution than the one asked about would be to point a web browser at http://whatismyip.com/ -mj
Re: RELEASE BUG - ami0: timeout ccb 1
On 12/27/05, Marco Peereboom [EMAIL PROTECTED] wrote: Strip a single RAID 5 set across channels to speed up the SCSI backend. Then slice it up using disklabel. That should do the trick. My problem is that the 2 OS drives are 160GB, whereas my attempt at a poor man's raid5 are 4x250GB. One thing I noticed. copying 240G worth of crap from a 250GB drive, across the motherboard's IDE interface, into the megaraid i4 raid0 (160GB on channel 0, 160GB on channel 1) took 2 hours. Copying from the above raid0 onto the 4x250GB raid5 (2 drives on channels 2 and 3) took 13+ hours. Does raid5 really use up that much cpu? I couldn't have saturated the PCI bus or the individual ide channels, could I? -Tai
Re: A Little Tip for OpenBSD Users of KDE
On 12/27/05, Otto Moerbeek [EMAIL PROTECTED] wrote: this is obviously a source of confusion. the permissions on a socket mean *nothing*. anyone can open any socket regardless of permissions, so long as they have necessary directory permissions to find it. That used to be the case. But since quite some time, you'll need write permission to open a unix domain socket. wow, crazy. i knew it was like that on linux, but never checked at home. :)
Re: a stupid question, and OT to boot
On Tue, 27 Dec 2005 16:11:09 -0500, Matthew Jenove wrote: David Benfell [EMAIL PROTECTED] wrote: Why is this off topic? Because it is administrivia more suitable for a unix newbies list? man afterboot, then searching for network will point you to ifconfig, which would be the right way to figure out the IP address(es) -- where as the where did that ping come from approach breaks behind NATing (as you already mentioned). And an easier solution than the one asked about would be to point a web browser at http://whatismyip.com/ I see this as a solution to a different problem than the one posed. But a worthwhile question to the newbie would have been the classic: What is the problem you're really trying to solve? -- David Benfell, LCP [EMAIL PROTECTED] --- Resume available at http://www.parts-unknown.org/
mergemaster (was: Re: CVS: cvs.openbsd.org: ports)
Over on ports-changes, Antoine Jacoutot [EMAIL PROTECTED] wrote: Modified files: sysutils/mergemaster: Makefile sysutils/mergemaster/patches: patch-mergemaster_sh Log message: use system sdiff, drop GNU diff dependency Since gdiff isn't needed anymore, do you think mergemaster could be integrated in the base system one of those days, I'm considering this. -- Christian naddy Weisgerber [EMAIL PROTECTED]
Re: flash on OpenBSD
On 12/26/05, Han Boetes [EMAIL PROTECTED] wrote: Hi, I just read this article: http://www.kaourantin.net/2005/12/flash-player-8-for-linux-update.html Via OSNews. If there ever was a chance to lobby for support of flash on OpenBSD it is now and there. Doesn't the Linux flash work under OpenBSD/i386 now (using a Linux browser such as www/opera)? Would this new version change that? A native version (or better, source code) would be nice, but let's face it, it's not bloody likely.
Re: A Little Tip for OpenBSD Users of KDE
Dave Feustel wrote: The problem with /tmp/.X11-unix/X0 addressed by the 2003 paper on XFree86 still exists today with Xorg. What problem? X11 implements its own authentication. -d
Re: ccd mirroring and ccdxc
Bobby Johnson wrote: A few questions in regards to the discussion between Robert Haarman and mickey around Nov 24 on ccd mirroring. The conclusion is don't use c for a usable partition in a ccd device. If conclusion is the right word in a discussion between someone who didn't understand the process and someone who wrote a large chunk of the driver in question, sure. Reality can be discussed, but discussion doesn't change reality. This sounds fine until I try to recover from a disk failure. When I use the c partition in a ccd mirror device I can unconfigure the ccd and mount each half of the mirror seperately. So if a hard disk were to fail I could edit my fstab and the server could be back up quickly. With any other partition scheme this seems impossible, and would require a dd before the filesystem could be mounted. Your statement is blatantly wrong. It is most certainly NOT impossible, and it is very easy to do if you do things right. You don't even have to edit anything...you could pull a disk out and not edit anything and have the system come back up on one disk...If you do it right. :) (hint: you can do a CCD of just one disk). (hint 2: you can't use the same partition twice, it will generate an error). (hint 3: Errors can be your friend, they are not always to be avoided) Mickey's reasoning behind not using c is that the real disk's label will get trashed. No, Mickey's reasoning behind not using the 'c' partition is that YOU DON'T DO THAT. BY DEFINITION. He's a developer. He gets to make definitions. I don't see how this is possible if the real disks are setup properly. Your lack of understanding doesn't change the reality. My real disks are setup with a small unused a partition, with d and e setup for the ccd mirrors. c is then used inside each ccd for the main filesystem. Then you are a fool. 'c' is the entire disk, be it physical or logical. By definition. It is not for general use. Again, by definition. Use it any other way, you are playing a stupid game. The fact that you do not lose this game at /any particular instant/ does not mean you won the game. If you sit me down in front of a chess master and I'm not defeated after three moves, I do NOT get to say, I know what I am doing! I am right! I know how to play this game! Follow my advice!. Even if there were no technical reason not to (mis)use things as you propose, the developers have said, DON'T DO THIS. If you violate the rules and get away with it today and developers make a change which clobbers your disk tomorrow, we will laugh at you. This is not that difficult. ccd(4) makes a virtual disk out of a physical partition of an existing system. That virtual disk has to have a disklabel. That virtual disk's disklabel is JUST LIKE ANY OTHER disklabel, 'c' is the entire (virtual) disk! You don't get to use 'c' on a physical disk for a file system, you don't get to use it on a logical disk for a file system. Period. One big hint: The initial disklabel ccd(4) provides a virtual disk is wrong. Hit D while in the command mode of disklabel to reset it to default, now things will look a lot more familiar, and perhaps a bit less likely to cause you to argue in favor of doing things wrong. Let me tell you point blank: It is not difficult to properly set up a ccd(4) mirroring system which can be rebooted off EITHER drive without making a single configuration change (don't think of trying to re-attach the mirrors without rebuilding first, however). I've done it, I have tested it, I have shown my process to the person who wrote much of the driver in question and he has said I did it right. I did this by reading the man pages and a lot experimenting and figuring out what was REALLY going on, not just punching a certain sequence of characters someone else told me and hoping magic happened. Doing things wrong buys you nothing. Nick.
Re: mergemaster (was: Re: CVS: cvs.openbsd.org: ports)
Christian Weisgerber wrote: Over on ports-changes, Antoine Jacoutot [EMAIL PROTECTED] wrote: Since gdiff isn't needed anymore, do you think mergemaster could be integrated in the base system one of those days, I'm considering this. Are you considering mergeslave as well? # Han
Re: OpenBSD on D-Link Access Points
On Wed, 2005-12-28 at 00:52:23 +, Stuart Henderson proclaimed... Obviously I don't speak for developers, but I'm not sure a device with a processor which looks around 10% the speed of a Zaurus, 8mb RAM, and undocumented wireless nic is going to be interesting enough to warrant the time a port takes..(read the slides about the Zaurus port for some information about what's involved in porting to a new machine, it is a lot of work: http://www.openbsd.org/papers/ven05-niallo-uwe/slides.pdf). Right, but the problem with a zaurus is that it doesn't lend itself to be a gateway easily. Further, there's many insecure products out there that I'm sure many of us are using for wireless access. Yes, I've created ad-hoc networks, etc., but this is a low powered device with no moving parts. Wouldn't it be nice if one of those vendors ported OpenBSD (or any other BSD) for us? grin
Re: OpenBSD on D-Link Access Points
eric wrote: Right, but the problem with a zaurus is that it doesn't lend itself to be a gateway easily. Further, there's many insecure products out there that I'm sure many of us are using for wireless access. Yes, I've created ad-hoc networks, etc., but this is a low powered device with no moving parts. Wouldn't it be nice if one of those vendors ported OpenBSD (or any other BSD) for us? grin Sure it'd be nice, but even if you had a port, OpenBSD does native compiles, so by the time you finished building the OS, you'd be two releases behind.
now, some issues that are OBSD front and center
So I spent yesterday putting up a nice OpenBSD box; Lot's of space, very fast -- and first thing today I discovered that EGCS does not equal GCC. I'd like to know what's involved in removing EGCS and installing GCC? And if you aren't a compiler person, my guess is that this not a trivial thing to do; And this has nothing to do with what I like, or even which is better; I have lot's of code that simply bombs! Even using -g I can't say br main in gdb. It bombs BEFORE execution -- though it works fine on gcc on FreeBSD. So I already know the problem, it's memory -- I come pretty close to the limit's of the environment. So, has anyone swapped compilers re OpenBSD? and thanx! --jg
Re: unzip path for f-prot update problem
Denny White wrote: When f-prot tries to update in root's cron, it reports fatal error, can't find unzip. Unzip is located in /usr/local/bin which is in root's path env: PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin: /usr/local/bin WHICH root's path env? When root logs in? or when root's crontab runs? That's two separate environments... Have tried unzip from deep into directory structure and it works, comes up fine. Just wondering what I'm doing wrong. Works fine on my old hp netserver running fbsd_5_4. Can't find any major differences in the setups. Thanks for any all help advice. Denny White replace your invocation of unzip or whatever you actually have in your cron job with a echo $PATH and see what your path REALLY is when the program executes. Something funny about the way your line broke there...gotta wonder if that /usr/local/bin is on a separate physical line...assuming that was in the crontab in the first place... Nick.
Re: OpenBSD on D-Link Access Points
On Tue, 2005-12-27 at 20:54:48 -0500, Steve Shockley proclaimed... Sure it'd be nice, but even if you had a port, OpenBSD does native compiles, so by the time you finished building the OS, you'd be two releases behind. Heh, true. That would be awful! There'd probably have to be quite a bit of everything removed out of base before even starting. Ugh.
Re: OpenBSD on D-Link Access Points
On Wed, Dec 28, 2005 at 12:52:23AM +, Stuart Henderson wrote: During this time I was reading through the documentation and realized there's just an ARM7 processor on the device. I know that some of the linksys devices have one of those other broken unix variant running on them, so would it ever be likely we'd see a port to one of these simple devices for OpenBSD? Obviously I don't speak for developers, but I'm not sure a device with a processor which looks around 10% the speed of a Zaurus, 8mb RAM, and undocumented wireless nic is going to be interesting enough to warrant the time a port takes..(read the slides about the Zaurus port for some information about what's involved in porting to a new machine, it is a lot of work: http://www.openbsd.org/papers/ven05-niallo-uwe/slides.pdf). Looks like it needs very fine soldering skills just to attach a serial port: http://seattlewireless.net/index.cgi/SamSung4510 If anyone knows about an ARM 11 based device that has reasonable IO: network, disk options (CF or better), minipci, ... The developers would be quite interested in finding out about such a device. Dale Rahn [EMAIL PROTECTED]
Re: Unexpected Expect timeout in chat script (ppp -auto)
I'm running PPP 3.1 (/usr/sbin/ppp) on OpenBSD 3.7 / i386. Every now and then, I run into a problem in which the chat script stops working in -auto mode: Dec 20 20:45:08 wally ppp[20296]: tun0: Chat: Expect(650): CONNECT 115200 Dec 20 20:45:21 wally ppp[20296]: tun0: Chat: Expect timeout Just as a followup to my own question - it looks as if the value being used for the chat timeout is about 100 times too small. I don't know if this means other timeouts are calculated incorrectly as well. Maybe the calculation of TICKUNIT or SECTICKS is being done wrong in timer.h? Dec 27 18:34:35 wally ppp[17586]: Warning: Begin of Timer Service List--- Dec 27 18:34:35 wally ppp[17586]: Warning: physical throughput timer[0x3c04b068] : freq = 1.00s, next = 0.00s, state = running Dec 27 18:34:35 wally ppp[17586]: Warning: chat timeout timer[0x3c037ab4]: freq = 650.00s, next = 650.00s, state = running Dec 27 18:34:35 wally ppp[17586]: Warning: End of Timer Service List --- Dec 27 18:34:35 wally ppp[17586]: Warning: timer_Start: Inserting physical throu ghput timer[0x3c04b068] before chat timeout timer[0x3c037ab4], delta = 10 Dec 27 18:34:36 wally ppp[17586]: Warning: Begin of Timer Service List--- Dec 27 18:34:36 wally ppp[17586]: Warning: physical throughput timer[0x3c04b068] : freq = 1.00s, next = 0.00s, state = running Dec 27 18:34:36 wally ppp[17586]: Warning: chat timeout timer[0x3c037ab4]: freq = 650.00s, next = 521.80s, state = running Dec 27 18:34:36 wally ppp[17586]: Warning: End of Timer Service List --- Obviously, I can't have gone through (650-521.8) seconds in between the two timestamps (18:34:35 and 18:34:36). At any rate, if anyone else is running into this problem, a user workaround is to put an insanely huge timeout in your chat script. Mine is currently 6500 (which should be nearly forever, but appears to be around 6.5 seconds). Andrew Jr. Just $16.99/mo. or less. dsl.yahoo.com
Re: OpenBSD on D-Link Access Points
On Tue, 27 Dec 2005, Dale Rahn wrote: SNIP If anyone knows about an ARM 11 based device that has reasonable IO: network, disk options (CF or better), minipci, ... The developers would be quite interested in finding out about such a device. Dale Rahn [EMAIL PROTECTED] I've been looking, all I've seen is a couple of reference designs. ti omap2420 H4 reference board. diana
iic verbosity
Most of our work in the iic(4) sensor framework is enabled now in -current and in the latest snapshots. Please note that it is quite verbose in dmesg for the moment; if you run into problem send me a private mail containing a 2-line machine description, the full dmesg, and output of sysctl hw.sensors if possible. I will deal with my parts or pass it on to the relevant developers. If we get all the bugs worked out before next release, we can ship with this stuff enabled. Today I was happy to get the following on my alpha: hw.sensors.0=lmenv0, +2.5Vin, volts_dc, 2.49 V hw.sensors.1=lmenv0, Vccp1, volts_dc, 1.60 V hw.sensors.2=lmenv0, +Vcc, volts_dc, 3.28 V hw.sensors.3=lmenv0, +5Vin/Vcc, volts_dc, 4.95 V hw.sensors.4=lmenv0, +12Vin, volts_dc, 12.12 V hw.sensors.5=lmenv0, Vccp2, volts_dc, 1.17 V hw.sensors.7=lmenv0, Int. Temp., temp, 24.00 degC / 75.20 degF hw.sensors.8=lmenv0, AIN1, volts_dc, 0.78 V hw.sensors.9=lmenv0, AIN2, volts_dc, 0.77 V hw.sensors.10=lmenv1, +2.5Vin, volts_dc, 2.50 V hw.sensors.11=lmenv1, Vccp1, volts_dc, 1.62 V hw.sensors.12=lmenv1, +Vcc, volts_dc, 3.32 V hw.sensors.13=lmenv1, +5Vin/Vcc, volts_dc, 4.95 V hw.sensors.14=lmenv1, +12Vin, volts_dc, 12.12 V hw.sensors.15=lmenv1, Vccp2, volts_dc, 0.31 V hw.sensors.17=lmenv1, Int. Temp., temp, 25.00 degC / 77.00 degF hw.sensors.18=lmenv1, AIN1, volts_dc, 0.74 V hw.sensors.19=lmenv1, AIN2, volts_dc, 0.75 V hw.sensors.20=lmenv2, +2.5Vin, volts_dc, 2.51 V hw.sensors.21=lmenv2, Vccp1, volts_dc, 1.50 V hw.sensors.22=lmenv2, +Vcc, volts_dc, 3.32 V hw.sensors.23=lmenv2, +5Vin/Vcc, volts_dc, 4.97 V hw.sensors.24=lmenv2, +12Vin, volts_dc, 12.19 V hw.sensors.25=lmenv2, Vccp2, volts_dc, 1.25 V hw.sensors.27=lmenv2, Int. Temp., temp, 44.00 degC / 111.20 degF hw.sensors.28=lmenv2, AIN1, volts_dc, 1.55 V hw.sensors.29=lmenv2, AIN2, volts_dc, 2.48 V hw.sensors.30=lmenv3, +2.5Vin, volts_dc, 0.00 V hw.sensors.31=lmenv3, Vccp1, volts_dc, 0.00 V hw.sensors.32=lmenv3, +Vcc, volts_dc, 3.23 V hw.sensors.33=lmenv3, +5Vin/Vcc, volts_dc, 5.08 V hw.sensors.34=lmenv3, +12Vin, volts_dc, 12.12 V hw.sensors.35=lmenv3, Vccp2, volts_dc, 0.00 V hw.sensors.37=lmenv3, Int. Temp., temp, 34.00 degC / 93.20 degF hw.sensors.38=lmenv3, AIN1, volts_dc, 0.77 V hw.sensors.39=lmenv3, AIN2, volts_dc, 0.78 V And many people have mailed in showing that much more stuff is now working for them. If something doesn't work for you, please keep trying newer and newer code since the development is still moving very fast.
Re: now, some issues that are OBSD front and center
On Tue, 27 Dec 2005, Julesg wrote: So I spent yesterday putting up a nice OpenBSD box; Lot's of space, very fast -- and first thing today I discovered that EGCS does not equal GCC. I'd like to know what's involved in removing EGCS and installing GCC? And if you aren't a compiler person, my guess is that this not a trivial thing to do; And this has nothing to do with what I like, or even which is better; I have lot's of code that simply bombs! Even using -g I can't say br main in gdb. It bombs BEFORE execution -- though it works fine on gcc on FreeBSD. Please wrap your lines. And next time include some details. Check www.openbsd.html/report.html and mail.html. If your code bombs, my advice would be to check the code, not change compiler. OpenBSd has some more restrictive memory management, which proabbly has triggered a bug in your code. Depending on platform, OpenBSD uses gcc 2.95 or gcc 3.3.5, both modified to suit our needs. You cannot switch compilers without breaking things. As for crashing before main is called: that might happen, but you still have a core file which can help you spot the problem. So I already know the problem, it's memory -- I come pretty close to the limit's of the environment. So, has anyone swapped compilers re OpenBSD? What makes you think that will solve you problem? -Otto
