Re: [patch] little typo on current.html
On Thu, Mar 20, 2014 at 11:46:01PM -0300, Daniel Bolgheroni wrote: Little typo on current.html. Fixed, thanks! Index: current.html === RCS file: /cvs/www/faq/current.html,v retrieving revision 1.475 diff -u -p -r1.475 current.html --- current.html 19 Mar 2014 20:10:29 - 1.475 +++ current.html 21 Mar 2014 02:42:42 - @@ -762,7 +762,7 @@ which supports L2TP, PPTP and PPPoE (cur uucpd(8) has been removed. As a result, the old binaries and manual pages should be removed: pre -rm -f /usr/libxec/uucpd +rm -f /usr/libexec/uucpd rm -f /usr/share/man/man8/uucpd.8 /pre
Re: pf: bad icmp packet checksums on vlans when natted to own network address
On Sat, Nov 23, 2013 at 08:31:56PM +0100, Walter Haidinger wrote: Am 2013-11-23 17:41, schrieb mxb: http://marc.info/?l=openbsd-techm=138493672609487w=2 This one might help? Thanks for the reference but no, unfortunately not. Applied the patch the issue remains. The above diff won't work on 5.4 because it depends on some significant post-5.4 changes in the way checksumming is done. Can you please try this one instead? http://marc.info/?l=openbsd-techm=137571298511653w=2
Re: snort inline
Hi Justin, First of all, thank you for testing my diff and providing feedback! At the moment, the need to use -k none with Snort inline is expected. Briefly, due to the way packets are processed when divert-packet is used with NAT, the checksums of packets being diverted from the kernel to userspace will be incorrect. That is why Snort needs to be told to ignore the checksums. To avoid having to calculate the checksums twice (once before diverting the packet from kernel to userspace, and once again after reinjecting it from userspace to kernel), my diff only calculates the checksums once on reinjection. I think that's a better spot to do it because the userspace program (which could be something other than Snort) can potentially modify the packets, which would require the checksums to be recalculated again anyway. Perhaps all that needs to be done is for the behavior to be documented. Anyway that's my take on what is going on and what's needed to fix it; perhaps someone else with more experience can chime in. :) Lawrence On Mon, Mar 11, 2013 at 12:33:09PM -0500, Justin Mayes wrote: So snort was running and I could use my little C test divert program also to see I was passing packets back and forth thru divert. I never got a snort alert though even though traffic was passing to and from client. So after noticing the snort exit output that showed bad chk sum: 100.000% I used the snort -k none option and now snort is alerting also. Just an FYI in case this is at all related to your work. I have run snort a lot in the past but never on OpenBSD so I don't know if that's normal or not. Justin -Original Message- From: Justin Mayes Sent: Thursday, March 07, 2013 4:02 PM To: 'Lawrence Teo' Cc: misc@openbsd.org Subject: RE: snort inline This works. Thank you very much. I'll let you know if I run into any issues but I am able to run snort inline now along with NAT. Justin -Original Message- From: Lawrence Teo [mailto:l...@openbsd.org] Sent: Wednesday, March 06, 2013 8:55 AM To: Justin Mayes Cc: misc@openbsd.org Subject: Re: snort inline Hi Justin, Not sure if you still need to use divert-packet with NAT, but if you do, could you please try the diff at http://marc.info/?l=openbsd-techm=136245826921904w=2 to see if it works for you? The easiest way to get the diff is: ftp -o divert-checksum.diff \ 'http://marc.info/?l=openbsd-techm=136245826921904q=raw' If you do try it, please let me know if it works for you. Thanks, Lawrence On Wed, Dec 19, 2012 at 03:09:47PM -0600, Justin Mayes wrote: Another update in case there is any interest in running divert-packet along with NATing. I ditched snort and wrote a little divert program based on the man page to test easier. I can now see that with nat as well as divert-packet on egress rule on external interface the packet will get NATed and go out. A reply will come back to external interface and then get diverted again and never make it to the client. I am as sure as I can be at this point that you cannot divert packets from a NATed client. Justin -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Sunday, November 25, 2012 4:37 PM To: misc@openbsd.org Subject: Re: snort inline Quick update. It seems to be a nat problem. If I just test by pinging either the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and snort sees the packets. Its only when the traffic is NATed that it fails. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Saturday, November 24, 2012 2:21 PM To: misc@openbsd.org Subject: snort inline Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From what I read it's possible with pf divert functionality. This is what I'm doing for testing in pf using simple ping Gateway info internal interface fxp0 - 192.168.1.32 external interface bce0 - 192.168.0.13 Running snort via this cmd line snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v Internal interface is in the skip list hence no active rules for it Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) This works as expected, I can ping 8.8.8.8 and since no diverting is active snort sees nothing I change rules to this to start diverting to snort Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port 8000 nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) Now internal interface sees outgoing ping tcpdump -n -i fxp0 -n host 8.8.8.8 192.168.1.32 8.8.8.8: icmp: request
Re: snort inline
Hi Justin, Not sure if you still need to use divert-packet with NAT, but if you do, could you please try the diff at http://marc.info/?l=openbsd-techm=136245826921904w=2 to see if it works for you? The easiest way to get the diff is: ftp -o divert-checksum.diff \ 'http://marc.info/?l=openbsd-techm=136245826921904q=raw' If you do try it, please let me know if it works for you. Thanks, Lawrence On Wed, Dec 19, 2012 at 03:09:47PM -0600, Justin Mayes wrote: Another update in case there is any interest in running divert-packet along with NATing. I ditched snort and wrote a little divert program based on the man page to test easier. I can now see that with nat as well as divert-packet on egress rule on external interface the packet will get NATed and go out. A reply will come back to external interface and then get diverted again and never make it to the client. I am as sure as I can be at this point that you cannot divert packets from a NATed client. Justin -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Sunday, November 25, 2012 4:37 PM To: misc@openbsd.org Subject: Re: snort inline Quick update. It seems to be a nat problem. If I just test by pinging either the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and snort sees the packets. Its only when the traffic is NATed that it fails. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Sent: Saturday, November 24, 2012 2:21 PM To: misc@openbsd.org Subject: snort inline Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From what I read it's possible with pf divert functionality. This is what I'm doing for testing in pf using simple ping Gateway info internal interface fxp0 - 192.168.1.32 external interface bce0 - 192.168.0.13 Running snort via this cmd line snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v Internal interface is in the skip list hence no active rules for it Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) This works as expected, I can ping 8.8.8.8 and since no diverting is active snort sees nothing I change rules to this to start diverting to snort Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port 8000 nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) Now internal interface sees outgoing ping tcpdump -n -i fxp0 -n host 8.8.8.8 192.168.1.32 8.8.8.8: icmp: request: External interface shows it going out and coming back 192.168.0.13 8.8.8.8: icmp: request: 8.8.8.8 192.168.0.13: icmp: reply: Snort sees it twice, external interface first 192.168.0.13 - 8.8.8.8 ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF Type:8 Code:0 ID:64870 Seq:2 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 8.8.8.8 - 192.168.1.32 ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84 Type:0 Code:0 ID:52297 Seq:2 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Client @ 192.168.1.32 never sees reply. Any comments or suggestions? Justin
Re: Snort, DAQ, and established flow
On Fri, Feb 22, 2013 at 03:05:36PM +0400, Wesley M.A. wrote: Hi, I use OpenBSD 5.3-beta kern.version=OpenBSD 5.3-beta (GENERIC) #33: Fri Feb 15 17:03:34 MST 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC I have some questions: 1) If i run this : $(whereis snort) -v # give me : Running in packet dump mode --== Initializing Snort ==-- Initializing Output Plugins! ERROR: Can't find pcap DAQ! Fatal Error, Quitting.. what is missing ? i already tried add p5-Net-Pcap, py-libpcap, same error... Please read /usr/local/share/doc/pkg-readmes/snort-2.9.4.0 for OpenBSD-specific Snort documentation. Specifically, the recommended way to start Snort is to use the /etc/rc.d/snort script. The rc.d(8) man page has information about rc.d scripts. Hope this helps, Lawrence
Re: Snort, DAQ, and established flow
On Fri, Feb 22, 2013 at 08:19:04PM +0400, Wesley M.A. wrote: Please read /usr/local/share/doc/pkg-readmes/snort-2.9.4.0 for OpenBSD-specific Snort documentation. Specifically, the recommended way to start Snort is to use the /etc/rc.d/snort script. The rc.d(8) man page has information about rc.d scripts. Hope this helps, Lawrence You are very funny, i already read /usr/local/share/doc/pkg-readmes/* I just wanted to make sure you didn't miss those docs. And the same for : Configure /etc/snort/snort.conf (HOME_NET, EXTERNAL_NET, var...RULES) local.rules file And put pkg_scripts=snort in /etc/rc.conf.local and start it manually with /etc/rc.d/snort start Therefore thank you for your trie. /etc/snort/snort.conf contains this line: config daq_dir: /usr/local/lib/daq/ So when you start Snort with the rc.d script, the rc.d script runs snort with -c /etc/snort/snort.conf, so it knows where to find the DAQ modules. If you want to use snort -v without using the config file: snort --daq-dir=/usr/local/lib/daq/ -v Lawrence
Re: pfctl -P
On Mon, May 28, 2012 at 03:34:04PM +0200, Jan Stary wrote: The manpage says -P Print ports using their names in /etc/services if available. This works with pfctl -P -sr, but not with pfctl -P -ss - is that intended? Good catch. :) I originally created -P for use with -sr, and did not consider that it might be useful for -ss too. Let me see if I can hack something up... Thanks, Lawrence
Re: Multiple ISP-connections/Routing/Packet filtering
Steven's method has worked for me as well, with OpenVPN on OpenBSD 4.9. Lawrence On Wed, Jan 11, 2012 at 07:48:55PM -0500, Steven Surdock wrote: I ran OpenVPN on the loopback and did an rdr (back in the day). It has worked for me. http://marc.info/?l=openbsd-miscm=119446553412564w=2 -Steve S. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Dr.-Ing. Torsten Finke Sent: Wednesday, January 11, 2012 10:48 AM To: misc@openbsd.org Subject: Re: Multiple ISP-connections/Routing/Packet filtering Hello Russell, On Wed, Jan 11, 2012 at 07:46:59AM -0500, Russell Garrison wrote: Have you considered routing domains? no I have not. According to your hint I started to study their concept, but have not found a description that would meet my situation. Thanks for your idea and best regards Torsten On Tue, Jan 10, 2012 at 1:41 PM, Dr.-Ing. Torsten Finke torsten.fi...@igh-essen.com wrote: Hello Jorge, I read again your mail and now i'm lost ! You Wrote: How can I force my Extl. FW to reply on exactly the same interface it had been requested on? For example I am running OpenVPN(1194/UDP) between my HomeOffice (Z=Client) and the Intl. FW(=Server). Alike I would appretiate SSH-portforwarding from Internet to the Intl. FW. SSH port forwarding from internet to Internal server is something like : ext_if=vr0 ext_ip=1.2.3.4 Spvt= 4.5.6.7 match in on $ext_if proto tcp from any to $ext_ip port 22 rdr-to $Spvt pass in on $ext_if proto tcp from any to $Spvt port 22 pass out on $int_if proto tcp from any to $Spvt port 22 The above line redirects all traffic coming from any place in internet to my external IP ( 1.2.3.4) to the server 4.5.6.7 which is located in my internal lan, in other words the packet comes in on external interface , goes out on internal interface .. These works on OpenBSD 4.8 or newer ! Is this what you need ? no. Obviously I have not explained clearly what my problem is. On my firewall I have TWO different internet connections. It is simple to forward - for instance ssh - from both connections to an internal machine. Now this machine answers and the firewall sends the reply back. How can I force the firewall to send the reply over exactly that interface the request came in? The problem is that the client anywhere on the internet expects the answer from the very address it had contacted. If now the reply comes from another address, it will get lost. Best regards Torsten On Tue, Jan 10, 2012 at 10:46 AM, Dr.-Ing. Torsten Finke torsten.fi...@igh-essen.com wrote: Hello Jorge, If i understood you well, the answer to your question is here ! http://www.openbsd.org/faq/pf/pools.html Under the section Load Balancing outgoing traffic, or take a look at: http://www.openbsd.org/faq/faq6.html#Multipath There are good examples there ! I hope this can help ! thank you for this. The FAQ on pools has nice examples but none of them really faces my problem. It discusses load balancing of incoming traffic to several servers as well as load balancing of outgoing traffic. I cannot figure out how to dispatch replies to incoming requests over different connections. The FAQ on multipath has helped me very well to set up multiple default routes - this works very well. Best regards Torsten Dear List, Here I show my network topology. Maybe it seems quite typical. My internal network is located behind an Intl/Extl Firewall which is connected to the Internet(IN) via pppoe/ppp(8). On the other side I run different systems, for instance a home office network, a mobile laptop, and several customers. +---+ +---+ | A | | B | (PC) +-+-+ +-+-+ | | +-+ --+-+---| Intl FW |---(DMZ)---+ (LAN/int) +-+ | | +---+ | +---+ | | Z | (PC) | () +---+ | +-+ pppoe/ppp(8) +---+ () ++ | | | |--| DSL-Modem |--()--| GW |--- -+- | | | rl0/tun0 +---+ () ++ (HomeOffice) +--| Extl FW | ( IN ) + --+ | | pppoe/ppp(8) +---+ ()--| Customer | |
Re: Bad MD5 on snapshot i386 install.iso
Joe Gidi wrote: I've downloaded the 9/24/08 i386 install.iso from both rt.fm and ftp3.usa.openbsd.org and got bad MD5s on both files. MD5 from both downloads was: 53238ca6a3212db65dadd9bef1ef1f3d while the ftp MD5 file says it should be: f87b839db833380f41f02bd7fffb2d27 Haven't checked the master fanout site because I got repeated too many users errors. Joe, I think the MD5 file was out of sync in the past week. I downloaded the i386 install44.iso a few days ago. I just checked the file I downloaded, and it does have the correct MD5 (f87b839db833380f41f02bd7fffb2d27) according to what you posted. *But* on the day I downloaded it, I was very sure the MD5 file on the FTP site was advertising a different hash. Like you, I thought I had a bad ISO, so I downloaded the ISO file from a different mirror, but the second ISO file had the same hash as the first. So the MD5 file was either ahead or behind. Since the install44.iso file I downloaded was dated Sep 20, the MD5 file was probably behind. Or maybe it's just one of those transient things that happen when FTP sites are being mirrored. Or maybe you and I are both crazy. :) Lawrence
xorg.conf for VMware Fusion on MacBook
If anyone's interested, here's an xorg.conf for OpenBSD 4.4-beta with the correct refresh rates and modeline to display the full 1280x800 resolution on VMware Fusion 1.1.3 on a MacBook: http://labs.calyptix.com/xorg.conf-vmware-fusion3 Hope it helps someone. :) Regards, Lawrence
Re: Thank You OpenBSD
Sean Darby wrote: Question: Is it true there was a developer's comment line in the Linux kernel that said, Does this belong here? http://lxr.linux.no/source/arch/i386/kernel/cpu/common.c#L677 -- Lawrence Teo Calyptix Security http://www.calyptix.com/
Re: spamd - 250 return text
Tom Bombadil wrote: Hi all, Short of recompiling spamd, is there any undocumented way of changing the 250 responses from spamd? - 250 Hello, spam sender. Pleased to be wasting your time. - 250 You are about to try to deliver spam. Your time will be spent, for nothing. man spamd and a quick search in the ML archives weren't very successful. If you check the spamd.c source, you'll see that those responses are hardcoded into spamd: snprintf(cp-obuf, cp-osize, 250 Hello, spam sender. Pleased to be wasting your time.\r\n); So no, there is no way to change those responses apart from modifying the code and recompiling. Lawrence -- Lawrence Teo Calyptix Security http://www.calyptix.com/
Re: How to track port updates in stable?
Todd Pytel wrote: On Fri, 2007-08-03 at 18:35 -0500, Todd Pytel wrote: Is there some other official way to track changes to ports? Thanks for all the responses. I went with the tracking system on ports.openbsd.nu. While I understand and admire the whole follow the source approach of watching cvs, my servers are hobby machines and family commitments mean that I can't geek out as much as I used to. While I don't run any high-profile ports that I would expect to be attacked, it's still nice to get a notification about a security update in case I haven't had time to check the lists in a while. If you're only interested in updated packages for the stable branch, and you have limited geek-out time (don't we all), there's always http://www.openbsd.org/pkg-stable.html You can see the changes to it in reverse chronological order at: http://www.openbsd.org/cgi-bin/cvsweb/www/build/packages-4.1 (assuming you're tracking 4.1-stable) Hope it helps, Lawrence -- Lawrence Teo Calyptix Security http://www.calyptix.com/
Re: About encryption
Brian Hansen wrote: Hi I have no prior experience in encryption but wants to figure out how to - as safe as possible - encrypt some files on my computer. I have been looking at both GNUPG and Mcrypt. I am not interested in the KEY part of GNUPG but only encrypting files. Which - if any - would you recommend for the task and using what algorithms? Simplest encryption/decryption program I've found: http://ccrypt.sourceforge.net/ There's an OpenBSD package for it too. Hope it helps, Lawrence -- Lawrence Teo Calyptix Security http://www.calyptix.com/
Re: xfce windows manager
Nick Templeton wrote: Here are the packages (and their dependencies) that I install to get a nice Xfce desktop: xfce-utils xfce4-session xfce4-taskbar xfdesktop xfwm4 For me I normally do.. pkg_add -i \ xfce-utils \ orage \ terminal \ xfwm4 \ xfdesktop \ mousepad \ xfce-mcs-plugins This is on -current though. Can't survive without terminal and mousepad. :) Hope it helps, Lawrence -- Lawrence Teo Calyptix Security http://www.calyptix.com/
Re: Problem on installing new packages
Stephen Liu wrote: Hi Stuart, Is your network working, can you connect to the site with ftp? Yes, I can ping yahoo.com/google.com, etc. without problem [EMAIL PROTECTED]:29$ ftp ftp://ftp.it.net.au/mirrors/OpenBSD/4.0/packages/amd64/ # ftp ftp://ftp.it.net.au/mirrors/OpenBSD/4.0/packages/amd64/ Connected to poledra.it.net.au 220 ProFTPD 1.2.10 Server (Informed Technoloty FTP Server) [203.8.116.111] 331 Anonymous loginod, send your completed email address as your password ... 230 Anonymous access granted, restrictions apply. Remote system type is UNIX. Using binary mode to transfer files 200 Type set to I 250 CWD command successful ftp exit 221 Goodbye B.R. Stephen Liu This is very weird. Try putting the PKG_PATH on the same line as the pkg_add command: PKG_PATH=ftp://ftp.it.net.au/mirrors/OpenBSD/4.0/packages/amd64 \ pkg_add -v nano-1.2.5.tgz Lawrence -- Lawrence Teo Calyptix Security http://www.calyptix.com/
Re: ODBC on OpenBSD *solved*
Joaquin Herrero wrote: The problem I had when tried to compile php4 (or php5) from ports is this: mach:/usr/ports/www/php4# /usr/bin/make === www/php4/core === Checking files for php4-core-4.4.0p0 php-4.4.0.tar.gz doesn't seem to exist on this system. Attempting to fetch /usr/ports/distfiles/php-4.4.0.tar.gz from http://us2.php.net/distributions/ . 100% |**| 6133 00:00 Size does not match for /usr/ports/distfiles/php-4.4.0.tar.gz /bin/sh: test: 3: unexpected operator/operand *** Error code 2 Same happens with php5. Anyone knows what is the problem here? I tried from a 4.0 machine and I got the same problem. The problem is that the PHP team either changed the URL of the PHP 4.4.0 tarball, or the PHP 4.4.0 tarball is no longer available. If you try using a web browser to access http://us2.php.net/distributions/php-4.4.0.tar.gz directly (which is essentially what the ports mechanism is trying to do), you'll see an error page. To get around it, try the following steps: 1. cd /usr/ports/distfiles 2. ftp ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/php-4.4.0.tar.gz 3. cd /usr/ports/www/php4 4. make You might have to repeat the above steps for other PHP tarballs. Re step #2, I would not recommend using that step very often.. it's much more preferable to grab the tarballs from their original locations (or mirrors).. the OpenBSD distfiles FTP location is meant as a last resort. I would also highly recommend using OpenBSD 4.0 and/or a more up-to-date version of PHP. There has been numerous security fixes since PHP 4.4.0 (see http://www.php.net/ChangeLog-4.php). Hope it helps, Lawrence -- Lawrence Teo Calyptix Security http://www.calyptix.com/
Re: OT: Getting a premade box or doing it yourself (was OT:)
.. as you have pointed out, there is a lack of drivers. So yes we had to be careful when choosing hardware vendors. It wasn't too difficult, but it also certainly wasn't pretty simple like another misc@ poster suggested. But what I found was, the drivers that _are_ there in OpenBSD are complete and Just Work -- there is no need to hunt down half-working third-party source code patches (or *shudder* binary blobs) or play the chase-the-kernel-version game to get something to work. I'd take a high-quality OpenBSD blob-free driver over a non-free driver any day. Another bonus of using OpenBSD: sensible API like strlcpy(3)/strlcat(3), the sys/queue.h and RB-tree convenience macros, and extra security-focused gcc warnings actually make development fun. There's also plenty of high-quality source code to learn from.. as I dig deep into both the userland and kernel, it is evident how well thought out the entire system is. In a world of bad code and vulnerabilities, it is such a joy to be able to read and learn from OpenBSD code to develop better software every day. Bottom line.. OpenBSD is a very viable and solid platform for commercial security appliances. It does require some investment in choosing hardware upfront, but in return you get a clean, secure, and robust foundation to develop on, which I believe will pay off in the long term, especially for security appliances. As an aside, it seems like there are a fair number of us OpenBSD users here in Silicon Valley. Lots of us have been individually lobbying various hardware manufactures, most of which are headquartered in this area, to release documentation for their products. I think it might be more effective if we combine efforts and started pressing to get in-person meetings with folks in product marketing at some of these companies. If we could get 2 or 3 of us who are pretty well versed in the business side of technology to present well-reasoned arguments for why it would benefit these companies to have their hardware more widely supported, we might begin to see some cracks in the blob armor. Is anyone else local here interested in starting an unofficial lobbying group to put together some position points as to why hardware vendors should release documentation and start trying to schedule some meetings with vendors? I applaud your efforts in doing this. I'm based all the way over here on the east coast in Charlotte, North Carolina, so I probably won't be of much help for in-person lobbying efforts in Silicon Valley.. however please email me privately if you would like to discuss any way I can help lob some ammunition your way. :) My 2 cents, Lawrence Lawrence Teo Calyptix Security 8701 Mallard Creek Rd Charlotte, NC 28262 Phone: 704-971-8989 [EMAIL PROTECTED] http://www.calyptix.com/
Re: IP change trouble
Paul Irofti wrote: I have changed one of my workstation's IP with: $ sudo ifconfig vr0 inet 192.168.1.64 Afterwards some applications (trn, rtorrent, gaim) acknowledged the change and worked on the fly. Others, such as irssi, worked on a random basis (i.e. restarting it would lead to connecting or not to the servers). Firefox, mutt, snownews, lynx didn't even bother. I did modify the /etc/hostname.vr0 and /etc/hosts files before executing the command. Changing /etc/hostname.vr0 before ifconfig does not do anything since /etc/hostname.vr0 is only read on reboot. But I do concur with Nick.. the easiest way to address the problem for now is to reboot, until you understand the startup scripts more thoroughly. Lawrence Lawrence Teo Calyptix Security 8701 Mallard Creek Rd Charlotte, NC 28262 Phone: 704-971-8989 [EMAIL PROTECTED] http://www.calyptix.com/
Re: OpenBSD Desktop Document
Roy Morris wrote:
Thanks to all those that replied. I have made the changes suggestedand
placed the document as {ps,pdf,txt} at
www.openalternatives.com/OpenBSD/OpenBSD-Desktop.txt
www.openalternatives.com/OpenBSD/OpenBSD-Desktop.ps
www.openalternatives.com/OpenBSD/OpenBSD-Desktop.pdf
Great work!
May I suggest shortening the tarball extraction command in the
Installing Open Office 2.0 section...
From this:
A. gzip -d Ooo_2.0.0_LinuxIntel_install.tar.gz; \
tar -xvf Ooo_2.0.0_LinuxIntel_install.tar
To this:
A. gzip -cd Ooo_2.0.0_LinuxIntel_install.tar.gz | tar xvf -
Less to type, less likely for a newbie user to make mistakes.
And all instances of Open Office and OpenOffice should be
OpenOffice.org if you want to keep things standardized.
Once again, great start!
Lawrence
Re: 9/1 snapshot on Dell Precision 380 w/Intel dual-port GigE card
Just replying to my own mail to get my findings into the misc@ archives. Perhaps it'll save someone else some time since I've found partial solutions to my problems. Thanks to Jonathan Gray for his help and pointers -- I wouldn't be able to figure all this out otherwise. First of all, the Dell Precision 380 workstation will NOT work with OpenBSD 3.7 even with the following workarounds. I have not tested OpenBSD 3.8 yet, but have verified that -current works reasonably well with the following workarounds enabled. Lawrence Teo wrote: I had difficulties installing OpenBSD-current (the 9/1 snapshot) on a Dell Precision 380 (manufacturing date: 07/23/05) with an Intel dual-port gigabit Ethernet card (em(4)). The installation was done using a home-brewed bootable CD. I encountered the following three problems and I hope someone can help or point me in the right direction. Problem 1 = The CD booted fine, but the keyboard hanged at the (I)nstall, (U)pgrade or (S)hell? prompt. I noticed in the dmesg (below) that several devices were not recognized, so that's probably the problem. Could SATA be part of the problem too? The PS/2 keyboard hung because of bugs in the Dell Precision BIOS (version A02 at the time of writing). As a workaround, disable USB support in the BIOS with the following steps: On boot, enter BIOS setup and change the following: Onboard Devices - USB Controller - Change On to Off Relevant info: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165749 The next version of the BIOS is supposed to fix this problem, but Dell has not released it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165838 As an aside, all devices are recognized now. Thanks to Jonathan for committing the relevant diff to pcidevs. Problem 2 = Since the keyboard hung, I tried installing using the serial console. This time the OpenBSD installation program said that no disks were found (see serial console output below). You have to disable AHCI for the disk to be detected. Enter BIOS setup and change the following: Drives - SATA Operation - Change RAID Autodetect / AHCI to RAID Autodetect / ATA. Problem 3 = The dual-port Intel card was not recognized, where the dmesg said The EEPROM Checksum Is Not Valid. I found similar reports in the misc@ archive, but there were no solutions. http://marc.theaimsgroup.com/?l=openbsd-miscm=111834108727054w=2 http://marc.theaimsgroup.com/?l=openbsd-miscm=111844056613828w=2 http://marc.theaimsgroup.com/?t=11086917673r=1w=2 The Intel card is an Intel PRO/1000 MT Dual Port Server Adapter (product #PWLA8492MT). The packaging has the following details, if it's relevant. Date: 10/18/2004 Version: A85400-006 I suspect it's a new Intel card that has been marketed with the product number of older Intel cards, and that's probably why the em(4) driver did not like it. Still no solutions with the Intel dual-port gigE card. Anyway if you're reading this because you're having problems with the Dell Precision 380 only, this will not affect you. See this thread for recent updates: http://marc.theaimsgroup.com/?t=11295873692r=1w=2 I'm pretty stuck right now, so I'll really appreciate any help on how to troubleshoot the above problems. I have tried to provide as much details as possible, but if you need further information, please let me know. dmesg and serial console output are appended below. The original dmesg and serial console output with the September 1 snapshot are at: http://marc.theaimsgroup.com/?l=openbsd-miscm=112664653901887w=2 The new dmesg for the Dell Precision 380 with the October 27 snapshot is appended below. Lawrence OpenBSD 3.8-current (GENERIC) #219: Thu Oct 27 10:43:43 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.80 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,CNXT-ID real mem = 534925312 (522388K) avail mem = 481222656 (469944K) using 4278 buffers containing 26849280 bytes (26220K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 05/24/05, BIOS32 rev. 0 @ 0xffe90 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfed10/272 (15 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801GB LPC rev 0x00) pcibios0: PCI bus #5 is the last bus bios0: ROM list: 0xc/0xc000! cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82955X MCH rev 0x00 ppb0 at pci0 dev 1 function 0 Intel 82955X PCIE rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 Nvidia Quadro NVS 285 rev 0xa1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) Intel
Re: Intel PRO/1000 MT Dual Port Server Adapter Issues
Ken Gunderson wrote: Hello All: I'm having some issues w/an Intel PRO/1000 MT Dual Port Server Adapter in an OBSD-3.7 box. The card is in the pci-x riser on one of these puppies; http://www.tyan.com/products/html/gt20b5151.html Dmesg complains the The EEPROM Checksum Is Not Valid. I've tested the card in a Winblows machine and it works. Any insights as to what is going on here greatly appreciated. I experienced the same problem with that card. And yes, it's driving me nuts too. :) What's strange is that I have two older cards (same model) and they work fine with OpenBSD. I am testing the problematic card in a Dell Precision 380 workstation (no PCI-X riser here :)). dmesg snippet: em0 at pci5 dev 2 function 0 Intel PRO/1000MT (82546GB) rev 0x01: irq 3em0: The EEPROM Checksum Is Not Valid em0: Unable to initialize the hardware em1 at pci5 dev 2 function 1 Intel PRO/1000MT (82546GB) rev 0x01: irq 9em1: The EEPROM Checksum Is Not Valid em1: Unable to initialize the hardware Full dmesg (slightly dated) at: http://marc.theaimsgroup.com/?l=openbsd-miscm=112664653901887w=2 (see Problem 3) At first, I thought the problem could be resolved by using the latest Intel drivers. OpenBSD recently sync'ed the em(4) driver with Intel's latest, and I just tried a recent October snapshot containing that driver. Unfortunately, the problem is still there. If you still have the packaging of your card, could you please let me know the date and version of your card? I'm just trying to see if there's a certain batch of cards exhibiting that problem. Mine are: Date: 10/18/2004 Version: A85400-006 Also, a kind soul on the Internet sent me the following link showing how it can be resolved with FreeBSD, but I haven't had time to investigate it in detail yet. http://lists.freebsd.org/pipermail/freebsd-mobile/2004-July/004302.html If you do find a solution, please let the list know. I'll do the same. Thanks! Lawrence
