BGP peering, 2 peers, hardware reqirements & questions
Hi, Our goal is uptime/redundancy, in pursuit of that we're looking to get another T1 (maybe less, radio or laser link to compliment our T1 wire) and peer. If we can get increased bandwidth that'd be very desireable too. Right now we're supporting about 150 users. With an extensive pf rule set we're rarely using more than 10% of a 500MHz Pentium III. We'd also be implementing carp and adding a WAN card(s) rather than using old leftover ciscos for their CSU/DSUs. CPU: I figure about any new piece of (i386) equipment will come with at least a 2GHz processer, which should be plenty. RAM: I hear reports (old?) of users who have only 512MB RAM, but I figure on 1GB. On another note, are the SBE (lmc(4)) WAN cards preferred over the Sangoma (san(4)) cards, or does it matter? Anything else I need to know about hardware? Finally, not knowing much about bgp, I've a question about load balancing over the two WAN links. Does bgp/OpenBGP have any provisions for load balancing, say based on WAN link latency? (Seems like this _could_ be a "bgp policy" at the local level, but nothing leaps out at me from bgpd.conf(5).) Thanks. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Obtaining glibc on OpenBSD?
On 09/12/2005 08:02:24 PM, Arthur Bebak wrote: Can anybody help and point me in the right direction? Also I should note that I'm trying to get glibc on an amd64 architecture. You're probably better off with a package than a port, something like this might be what you want: ftp://ftp3.usa.openbsd.org/pub/OpenBSD/3.7/packages/amd64/glib2-2.4.8.tgz Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Bug in pf.conf(5) man page?
In the BNF grammer it says:
route = "fastroute" |
( "route-to" | "reply-to" | "dup-to" )
( routehost | "{" routehost-list "}" )
[ pooltype ]
Shouldn't it be:
route = "fastroute" |
( "route-to" | "reply-to" | "dup-to"
( routehost | "{" routehost-list "}" )
[ pooltype ] )
?
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Another pf.conf(5) man bug?
I may be wrong here but it seems to me that either
http://www.openbsd.org/faq/pf/pools.html#outexample
is wrong in it's route-to syntax or the grammer
in pf.conf(5) has a bug.
http://www.openbsd.org/faq/pf/pools.html#outexample
has 4 statements that contain route to, vis:
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any
The pf.conf(5) grammer says:
routehost = ( interface-name [ address [ "/" mask-bits ] ] )
I'm thinking it should be:
routehost = "(" interface-name [ address [ "/" mask-bits ] ] ")"
?
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Re: BGP peering, 2 peers, hardware reqirements & questions
On 09/13/2005 05:16:38 PM, j knight wrote: --- Quoting Darrin Chandler on 2005/09/13 at 13:56 -0700: > which will try to talk you out of using BGP for load balancing and > present a simpler alternative. Best bet if this track is taken is to involve pf's load balancing features (http://www.openbsd.org/faq/pf/pools.html and pf.conf(5)). What happens when this technique is used and one of the links goes down? Seems to me that there's no provision for failover to the working link and half your connection attempts will fail. Can this be right? Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: BGP peering, 2 peers, hardware reqirements & questions
On 09/13/2005 05:16:38 PM, j knight wrote: --- Quoting Darrin Chandler on 2005/09/13 at 13:56 -0700: > You might also want to read > http://www.inetdaemon.com/columns/ask/internet-load-balancing.shtml, > which will try to talk you out of using BGP for load balancing and > present a simpler alternative. This solution talks about using dual static routes. This doesn't (yet) work on OpenBSD as the support isn't there. Best bet if this track is taken is to involve pf's load balancing features (http://www.openbsd.org/faq/pf/pools.html and pf.conf(5)). I may wind up using pf load balancing and BGP. But I've had trouble with "round-robin" in the past with web sites that use source ip as part of a login process, so I may have to be careful with timeouts and use sticky-address. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: BGP peering, 2 peers, hardware reqirements & questions
On 09/15/2005 10:31:44 PM, j knight wrote: Karl O. Pinc wrote: On 09/13/2005 05:16:38 PM, j knight wrote: Best bet if this track is taken is to involve pf's load balancing features (http://www.openbsd.org/faq/pf/pools.html and pf.conf(5)). What happens when this technique is used and one of the links goes down? Seems to me that there's no provision for failover to the working link and half your connection attempts will fail. Can this be right? That's about right, yep. I do recall some OpenBGP hooks into pf. Maybe there's a way to use these to make failover work. ? Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
ftp-proxy binat design -- Was: Re: binat questions
On 03/22/2007 03:17:00 PM, Stuart Henderson wrote:
One thing to watch out for with binat: you can't use it with
ftp-proxy(8), since binat is of higher priority than the rdr or
nat rules which are added to the anchor. The workaround there
is to list nat and rdr separately.
I just figured this out myself.
binat + ftp-proxy => passive ftp broken
It seems a bit clunky to work-around this in pf.conf
by doing both an rdr and a nat, and having double the
states in consequence.
Instead, how does the design below sound?
The basic idea is to modify ftp-proxy so it adds binat
rules to it's anchors.
ftp-proxy adds a binat rule for every nat rule
added to its anchors. Like so (based on the man page):
---
In case of passive mode (PASV or EPSV):
binat from $client to $server port $port -> $proxy
nat from $client to $server port $port -> $proxy
pass in quick inet proto tcp \
from $client to $server port $port
pass out quick inet proto tcp \
from $proxy to $server port $port
---
The ftp-proxy(8) man page could then have something like
this starting the CONFIGURATION section:
---
To make use of the proxy, pf.conf(5) needs the following rules.
The binat-anchor is optional, all other anchors are
mandatory. The binat-anchor should be filtered so that
it applies to connections initiated by those hosts, and
only those hosts, which are translated with binat rules
further down in the pf rule set. Applying the binat-anchor
to hosts not translated with binat rules, especially
to connections initiated from the Internet, may be a
security risk.
Adjust the rules as needed.
In the TABLE section:
table { 192.168.1.10, 192.168.1.11 }
At the top of the NAT section:
binat-anchor "ftp-proxy/*" from to any
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr pass on $int_if proto tcp from $lan to any port 21 -> \
127.0.0.1 port 8021
---
Note that in theory ftp-proxy could use binat all the
time instead of nat. Not only would this horribly break
backwards compatibility with existing pf configs, it would
require much care when writing pf configs to ensure that
the binat was filtered so that it is used only when
the ftp client initiates a passive ftp data connection.
I can't think of a way to write the binat rule so that
it will only ever apply when the ftp client initiates
a passive data connection. But then, it's late.
If somebody else can then the binat-anchor config
line in pf.conf becomes simpler, and nat _could_ be
entirely replaced by binat.
Yes Virginia, FTP is ugly.
Regards,
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Re: ftp-proxy binat design -- Was: Re: binat questions
On 07/01/2007 12:53:59 PM, Camiel Dobbelaar wrote: On Sun, 1 Jul 2007, Karl O. Pinc wrote: > The basic idea is to modify ftp-proxy so it adds binat > rules to it's anchors. You cannot use port in binat rules, so that would not work. I think this problem can only be fixed in pf itself, by not prioritizing binat and just use the order in which all NAT rules are configured. Changing binat so that you _can_ use port in a binat rule would do it too. It'd be kind of silly, turning binat into a nat with a higher pf priority, but would allow this issue to be addressed in ftp-proxy. Less sensible than eliminating the binat>nat pf priority, but more backwardly compatible. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Running out of RAM -- for the archives
FYI, Running OpenBSD 4.0 stable, 32MB RAM, 3 identical nics. One symptom of running out of RAM is getting a panic on boot. The system boots fine with bsd.rd, but try to boot with the bsd image and you get (from handwritten notes): bmtphy1 at dcl phy1; BCM5201 10/100, rev. 2 dc2 at pci0 dev 12 function 0 "Lite-On PCNIC" rev 0x20: irq 11,: can't create tx map panic config_make_softc: allocation for device softc failed I assume the problem is not enough RAM because when I add more RAM everything works fine. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Running out of RAM -- for the archives
On 07/06/2007 06:46:26 PM, Chris Smith wrote: I assume the problem is not enough RAM because when I add more RAM everything works fine. Repeatable? Sure you've ruled out a seating problem? Yes, repeatable. I didn't try to reseat the nic (or the ram), but it worked fine booting from the bsd.rd kernel, either off the hard drive or the cd. The box ran fine for years until just now. I do get errors on boot that say something like "unable to reset tx and rx to idle state", one for each card. I think 3.9 (and earlier but I don't recall for how far back) did that also. I can get the exact message if you like. Is there something you want me do on repeat? FYI, kernel is 4.0 stable as of June 27, 2007. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Daylight savings time paranoia
Hi, I've applied patch 009_timezone.patch to update the tzfiles for the US DST change. (OpenBSD 4.0) Are the libraries clever enough to know that the files changed or do processes need to be restarted. It's simple enough to reboot the entire box but I'm curious, and it's aesthetically pleasing if I don't need to bring anything down. Thanks. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/14/2007 09:13:19 AM, Martin Schrvder wrote: 2007/3/13, Theo de Raadt <[EMAIL PROTECTED]>: This means everyone should have our latest patches installed. Just a reminder: security-announce exists for messages like this. Use it or delete it. While the bug is bad, the handling of it is even worse. I agree. I'm very annoyed that I have to read about this problem on slashdot. The misc list is not the right place for this announcement, some low-traffic announce list that goes right into my inbox is where this stuff belongs. I rely on having a clear channel for security related problems. OpenBSD's excellent reputation is what allows me to sell it to my clients, which allows me to work with OpenBSD. I've always used the proactive, transparent, and forthright tone of OpenBSD related communication as a selling point. This is the first time I've felt let down and I hope it's the last. I realize we get what we get from the OpenBSD project, and I've certainly gotten a lot more than I've put into it. The response and and announcement latency has always been great, with a low signal to noise ratio. My high expectations have always been met and that's what makes this communication breakdown hurt. It's not the magnitude of the security vulnerability that's the problem. Problems communicating patch availability lead to security problems as severe as unpatched vulnerabilities. Therefore communication problems deserve the degree of acknowledgment and resolution accorded to bugs in the code. Regards, Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/15/2007 10:24:31 PM, Tony Abernethy wrote: Karl O. Pinc wrote: > > On 03/14/2007 09:13:19 AM, Martin Schrvder wrote: > > 2007/3/13, Theo de Raadt <[EMAIL PROTECTED]>: > >> This means everyone should have our latest patches installed. > > > Just a reminder: security-announce exists for messages like > this. Use > > it or delete it. > I rely on having a clear channel for security related problems. > My high expectations have always been met and that's what > makes this communication breakdown hurt. It's not the > magnitude of the security vulnerability that's the problem. > > Problems communicating patch availability lead to security > problems as severe as unpatched vulnerabilities. 1) JUMP! 2) HOW HIGH? If the security is real and is actually proactive Seems like you shouldn't have to play that game. All the security in the world does me no good if it's not installed on my systems. Is the bug actually serious in practice? No. Are you actually safer with the bug fixed? Yes. If I wasn't then there wouldn't be an errata would there? My gut feel is that the next unsung fix will actually make more difference to how secure the resulting system is. I track -STABLE, because I want relyability. I won't get the next unsung fix until an errata is announced that might affect me. I've better things to do than install new builds all the time. This is from a kibitzer, BUT I can guarantee that the security of OpenBSD is NOT due to panic attacks of trying to keep up with the latest security breaches. No, but if security errata announcements arn't delivered in a fashion that delivers them to a human then they do no good. I should not be expected to peruse the misc@openbsd.org list to find errata announcements. OpenBSD says announcements will be made on security-announce when patches become available. This did not happen. Ergo, something is broken. I can't fix it. It may not be fixable, but if it is fixable then it should be fixed. We should not all just pretend it didn't happen. If there is something that can be fixed I'd like to hear about it when it gets fixed. Hence my post. Further, it's important to let the OpenBSD project know how important the brokenness is. (Recall, I'm not talking about the security vulnerability, I'm talking about the communication breakdown.) If my clients hear about a OpenBSD vulnerability from the media, before I hear about it from OpenBSD, that's bad. I want them to hear about problems with their systems, however slight, from me (or directly from OpenBSD of course). I don't want clients to hear about problems on their systems from some media panic attack article. OpenBSD has always solicited feedback regards how important particular bugs are. Now you've the relevant information you can decide how high to jump. Regards, Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/15/2007 10:48:49 PM, Ray Percival wrote: On Mar 15, 2007, at 7:31 PM, Karl O. Pinc wrote: I rely on having a clear channel for security related problems. The only communication problem here is that you don't look at the information that the project puts out there for you. The project says it will announce security errata on the security-announce list. I _am_ assuming this will be done in a timely fashion... This does not seem like an unreasonable assumption. If security-announce is not a place for timely security announcments then change the description, or get rid of it. Which brings the discussion back to where it started, and where it belongs. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/15/2007 11:04:49 PM, Jeremy Huiskamp wrote: That's what I was going to say. If you did things properly, you would have had this patch applied before you knew that it was a remote hole. You have a valid point: any bug is a security problem. However, the topic is not my management practices and the tradeoffs involved therein. The topic is the efficacy of the security-announce list. If I knew security-announce was broken I could write a screen-scraper to check the errata page for me. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/15/2007 11:29:22 PM, Theo de Raadt wrote: I looked for your name on the donations list. I don't see it. I only buy CDs and stuff occasionally, and generally invest time in what I hope are productive ways. How much do I need to donate to keep from having to waste my time in unproductive threads like this? Seriously. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/16/2007 12:09:46 AM, Theo de Raadt wrote: >> I looked for your name on the donations list. I don't see it. > >I only buy CDs and stuff occasionally, and generally >invest time in what I hope are productive ways. I think you bought one CD. I think I've bought 4 over the last 5 years. I wouldn't swear to it. I spent at least one release learning to do it myself sans cd. And 1 t-shirt for sure. Believe me or not. At least one cd was bought under a different name and I don't have the receipt any more. Now you spout and whine. Is that a Robert Heinlein philosophy? I pointed out what I thought was a problem, and I tried to be respectful when I did so. One security errata did not get announced on the security-announce mailing list. Nobody wants to acknowledge it as a problem. Fine. Is it a big problem? Not really. But people seem to want to give me shit for mentioning it. That's fine too but I've a weakness for standing up to agression. I apologize if the repetition to which that has led has made this into a bigger deal than it is. >How much do I need to donate to keep from having to >waste my time in unproductive threads like this? Is that a Robert Heinlein philosophy too? I thought you were offering. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/15/2007 11:55:44 PM, Kian Mohageri wrote: Security isn't about receiving notifications to your Inbox in a timely fashion. It is about being proactive yourself. You should be the one taking measures to secure your systems, and you should be the one ACTIVELY LOOKING for problems. Watching mailing lists isn't enough, and this was announced very early on the ERRATA page. Perhaps my problem is that until this thread it wasn't clear to me that the errata page was inherently more reliable than the mailing list. From a technical perspective I see no reason why either can't be equally reliable. How am I to know? Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/16/2007 12:40:57 AM, Daniel Ouellet wrote: And what are the developers doing with their time? They give it to you and you have the got to complain on top of it! So next time I shouldn't post when I see a problem? That'll help, not. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
I apologise to the list for responding to the flames. I made my point and went beyond into unproductiveness. I'm sorry and I'll stop now. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/16/2007 02:51:48 AM, Kian Mohageri wrote: Expectations aside, being condescending is never warranted. Both Karl and Martin did just that. I did not intend to be condesending and apologise if it was taken that way. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
Thanks very much for taking the time to respond. On 03/16/2007 02:33:28 PM, Kian Mohageri wrote: I'm not saying that you're unappreciative, just that it seemed that way. That is why when I write suggestions, I usually find something to thank the person for too, just so they don't feel under attack. Only hearing from people about things that are done _wrong_ really gets old. We all know that. This is the point I should take away. I tried to praise OpenBSD but I should have thanked folks for the good patch before I started in the problem. Darren's latest reply summed up what I have to say so I'm gonna stop replying to this thread. I think everyone has made their points and we're all on the same page. I like his reply too. I did (just) write him back and say that what I think broke down was what OpenBSD usually excells at: the open admission and discussion of problems. That's what got me about the whole thing, somehow it was out of control from the get-go. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/16/2007 02:51:35 PM, Karel Kulhavy wrote: On Fri, Mar 16, 2007 at 01:26:39PM +, Karl O. Pinc wrote: > It's actually really easy. Follow the first 2 steps in "man release". Unfortunately these instructions fail with not being clear if I should use OPENBSD_4_0_BASE or OPENBSD_4_0 in step 1. It doesn't say if I should pick up the version I have currently installed (4_0_BASE in my case) or the version whose kernel I want co compile (4_0 in my case) Somebody else already pointed out that you need to read the FAQ, particularly http://www.openbsd.org/faq/faq5.html "Building the System from Source" to understand everything. Your question should be answered there. Instead, isn't it possible to download the kernel somewhere from openbsd.org site, check the md5 and replace in bsd/ or wherever the kernel image is stored? Nope. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
lint warnings in release(8) process on i386
Hi, I just installed my shiny new OpenBSD 4.0 cd on a i386 box and went through the release(8) process to bring the system up to 4.0-stable as of Nov 4. I notice a lot of lint warnings somewhat early-on in the process that happens after the install of the new kernel and the reboot. Have I done anything wrong or is this something I need to be concerned about? (I did update partially from one cvs mirror and when that failed went to another.) Thanks. e.g.: lint -z -DMEMMOVE -DLIBC_SCCS -DSYSLIBC_SCCS -I/usr/src/lib/libc/include -DAPIWARN -DYP -I/usr/src/lib/libc/yp -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc -DRESOLVSORT -DPOSIX_MISTAKE -DFLOATING_POINT -DNLS -i -o memmove.ln /usr/src/lib/libc/string/bcopy.c /usr/src/lib/libc/string/bcopy.c:80: warning: converted from 'long' to 'unsigned long' /usr/src/lib/libc/string/bcopy.c:81: warning: converted from 'long' to 'unsigned long' /usr/src/lib/libc/string/bcopy.c:86: warning: converted from 'long' to 'unsigned long' /usr/src/lib/libc/string/bcopy.c:106: warning: converted from 'unsigned long' to 'long' /usr/src/lib/libc/string/bcopy.c:107: warning: converted from 'unsigned long' to 'long' /usr/src/lib/libc/string/bcopy.c:108: warning: converted from 'long' to 'unsigned long' /usr/src/lib/libc/string/bcopy.c:109: warning: converted from 'long' to 'unsigned long' /usr/src/lib/libc/string/bcopy.c:110: warning: converted from 'long' to 'unsigned long' There are also just a few warnings from cc. e.g. (earlier on): cc -O2 -pipe -g -DLIBC_SCCS -DSYSLIBC_SCCS -I/usr/src/lib/libc/include -DAPIWARN -DYP -I/usr/src/lib/libc/yp -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc -DRESOLVSORT -DPOSIX_MISTAKE -DFLOATING_POINT -DNLS -c /usr/src/lib/libc/net/res_init.c -o res_init.o /usr/src/lib/libc/net/res_init.c: In function `_res_init': /usr/src/lib/libc/net/res_init.c:236: warning: comparison is always true due to limited range of data type Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Bridge lockup
Hi,
I was just messing about upgrading some boxes from 3.8
and I shut a router down for a while and the bridge
it was plugged into hung. No response to pings and
no response to the keyboard. The only thing I noticed
was that the 3 keyboard lights were all blinking off
and on together at about a 1 second interval.
Everything is running 3.8.
The OpenBSD router/firewall is plugged into an OpenBSD
bridge via a crossover cable. The bridge interface is
a dc device. The firewall was powered down for a while
and there was probably some traffic destined through it
over the bridge while it was down. The purpose of the
bridge is to do traffic queueing, on both sides of the
bridge, so the bridge is running pf and altq. The
bridge is transparent.
I power cycled the bridge and everything's back to normal.
I don't see anything in the logs.
It's all old, old hardware, fwiw.
Dmesg output for the bridge appended.
It's never been a problem before so I'm not particularly
anxious about the problem, but if there's something to
be learned I'm all ears.
Thanks.
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
OpenBSD 3.8-stable (GENERIC) #1: Tue Dec 20 21:20:37 CST 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD-K6(tm) 3D processor ("AuthenticAMD" 586-class) 501 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX
real mem = 28934144 (28256K)
avail mem = 18362368 (17932K)
using 378 buffers containing 1548288 bytes (1512K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(04) BIOS, date 07/01/99, BIOS32 rev. 0 @
0xf06f0
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/0xda2
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0d10/144 (7 entries)
pcibios0: PCI Interrupt Router at 000:01:0 ("SIS 85C503 System" rev
0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "SIS 530 PCI" rev 0x02
pciide0 at pci0 dev 0 function 1 "SIS 5513 EIDE" rev 0xd0: 530: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 1036MB, 2122780 sectors
atapiscsi0 at pciide0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <, ATAPI CDROM, 1.30> SCSI0 5/cdrom
removable
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
pcib0 at pci0 dev 1 function 0 "SIS 85C503 System" rev 0xb3
"SIS 5595 System" rev 0x00 at pci0 dev 1 function 1 not configured
ppb0 at pci0 dev 2 function 0 "SIS 86C201 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "SIS 530 VGA" rev 0xa2: aperture at
0xe780, size 0x40
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
dc0 at pci0 dev 10 function 0 "Lite-On PNIC" rev 0x20: irq 12, address
00:a0:cc:66:7d:9c
bmtphy0 at dc0 phy 1: BCM5201 10/100 PHY, rev. 2
dc1 at pci0 dev 11 function 0 "Lite-On PNIC" rev 0x20: irq 10, address
00:a0:cc:66:7d:9d
bmtphy1 at dc1 phy 1: BCM5201 10/100 PHY, rev. 2
dc2 at pci0 dev 12 function 0 "Lite-On PNIC" rev 0x20: irq 11, address
00:a0:cc:66:7d:9b
bmtphy2 at dc2 phy 1: BCM5201 10/100 PHY, rev. 2
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
lm0 at isa0 port 0x290/8: LM78
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask e365 netmask ff65 ttymask ffe7
pctr: user-level cycle counter enabled
mtrr: K6-family MTRR support (2 registers)
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
WARNING: / was not properly unmounted
dc0: failed to force tx and rx to idle state
dc0: failed to force tx and rx to idle state
dc1: failed to force tx and rx to idle state
dc2: failed to force tx and rx to idle state
Re: Bridge lockup
On 12/25/2006 06:25:44 AM, Reyk Floeter wrote: hi, On Sun, Dec 24, 2006 at 09:44:46PM +, Karl O. Pinc wrote: > I was just messing about upgrading some boxes from 3.8 > and I shut a router down for a while and the bridge > it was plugged into hung. No response to pings and > no response to the keyboard. The only thing I noticed > was that the 3 keyboard lights were all blinking off > and on together at about a 1 second interval. > > Everything is running 3.8. > can you see anything on the bridge console? Nothing but the usual login prompt. It occurs to me I didn't look around for core files. Where would I find such? (And wouldn't they get cleaned up on reboot?) did it happen before or after the upgrade? Before anything was upgraded. can you please try with 4.0 or -current? I'll give a shot at reproducing it after upgrading to 4.0 stable. It distracted me enough that I did not upgrade. And I figured it couldn't hurt to report it before messing with anything. Thanks. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Why isn't /usr/local/sbin in $PATH?
Hi, I was wondering why /usr/local/sbin was not in the $PATH of the default section of /etc/login.conf. Since /usr/local/bin is in there I can think of no reason not to also have /usr/local/sbin. Regards, Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
"Stock" fstab
Is the "stock" fstab documented anywhere? That is, the fstab that you get if you use the recommended partitions that the install program sets up for you. I've been shuffling partitions around and would like something to compare against with regards to mounting "noexec" "nosuid" etc. Thanks. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: "Stock" fstab
On 01/01/2007 04:08:49 PM, Ingo Schwarze wrote: The default is: - everything except / is nodev - everything except /sbin /usr /usr/bin /usr/sbin /usr/libexec /usr/libexec/* /usr/local /usr/local/* /usr/X11R6 /usr/X11R6/bin is nosuid - noexec is not used by default Thanks to everybody. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: pf rules and binat
On 12/23/2005 05:22:28 AM, Kilaru Sambaiah wrote: I have a question regarding pf and binat. I need to protect mail server and web server behind firewall. I am planning to run pf with binat rules. I need to do the following: 1) Allow only ssh to firewall 2) Allow 80, 443 fron net to web server through binat 3) Allow 25 and 143 to mail server I am ending with allowing 22, 25, 80, 143, 443 to firewall, mail server and webserver. How to enable only required ports for binat instead of all. You don't enable the ports for binat, you binat everything and then enable the ports as you would any other sort of nat-ted ports. Nat-ting of any sort and filtering are separate operations. (You may find more help at pf@benzedrine.cx, but I suggest you read the pf FAQ first.) Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
/etc/isakmpd/ missing from etc38.tgz?
Hi, I just did a 3.6 -> 3.7 -> 3.8 upgrade and looking through the /etc/security mailing I see that I don't have /etc/disklabls/ or /etc/isakmpd/. These directories do not seem to be in etc38.tgz, although they do show up on a system I did a clean 3.8 install on. (3.8 patched to stable as of Dec 20.) 1) Have I done something wrong that these directories have not shown up? 2) Is there anything I need to do to recover other than create the same directory structure that exists on my clean install on the upgraded boxes? Thanks. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: pf rules and binat
On 12/23/2005 05:22:28 AM, Kilaru Sambaiah wrote: I need to do the following: 1) Allow only ssh to firewall 2) Allow 80, 443 fron net to web server through binat 3) Allow 25 and 143 to mail server Rdr may do what you want (maybe along with some natting too but my brain is full at the moment and I can't think about it.) Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
FYI /etc/sysctl.conf comments
FYI, FWIW, While it's on my mind, I get bit by this whenever I upgrade. For whatever reason, whenever I look at /etc/sysctl.conf I think that I'm looking at the system defaults commented out, like /etc/ssh/sshd_config. Instead, they are the opposite of the defaults. #net.inet.ip.forwarding=1 # 1=Permit forwarding (routing) of packets But of course the default is that forwarding is off... I guess I'm writing because this is the only config I can think of that does not document the defaults. Regards, Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: /etc/isakmpd/ missing from etc38.tgz?
On 12/23/2005 09:24:09 AM, Jason Crawford wrote: On 12/23/05, Karl O. Pinc <[EMAIL PROTECTED]> wrote: > Hi, > > I just did a 3.6 -> 3.7 -> 3.8 upgrade and > looking through the /etc/security mailing > I see that I don't have /etc/disklabls/ > or /etc/isakmpd/. These directories do > not seem to be in etc38.tgz, although they > do show up on a system I did a clean 3.8 > install on. (3.8 patched to stable as > of Dec 20.) > 2) Is there anything I need to do to recover > other than create the same directory structure > that exists on my clean install on the > upgraded boxes? You need to personally update /etc yourself, updating doesn't extract etc38.tgz, as that would over write ALL your personal settings including users and passwords. There are sections in the upgrade guide for updating etc, so make sure you do those. If you want to get just the directories, you can do: DESTDIR= make distrib-dirs inside /usr/src/etc but you still need to actually put the files there. Follow the upgrade guide better. Ah, I see the problem. I read the FAQ, chapter 4, install, and it did not point me to the upgrade guide, just said be sure to upgrade /etc (which I did using etc38.tgz as a template, and hence wound up with the missing directories). It would be good if there was a link in chapter 4 of the FAQ to the upgrade guide at the point where it says to upgrade /etc. (Wierd I missed it as I've used the upgrade guide before, but it was late...) So, turns out all I really need to do is run mtree. Thanks. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Dead switch, a quick carp failover question
Hi, Sorry, but I just can't seem to get (all of) net.inet.carp.preempt from the man pages. I could set this up and test it, but I know that somebody's done it already and a quick search of the list archives fails me. Suppose I have 2 firewalls, one failing over to the other with carp. (net.inet.carp.preempt=1 on both firewalls.) Each has 3 interfaces, internet, lan, and dmz. The dmz has, say, a webserver. Now to connect the 2 firewalls to the webserver an additional switch/hub is required in the physical topology. Suppose the switch dies. (I'm thinking the link goes down on both firewalls' dmz interface, but I suppose there are other more spectacular ways the switch could fail.) What is the state of all the carp interfaces on the firewalls? If the dmz interfaces go down, then does this not shut off all the carp interfaces on both firewalls as a group, turning off the parts of both firewalls that are still functioning? Is the solution to this to use ifstated to check the opposite firewall and see if it's master, and if not then shut down the dmz carp interface? (If this is the answer it'd be nice to have ifstated be able to examine interfaces on other hosts, not just on the local host.) TIA. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
ifstated.conf documentation problem?
man 5 ifstated.conf says:
"The init block is used
to initialise the state and is executed each time the
state is entered."
But this does not seem to be true if you use 'init-state'
to enter the state. Or maybe there's something else
wrong with my config below, or with ifstated when there's
no body. Or something.
Odd things happen with the following ifstated.conf.
It just hangs out in the state "starting".
(Starting the daemon by hand after booting.)
Things go back in sync after a state change on
carp0. (carp0 starts out in MASTER. Unpugging
the cable sends it into BACKUP. At that time
ifstated first changes state to 'master', and
then immediately to 'not_master'.)
OTOH, the given config works just fine if
you remove the "init {" and "}" from the "starting"
state, leaving the action as the body of the "starting".
I would expect the opposite, that without "init" the state would
stay in "starting" and have to wait for a state
change before the body was evaluated.
So, it seems that ifstated with "init-state" executes
the body of the inital state on startup, and ignores the
"init" block.
/etc/ifstated.conf:
# Reconfigures daemons based on whether we're master or not.
# We want to startup
init-state starting
# net.inet.carp.preempt must be enabled (set to 1)
# for this to work correctly.
carp_up = "carp0.link.up"
state starting {
init {
# Here we boot the box.
if $carp_up
set-state master
if ! $carp_up
set-state not_master
}
}
state not_master {
init {
run "rm /tmp/am_master"
}
if $carp_up
set-state master
}
state master {
init {
run "touch /tmp/am_master"
}
if ! $carp_up
set-state not_master
}
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Re: ifstated.conf documentation problem?
On 01/01/2006 11:35:19 AM, Jon Hart wrote:
The BNF seems to indicate that what you are trying to do is legal
syntax-wise. At one point I had an ifstated.conf that did something
similiar with a master "switch state" that was the target of
init-state
-- it would help determine what the correct initial state of ifstated
was.
Exactly, the initialization of the state machine is not clearly
documented. How is it that when I remove the INIT{} block from
the given config, taking the set-state out of the init block,
that a set-state actually gets executed when ifstated starts?
The body is not supposed to get executed until a state changes,
and nothing has changed on the interfaces.
Always executing the
body of the initial state on ifstated startup is ok, which is
what _seems_ to be happening. But it's not
documented and it does not make for a particularly clean state
machine implimentation, I think. Suppose you want to have a state
that represents ifstated startup, which is left (forever) as soon
as an interface changes? I feel like I simply poked at my
ifstated.conf with a stick until the state at daemon start turned out
right, which does not give me a high degree of confidence in
my config.
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Re: Dead switch, a quick carp failover question
On 01/01/2006 03:09:03 PM, Marco Pfatschbacher wrote: On Sun, Jan 01, 2006 at 12:28:42AM +, Karl O. Pinc wrote: [...] > Suppose I have 2 firewalls, one failing over to the > other with carp. (net.inet.carp.preempt=1 on > both firewalls.) Each has 3 interfaces, internet, > lan, and dmz. The dmz has, say, a webserver. > Now to connect the 2 firewalls to the webserver > an additional switch/hub is required in the physical > topology. > [...] > If the dmz interfaces go down, then does this > not shut off all the carp interfaces on both > firewalls as a group, turning off the parts > of both firewalls that are still functioning? [...] [...] In your scenario, both firewalls would chage their advskew to 240. But a takeover only happens if one has a lower advskew, not if they are equal. Therefore you should be just fine. So then what happens next when, say, the internet interface goes down on just the master firewall? Even though the backup has two working interfaces and the master only one, the advskew everywhere is already at 240 and the backup will not become the master. Right? (Seems like when net.inet.carp.preempt=1 the advskew should keep going up as more interfaces go down.) Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Dead switch, a quick carp failover question
On 01/02/2006 03:31:10 AM, Marco Pfatschbacher wrote: Although it's rather hypothetical to have two broken switches at the same time, your assumptions are correct. The backup will not take over. It is rather hypothetical, but perhaps not as much as you might think. I have already, during periods of maintenance in a poorly laid out "computer room", kicked the power cord of a switch and unplugged it. Had that happened while I was otherwise re-routing cables a similar situation would have arisen. (It's the old problem of putting _people_ into the mix. :-) Actually I already have a diff that solves this issue. Thank you for the work. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: CGD
On 01/03/2006 09:45:02 PM, Ted Unangst wrote: On 1/3/06, kami petersen <[EMAIL PROTECTED]> wrote: > on a related subject: what's keeping that diff you did to add salting to > vnconfig from hitting the tree? (or something like it) i don't believe that the people asking for cgd really even intend to use it. I don't intend to use svnd (and so have not been paying attention but am venturing to comment anyway), but I do _like_ the idea of having it there to use should the need arise. Salting sounds like something I want because, again, in my uninformed opinion, otherwise you wouldn't see it all over the place in password hashes. Apparently the implementation complexity v.s. increase in security trade-off comes out in favor of salting in at least that problem domain. It would be a question I'd investigate should I ever want an encrypted file system. I'm interested enough to pay a little attention now should somebody either decide to implement salting in svnd or explain why I don't want it. I suspect others are in the same frame of mind. Hence the not-necessarily-informed hand waving surrounding all sorts of encrypted filesystem issues (even though, IMHO, salting is the only issue of significance in svnd that was brought up in the CGD article.) Why did I write this? I guess because I'm lazy like everybody else and am hoping for an expert answer vis. svnd and salting. Perhaps I'm thinking you'd appreciate the data point regards my interest in the subject. Feel free to ignore me. Regardless you should know I do appreciate the work done. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: CGD
On 02/04/2006 01:05:17 AM, veins wrote: I think you are missing the point, cgd and salting are two different and unrelated things. It's not because cgd isn't making it into OpenBSD, that salting won't make it into svnd. I'd explain, but frankly after a night at work i'd rather go and sleep while you google :-) I know cgd and salting are two different things, but cgd salts and svnd does not. IMO, what the thread is about is the criticisms that came up of svnd, compared with "the goodness of CGD", in the interview about CGD. So, people are suddenly wanting CGD... Or maybe I am OT, it is late. :) The svnd salting patch did come up in the CGD thread, which sorta changed the subject to whether or not svnd _should_ salt. ps. tedu just said that he got no comments about his diff, if you really think the idea is valuable, you should be testing the diff. You are right. But another point of my post was to indicate that yes, tedu is right in that most people _won't_ run CGD (or svnd) but people _still_ appreciate having the option open. I, like IMO a lot of people, have only enough interest to kibbutz in the hope of slowly collecting enough information to make an informed choice should the time come to exercise the option. The only apology I make regards this aspect of my post is cluttering up the list in the hopes that what I say will make the people actually doing the work feel appreciated rather than put-upon, by pointing out that the clueless questions are an indication of the large breadth (but not depth) of desire for a crypto fs. It seems tough working on something complex a whole lot of people sorta think they want a little bit. Crypto fs seems to fit that bill more than most. So in way of support I thought I'd try to point this out and give encouragement. Again, sorry if it's a distraction. Regardless, thanks for hitting me with a clue-stick even if I did not need it, because sometimes I do. :-) Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Postfix race condition at boot
Hi, I've an OpenBSD box that's been running postfix for a few years, strictly as a "send-only" mta, and every night the box gets rebooted. Every couple of months postfix does not come up on reboot. All that shows up in the logs is: postfix/postfix-script[3005]: fatal: Postfix integrity check failed! My suspicion is that syslogd has not yet finished making the log socket and the "postfix check" that happens at postfix start fails. (/etc/rc.conf.local has: syslogd_flags="-a /var/spool/postfix/dev/log" ) I can always log in and start postfix manually using the same sendmail command that the rc scripts use. Any suggestions as to how to confirm the problem and/or what to do about it? Does anyone else have this problem? Should I be talking to the postfix port maintainer? FWIW the box is old and slow, a 500MHz-ish i386-ish something. Clearly this does not have my undies in a bunch, but it would be nice to make the problem go away. Thanks for the help. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Postfix race condition at boot
On 07/14/2008 12:47:40 PM, Karl O. Pinc wrote: I've an OpenBSD box that's been running postfix for a few years, strictly as a "send-only" mta, and every night the box gets rebooted. Every couple of months postfix does not come up on reboot. For the record, it seems the problem has something to do with syslogd being configured to log to a central log host, and the log host also rebooting. Or then again maybe not. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Exposing the rc(8) constructed pf ruleset, some patches
Hello, Attached are 3 patches to -current for your consideration. Apply with: cd /usr/src patch -p1 ... The first, expose-default-pf-rules.patch, lets the sysadm use the rc(8) constructed default pf ruleset. This ability was, in a sense, compromised when 5.8 eliminated the pf_rules variable from rc.conf(8). The acceptance of this patch depends in part on whether or not the default pf ruleset in rc(8) is something you want to make readily accessible or whether it's just there as a stopgap. The supplied patch allows the rc.conf(8) pf variable to be set to MINIMAL (in addition to the current YES and NO). A setting of MINIMAL loads the rc(8) default pf ruleset and enables pf. MINIMAL means that rc(8) does not load /etc/pf.conf. Any loading of /etc/pf.conf is left to the sysadm. Why would anyone want such control? Loading /etc/pf.conf after the daemons have started allows pf.conf to contain (in many cases) names instead of IP numbers, simplifying administration. The host is configured as a slave DNS server (serving only on 127.0.0.1) for locally administered zones. So the host always has more or less up to date copies of the zones available locally without need of network connection. pf.conf can then make use of DNS names in the local zones if loaded after the DNS slave is started. Circumstances depending, this can be easier to administer and less error prone than other methods of copying IP addresses from DNS into pf.conf. Other use-cases come to mind. Enabling pf, using the rc(8) fallback pf ruleset, and delaying the load of /etc/pf.conf until after the completion of boot could allow the sysadm to perform final checks or give a final authorization before the host is made fully available on the network. It could be useful for failure testing, testing what happens when the system is booted with broken /etc/pf.conf content. It provides a dirt simple ssh-only mode. In short the feature does not seem crazy and seems useful. Prior to 5.8 access to the rc(8) default rules was "provided" by the rc.conf(8) pf_rules variable. In rc.conf.local the sysadm could set pf_rules=/etc/pf.conf.boot, and have bad content in pf.conf.boot so that pfctl retains the rc(8) default rules. Then, in /etc/rc.local or otherwise, load /etc/pf.conf. Given the present system I can't think of a clean way to both enable pf early in the boot sequence and avoid manually duplicating the default pf ruleset in rc(8). You could resort to keeping a set of minimal boot-time rules in an anchor in /etc/pf.conf, and then swap out the contents of the anchor when ready. A minor problem is that you have the complication of messing with anchors and having an extra file with your real "runtime" pf rules instead of putting them in /etc/pf.conf. The real problem is that you have to come up with your own set of minimal rules that will let the network configure and the system boot but no more. Alternately, you could put unloadable content in /etc/pf.conf, and keep your real pf rules in, say, /etc/pf.conf.runtime. Because the load of /etc/pf.conf would fail you'd retain the rc(8) default pf rules until you loaded /etc/pf.conf.runtime. But this approach is butt-ugly. The 2nd patch, rc-RULES-doc.patch, documents the default pf ruleset in the rc(8) man page. The documentation in both patches was influenced by the wording of the 2nd paragraph in the DESCRIPTION section of the pfctl(8) man page. The 3rd patch, rc-RULES-doc-fix.patch, eliminates the mention of the RULES variable in rc(8) from the man pages. Note: I did my best with the roff. Where I didn't know what I was doing I tried to find a man page that did something similar and copied that. However I'm no roff expert and may have made mistakes. The generated output looks good to me. Please consider these patches and provide feedback if you'd like something changed. Thank you. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein [demime 1.01d removed an attachment of type text/x-patch] [demime 1.01d removed an attachment of type text/x-patch] [demime 1.01d removed an attachment of type text/x-patch]
Re: Exposing the rc(8) constructed pf ruleset, some patches
Well, since there's no attachments, I am including the patches inline. On Mon, 19 Oct 2015 10:27:16 -0500 "Karl O. Pinc" wrote: > Attached are 3 patches to -current for your > consideration. Apply with: > > cd /usr/src > patch -p1 ... > > The first, expose-default-pf-rules.patch, lets > the sysadm use the rc(8) constructed default pf > ruleset. This ability was, in a sense, > compromised when 5.8 eliminated the pf_rules > variable from rc.conf(8). > The supplied patch allows the rc.conf(8) pf > variable to be set to MINIMAL (in addition to > the current YES and NO). A setting of MINIMAL > loads the rc(8) default pf ruleset and enables > pf. MINIMAL means that rc(8) does not load > /etc/pf.conf. Any loading of /etc/pf.conf > is left to the sysadm. > diff -ru old/etc/rc new/etc/rc --- old/etc/rc 2015-10-18 18:48:00.563999219 -0500 +++ new/etc/rc 2015-10-18 23:32:20.084680681 -0500 @@ -329,7 +329,7 @@ # Load pf rules and bring up pfsync interface. if [[ $pf != NO ]]; then - if [[ -f /etc/pf.conf ]]; then + if [[ $pf != MINIMAL && -f /etc/pf.conf ]]; then pfctl -f /etc/pf.conf fi if [[ -f /etc/hostname.pfsync0 ]]; then diff -ru old/usr/share/man8/rc.conf.8 new/usr/share/man8/rc.conf.8 --- old/usr/share/man8/rc.conf.82015-10-18 18:52:15.094082040 -0500 +++ new/usr/share/man8/rc.conf.82015-10-19 09:56:04.757154333 -0500 @@ -187,6 +187,19 @@ .Xr spamd-setup 8 . .El .Pp +.Cm pf +may also be set to +.Cm MINIMAL . +This enables +.Xr pf 4 +packet filtering and, instead of loading the +.Pa /etc/pf.conf +ruleset, retains the ruleset defined in +.Xr rc 8 +by the +.Va RULES +variable. +.Pp .Sy Auxiliary configuration variables mostly determine the locations of specific configuration files. > The 2nd patch, rc-RULES-doc.patch, documents > the default pf ruleset in the rc(8) man page. diff -ru old/usr/share/man8/rc.8 new/usr/share/man8/rc.8 --- old/usr/share/man8/rc.8 2015-10-18 18:51:57.794484223 -0500 +++ new/usr/share/man8/rc.8 2015-10-19 09:49:33.190198395 -0500 @@ -156,6 +156,19 @@ .Nm rc , but this time without performing the file system preen. .Pp +.Nm rc +defines a set of minimal packet filter rules in it's +.Va RULES +variable, used when the +.Xr pf 4 +packet filter is enabled but before +.Pa /etc/pf.conf +is loaded. These rules deny all traffic except that +necessary for inbound SSH connections, outbound ICMP ECHO_REQUEST +datagrams and their returning ECHO_REPLY datagrams, DHCP and BOOTP +client configuration, CARP synchronization and, if needed, NFS mounts +of remote file systems. +.Pp Before .Nm rc starts most system daemons, > The 3rd patch, rc-RULES-doc-fix.patch, eliminates > the mention of the RULES variable in rc(8) from > the man pages. diff -ru new/sbin/pfctl/pfctl.8 newer/sbin/pfctl/pfctl.8 --- new/sbin/pfctl/pfctl.8 2015-10-18 20:27:07.621084480 -0500 +++ newer/sbin/pfctl/pfctl.82015-10-19 10:12:20.638745856 -0500 @@ -98,9 +98,7 @@ be unable to load a ruleset, an error occurs and the original ruleset remains in place. If this happens at system startup, -the ruleset defined by the -.Va RULES -variable in +the minimal ruleset constructed by .Xr rc 8 remains in place. .Pp diff -ru new/usr/share/man8/rc.8 newer/usr/share/man8/rc.8 --- new/usr/share/man8/rc.8 2015-10-19 09:49:33.190198395 -0500 +++ newer/usr/share/man8/rc.8 2015-10-19 10:11:50.091443657 -0500 @@ -156,12 +156,11 @@ .Nm rc , but this time without performing the file system preen. .Pp -.Nm rc -defines a set of minimal packet filter rules in it's -.Va RULES -variable, used when the +If the .Xr pf 4 -packet filter is enabled but before +packet filter is enabled +.Nm rc +constructs a minimal set of rules for use until .Pa /etc/pf.conf is loaded. These rules deny all traffic except that necessary for inbound SSH connections, outbound ICMP ECHO_REQUEST diff -ru new/usr/share/man8/rc.conf.8 newer/usr/share/man8/rc.conf.8 --- new/usr/share/man8/rc.conf.82015-10-19 09:56:04.757154333 -0500 +++ newer/usr/share/man8/rc.conf.8 2015-10-19 10:12:03.667133799 -0500 @@ -192,13 +192,10 @@ .Cm MINIMAL . This enables .Xr pf 4 -packet filtering and, instead of loading the -.Pa /etc/pf.conf -ruleset, retains the ruleset defined in -.Xr rc 8 -by the -.Va RULES -variable. +packet filtering and retains the ruleset constructed by +.Xr rc 8 , +instead of loading +.Pa /etc/pf.conf . .Pp .Sy Auxiliary configuration variables mostly determine Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Exposing the rc(8) constructed pf ruleset, some patches
On Mon, 19 Oct 2015 12:47:46 -0600 Theo de Raadt wrote: > > > The supplied patch allows the rc.conf(8) pf > > > variable to be set to MINIMAL (in addition to > > > the current YES and NO). A setting of MINIMAL > > > loads the rc(8) default pf ruleset and enables > > > pf. MINIMAL means that rc(8) does not load > > > /etc/pf.conf. Any loading of /etc/pf.conf > > > is left to the sysadm. > > I read your explanation, but I really don't see the point. Consider what happens when the IP number of some server, say an SMTP server, is changed. 1) DNS must be updated. 2) On the firewall the pf rules or some pf table content must be changed. But keeping a single IP, like that of an SMTP server, in a table is inefficient and overly complicated. So pf.conf must be edited. (Most rules are kept in files and are not programmatically generated.) 3) Then the rules must be reloaded. But if you write DNS names into your pf.conf file then step 2 can be eliminated. All that's required is to reload the rules. Eliminating an extra editing step reduces error. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Exposing the rc(8) constructed pf ruleset, some patches
On Tue, 20 Oct 2015 01:08:42 -0600 Devin Reade wrote: > > > > On Oct 19, 2015, at 18:26, Karl O. Pinc wrote: > > > But if you write DNS names into your pf.conf > > file then step 2 can be eliminated. All > > that's required is to reload the rules. > > > > Eliminating an extra editing step reduces > > error. > > Unless of course your DNS is on your LAN and after a major power > outage everything is trying to cold boot at once, and now your pf > rules won't resolve because no DNS is available. Exactly. That's why an essential part of the design is to have a slave DNS server for your authoritative zones on the firewall itself. (The firewall need not have a NS record, or serve DNS to anything but itself.) This ensures that authoritative names will always resolve on the firewall, at least until the slave zones timeout because of problems reaching the DNS master. But, since a month is a reasonable timeout, if that happens you've got bigger problems and have had them for a long time. See the first message in the thread for more details regarding ensuring that slave DNS server is there when pf rules load at boot. Thanks for the feedback. I'd love to hear further critique. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Multipath routing and ftp-proxy
Hi, It occurs to me that multipath routing (http://www.openbsd.org/faq/faq6.html#Multipath) might not play nicely with ftp-proxy on a firewall because passive ftp sessions could multiplex the data and control connections via different ISPs. My assumption here is that if you're using multipath routing and 2 ISPs then your NATting, so the ftp server on the Internet would see the control connection from one ISP and the data connection from another, leading to failure. Is this a correct analysis or am I missing something? Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Multipath routing and ftp-proxy
On 06/15/2009 06:58:33 AM, Claudio Jeker wrote: On Sun, Jun 14, 2009 at 11:28:31PM -0500, Karl O. Pinc wrote: > Hi, > > It occurs to me that multipath routing > (http://www.openbsd.org/faq/faq6.html#Multipath) > might not play nicely with ftp-proxy on a firewall > because passive ftp sessions could multiplex the > data and control connections via different ISPs. > My assumption here is that if you're using > multipath routing and 2 ISPs then your NATting, > so the ftp server on the Internet would see > the control connection from one ISP and the > data connection from another, leading to failure. > > Is this a correct analysis or am I missing something? > This could only happen if you created such a freak setup that only a few people manage to setup. The multipath code uses a hash over src and destination IP to decide wich link it will take. So it should be almost impossible to get a mixup of ftp session to the same host. Thanks. I was confused about 2 things: The RFC referenced in the multipath FAQ refesr only to flows, and it was not clear whether the hash that determined path was only over source and destination IP or also included the source and destination port. 2nd I somehow missed the NAT-ting of the passive data connection to the ftp-proxy source address (doh). You cleared these up for me. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
BGP and NATting to multiple ISPs
Hello, In order to minimize Internet connectivity downtime I am looking at obtaining connections from 2 ISPs and running BGP. However I won't have a publicly routeable IP block from ARIN. Each ISP will allocate some of their addresses and the LAN's rfc1918 addresses will be NATted. This presents no real issues for short-lived connections (i.e. traditional HTTP transactions) but for longer lived connections (ssh sessions) some routing change out there on the Internet could cause an established flow to change it's (outbound) route via one of the ISPs to the other. This breaks NAT, or rather the change from one ISP to the other would change the NATing done to the flow and break the connection. What's the best way to solve this problem? The straightforward solution (idea gleaned from Simon Slaytor and the thread at http://marc.info/?l=openbsd-misc&m=122349653116879&w=2) is to use a separate OpenBSD router running BGP to connect to each ISP. +Internet+ || +--- -+ +-+ | ISP1 | | ISP2 | | ROUTER | | ROUTER | | | | | +-+ +-+ |Off-site| ||=== |On-site | +-+ +-+ | OpenBGP | | OpenBGP | | ROUTER |---| ROUTER | |A| |B| +-+ +-+ || || +-+ | PRIVATE NETWORKS| +-+ Routers A and B would be configured with an ASN assigned by ARIN. Each router, A and B, would prefer it's own route to the Internet and I would load balance the traffic from the private networks to the two routers using carp on the interfaces facing the private networks. Because carp will always deliver any given machine's outbound traffic to either router A or router B any given machine's traffic will reach the Internet via a single ISP, resolving the NAT issue. (Existing connections will break should there be a failure and all traffic winds up routing via a single ISP, but that's life.) We would turn the BGP dead timers (holdtime) down low to minimize blackholed traffic. (I'm thinking 3 seconds. Comment?) Naturally we would not advertise our private networks or the routes between the 2 ISPs. What do people think of the above setup? A second question is whether or not it's possible to run 2 instances of bpgd on a single box, using separate routing tables and basically merge the two machines above into 1. (It would be nice then, to use the 2nd box as a carp based hot-spare.) AFAIK all the pieces seem to be in place to for such an approach, but would it really work? Thank you for your time. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: BGP and NATting to multiple ISPs
On 06/18/2009 01:50:17 PM, Pete Vickers wrote: On 18. juni. 2009, at 19.45, Karl O. Pinc wrote: What's the best way to solve this problem? stop trying to bodge it, and get some PI space. I'd love but, how can I justify to ARIN a large enough address block that it won't be dropped by BGP administrators? The only reason we'd need the addresses is to muti-home. I am under the impression this is not reason enough for ARIN, that they are in a rationing mood when it comes to handing out IPv4 address blocks. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: BGP and NATting to multiple ISPs
On 06/18/2009 03:49:08 PM, tico wrote: Karl O. Pinc wrote: On 06/18/2009 01:50:17 PM, Pete Vickers wrote: stop trying to bodge it, and get some PI space. I'd love but, how can I justify to ARIN a large enough address block that it won't be dropped by BGP administrators? The only reason we'd need the addresses is to muti-home. ARIN says you can get a /22 for multihoming if you can justify their 25% / 50% usage as spelled out in their numbering policy. https://www.arin.net/policy/nrpm.html#four322 Can't justify it. Not without cheating, which is not only greedy but stupid. If you can't justify that, then get a /24 of PA space from a provider that *will* allow you to reannounce that /24 via an additional transit and *will* provide you with an LOA that you can provide to that additional transit operator. I may have to go that way if nothing better is available. The number of networks that filter prefixes smaller than /22 don't appear to be that numerous IMHO, but if they do, your /24 will still be reachable as they'll see the larger /19 or whatever from your provider that it's carved out of. But not from the 2nd provider, which defeats the purpose: having a reliable Internet connection no matter what. IP resources are scarce and people are wasteful and greedy. Yes. Most offices don't need BGP multihoming, or any sort of inbound multihoming at all-- just outbound which is easily done without the assistance of the ISPs themselves or ARIN by using NAT and upstream-failover features commonly found in most routers. In this case the requirement is to have Internet service that reaches everywhere, all the time. Upstream failover features involving pinging the link endpoint and such won't cut it. If somebody removes one of the lower floors of the building that will cut the risers and we'll be out of Internet; but then we'll have other problems anyway. Any other sort of outage, it does not matter if the problem's in a router half way around the world, and it's my head on the block. (We've tried other physical links, radio and such, with no luck.) BGP seems the appropriate technology to use in this circumstance. The question becomes how to best deploy it. The 2 router/2 bgpd hack seemed to me to fall within BGPs design parameters, in that it does not seem to be something that will simply stop working one day. But that's what it seems to me; you folks know a lot more and have a lot more experience than I do which is why I'm writing and listening. Is the two router approach really a bodge or a legitimate hack? Thanks for the help. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: BGP and NATting to multiple ISPs
On 06/18/2009 06:01:36 PM, tico wrote: The number of networks that filter prefixes smaller than /22 don't appear to be that numerous IMHO, but if they do, your /24 will still be reachable as they'll see the larger /19 or whatever from your provider that it's carved out of. But not from the 2nd provider, which defeats the purpose: having a reliable Internet connection no matter what. I disagree. "Having a reliable Internet connection no matter what" fails (in my experience) much more frequently for other reasons than not being able to reach the small portions of the world that filter "le 22" ... like power failure, split-brain load balancers, human error, etc. I'm sure you're right. On one of my routers (pulling down a full table), I see That should be enough of an answer, I think. YMMV. Pretty good looking answer. Thanks. Any other sort of outage, it does not matter if the problem's in a router half way around the world, and it's my head on the block. That's the world of I.T. You can spend tons of money [and time] chasing after potential problems that could occur on the other side of the world, and trying to add more theoretical "9's" to your availability, but in my experience keeping clueful people around and solving the most common failure modes first and adding decent monitoring/logging tools pays off much better. Even the "problem on the other side of the world" issues tend to be relatively easy to work around: a) Tier 1 de-peering. solution, don't buy transit from a single tier-1 operator, or from a tier-1 operator at all. b) weird BGP bugs, like the confederation-in-AS4 bug that spread from some small ISP in the Ukraine and affected a bunch of machines around the world. solution, have a fall-back default route on at least one of your BGP speakers and/or have at least one BGP speaker be a router that uses a completely-different BGP stack and hope that one bug won't affect every implementation. Regardless, you'll probably be bitten much more often by common problems before you see these sorts of issues being the limiting factors in your environments overall availability. Especially since it doesn't sound like you're a datacenter. No, we're not a datacenter. Thanks for the good advice. Ultimately, what it comes down to is politics. What reasons will management accept should there be a failure of connectivity. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: BGP and NATting to multiple ISPs
On 06/18/2009 05:52:44 PM, Daniel Ouellet wrote:
Hi, here is a few ideas for you.
A few things to think about here depending on what issue you really
try to solved.
First a good ISP after you actually reach them have built redundancy
on their
network, so unless you try a cheap one, then you should be fine there.
Then what could go wrong? Well plenty yes, but less take them.
- Power, well UPS, if UPS runs out, two ISP will do nothing.
- single router blow up, same thing. So, you designed it with two as
you put it,
great.
- Local loop, last mile, well if it get cut, then it's cut and needs
to be fix.
So two line needs to come in.
One solution may be as simple as getting these two lines form the same
ISP and
have them merge together.
This is all good advice, and has been followed. The next thing
that happens is that there's a failure in the ISPs central office
that takes out both lines. This was solved with different physical
paths to different COs, which prevents bonding but can be poked with
a stick to balance well enough. However, the movement is away
from wire and toward commodity service delivered via ethernet jack.
At that point the players, here anyway, will no longer guarantee
physical path. The only ("only" up to some level of
expenditure above what could get approved) way to get
that level of diversity is to get another ISP (that's not a
reseller of the first one.)
I don't know how things are in Chicago, but if it is like hereon the
east coast,
looks like Verizon enjoy playing with wire in central office and
disconnect
lines at random. I don't really think they are doing that, but sure
hell look
like it however as problem are always with the local loop!
Generally yes. And has been pointed out, by human error of
wondrous variety. I will note however that some
vendor got canned when the Ukrainian (or whatever) ASN problem
took out some router on the other side of the country that
the vendor probably had no control over anyway. As an
IT foot solder I fully expect to someday suffer the same fate.
Now that I think about it I think the strategy I've
been using is to avoid having the same failure occur twice.
Psychologically, it makes me feel better. I'm sure that
reality will catch up with psychology someday, but I'm
putting it off. ;)
Just a thought anyway for your consideration that may address your
needs in a
different way.
Thank you. Good advice.
Karl
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Re: how to create cdrom42.fs?
On 11/08/2007 10:54:20 AM, Soner Tari wrote: On Wed, 2007-11-07 at 13:45 -0500, Steve Shockley wrote: > Try using cdbr as the boot record in no emulation, and put cdboot in the > root directory of the CD. I've tried as you suggested, and it works ... For the archives here's a mkisofs command (after moving cdboot to /path/to/cdrom/root/fs): mkisofs -r -no-emul-boot -b 4.2/i386/cdbr -c boot.catalog \ -o custom42.iso /path/to/cdrom/root/fs/ Note, cdboot boots 4.2/i386/bsd.rd by default. The boot.conf man page is not clear (to me) that you can use a full pathname, not just a filename, to refer to a kernel. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
CVE-2018-15473 ssh user enumeration vulnerability in OpenBSD 6.3
Hi, Ssh in OpenBSD 6.3 (stable), and I presume 6.2, is vulnerable to username existance checking by remote systems. OpenBSD current has a patch. https://github.com/openbsd/src/commit/779974d35b4859c07bc3cb8a12c74b43b0a7d1e0 Demonstration code is found here: https://bugfuzz.com/stuff/ssh-check-username.py Those not familiar with Python can follow these steps to confirm vulnerability existance: # Python version 2.7 may have a different name on your system. virtualenv -p python2.7 sshenum_venv ./sshenum_venv/bin/pip install paramiko ./sshenum_venv/bin/python ssh-check-username.py host.example.com testuser More information can be found in the attached emails previously sent to secur...@openbsd.org. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein CVE-2018-15473 OpenSSH through 7.7 is prone to a user enumeration vulnerability Description: Binary data Re: CVE-2018-15473 OpenSSH through 7.7 is prone to a user enumeration vulnerability Description: Binary data
Re: CVE-2018-15473 ssh user enumeration vulnerability in OpenBSD 6.3
On Tue, 4 Sep 2018 13:16:26 -0400 Daniel Jakots wrote: > On Tue, 4 Sep 2018 12:05:01 -0500, "Karl O. Pinc" > wrote: > > > Ssh in OpenBSD 6.3 (stable), and I presume 6.2, is vulnerable > > to username existance checking by remote systems. > > It was already discussed on the list: > https://marc.info/?l=openbsd-misc&m=153512055014488&w=2 Thank you. I'd looked for "ssh" in past emails, but not the CVE number when looking to see if this was discussed. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Hardware or 4.4 vm problem?
Hello,
I seem to have a problem where 4.4 hangs writing to swap.
I can run: stress --vm 5 --vm-bytes 5M --vmhang 5 --timeout 1m
under 4.3 but under 4.4 the machine hangs. Here's the background.
I'm ran nothing but bind (+ cron etc.) on a 586 with 48M of RAM
(machine A, the problem machine). After upgrading from 4.2 to 4.4
stable patch 7 (via 4.3) it began hanging, no response to keyboard or
network. The console's monitor shows video so I could see there
were no messages on the console. (I have reflexively pressed the
shift key before the attached crt warms up so I can't say whether
there is keyboard response that turns off any sort of video blanking.)
I tried adding another 8M of RAM for a total of 64M, and told bind to
decrease the size of it's data cache, and neither helped.
I ran 9 passes of memtest86+ and booted into knoppix and ran 2 passes
of badblocks -w and got no errors. (I believe I have since messed
with the RAM sticks, FWIW.) Moving the hard drive to another
(slightly slower) 586 with 64M of RAM made the problem go away. The
two boxes are slightly different versions of the same product, old HP
Vectra desktops.
It seemed to me the problem occurred when pages were being swapped
out. There was no thrashing, swapctl showed between 6 and 30%
swap utilization. Sometimes writing to swap works fine because
I can watch increased swap utilization with swapctl -l.
I ran: stress --vm 5 --vm-bytes 5M --vmhang 5 --timeout 1m
after putting another drive in box A. (I picked these
numbers to fill physical ram but not swap.)
On box A the stress command runs fine on 4.3, but if I run the same
command after upgrading to 4.4 it hangs every time. I can run this
command on box B 4.4 (again, stable patched to patch 7) without
problem.
I've already spent more time on this problem that it's worth, but it's
driving me batty. I've even completely disassembled and cleaned box A
down to reseating the processor. Do I have some sort of strange
hardware problem, a software bug, or something else?
Thanks for the help.
Box A dmesg (the box that fails, aprox 40M swap, had 90M of swap
until I replaced the drive):
OpenBSD 4.4-stable (GENERIC) #31: Fri Jan 16 00:18:55 CST 2009
k...@forge.meme.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 167 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
cpu0: F00F bug workaround installed
real mem = 66678784 (63MB)
avail mem = 55009280 (52MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/03/97, BIOS32 rev. 0 @ 0xf705f
apm0 at bios0: Power Management spec V1.2 (BIOS management disabled)
apm0: APM power management enable: unrecognized device ID (9)
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xf6fa0/0x990
pcibios0: PCI BIOS has 7 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 9
pcibios0: PCI Interrupt Router at 000:15:0 ("Intel 82371SB ISA" rev
0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82439HX" rev 0x03
rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 9, address
00:50:fc:27:3d:ea
rlphy0 at rl0 phy 0: RTL internal PHY
vga1 at pci0 dev 13 function 0 "S3 Trio64V2/DX" rev 0x04
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
drm at vga1 unsupported
pcib0 at pci0 dev 15 function 0 "Intel 82371SB ISA" rev 0x01
pciide0 at pci0 dev 15 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 2015MB, 4127760 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets, initiator 7
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask fd65 netmask ff65 ttymask
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
WARNING: / was not properly unmounted
Box B dmesg (aprox 90M swap):
OpenBSD 4.4-stable (GENERIC) #27: Wed Nov 19 23:38:45 CST 2008
k...@forge.meme.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 100 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
cpu0: F00F bug workaround installed
real mem =
Re: Hardware or 4.4 vm problem?
On 02/08/2009 08:23:44 PM, Ariane van der Steldt wrote: On Sun, Feb 01, 2009 at 10:07:49PM -0600, Karl O. Pinc wrote: > I seem to have a problem where 4.4 hangs writing to swap. Chances are its fixed in -current. I just upgraded to a snapshot and the problem seems to have gone away. Thanks. Can you point me to the fix or some other reference so I could tell what other systems might be affected? Thanks. (FWIW, I just had a panic on a similar 4.4 box. It could be totally unrelated. I noticed that the named total memory seems to keep going up even though I've limited the max-cache-size. It may eventually be filling up swap.) Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Hardware or 4.4 vm problem?
On 02/11/2009 04:55:34 PM, Karl O. Pinc wrote: On 02/08/2009 08:23:44 PM, Ariane van der Steldt wrote: On Sun, Feb 01, 2009 at 10:07:49PM -0600, Karl O. Pinc wrote: > I seem to have a problem where 4.4 hangs writing to swap. Chances are its fixed in -current. I just upgraded to a snapshot and the problem seems to have gone away. Thanks. I take it back. The machine hung again a few days ago. It appears that: stress --vm 15 --vm-bytes 5M --timeout 15m will make it hang. (Prior I had also added "--vm-hang 5".) I can't say whether this is a good test or not, because I don't know that this command would have run successfully on 4.3. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: What's the progress of in-kernel proxy for pf NAT?
On 07/23/2009 05:52:38 AM, Henning Brauer wrote: * hu st [2009-07-23 12:35]: > AFAIK pf has only a ftp-proxy anchor. it has userland helpers for the most relevant protocols. Is there a list of these anywhere? ftp-proxy is the only one that comes to mind, of those where the protocol is stupid and utilizes multiple connections/ports. Other proxies, as for http, can be implemented entirely in userspace. I'm not sure but I believe that SIP is also bad this way. Is there a SIP proxy? Are there other "bad" protocols that require things like anchor updates? Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: OpenBSD 4.8 released Nov 1, 2010
On 11/01/2010 10:02:28 AM, Theo de Raadt wrote: > We are pleased to announce the official release of OpenBSD 4.8. I notice that the Errata link on the OpenBSD home page gets a 404. Are there no errata? Thanks for all the great work. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
4.8-stable GENERIC i386 compliliation failure
Hi, I just upgraded from 4.7-stable to 4.8-stable and tried to rebuild the GENERIC i386 kernel and 'make depend' failed. Figuring that maybe I'd done something wrong updating the source with cvs I tried removing /usr/src and replacing it with the 4.8 tarballs and I had the same problem. Here's the output: # cd /sys/arch/i386/conf # config GENERIC Don't forget to run "make depend" # cd ../compile/GENERIC/ # make clean rm -f eddep *bsd *bsd.gdb tags *.[io] [a-z]*.s [Ee]rrs linterrs assym.h # make depend make: don't know how to make ../../../../arch///locore.s. Stop in /usr/ src/sys/arch/i386/compile/GENERIC. (Looks like something wrong with the _arch make variable) Where should I go from here? Thanks. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: 4.8-stable GENERIC i386 compliliation failure
On 11/12/2010 12:41:41 AM, Vivien MOREAU wrote: > Thursday 11 Nov 2010 23:51 (-0600), Karl O. Pinc wrote : > > > I just upgraded from 4.7-stable to 4.8-stable > > How did you upgrade? Did you follow instructions at > <http://www.openbsd.org/faq/upgrade48.html>? Humm. I thought that I used upgrade48.html, but now that I think of it I was doing a couple of systems and uname -a confirms that I didn't do the box I'm building on! Thanks for the cluestick and sorry for the trouble. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
4.8-stable bsd.rd hangs on boot
Hi,
I've an old HP Vectra, with 64MB RAM. When I try to upgrade
from 4.7 to 4.8 the bsd.rd hangs -- the boot
sequence gets as far as "softraid0 at root"
and then stops. There is no response to
ctrl-alt-del and the system must be power
cycled.
Appended is the output from a serial console
booting 4.8 bsd.rd and the dmesg from a regular
4.7 boot. (The output below is from my rebuild
of bsd.rd from the latest in cvs, booting off
the hard drive. I get the same behavior when
booting from a purchased 4.8 cd.)
Where should I go from here?
Thanks.
The 4.8 bsd.rd serial port boot output:
--
>> OpenBSD/i386 BOOT 3.02
boot> bsd.rd
booting hd0a:bsd.rd: 5869116+942776 [61+224832+212939]=0x6ea0dc
entry point at 0x200120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights
reserved.
Copyright (c) 1995-2010 OpenBSD. All rights reserved. http://
www.OpenBSD.org
OpenBSD 4.8-stable (RAMDISK_CD) #0: Sat Nov 13 01:56:19 CST 2010
k...@forge.meme.com:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 100 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
real mem = 66678784 (63MB)
avail mem = 58777600 (56MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/27/97, BIOS32 rev. 0 @ 0xf849d
apm0 at bios0: Power Management spec V1.1
apm0: APM power management enable: unrecognized device ID (9)
pcibios0 at bios0: rev 2.1 @ 0xf83b0/0x920
pcibios0: PCI BIOS has 5 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 9
pcibios0: PCI Interrupt Router at 000:15:0 ("Intel 82371FB ISA" rev
0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0: (uniprocessor)
cpu0: F00F bug workaround installed
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82437FX" rev 0x02
rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 9, address
00:50:fc:4e:9b:5b
rlphy0 at rl0 phy 0: RTL internal PHY
vga1 at pci0 dev 13 function 0 "S3 Trio32/64" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
pcib0 at pci0 dev 15 function 0 "Intel 82371FB ISA" rev 0x02
pciide0 at pci0 dev 15 function 1 "Intel 82371FB IDE" rev 0x02: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 1222MB, 2503872 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
wdc_atapi_intr: warning: reading only 0 of 18 bytes
wdc_atapi_intr: warning: reading only 0 of 36 bytes
wdc_atapi_intr: warning: reading only 0 of 18 bytes
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/
cdrom removable
cd0(pciide0:1:0): using PIO mode 3
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask fde5 netmask ffe5 ttymask
rd0: fixed, 3800 blocks
softraid0 at root
--
4.7 dmesg output
--
$ dmesg
OpenBSD 4.7-stable (GENERIC) #55: Mon Nov 8 03:16:58 CST 2010
k...@forge.meme.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 100 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
real mem = 66678784 (63MB)
avail mem = 54943744 (52MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/27/97, BIOS32 rev. 0 @ 0xf849d
apm0 at bios0: Power Management spec V1.1 (BIOS management disabled)
apm0: APM power management enable: unrecognized device ID (9)
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xf83b0/0x920
pcibios0: PCI BIOS has 5 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 9
pcibios0: PCI Interrupt Router at 000:15:0 ("Intel 82371FB ISA" rev
0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0: (uniprocessor)
cpu0: F00F bug workaround installed
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82437FX" rev 0x02
rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 9, address
00:50:fc:4e:9b:5b
rlphy0 at rl0 phy 0: RTL internal PHY
vga1 at pci0 dev 13 function 0 "S3 Trio32/64" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 15 function 0 "Intel 82371FB ISA" rev 0x02
pciide0 at pci0 dev 15 function 1 "Intel 82371FB IDE" rev 0x02: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 1222MB, 2503872 sectors
wd0(pciide0:0:0): us
Re: 4.8-stable bsd.rd hangs on boot
On 11/15/2010 06:35:38 PM, Nick Holland wrote:
> On 11/15/10 15:54, Karl O. Pinc wrote:
> > I've an old HP Vectra, with 64MB RAM. When I try to upgrade
> > from 4.7 to 4.8 the bsd.rd hangs --
> >
> > Where should I go from here?
>
> try a snapshot, or do a "remote" upgrade (which doesn't use bsd.rd).
>
> As I recall, 4.8 bsd works just fine on Pentium I machines, but
> bsd.rd
> does not. Only impacts Pentium I machines, not 486 (unless you put a
> "Pentium Overdrive" chip in it), not PII.
The "remote" upgrade option worked. Thanks!
FYI, the Nov 14 bsd.rd snapshot boots as well.
> > The 4.8 bsd.rd serial port boot output:
> > --
> > OpenBSD 4.8-stable (RAMDISK_CD) #0: Sat Nov 13 01:56:19 CST 2010
> > k...@forge.meme.com:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> > cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 100 MHz
> ... (gotta love dmesgs!) ...
:)
Karl
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
