Problem with isakmpd, PAYLOAD_MALFORMED and packet lengths
Hi misc, I've been trying to configure the following IPSec client using certificates, but with no success. I want to use it a roadwarrior setup: http://www.ncp-e.com/en/vpn-szenarien-produkte/vpn-produkte/secure-entry-client.html Of course, I'm using isakmpd on the OpenBSD side (4.3). I did manage to get it working with PSK though. The problem is reported on the client side like this (error line): Ike: phase1:name(NCP test) - error - PAYLOAD_MALFORMED isakmpd reports that phase 1 has finished though: 203820.350607 Default isakmpd: phase 1 done: [snip] There are a couple of odd things that I'm noticing. When I run isakmpd to dump everything to /var/run/isakmpd.pcap, I then review it with tcpdump, one of the packets is like this (I've changed the IP addresses to ficticious ones): 18:40:45.034602 200.1.2.3.500 > 190.1.8.1.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 6ae7205b40eda6dc->1673892cac8a5b55 msgid: len: 200 payload: ID len: 12 type: IPV4_ADDR = 200.1.2.3 payload: SIG len: 132 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (6ae7205b40eda6dc->1673892cac8a5b55) [ttl 0] (id 1, len 228) As you can see, the length is of 200 octets. But then, when capturing the same thing on the Windows box, using wireshark, I get this: Frame 9 (260 bytes on wire, 260 bytes captured) Ethernet II, Src: Riverdel_c6:42:91 (00:30:b8:c6:42:91), Dst: Dell_58:de:fb (00:15:c5:58:de:fb) Internet Protocol, Src: 200.1.2.3 (200.1.2.3), Dst: 190.1.8.1 (190.1.8.1) User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500) Internet Security Association and Key Management Protocol Initiator cookie: 6AE7205B40EDA6DC Responder cookie: 1673892CAC8A5B55 Next payload: Identification (5) Version: 1.0 Exchange type: Identity Protection (Main Mode) (2) Flags: 0x81 Message ID: 0x Length: 204 Encrypted payload (176 bytes) It seems to be of 204 bytes. I got this very same result when capturing on the physical interface of the VPN gateway, but I can't find the pcap file right now. So there's nothing in the middle changing this value. Also the Flags fields seem to differ. Also, right now, for some reason, the client is trying to use udpencap (it wasn't in the previous example), and I'm getting udp checksum errors. I did get the certificates authentication working with thegreenbowclient, but couldn't get it to work when using Windows Mobile (my real objective), so I'm moving on with this one (by the way, did any of you have any luck configuring thegreenbow using Windows Mobile with a OpenBSD VPN gateway?). So I really don't know if isakmpd is messing with the packets somewhere. Here's my isakmpd.conf file: [General] Default-phase-1-lifetime=86400,60:86400 Default-phase-2-lifetime=3600,60:86400 Retransmits=5 Exchange-max-time=120 Listen-on=200.1.2.3 [Phase 1] default=checkpoint [checkpoint] Phase=1 Transport=udp Local-address=200.1.2.3 Address=200.1.2.3 Configuration=Default-main-mode [Phase 2] Connections=VPN-Checkpoint [VPN-Checkpoint] Phase=2 ISAKMP-peer=checkpoint Configuration=Default-quick-mode Local-ID=network_corporate Remote-ID=client_thegreenbow [network_corporate] ID-type=IPV4_ADDR_SUBNET Network=192.168.18.0 Netmask=255.255.255.0 [client_thegreenbow] ID-type=IPV4_ADDR_SUBNET Network=10.9.0.0 Netmask=255.255.0.0 [Default-main-mode] DOI=IPSEC EXCHANGE_TYPE=ID_PROT Transforms=3DES-SHA-GRP2-RSA_SIG #Transforms=3DES-SHA-GRP2 [Default-quick-mode] DOI=IPSEC EXCHANGE_TYPE=QUICK_MODE Suites=QM-ESP-3DES-SHA-SUITE [X509-certificates] CA-directory= /etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ CRL-directory= /etc/isakmpd/crls/ Private-key=/etc/isakmpd/private/ncp.key My isakmpd.policy file: KeyNote-Version: 2 Authorizer: "POLICY" I haven't used ipsec.conf for this, as I haven't found examples using X.509 certificates. Any help with this will be greatly appreciated, Thanks Martmn.
Re: Hardware recommendation for firewalls (more than 4 NICs)
First of all, thanks to all of you that have replied. I've thought of adding VLANs, and will be doing it in the future maybe, but in our current situation, that's not possible; not all the switches support this option, and there's still some concern about security implications (specially in upper layers of the company). This may be unfounded, but there is not much that I can do for the time being, and keeping things "simple" by dividing networks physically does it for us right now. I know that it means more cables, more switches, etc., but we can also choose almost any kind of switch and do not need to manage each switch in addition to the firewalls. I really don't want to add to this discussion, but that's the way it's being done right now. Anyway, thanks to everyone! Martmn Coco escribis: Hi misc, I'm currently looking for hardware alternatives for firewalls that should have more than four NICs. Currently we are buying R200s from Dell, but we have the 4 NIC limitation. We could tell Dell to install a quad port NIC (in addition to the two-port onboard card), but I haven't read good things about the way they work. I've also looked into soekris, but they don't seem to have enough CPU for what we want (this is pure speculation) as we also have intense IPSec traffic on some of these firewalls (I've seen that some of them could have encryption boards added to increase performance, but I don't know if it works for any kind of protocol, or at what rate). In any case, what I would like to have is firewalls with multiple NICs (at least 6 NICs) *and* sufficient CPU to let IPSec work alright at least at ~50Mbps (internal backbone firewalls). The multiple NICs are to use trunk, pfsync, real network interfaces, etc. Thanks, Martmn.
Re: Hardware recommendation for firewalls (more than 4 NICs)
Thanks! Have you tried the quad nics on those Dells? We do have a couple of R200s, 860s and 850s running with 2 dual port cards no problem, but we have never tried the quad ports. Torsten Frost escribis: On Fri, Jul 11, 2008 at 11:47 PM, Martmn Coco <[EMAIL PROTECTED]> wrote: Hi misc, I'm currently looking for hardware alternatives for firewalls that should have more than four NICs. Currently we are buying R200s from Dell, but we have the 4 NIC limitation. We could tell Dell to install a quad port NIC (in addition to the two-port onboard card), but I haven't read good things about the way they work. I've also looked into soekris, but they don't seem to have enough CPU for what we want (this is pure speculation) as we also have intense IPSec traffic on some of these firewalls (I've seen that some of them could have encryption boards added to increase performance, but I don't know if it works for any kind of protocol, or at what rate). In any case, what I would like to have is firewalls with multiple NICs (at least 6 NICs) *and* sufficient CPU to let IPSec work alright at least at ~50Mbps (internal backbone firewalls). The multiple NICs are to use trunk, pfsync, real network interfaces, etc. Thanks, Martmn. We run a pair of dell 1950s and have been generally happy with them. We run one dual port intel card and the two build in ports, no problem pushing about 400mbit. The intel cards have worked ok for us for years now in various versions. You can configure the box with two dual nics or two quad nics on the dell web.
Hardware recommendation for firewalls (more than 4 NICs)
Hi misc, I'm currently looking for hardware alternatives for firewalls that should have more than four NICs. Currently we are buying R200s from Dell, but we have the 4 NIC limitation. We could tell Dell to install a quad port NIC (in addition to the two-port onboard card), but I haven't read good things about the way they work. I've also looked into soekris, but they don't seem to have enough CPU for what we want (this is pure speculation) as we also have intense IPSec traffic on some of these firewalls (I've seen that some of them could have encryption boards added to increase performance, but I don't know if it works for any kind of protocol, or at what rate). In any case, what I would like to have is firewalls with multiple NICs (at least 6 NICs) *and* sufficient CPU to let IPSec work alright at least at ~50Mbps (internal backbone firewalls). The multiple NICs are to use trunk, pfsync, real network interfaces, etc. Thanks, Martmn.
Dell R200
Hi misc, I'll be buying a couple of Dell R200 Rackmount servers to use as firewalls/routers. I found this thread in the archives about it: http://marc.info/?l=openbsd-misc&m=120167827217058&w=2 And it seems to be working with snapshots. But my question is: will it be supported by the 4.3 release? We're not used to run -current on our firewalls, and we'd prefer to continue with -release and -stable. Thank you, Martmn.
Re: kernel_map out of virtual space panic on different hardware within hours of difference
That's interesting indeeed. We are running stable, but I'm not sure how frequently we are updating it. And it seems like this one is a somewhat recent patch, so maybe it's not been included on that install. I'm going to try it and let you know. Thanks for your advice and sorry for not checking the errata thoroughly before! Oh, and by the way, do you (or someone else) know why is that message appearing when trying to debug the core file? I mean: (gdb) target kvm bsd.0.core Cannot access memory at address 0xffbe6afc Thanks again, Martmn. Richard Toohey wrote: > On 11/01/2008, at 7:47 AM, Martmn Coco wrote: > >> Hi misc, >> >> I'm having frequent crashes on OpenBSD 4.2 (stable) on different >> machines with the following error: >> >> panic: pmap_pinit: kernel_map out of virtual space! >> >> Specifically, we have two carped firewalls (running pfsync) that >> showed >> the same error with a difference of around 8 hours. First the backup >> crashed, and then master. >> >> > [cut] >> In use 540926K, total allocated 559516K; utilization 96.7% >> >> Particularly, I saw this: >> >> Memory Totals: In UseFreeRequests >> 2115K225K286218211 >> >> And this: >> >> In use 540926K, total allocated 559516K; utilization 96.7% >> >> Which seems to be little to spare. I also checked that a swap >> device is >> configured like this: >> > [cut] >> The other thing I can think of is something related to carp or pfsync. >> >> Any input on this will be much appreciated. >> >> Thank you, >> Martmn. > > If you are running stable, it is not likely to be this (patch 4), is > it? Might be worth double-checking and eliminating the obvious. > > http://marc.info/?l=openbsd-misc&m=119798530823904&w=2
kernel_map out of virtual space panic on different hardware within hours of difference
Hi misc, I'm having frequent crashes on OpenBSD 4.2 (stable) on different machines with the following error: panic: pmap_pinit: kernel_map out of virtual space! Specifically, we have two carped firewalls (running pfsync) that showed the same error with a difference of around 8 hours. First the backup crashed, and then master. I could run "boot dump" on the first one that crashed (the backup box), and then recover the core files with savecore (bsd.0 and bsd.0.core). But now, when trying to run the gdb commands, I get to a point where it tells me this when typing "target kvm bsd.0.core" and hitting enter: myhost:/var/crash# gdb GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd4.2". (gdb) file bsd.0 Reading symbols from /u/data/crash/bsd.0...(no debugging symbols found)...done. (gdb) target kvm bsd.0.core Cannot access memory at address 0xffbe6afc (gdb) Why could this be? I'm kind of stuck at this point. I could run vmstat and ps commands with the -N and -M options, but I don't think I'm getting something very useful. I did see this with vmstat -m though: Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 3918 1714 2283171301280 71 32 321447 17128808 640 0 64 1222 1018 13797629 320 295030 128 405 434699894 160 0 256 229 59 14697840 80 71663 512 447 252447129 40 5629 1024 1274 30 941406 20 419326 2048 17 172263518 101768442 4096 21 61920222 5 0 8192 12 0 12 5 0 163842 0 4615 5 0 327684 0 8 5 0 Memory usage type by bucket size Size Type(s) 16 devbuf, pcb, routetbl, ifaddr, sysctl, vnodes, UFS mount, dirhash, in_multi, exec, xform_data, VM swap, UVM amap, UVM aobj, USB, USB device, temp 32 devbuf, pcb, routetbl, ifaddr, sem, dirhash, proc, VFS cluster, in_multi, ether_multi, exec, pfkey data, xform_data, VM swap, UVM amap, USB, crypto data, temp 64 devbuf, pcb, routetbl, ifaddr, vnodes, sem, dirhash, in_multi, pfkey data, UVM amap, USB, NDP, temp 128 devbuf, routetbl, ifaddr, iov, vnodes, ttys, exec, pfkey data, tdb, UVM amap, USB, USB device, crypto data, NDP, temp 256 devbuf, routetbl, ifaddr, sysctl, ioctlops, vnodes, shm, VM map, file desc, proc, NFS srvsock, NFS daemon, pfkey data, newblk, UVM amap, USB, USB device, temp 512 devbuf, pcb, ifaddr, ioctlops, mount, UFS mount, shm, dirhash, file desc, ttys, exec, UVM amap, USB device, temp 1024 devbuf, ioctlops, namecache, file desc, proc, ttys, exec, tdb, UVM amap, UVM aobj, crypto data, temp 2048 devbuf, ifaddr, ioctlops, UFS mount, pagedep, VM swap, UVM amap, temp 4096 devbuf, ioctlops, UFS mount, MSDOSFS mount, UVM amap, memdesc, temp 8192 devbuf, NFS node, namecache, UFS quota, UFS mount, ISOFS mount, inodedep, crypto data 16384 devbuf, UFS mount, VM swap, temp 32768 devbuf, namecache, VM swap, UVM amap Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 2397 1445K 1445K 39322K 24580 0 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768 pcb95 8K 9K 39322K 4691280 0 16,32,64,512 routetbl 22020K 28K 39322K 16195540 0 16,32,64,128,256 ifaddr 11822K 22K 39322K 1200 0 16,32,64,128,256,512,2048 sysctl 2 1K 1K 39322K20 0 16,256 ioctlops 0 0K 4K 39322K 100884360 0 256,512,1024,2048,4096 iov 0 0K 1K 39322K 180 0 128 mount 4 2K 4K 39322K 1200 0 512 NFS node 1 8K 8K 39322K10 0 8192 vnodes41 7K 80K 39322K 3502240 0 16,64,128,256 namecache 341K 41K 39322K30 0 1024,8192,32768 UFS quota 1 8K 8K 39322K10 0 8192 UFS mount1733K 68K 39322K 4810 0 16,512,2048,4096,8192,16384 shm 2 1K 1K 39322K20 0 256,512 VM map
IP-IP with ipsecctl problem
Hi, I am trying to build IP-IP flows with the new ipsecctl tool. I have two OpenBSD 4.0 snapshots running in different vmware virtual machines, attached to the same network. Box 1 has the following configuration: fw_1 = "10.0.0.1/32" fw_2 = "10.0.0.2/32" flow ipip from $fw_1 to $fw_2 ipip from $fw_1 to $fw_2 spi 0x:0x1110 And Box 2: fw_1 = "10.0.0.1/32" fw_2 = "10.0.0.2/32" flow ipip from $fw_2 to $fw_1 ipip from $fw_2 to $fw_1 spi 0x1110:0x When I ping from either machine to the other having these flows/associations in place, I can see the following on the receiving end (using tcpdump): In Box 1 # ping 10.0.0.2 In Box 2 # tcpdump -ni pcn0 tcpdump: listening on pcn0, link-type EN10MB 17:44:01.570028 10.0.0.1 > 10.0.0.2: icmp: echo request (encap) 17:44:02.610017 10.0.0.1 > 10.0.0.2: icmp: echo request (encap) 17:44:03.590016 10.0.0.1 > 10.0.0.2: icmp: echo request (encap) 17:44:04.590479 10.0.0.1 > 10.0.0.2: icmp: echo request (encap) 17:44:05.610017 10.0.0.1 > 10.0.0.2: icmp: echo request (encap) And the reply is never sent from box 2. I've tried to set net.inet.ipip.allow to 1, but it's the same story. pf is disabled. I've also tried tcpdump on the enc0 interface (after bringing it up), but I don't see anything there either. I was succesful in setting up ipsecctl to use esp flows though. The thing is that I didn't find any examples using ipip with ipsecctl. Any clues? Thanks, Martmn.
Re: IPSec routing problem when using UDP
Yes, my bad. I didn't include any other information because I didn't think it could be version specific. We are using OpenBSD 3.8, and OpenVPN 2.0.6 (from packages). You are right about IPSec not routing. What I meant is how the configured flows are being chosen/matched so that the OS routes the packets through the enc interface or the dmz interface. We are not using carp on that machine. About the ARP issue, we are not connecting between locally attached hosts, so I'm not sure of what you mean, or how it would affect us. When you say toss, you mean discard? I _can_ see the udp reply packet generated by OpenVPN going through the enc0 using tcpdump when connecting from the Internet. There's also the issue of why flushing and reloading the ipsec tunnels/flows solves the problem temporarily. One thing I forgot to mention that may be part of this problem: when we connect to this machine from the office on the other end, the packets don't go through an ipsec tunnel (ie, no flow is used), but when the box running OpenVPN replies, they _do_ get back trough a flow. The first part is also true for someone connecting from the Internet, but the replying packets should get routed trough the dmz interface going to the Internet, not the enc interface. This does work for some time, until, for some reason, they begin to appear in the enc interface. Let me know if this clarifies my first message and if you need more info. Thanks, Martmn. David Bryan wrote: > You may want to include some more information, like what version of > OpenBSD your running, and one version of OpenVPN your running. > One thing you must remember is that IPSec does not route, packets must > match an IPSec profile and are then that packet is wraped up in an > IPSec header and sent across to the remote end. > > If you can get to it with TCP, but not UDP you may have either an ARP > issue (EG: UDP tosses the packet, and does not try again, and > generally it does not get status messages) or a CARP/PF rule set issue. > > More info is needed before questions can be answered. > > Martmn Coco wrote: > >> Hello misc! >> >> We are experiencing what seems to be a routing problem when using ipsec >> flows and udp traffic. >> >> We are using OpenVPN for the employees to connect from the outside world >> to our network. It is configured to use UDP. At the same time, this box >> has an ipsec tunnel configured to talk between different offices in >> different countries. >> >> The problem seems to be that, at some point in time, all the udp packets >> coming from anywhere end up being routed through the enc0 interface, >> when some of them (the ones coming through the Internet and not from our >> other office) should be routed normally, without using any ipsec flow. >> This of course causes all OpenVPN connection attempts coming from the >> Internet to fail, as they will never receive an aswer from the server. >> >> This is not the first time we've encountered this behaviour. I've also >> seen this happening when using named together with ipsec tunnels. The >> very same thing would happen (ie, packets that should go to the Internet >> being routed via enc0). >> >> We have just realised that in both cases, OpenVPN and named, UDP might >> be in use. When the OpenVPN server begins to "misbehave", I can still >> connect via ssh from the Internet (thus discarding TCP issues). >> >> To solve this we have to flush the ipsec tunnels. This seems to solve >> the issue. >> >> The pf rules seem to be alright, keeping state for udp connections. The >> only thing that we may be doing wrong is the ipsec flow configuration, >> but why would it work for some time, to show the detailed behaviour only >> after a couple of hours? >> >> I'll appreciate your input, >> Martmn.
IPSec routing problem when using UDP
Hello misc! We are experiencing what seems to be a routing problem when using ipsec flows and udp traffic. We are using OpenVPN for the employees to connect from the outside world to our network. It is configured to use UDP. At the same time, this box has an ipsec tunnel configured to talk between different offices in different countries. The problem seems to be that, at some point in time, all the udp packets coming from anywhere end up being routed through the enc0 interface, when some of them (the ones coming through the Internet and not from our other office) should be routed normally, without using any ipsec flow. This of course causes all OpenVPN connection attempts coming from the Internet to fail, as they will never receive an aswer from the server. This is not the first time we've encountered this behaviour. I've also seen this happening when using named together with ipsec tunnels. The very same thing would happen (ie, packets that should go to the Internet being routed via enc0). We have just realised that in both cases, OpenVPN and named, UDP might be in use. When the OpenVPN server begins to "misbehave", I can still connect via ssh from the Internet (thus discarding TCP issues). To solve this we have to flush the ipsec tunnels. This seems to solve the issue. The pf rules seem to be alright, keeping state for udp connections. The only thing that we may be doing wrong is the ipsec flow configuration, but why would it work for some time, to show the detailed behaviour only after a couple of hours? I'll appreciate your input, Martmn.
Re: Problems with dvd+rw-tools and UDF
Ok, I've just upgraded to OpenBSD 3.9, but I'm still having the same issues. Martmn Coco escribis: Thanks for your reply. Yes, I have checked this. I didn't associate it with my problem as I am not getting "blue" kernel messages, the disc IS mounted ok, and I'm also not seeing negative numbers when listing the directory for example. Now, previous to using OpenBSD 3.8, I was using 3.7, and I WAS getting negative numbers when listing the directory. That, and seeing that OpenBSD 3.8 had support for UDF, convinced me to migrate to that version. However, when browsing the source via web, I can see changes in the tree for udf (at least I can see newer versions), specially for HEAD and OpenBSD 3.9. Maybe it also got fixed in the STABLE branch of OpenBSD 3.8, although I'm not seeing any differences between OPENBSD_3_8 and OPENBSD_3_8_BASE. Do you think I could solve this by migrating from 3.8 to 3.9? Uwe Dippel wrote: On Mon, 05 Jun 2006 01:04:31 -0300, Martmn Coco wrote: Hi misc, I have, apparently, some sort of problem when burning DVDs with dvd+rw-tools-5.21.4.10.8 using UDF on OpenBSD 3.8. Have you checked the archive; e.g. the thread of 30-12-2005 ? "UDF - where are we ?" Uwe
Re: Problems with dvd+rw-tools and UDF
Thanks for your reply. Yes, I have checked this. I didn't associate it with my problem as I am not getting "blue" kernel messages, the disc IS mounted ok, and I'm also not seeing negative numbers when listing the directory for example. Now, previous to using OpenBSD 3.8, I was using 3.7, and I WAS getting negative numbers when listing the directory. That, and seeing that OpenBSD 3.8 had support for UDF, convinced me to migrate to that version. However, when browsing the source via web, I can see changes in the tree for udf (at least I can see newer versions), specially for HEAD and OpenBSD 3.9. Maybe it also got fixed in the STABLE branch of OpenBSD 3.8, although I'm not seeing any differences between OPENBSD_3_8 and OPENBSD_3_8_BASE. Do you think I could solve this by migrating from 3.8 to 3.9? Uwe Dippel wrote: > On Mon, 05 Jun 2006 01:04:31 -0300, Martmn Coco wrote: > > >> Hi misc, >> >> I have, apparently, some sort of problem when burning DVDs with >> dvd+rw-tools-5.21.4.10.8 using UDF on OpenBSD 3.8. >> > > Have you checked the archive; e.g. the thread of 30-12-2005 ? > "UDF - where are we ?" > > Uwe
Problems with dvd+rw-tools and UDF
Hi misc,
I have, apparently, some sort of problem when burning DVDs with
dvd+rw-tools-5.21.4.10.8 using UDF on OpenBSD 3.8.
The DVDs are burned, but when I check them with tar (to list its
contents for example) I get invalid header errors. Also, when checking
the txt index file I also produce with the backup script, I get garbled
text in some parts. This happens when I try this on the mounted DVD.
The weird things is that, when doing md5 or sha1, I'm getting the same
results. For example:
backup:/# mount -t udf /dev/cd0a /mnt
backup:/# mount
/dev/wd0a on / type ffs (local)
/dev/wd0f on /backups type ffs (local, nodev, nosuid)
/dev/wd0d on /usr type ffs (local, nodev)
/dev/wd0e on /var type ffs (local, nodev, nosuid)
/dev/cd0a on /mnt type udf (local, read-only)
backup:/# md5 /backups/IT.0.tar.gz
MD5 (/backups/IT.0.tar.gz) = a0f59f6af6392c7f2e6ccb9edc52a3a0
backup:/# md5 /mnt/IT.0.tar.gz
MD5 (IT.0.tar.gz) = a0f59f6af6392c7f2e6ccb9edc52a3a0
Of course, the files I burn to the DVD come from /backups. Now, if I
copy it back to the hard disk, there seems to be something not quite right.
backup:/# cp /mnt/IT.0.tar.gz /tmp
backup:/# md5 /tmp/IT.0.tar.gz
MD5 (/tmp/IT.0.tar.gz) = d552935f4992620c66eb787731233881
The md5 result for the /tmp directory seems to vary after copying the
file from the dvd to the hdd a couple of times. So one could say that
the DVD recorder seems to be having problems reading the disc, but then,
why am I getting good md5 or sha1 results when doing them on /mnt? I
have run the md5 tests several times on /mnt, always yielding the same
good result.
The line I use to burn the DVDs is:
backup:/# growisofs -Z /dev/rcd0c -J -joliet-long -udf -r .
I'm doing this on a rather old machine (Pentium 166), but it seems to be
burning them ok at around 1X. After having burned the first one, I then
checked it on a different machine (Windows) opening it with WinRAR and
it seemed to be good.
It seems that md5 (and its relatives) seem to use open() to digest the
file, where cat for example uses fopen(). I really don't know if this
could mean any difference, just speculating, but I really can't see any
other difference between one command and the other.
Any clues?
Full dmesg of the backup box below:
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium/MMX ("GenuineIntel" 586-class) 166 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX
cpu0: F00F bug workaround installed
real mem = 33136640 (32360K)
avail mem = 22245376 (21724K)
using 430 buffers containing 1761280 bytes (1720K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 07/15/95, BIOS32 rev. 0 @ 0xfdb10
apm0 at bios0: Power Management spec V1.2 (BIOS mgmt disabled)
apm0: APM power management enable: power management disabled (1)
apm0: APM engage (device 1): power management disabled (1)
apm0: AC on, battery charge unknown
apm0: flags b0102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI BIOS has 4 Interrupt Routing table entries
pcibios0: no compatible PCI ICU found
pcibios0: Warning, unable to fix up PCI interrupt routing
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 5 function 0 "Hint Host" rev 0x00
pcib0 at pci0 dev 5 function 1 "Hint ISA" rev 0x00
pciide0 at pci0 dev 5 function 2 "Hint EIDE" rev 0x00: no DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 38166MB, 78165360 sectors
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0
5/cdrom removable
rl0 at pci0 dev 9 function 0 "Realtek 8139" rev 0x10: irq 10 address
00:50:bf:17:cc:17
rlphy0 at rl0 phy 0: RTL internal phy
vga1 at pci0 dev 10 function 0 "Cirrus Logic CL-GD5430" rev 0x22
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
rl1 at pci0 dev 11 function 0 "Realtek 8139" rev 0x10: irq 11 address
00:c0:26:00:c9:3c
rlphy1 at rl1 phy 0: RTL internal phy
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
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
isapnp0 at isa0 port 0x279: read port 0x203
"CMI8330. Audio Adapter, @@@0001, , " at isapnp0 port 0x530/8,0x388/8
irq 5 drq 0 not configured
"CMI8330. Audio Adapter, @[EMAIL PROTECTED], , " at isapnp0 port 0x330/2 irq 9 not
configured
joy0 a
Re: Booting very slow when using CompactFlash adapters
Nick,
First of all, thanks for all your input!
My comments below:
Nick Holland escribis:
Martmn Coco wrote:
Hi there,
We are beginning to do some tests with Compact Flash IDE adapters and
OpenBSD 3.8.
We installed the OpenBSD 3.8 using a SanDisk 1.0GB CompactFlash on a
Pentium 4 (dmesg at the end of this message). The installation finished
flawlessly. But when booting, it seems to take ages to boot. The last
time we checked, it took about 55 minutes for it to finish booting. Once
it has booted, all the speed issues seem to disappear.
whoa.
Flash isn't as fast as disk...but..not 55 minutes!
Where is it spending its time?
We went through the BIOS to find anything related to PIO or DMA, but
found nothing suitable.
Nah. I run OpenBSD on lots of machines without DMA, boot time is hardly
any different.
We tried the very same card with a VIA Chipset and it worked like a
charm, we couldn't tell the difference from booting from a normal HD.
ok, good media, good install. Good test. :)
Any input on this will be greatly appreciated :)
Thanks,
Martmn.
I attach the dmesg of the machine that seems to be having problems when
booting:
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz ("GenuineIntel" 686-class) 2.42 GHz
...
pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
^
wd0 at pciide0 channel 1 drive 0:
wd0: 1-sector PIO, LBA, 977MB, 2001888 sectors
wd0(pciide0:1:0): using PIO mode 4, DMA mode 2
...
I see one oddity and another POSSIBLE explanation...
The oddity is you have the flash on the SECOND disk channel. That
should work, but a buggy BIOS might get in the way.
I tried to move it to the first channel, but the speed problem was still
there when booting:
...
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 977MB, 2001888 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 disabled (no drives)
...
The other POSSIBLE explanation is really a stretch, but it is so good
and explains things so well (fortunately, you didn't give details of
what part of the boot process took the time :), I gotta mention it:
I see you have a P4. Could the heat sink have fallen off/not been
mounted properly? Supposedly, the P4 will slow itself down when it
overheats. IF the heat sink were not on at all (or a tiny air gap
existed), the thing would probably reach critical temp within a couple
seconds of power-on, and slow to an absolute crawl. The kernel is
loaded by the BIOS, so until the kernel was completely loaded. At that
point, OpenBSD would be halting the processor when it was idle, and it
would probably stay cool enough to keep running at respectable speed.
Yeah, that's a wacko explanation, but it fits the facts so far (I think.
I live in a P4-free house, so I can't test this theory). I fixed a P3
machine over the phone that did the P3 version of the same problem
(started to boot, then froze, as P3's hang, rather than go glacial).
Blew a good service call by doing that. :)
It is a really good theory :), but as I mentioned before, the install on
this machine went flawlessy, this meaning that when we boot from the
floppy, no speed issues were encountered. We only get slow speeds when
booting from the CompactFlash.
Assuming those two ideas are not worth they electrons they were written
on, next test would be to try an ordinary HD in this machine.
Next thing I'd like to see is a running commentary on what's on the
screen at, say, every five or ten minute intervals, so we can get some
idea where the slow-down is, and what is going on in the machine at each
point. Booting is fairly complicated, a combination of ROM, boot
loaders, OS and hardware...lots of places for things to go wrong.
However, never heard of this one before...
I'm not sure of what you mean by this. When you boot the box, first the
boot> prompt takes a while to appear. Even the part that says using
"disk 0 partition 3" (or something like that) is slow. When you get to
the boot> prompt, and you hit enter, you start to get the "/-\|..."
progress indicator, going rally slow, but one can tell that some
progress is being done, and that is why we left it to see how much it
took to boot. For 55, 56 minutes, it's the same thing, and then the
kernel is load and everything seems to start to work fine. The speed
issue seems to disappear, so it's definitely a BIOS thing or something
like that.
I will use this CompactFlash in the VIA System to move on with the
upgrade, and will try to do some more tests, but I really don't know how
could I continue testing, other than upgrading the mobo's firmware (it's
a Gigabyte board), but I really don't think that will do the trick.
Booting very slow when using CompactFlash adapters
Hi there,
We are beginning to do some tests with Compact Flash IDE adapters and
OpenBSD 3.8.
We installed the OpenBSD 3.8 using a SanDisk 1.0GB CompactFlash on a
Pentium 4 (dmesg at the end of this message). The installation finished
flawlessly. But when booting, it seems to take ages to boot. The last
time we checked, it took about 55 minutes for it to finish booting. Once
it has booted, all the speed issues seem to disappear.
We went through the BIOS to find anything related to PIO or DMA, but
found nothing suitable.
We tried the very same card with a VIA Chipset and it worked like a
charm, we couldn't tell the difference from booting from a normal HD.
Any input on this will be greatly appreciated :)
Thanks,
Martmn.
I attach the dmesg of the machine that seems to be having problems when
booting:
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.40GHz ("GenuineIntel" 686-class) 2.42 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,CNXT-ID
real mem = 536391680 (523820K)
avail mem = 482537472 (471228K)
using 4278 buffers containing 26923008 bytes (26292K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(ec) BIOS, date 03/16/04, BIOS32 rev. 0 @ 0xfb210
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xd9a4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd8b0/224 (12 entries)
pcibios0: PCI Exclusive IRQs: 3 4 5 7 10 11 12
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371SB ISA" rev 0x00)
pcibios0: PCI bus #2 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x1800 0xca000/0x1800
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82865G/PE/P CPU-I/0-1" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel 82865G/PE/P CPU-AGP" rev 0x02
pci1 at ppb0 bus 1
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: irq 5
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: irq 3
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: irq 10
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3 at pci0 dev 29 function 3 "Intel 82801EB/ER USB" rev 0x02: irq 5
usb3 at uhci3: USB revision 1.0
uhub3 at usb3
uhub3: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB" rev 0x02: irq 7
usb4 at ehci0: USB revision 2.0
uhub4 at usb4
uhub4: Intel EHCI root hub, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
ppb1 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xc2
pci2 at ppb1 bus 2
fxp0 at pci2 dev 0 function 0 "Intel 82557" rev 0x0c, i82550: irq 10,
address 00:02:b3:41:67:11
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
vga1 at pci2 dev 2 function 0 "S3 ViRGE DX/GX" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp1 at pci2 dev 4 function 0 "Intel 82557" rev 0x0c, i82550: irq 10,
address 00:0e:0c:6c:48:47
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
skc0 at pci2 dev 9 function 0 "Marvell SKv2" rev 0x13: irq 11
skc0: Marvell Yukon Lite rev. A3 (0x7)
sk0 at skc0 port A: address 00:0d:61:75:19:cf
eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5
ichpcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
wd0 at pciide0 channel 1 drive 0:
wd0: 1-sector PIO, LBA, 977MB, 2001888 sectors
wd0(pciide0:1:0): using PIO mode 4, DMA mode 2
"Intel 82801EB/ER SMBus" rev 0x02 at pci0 dev 31 function 3 not configured
isa0 at ichpcib0
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
it0 at isa0 port 0x290/8: IT87
npx0 at isa0 port 0xf0/16: 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 f7fd netmask fffd ttymask
pctr: user-level cycle counter enabled
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
