Re: A question about puting OpenBSD on a Soekris
On Tue, 15 Dec 2009 15:15:25 -0500, Ted Unangst ted.unan...@gmail.com wrote: As the manufacturers point out, 10,000 write cycles (basically the minimum) means you can overwrite the flash once per day for 27 years. That's a lot of IO for a soekris. It's possible to kill CF cards doing builds or similar. The wear leveling isn't that great. I also find people don't necessarily realize the mysterious green boxes in wiring closets might have problems with surprise reboots. Or better yet a solar powered box up a radio tower out in the middle of nowhere. Using read-only filesystems avoids the need for an fsck to work first time every time in unattended reboots. I think it's useful, but then I've never asked for help for problems I couldn't reproduce on a stock system. :) -Anthony
Re: automating 'fsck -y' after a power failure
What I tend to do for those is just make the filesystems for that machine read-only. This is inconvenient to set up/use for several reasons, but it helps make machines indifferent to surprise reboots. It's handy if the site has unreliable power (eg solar/battery out in the bush somewhere) or even simply because people don't realize random Soekris boxes in wiring cabinets might need to be shut down cleanly. -Anthony On Sat, 3 Oct 2009 11:14:16 -0300, Jose Fragoso inet_use...@samerica.com wrote: Hi, If that was a wisething to do, we would have already done so. In other words, it is not wise. It's foolish. -Otto I totally agree with you. This should not be in the release. However, I have a few obsd boxes working at places where I can not reach with ease. What I want to avoid is telling a client (who does not know anything about unix or Xbsd), by phone, to run 'fsck -y', when the system does not boot, as a last resource, before I have to go there myself. Sometimes, not even a console is available. Thanks for your insight. Regards, Jose
Re: pf, altq, packet rate
I know this is an option, but forcing the resending of traffic doesn't seem to be the most efficient method to me, when I could instead just shape that same traffic when it leaves another interface. That's what I do, and that's how I know it can provide the benefit I claim, though that makes for cumbersome configs when the number of interfaces starts to grow.
Re: pf, altq, packet rate
I was trying to highlight to irix that once traffic is received, it is too late to alter the bandwidth it already used coming in. Dropping packets you've already received can have the impact of causing well-behaved hosts to back off when sending future packets. That's a useful result in itself, even though it's not as powerful as what you can do in the outbound direction. -Anthony
ral(4) questions
Hi, I've been having issues with ral(4) wifi cards, and in going through misc@ archives I've seen similar issues reported by others: the card tends to stop working under load, down/up can sometimes fix it temporarily. I also noticed that several of the people reporting this issue have rt2561 cards, which is the same chipset my existing cards have. I am curious if anyone knows of a version of this chipset that doesn't suffer from this problem. TIA for any advice. :) -Anthony
crashiness when using IPv6 over tun
I'm using OpenVPN to tunnel IPv6 over a tun interface, and I've noticed that if there's a local ping going on the box that goes over the interface when the openvpn process dies, it'll dump the console out to a ddb prompt and that's it until the watchdog timer runs out. I am wondering if anyone else has encountered this in other instances, as an OpenVPN setup specific to me that requires a server is not ideal for helping someone else reproduce this. I'm running 4.4 patched to 005 on i386, but I noticed this on 4.3 as well. I'm using the binary package for openvpn. Hardware is a Soekris net5501. Cheers, -Anthony
Re: altq on inbound traffic
[EMAIL PROTECTED] :-) Bah. It's still relevant. :) for simple cases yes, but you missed quoting this bit: For example, if there is more than one internal network, one can't create a single altq instance that covers them all. You can divide bandwidth between them, but you can't borrow between the different queues in this case. What he said. Queuing on outbound means the destination sees the packet later, so ACKs _are_ delayed, which is the reason this does actually slow down the sending rate (for TCP, anyway). I think the larger concern is that those methods aren't really applicable beyond TCP, even if it's TCP tunneled over UDP/proto 41/whatever. Everything understands dropped packets. :) -Anthony
Re: Kaminsky's DNS bug: PF workaround
Yea but I wonder why PF isn't working here. I didn't see you mention it not working in any of your posts. What you might notice with the PF workaround is that sites like doxpara think you're vulnerable, because queries to the same name server use the same source port. Queries to different servers will use different source ports. The way to confirm it's working is to watch some DNS packets to different servers with tcpdump.
Re: 4.3 random reboots on Soekris 4501
I wanted to check if anyone has experienced similar problems. Is there anything I can do to further debug the issue?Can I change the behavior of a potential crash ? I've never used a 4501, but the 4801s can reboot if they're overloaded and don't have time to poke their watchdog timer.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
I don't think this actually accomplishes much. It still lets poisoned replies back in on the previous port number. hm... I don't think it does. BIND would, but it's going through PF. Without an additional rule to pass in to user named, the UDP reply has to be to the new NATed port. That's the only thing the state associated with the pass out on egress rule is going to be aware of. Eg, I applied the PF rule to one of my machines and checked, here's one of the states: all udp x.y.z.201:42001 - x.y.z.201:60538 - 68.142.196.63:53 MULTIPLE:MULTIPLE I don't care that someone can forge a packet from 68.142.196.63:53 to x.y.z.201:60538, the goal of the NAT rule in this case is to prevent the attacker from finding out what local port I'm using with anyone else. Without that NAT rule, everyone sees 42001. With that NAT rule, the attacker won't discover what local port I'm using for other DNS servers like google or yahoo or whatever. The lookup they get me to do against their domain doesn't have the same local port as the others. If the local port is known, there's apparently some other attacks that can build on that.
trouble talking to serial port
I'm working with a Portwell NAR-5520 (dmesg follows). These machines have an LCD on the front that uses a serial port to talk to the OS. I've been having trouble with these: # stty 2400 /dev/tty01 ...hangs forever... ^Cksh: cannot open /dev/tty01: Interrupted system call # stty -f /dev/tty01 2400 # stty -f /dev/tty01 speed 19200 baud; lflags: echoe echoke echoctl cflags: cs8 -parenb # python Python 2.5.2 (r252:60911, Mar 10 2008, 16:28:59) [GCC 3.3.5 (propolice)] on openbsd4 Type help, copyright, credits or license for more information. f=open(/dev/tty01, w) ...hangs forever... ^CTraceback (most recent call last): File stdin, line 1, in module KeyboardInterrupt This same stuff works fine running Linux on the same hardware: [EMAIL PROTECTED]:~# stty 2400 /dev/ttyS1 [EMAIL PROTECTED]:~# stty /dev/ttyS1 speed 2400 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel -opost -isig -icanon I can also write messages to the LCD from Linux. Both OSes detect the same hardware for the serial ports: OpenBSD: # dmesg | grep pccom pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom0: console pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo Linux: # dmesg | grep 16550A [ 47.459103] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 47.495182] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [ 47.531631] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 47.565162] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A In both cases, I'm using pccom0/tty00/ttyS0 as a serial console. If I stty com1 2400 for OpenBSD at the boot prompt, it sets com0 to 2400 and I get gibberish on the console until I set my terminal app to 2400. Does anyone have any suggestions? I'm kinda stumped. Thanks, Anthony OpenBSD 4.3 (GENERIC.MP) #5: Tue May 6 13:34:02 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (GenuineIntel 686-class) 1.81 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,CX16,xTPR real mem = 1063743488 (1014MB) avail mem = 1020473344 (973MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/05/08, BIOS32 rev. 0 @ 0xfa710, SMBIOS rev. 2.2 @ 0xf (40 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 03/05/2008 acpi0 at bios0: rev 0 acpi0: tables DSDT FACP MCFG APIC acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S5) UAR2(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1) USBE(S1) AC97(S5) AZAL(S5) PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (GenuineIntel 686-class) 1.81 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,CX16,xTPR ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEX0) acpiprt2 at acpi0: bus 2 (PEX1) acpiprt3 at acpi0: bus 3 (PEX2) acpiprt4 at acpi0: bus 4 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus 5 (HUB0) acpicpu0 at acpi0 acpicpu1 at acpi0 acpitz0 at acpi0: critical temperature 60 degC acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xac00! 0xcc000/0x1000 0xef000/0x1000! pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82945G Host rev 0x02 agp0 at pchb0: aperture at 0xd000, size 0x1000 vga1 at pci0 dev 2 function 0 Intel 82945G Video rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 4 int 16 (irq 9) pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: apic 4 int 16 (irq 9), address 00:90:fb:11:75:9e ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x01: apic 4 int 17 (irq 10) pci2 at ppb1 bus 2 em1 at pci2 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: apic 4 int 17 (irq 10), address 00:90:fb:11:75:9f ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x01: apic 4 int 18 (irq 5) pci3 at ppb2 bus 3 em2 at pci3 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: apic 4 int 18 (irq 5), address 00:90:fb:11:75:a0 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x01: apic 4 int 19 (irq 11) pci4 at ppb3 bus 4 em3 at pci4 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: apic 4 int 19 (irq 11), address 00:90:fb:11:75:a1 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 4 int 23 (irq 10) uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 4 int 19 (irq 11) uhci2 at pci0
Re: trouble talking to serial port
In this case, you need to use the callout device for the first serial port, /dev/cua00 in this case. Good luck, see tty(4) or cua(4). Hi, Thanks for the response. :) It looks like I was indeed supposed to use cua, and I can now get a file descriptor. However, I'm still not able to set the baud rate, it's stuck at 19200 whether I try to set it with tty01 or cua01. cua00 corresponds with tty00, which is the serial console, so I shouldn't use that. Thanks, Anthony
Re: trouble talking to serial port
It looks like I was indeed supposed to use cua, and I can now get a file descriptor. However, I'm still not able to set the baud rate, it's stuck at 19200 whether I try to set it with tty01 or cua01. cua00 corresponds with tty00, which is the serial console, so I shouldn't use that. BTW, using stty to set the baud rate for tty00/cua00 has no problems. Exactly the same command lines for tty01/cua01 just don't work.
Re: problem building release for 4.3 stable
On Tue, May 6, 2008 1:27 am, Christer Solskogen wrote: Just to be 100% sure. Do you see libc.so.43.0 in /usr/dest/usr/lib ? I've come across the problem you got just a week ago, and my mistake was wrong tag, but the problem could be that you try to build 4.3 on a 4.3-current/snapshot. Yes, I have libc.so.43.0. I can also confirm the ISO I used to install matches the MD5 sum of cd43.iso at ftp://ftp.openbsd.org/pub/OpenBSD/4.3/i386/MD5, and I'm sure I used OPENBSD_4_3 to check the source out. On Tue, May 6, 2008 9:48 am, Maurice Janssen wrote: Yes, I noticed this as well. I think you can safely ignore this. Interesting. I checked on what's in src.tar.gz. The revision of src/distrib/sets/lists/base/md.i386 in src.tar.gz is NOT the same one as is tagged OPENBSD_4_3. The tarball's revision of the file is 1.693, but the revision of the file tagged for OPENBSD_4_3 is 1.692. I believe what happened is the machine used to generate the release and the tarballs has a newer version of the file than someone will get if they check out the source using the tag OPENBSD_4_3.
Re: problem building release for 4.3 stable
Is this file really supposed to be present in 4.3?
No, because you are building 4.3-current. Change tag to OPENBSD_4_3
instead, and rebuild.
I'm reasonably sure that's not the issue. The rt2860 firmware is
definitely present in the source tree, in files tagged OPENBSD_4_3:
[EMAIL PROTECTED]:/usr/src/sys/dev/microcode/ral# cvs status build.c
===
File: build.c Status: Up-to-date
Working revision:1.4
Repository revision: 1.4 /cvs/src/sys/dev/microcode/ral/build.c,v
Sticky Tag: OPENBSD_4_3 (branch: 1.4.4)
Sticky Date: (none)
Sticky Options: (none)
[EMAIL PROTECTED]:/usr/src/sys/dev/microcode/ral# grep rt2860 *
Makefile:FIRM= ral-rt2561 ral-rt2561s ral-rt2661 ral-rt2860
build.c:output(ral-rt2860, rt2860, sizeof rt2860);
microcode.h:static const uint8_t rt2860[] = {
But it isn't present in src/distrib/sets/lists/base/md.i386
[EMAIL PROTECTED]:/usr/src/distrib/sets/lists/base# cvs status md.i386
===
File: md.i386 Status: Up-to-date
Working revision:1.692
Repository revision: 1.692 /cvs/src/distrib/sets/lists/base/md.i386,v
Sticky Tag: OPENBSD_4_3 (branch: 1.692.2)
Sticky Date: (none)
Sticky Options: (none)
[EMAIL PROTECTED]:/usr/src/distrib/sets/lists/base# grep ral-rt2860 md.i386
***no output***
The file is present in the 4.3 release tarballs obtained from the FTP site:
[EMAIL PROTECTED]:~# tar tzf base43.tgz | grep ral-rt2860
./etc/firmware/ral-rt2860
I don't think me checking out the wrong tag would explain this. I'd love
it if someone could point out any error on my part though.
-Anthony
problem building release for 4.3 stable
I've been having trouble building releases for 4.3. It fails on checkflist, apparently it doesn't expect to see /etc/firmware/ral-rt2860. Output is: [EMAIL PROTECTED]:/usr/src/distrib/sets# sh checkflist 115a116 ./etc/firmware/ral-rt2860 [EMAIL PROTECTED]:/usr/src/distrib/sets# echo $? 1 [EMAIL PROTECTED]:/usr/src/distrib/sets# It looks like src/distrib/sets/lists/base/md.i386 is missing a line for ./etc/firmware/ral-rt2860. This gets added in revision 1.693, but the revision that was tagged OPENBSD_4_3 doesn't have that line. Adding the line locally lets checkflist succeed for me, but I'm not really sure if I'm just silencing a problem while producing an incorrect build. Is this file really supposed to be present in 4.3? TIA for any feedback, -Anthony
Re: removing sendmail
I have seen several installations of Postfix go catatonic due to spam overload, large messages, mailing list expansions, and other undiagnosed problems. These were run by Postfix lovers, so I have always assumed that the installation was correct. In the one case I saw tested replacing Postfix with Sendmail resulted in no further problems. I have seen equally catastrophic failures of Qmail. Trying to do mail right for everyone in base is an exercise in futility.
altq on inbound traffic
I've been tuning some networks for VoIP recently, and to get really good results I've found it's been necessary to do altq in both directions. This has familiarized me with the problems associated with not being able to do altq on inbound traffic. I'm aware of several arguments against doing this, but I don't think any of the ones I've heard address the problem satisfactorily: -Hosts cannot be prevented from sending me packets, so the potential exists for inbound bandwidth to be exausted no matter what I do. But this flaw is shared by other policy tools in PF, such as OS fingerprinting. That OS fingerprinting can be thwarted by an attacker does not mean it's useless as a policy tool. Similarly, in most cases the protocol in question (usually TCP) will throttle a connection in response to lost packets. If the inbound limit is set sufficiently below the maximum of the connection (in my experience, about 10-15% below), it will have the effect of reserving some bandwidth for more important traffic. An attacker or misbehaving protocol can still cause problems, but they will be a problem either way. -Inbound queuing can be implemented in some circumstances by using altq on the internal interface. These situations are what have convinced me it's useful as a policy tool. However, this has flaws. For example, if there is more than one internal network, one can't create a single altq instance that covers them all. You can divide bandwidth between them, but you can't borrow between the different queues in this case. Also, if there's traffic bound for the firewall itself, this won't touch any queues on the inbound direction. As an example, one of the sites where I've encountered this issue has a 10 mb external connection, with two companies sharing the connection. Currently, bandwidth must be divided between the two offices, with no borrowing on the inbound queues because they're on different interfaces. Another instance where this might happen is if an office has a LAN and also a restricted wireless network. I can understand why inbound queuing would be regarded as the wrong solution to this since it's not really inbound queuing; the packet has already been received. An alternative might be the ability to do borrowing between queues for different interfaces, or create a virtual queue that can be a parent to queues on many interfaces. Does anyone know of a way to handle this with the existing capabilities of PF/altq? -Anthony
Re: howto clean disks ?
The 'dd' way is good enough unless someone is willing to to tear the drive apart in a lab.
Re: howto clean disks ?
Once information on a digital media has been overwritten, it cannot be recreated/restored in any lab. All this talk about electron microscopes and overwriting in multiple passes is just a load of crap derived from an old DoD standard. It has no practical meaning. One overwrite is enough. Please let this ugly rumour die :) That is not the case. On magnetic drives, the field can spread beyond the region written to by the drive heads, and can be read by a suitably equipped lab. Reports on how effective this is and what methods can be used to destroy the data vary, but it's safe (or rather, it's necessary) to assume intelligence agencies or big companies can do stuff we don't know about. Besides, drives can transparently reassign sectors that go bad, and no mere dd can get to those. If 'they' can take apart the drive or get suitable firmware for it, they can certainly read all the sectors. Even if you assume overwritten data can not be recovered, you would still need to wipe these sectors. On 6/1/05, Diana Eichert [EMAIL PROTECTED] wrote: place drive in front of dirt embankment position yourself ~100'/30M (you want to get some practice in don't you?)from the target, hrrrm, drive. begin target practice, hrrrm, drive cleaning, until drive is thoroughly destroyed, hrrrm, cleaned. retrieve spent brass ( you do reload don't you?), hrrrm, drive cleaning materials Rendering the drive media unreadable to a standard drive won't necessarily render it unreadable to determined forensic annalysis. It requires high temperatures. If you have information valuable enough to spend that kind of money to recover, then the cost of losing the use of a drive is trivial. I don't advocate thermite or an oxy torch to prevent 'them' from getting their hands on my MP3 collection. I wouldn't take the trouble to destroy any of my hard drives because I don't have anything worth spending that kind of money to recover.
Re: OpenBSD 3.7 -current #50 vs OpenBSD 3.7 Release
Is the 3.7 #50 -current (as of Mar 20) identical to 3.7 #50 -release (as of May 19) My impression is that the #N is to enumerate the generation of the kernel on the current machine. For example, #50 is a high number because they built a whole bunch of kernels on that machine before releasing it. If you build your own kernel, it'll go back to #0 because you're on a different machine, and then count up as you apply patches and make new kernels. I could be wrong though. :)
Re: OpenBSD tested on students learning Unix
Do you think that OpenBSD did things in a way that seemed more obvious to your students, or was it just better/accurate documentation? I would say it's a bit of both. On Linux, the best you can do sometimes is HOWTOs on tldp.org, and those generally don't cover the various cases outside the scope of the specific thing the HOWTO addresses. The docs on OpenBSD are easy to find because there's only a few places to look, and good enough that you can figure things out without consulting anything else most of the time. It actually works, and that encourages you to consult the docs early and often. Also, the critical mass of stuff you need to learn to run the system is a lot smaller. On Linux, you generally need to know how to compile a kernel and several other things that are fairly complicated. With OpenBSD, the core set of things you need to know to run the system are very well documented so you can be mostly self-sufficient very quickly. When you want to do something new, you learn it from a base of things you actually understand already. I tried to get into Linux a number of times, but I couldn't get fluent enough with it to actually do anything useful, so I always ended up abandoning it because I had a perfectly good Windows box (for small values of perfectly) and because I couldn't maintian a Linux machine properly. OpenBSD was completely different. It only took a few days to learn the basics of how to maintain the system, and setting up new stuff was trivial. Because setting things up was so easy, I quickly came to rely on the box for a number of services. Once I actually had a reason to stick with it, it was a done deal. Also, learning Linux wasn't so hard once I knew the general UNIX philosophy, and Linux ultimately did displace Windows on my desktop, but it's basically a client machine. I'm SSHed to the OpenBSD box for everything important or complicated. Linux has since improved significantly, but they haven't actually fixed the stuff that sucks. They've mostly just painted over it. It's still really annoying if you have to get into the details. And that's on Debian, where they actually test things.
