Re: serial input line not working [solved]
Am 22.09.2016 um 04:47 schrieb Philip Guenther: > Backing up to the beginning... > > On Wed, Sep 21, 2016 at 2:39 PM, Peer Janssen <p...@pjk.de> wrote: >> I updated an alix.3c3 box from OpenBSD 4.6 release to 6.0 release >> recently via bsd.rd install kernel. >> This went very smoothly, except that now I can't get a serial stream via >> the DB9 serial connector. > Ah, you accessed it under OpenBSD 4.6. That raises two questions: > 1) What was the dmesg when this box ran 4.6? > 2) What was the exact command line you used then Since I riskily upgraded in-place, no chance to get back to a dmesg of the installation which was already history. >> But on that alix box, nothing seems to arrive at the serial line. > The 6.0 dmesg you included doesn't include any "com" drivers that I > recognize, so it doesn't surprise me that nothing seems to work...and > thus the query about what 4.6 reported and what worked there. That was indeed the problem. The solution was to switch a setting in the BIOS which enabled the com0 port. Duh! It was there from the beginning to see, but I didn't know certain OpenBSD terminology yet to understand how the different levels of access to the port were named and interact. E.g. what precisely "configured" (as in "Device not configured") referred to, namely that it's not me who had to do that configuring manually in whatever securelevel etc. of the fine OpenBSD software, but that it should have been the autoconf mecanism of the kernel which should have done it, so I searched around without realizing, what is now obvious to me, too, that the configuration had to take place -- manually indeed -- before OpenBSD even got it's chance to do it's own configuration. So, more RTFM cleared things up, and now I got a better grip on the system. This also enabled me to get gpio working on that and other boards. Great fun! Thanks to all who helped! Great software! Peer -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Am 29.09.2016 um 14:05 schrieb Stuart Henderson: > On 2016-09-28, Peer Janssen <p...@pjk.de> wrote: >> # tftpd -d /tftpboot >> >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out > Check your firewall rules. The packets where the file is actually > transferred come from a high numbered source port: > > Request $high_port_A -> port 69 > First file packet $high_port_B -> $high_port_A > Ack $high_port_A -> $high_port_B > Second file packet $high_port_B -> $high_port_A > etc. > > I suspect you might not be allowing the return packets. Adding "log" > to any "block" rules that you have and watch "tcpdump -neipflog0" > probably gives you some clues. Thank you for this hint. Frankly, I find it generally enthusing to realize the power of the tools you OpenBSD ecosystem create. The pflog0 live tcpdump log revealed that no packets at all were dropped, and even turning off pf completely didn't change the behavior. But I realized that there must be something in the dhcpd options and/or something related to arp resolution, which I didn't grok. So I read some more RFCs about pxebooting in relation to dhcp and arp, but finally abandoned this problem for now, because it was taking way too much time for my current local situation. That alix2d13 is now working fine, although I finally installed it via CF-Disk, now that I got that reader. (I'm not working in my home lab, so I didn't have that part handy, what made my try using pxeboot in the first place.) Maybe I'll try pxebooting again later, either just to get to the bottom of it, or using it for installing a row of servers, because I still like the idea of that method. Peer -- Peer Janssen - p...@pjk.de
Re: OpenBSD 6.0 bsd.rd doesn't boot on soekris net4801 [wrap up]
Wrap-up:
The net4801 is now working as expected.
(Before reading his post,) I did exactly what Nick suggested. This
worked well. Lesson learned: mixing bootloader and kernel from different
releases doesn't necessarily work.
Another lesson: An intuition told me that I might have had to sync after
dd'ing an image to the new CF card before taking it out of the
zillion-in-1 adapter (before any automatic sync occured, that is). A log
confirmed that I indeed forgot that sync. The reinstallation then should
have solved any of these.
Thanks to all who helped, or encouraged me by contributing their
comparative working or failing cases!
Peer
Am 02.10.2016 um 17:54 schrieb Peer Janssen:
> Goal: Upgrade a working soekris net4801 from OpenBSD 4.6 to 6.0.
>
> First I copied the complete 256 MB SiliconDrive CF-Disk to a newer
> SanDisk 8 GB Ultra one and rebootet, which worked smoothly and fine.
>
> I took the bsd.rd from an OpenBSD 6.0 i386 machine:
>
> # ls -l /bsd.rd
> -rw-r--r-- 1 root wheel 7173390 Sep 20 19:17 /bsd.rd
> # md5 /bsd.rd
> MD5 (/bsd.rd) = 191559b8c5907ca34c144462366b021a
> # dmesg
> OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
> 586-class) 499 MHz
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
>
> [snip]
>
> put it in / of a working soekris net4801 with OpenBSD 4.6 in order to
> jump-upgrade the system, but it doesn't boot the 6.0 bsd.rd install image:
>
> $ cu -l /dev/ttyS0 -s 19200
> Connected.
> 1
> Using drive 0, partition 3.
> Loading...
> probing: pc0 com0 com1 pci mem[639K 255M a20=on]
> disk: hd0+
>>> OpenBSD/i386 BOOT 3.02
> switching console to com0
> >> OpenBSD/i386 BOOT 3.02
> boot> stty com0 19200
>
> com0: 19200 baud
> boot> set tty com0
> switching console to com0
>>> OpenBSD/i386 BOOT 3.02
> boot> boot bsd.rd
> booting hd0a:bsd.rd: 3211188+1318224+2061312+0+442368
> [72+298576+282894]=0x744144
> entry point at 0x2000d4
> cu: Got hangup signal
>
> Disconnected.
> ==> So here is where it brakes. Immediate reconnect:
>
> $ cu -l /dev/ttyS0 -s 19200
> Connected.
>
> [snip: more empty lines]
> ==> it goes into a reboot like this:
>
> comBIOS ver. 1.28 20050529 Copyright (C) 2000-2005 Soekris Engineering.
>
> net4801
>
> 0256 Mbyte MemoryCPU Geode 266 Mhz
>
> Pri Mas SDCFHS-008G LBA Xlt 974-255-63 7831 Mbyte
>
> Slot Vend Dev ClassRev Cmd Stat CL LT HT Base1Base2 Int
> ---
> 0:00:0 1078 0001 0600 0107 0280 00 00 00
> 0:06:0 100B 0020 0200 0107 0290 00 3F 00 E101 A000 10
> 0:07:0 100B 0020 0200 0107 0290 00 3F 00 E201 A0001000 10
> 0:08:0 100B 0020 0200 0107 0290 00 3F 00 E301 A0002000 10
> 0:10:0 104C AC23 06040002 0107 0210 08 3F 01
> 0:18:2 100B 0502 01018001 0005 0280 00 00 00
> 0:19:0 0E11 A0F8 0C031008 0117 0280 08 38 00 A0003000 11
> 1:00:0 100B 0020 0200 0107 0290 00 3F 00 D001 A400 05
> 1:01:0 100B 0020 0200 0107 0290 00 3F 00 D101 A4001000 11
> 1:02:0 100B 0020 0200 0107 0290 00 3F 00 D201 A4002000 05
> 1:03:0 100B 0020 0200 0107 0290 00 3F 00 D301 A4003000 11
>
> 1 Seconds to automatic boot. Press Ctrl-P for entering Monitor.
>
> comBIOS Monitor. Press ? for help.
> [snip]
> ==> For comparison and giving machine details, booting into the working
> OpenBSD 4.6:
>> boot
> Using drive 0, partition 3.
> Loading...
> probing: pc0 com0 com1 pci mem[639K 255M a20=on]
> disk: hd0+
>>> OpenBSD/i386 BOOT 3.02
> switching console to com0
> >> OpenBSD/i386 BOOT 3.02
> boot>
> booting hd0a:/bsd: 6563548+1052072 [52+345584+327881]=0x7e7ce8
> entry point at 0x200120
>
> [ using 673892 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> Copyright (c) 1995-2009 OpenBSD. All rights reserved.
> http://www.OpenBSD.org
>
> OpenBSD 4.6 (GENERIC) #58: Thu Jul 9 21:24:42 MDT 2009
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC"
> 586-class) 267 MHz
> cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
> real mem = 268005376 (255MB)
> avail mem = 250331136 (238MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 20/50/29, BIOS32 rev. 0 @ 0xf7
Re: OpenBSD 6.0 bsd.rd doesn't boot on soekris net4801 [solved, but ...]
Am 02.10.2016 um 21:24 schrieb Paul Suh: >> On Oct 2, 2016, at 3:06 PM, Peer Janssen <p...@pjk.de> wrote: >> >> Now I reinstalled on another CF-Disk (4GB Transcend) with another method >> (miniboot.fs), this went through and first-rebooted just fine. >> >> But now halting the machine produces a panic: > I suspect that part of the problem with your 4801 is just old age. I'm phasing > out the four units that I own, since they're all becoming unreliable with > inexplicable and unrepeatable crashes, freezes, and panics. Some of the > problem can be traced to bad power supplies, but overall a big part is just > plain old age. Any 4801 must be at least ten to twelve years old (date of > manufacture, not date of sale). I think by now enough of the capacitors have > gone bad or are on the way to going bad that they're dying. :-( > > Also, for my use they don't have enough CPU power to run IPSec tunnels at full > WAN speed so I need new hardware anyway. > > Hope this helps. This surely is interesting background information. Only, the installed system also showed a panic when I put that same CF-Disk in an alix board (the one I talked in my message with this "[misc] tfdpd doesn't deliver pxeboot file" title). It booted just fine, but also panicked on halt. So there might be more to it. Of course, these systems probably are rarely halted anyway. But still, who knows what else is hiding behind such a panic. Peer -- Peer Janssen - p...@pjk.de
Re: OpenBSD 6.0 bsd.rd doesn't boot on soekris net4801 [solved, but ...]
g 2:17, of which 52 s
are for reordering libraries).
But then I could reproduce it several times, halting directly after
logging in.
Peer
Am 02.10.2016 um 17:54 schrieb Peer Janssen:
> Goal: Upgrade a working soekris net4801 from OpenBSD 4.6 to 6.0.
>
> First I copied the complete 256 MB SiliconDrive CF-Disk to a newer
> SanDisk 8 GB Ultra one and rebootet, which worked smoothly and fine.
>
> I took the bsd.rd from an OpenBSD 6.0 i386 machine:
>
> # ls -l /bsd.rd
> -rw-r--r-- 1 root wheel 7173390 Sep 20 19:17 /bsd.rd
> # md5 /bsd.rd
> MD5 (/bsd.rd) = 191559b8c5907ca34c144462366b021a
> # dmesg
> OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
> 586-class) 499 MHz
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
>
> [snip]
>
> put it in / of a working soekris net4801 with OpenBSD 4.6 in order to
> jump-upgrade the system, but it doesn't boot the 6.0 bsd.rd install image:
>
> $ cu -l /dev/ttyS0 -s 19200
> Connected.
> 1
> Using drive 0, partition 3.
> Loading...
> probing: pc0 com0 com1 pci mem[639K 255M a20=on]
> disk: hd0+
>>> OpenBSD/i386 BOOT 3.02
> switching console to com0
> >> OpenBSD/i386 BOOT 3.02
> boot> stty com0 19200
>
> com0: 19200 baud
> boot> set tty com0
> switching console to com0
>>> OpenBSD/i386 BOOT 3.02
> boot> boot bsd.rd
> booting hd0a:bsd.rd: 3211188+1318224+2061312+0+442368
> [72+298576+282894]=0x744144
> entry point at 0x2000d4
> cu: Got hangup signal
>
> Disconnected.
> ==> So here is where it brakes. Immediate reconnect:
>
> $ cu -l /dev/ttyS0 -s 19200
> Connected.
>
> [snip: more empty lines]
> ==> it goes into a reboot like this:
>
> comBIOS ver. 1.28 20050529 Copyright (C) 2000-2005 Soekris Engineering.
>
> net4801
>
> 0256 Mbyte MemoryCPU Geode 266 Mhz
>
> Pri Mas SDCFHS-008G LBA Xlt 974-255-63 7831 Mbyte
>
> Slot Vend Dev ClassRev Cmd Stat CL LT HT Base1Base2 Int
> ---
> 0:00:0 1078 0001 0600 0107 0280 00 00 00
> 0:06:0 100B 0020 0200 0107 0290 00 3F 00 E101 A000 10
> 0:07:0 100B 0020 0200 0107 0290 00 3F 00 E201 A0001000 10
> 0:08:0 100B 0020 0200 0107 0290 00 3F 00 E301 A0002000 10
> 0:10:0 104C AC23 06040002 0107 0210 08 3F 01
> 0:18:2 100B 0502 01018001 0005 0280 00 00 00
> 0:19:0 0E11 A0F8 0C031008 0117 0280 08 38 00 A0003000 11
> 1:00:0 100B 0020 0200 0107 0290 00 3F 00 D001 A400 05
> 1:01:0 100B 0020 0200 0107 0290 00 3F 00 D101 A4001000 11
> 1:02:0 100B 0020 0200 0107 0290 00 3F 00 D201 A4002000 05
> 1:03:0 100B 0020 0200 0107 0290 00 3F 00 D301 A4003000 11
>
> 1 Seconds to automatic boot. Press Ctrl-P for entering Monitor.
>
> comBIOS Monitor. Press ? for help.
> [snip]
> ==> For comparison and giving machine details, booting into the working
> OpenBSD 4.6:
>> boot
> Using drive 0, partition 3.
> Loading...
> probing: pc0 com0 com1 pci mem[639K 255M a20=on]
> disk: hd0+
>>> OpenBSD/i386 BOOT 3.02
> switching console to com0
> >> OpenBSD/i386 BOOT 3.02
> boot>
> booting hd0a:/bsd: 6563548+1052072 [52+345584+327881]=0x7e7ce8
> entry point at 0x200120
>
> [ using 673892 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> Copyright (c) 1995-2009 OpenBSD. All rights reserved.
> http://www.OpenBSD.org
>
> OpenBSD 4.6 (GENERIC) #58: Thu Jul 9 21:24:42 MDT 2009
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC"
> 586-class) 267 MHz
> cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
> real mem = 268005376 (255MB)
> avail mem = 250331136 (238MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 20/50/29, BIOS32 rev. 0 @ 0xf7840
> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #1 is the last bus
> bios0: ROM list: 0xc8000/0x9000
> cpu0 at mainbus0: (uniprocessor)
> cpu0: TSC disabled
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
> sis0 at pci0 dev 6 function 0 "NS DP83815 10/100"
OpenBSD 6.0 bsd.rd doesn't boot on soekris net4801
uot; rev 0x00, DP83816A: irq 11, address 00:00:24:c4:fa:31 nsphyter4 at sis4 phy 0: DP83815 10/100 PHY, rev. 1 sis5 at pci1 dev 2 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 5, address 00:00:24:c4:fa:32 nsphyter5 at sis5 phy 0: DP83815 10/100 PHY, rev. 1 sis6 at pci1 dev 3 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 11, address 00:00:24:c4:fa:33 nsphyter6 at sis6 phy 0: DP83815 10/100 PHY, rev. 1 gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00 gpio0 at gscpcib0: 64 pins "NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 1-sector PIO, LBA48, 7647MB, 15662304 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3 wdstatus 0 ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev 0x08: irq 11, version 1.0, legacy support isa0 at gscpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifocu: Got hangup signal Disconnected. ==> (Why that?) Well, again, immediate reconnect: (Just hese lines (reinserted from dmesg after login) are missing: com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo) $ cu -l /dev/ttyS0 -s 19200 Connected. pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 midi0 at pcppi0: spkr0 at pcppi0 nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 10: GPIO VLM TMS gpio1 at nsclpcsio0: 29 pins gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1: npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb0 at ohci0: USB revision 1.0 uhub0 at usb0 "Compaq OHCI root hub" rev 1.00/1.00 addr 1 biomask fbc5 netmask ffe5 ttymask softraid0 at root root on wd0a swap on wd0b dump on wd0b Automatic boot in progress: starting file system checks. /dev/rwd0a: file system is clean; not checking setting tty flags pf enabled starting network DHCPREQUEST on sis0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 (c0:25:06:d4:45:9e) bound to 192.168.0.122 -- renewal in 432000 seconds. starting system logger starting initial daemons: ntpd. savecore: /dev/wd0b: Device not configured checking quotas: done. building ps databases: kvm dev. clearing /tmp starting pre-securelevel daemons:. setting kernel security level: kern.securelevel: 0 -> 1 creating runtime link editor directory cache. preserving editor files. starting network daemons: sendmail inetd sshd. starting local daemons:. standard daemons: cron. Sun Oct 2 17:25:22 CEST 2016 OpenBSD/i386 (net4801.fritz.box) (tty00) login: root Password: Last login: Sun Oct 2 17:00:53 on ttyp0 from kubuntu-neu.fritz.box OpenBSD 4.6 (GENERIC) #58: Thu Jul 9 21:24:42 MDT 2009 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. You have new mail. # md5 /bsd.rd MD5 (/bsd.rd) = 191559b8c5907ca34c144462366b021a # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 244M219M 12.8M94%/ # ping google.com PING google.com (172.217.22.46): 56 data bytes 64 bytes from 172.217.22.46: icmp_seq=0 ttl=56 time=61.595 ms # So the non-booting kernel is indeed the unaltered one from the other i386 OpenBSD 6.0 machine, and these https://marc.info/?l=openbsd-misc=144242763106881=2 hints were taken into account. Is a system like the soekris net4801 not supported any more? Or is there something I can do to install the new version on it? Peer -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 13:27 schrieb Solène Rapenne: > Le 2016-09-28 12:45, Peer Janssen a écrit : >> TFTP pxeboot requests: >> >> 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ >> "pxeboot" >> : 4500 0034 0002 1411 24ea c0a8 0051 E..4..$Q >> 0010: c0a8 002c 0816 0045 0020 f181 0001 7078 ...,...E. px >> 0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a eboot.octet.tsiz >> 0030: 6500 3000e.0. > > The TFTP request from alix asks for a binary transfer > >> As a comparison, the reaction against the RRQ from the linux box: >> >> 12:38:12.807419 kubuntu-neu.fritz.box.36672 > alix.fritz.box.tftp: 19 >> RRQ "pxeboot" (DF) >> : 4500 002f eca9 4000 4011 cc78 c0a8 001f E../..@.@..x >> 0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078 ...,.@.E..u...px >> 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. >> >> > > The TFTP request from your linux box asks for an ascii transfer > > There is a difference between the 2 tftp transfers that may explain > your problem > > Can you try the cli tftp and type "binary" before "get pxeboot" ? > > like the following : > > tftp 192.168.0.44 > tftp> binary > tftp> get pxeboot > Good idea. This works fine. As well as with "localhost". # tftp localhost tftp> binary tftp> get pxeboot Received 81444 bytes in 0.0 seconds tftp> ascii tftp> get pxeboot Received 81965 bytes in 0.1 seconds tftp> # 13:54:47.936070 localhost.23896 > localhost.tftp: [udp sum ok] 16 RRQ "pxeboot" (ttl 64, id 51686, len 44) : 4500 002c c9e6 4011 b2d8 7f00 0001 E..,@... 0010: 7f00 0001 5d58 0045 0018 9309 0001 7078 ]X.E..px 0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet. 13:54:54.649378 localhost.23896 > localhost.tftp: [udp sum ok] 19 RRQ "pxeboot" (ttl 64, id 50915, len 47) : 4500 002f c6e3 4011 b5d8 7f00 0001 E../@... 0010: 7f00 0001 5d58 0045 001b 2b39 0001 7078 ]X.E..+9..px 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. # tftp 192.168.0.44 tftp> binary tftp> get pxeboot Received 81444 bytes in 0.0 seconds tftp> ascii tftp> get pxeboot Received 81965 bytes in 0.1 seconds tftp> # 13:55:11.780098 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok] 16 RRQ "pxeboot" (ttl 64, id 50778, len 44) : 4500 002c c65a 4011 32be c0a8 002c E..,.Z..@.2, 0010: c0a8 002c 810e 0045 0018 ebac 0001 7078 ...,...E..px 0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet. 13:55:18.738183 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok] 19 RRQ "pxeboot" (ttl 64, id 51568, len 47) : 4500 002f c970 4011 2fa5 c0a8 002c E../.p..@./, 0010: c0a8 002c 810e 0045 001b 83dc 0001 7078 ...,...E..px 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. Maybe the additional options which the alix target (at IP .81) sends are what the server does not like.There we had: 12:16:05.039971 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot" : 4500 0034 0006 1411 24e6 c0a8 0051 E..4..$Q 0010: c0a8 002c 081a 0045 0020 f17d 0001 7078 ...,...E. .}..px 0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a eboot.octet.tsiz 0030: 6500 3000e.0. 12:16:15.203886 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot" : 4500 0039 0007 1411 24e0 c0a8 0051 E..9..$Q 0010: c0a8 002c 081b 0045 0025 619c 0001 7078 ...,...E.%a...px 0020: 6562 6f6f 7400 6f63 7465 7400 626c 6b73 eboot.octet.blks 0030: 697a 6500 3134 3536 00 ize.1456. => Could it be that OpenBSD6.0's tftpd refuses to serve a binary tftp RRQ with tsize 0 or blksize 1456? Is there a way to tell the target how to build it's pxeboot request (maybe some dhcpd option which will get sent to it)? Peer -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 11:33 schrieb Peer Janssen: > the request seems to be constructed in different ways. This goes > beyond what tftpd man page says about tftpd's options. Indeed, it > looks like there aren't any tftpd options for this kind of variation > at all, so it seems to me at this time that a pxeboot of such an > alix.2d13 target is currently not possible with OpenBSD 6.0's tftpd. Here is a complete tcpdump of such an unsuccessful pxeboot session from an alix.2d13 to the alix.3x server: # tcpdump -Xi vr0 tcpdump: listening on vr0, link-type EN10MB Getting an IP: 12:15:43.020040 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c secs:4 flags:0x8000 [|bootp] : 4500 0240 1411 a4ae E..@ 0010: 0044 0043 022c d577 0101 0600 .D.C.,.w 0020: ba33 d45c 0004 8000 .3.\ 0030: 000d b933 d45c ...3.\.. 0040: 0050: 0060: .. 12:15:44.031351 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 cd31 0201 0600 .C.D.7.1 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. 12:15:44.031755 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 afc7 0201 0600 .C.D.7.. 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. 12:15:44.055566 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c secs:4 flags:0x8000 [|bootp] : 4500 0240 0001 1411 a4ad E..@ 0010: 0044 0043 022c fc8d 0101 0600 .D.C.,.. 0020: ba33 d45c 0004 8000 .3.\ 0030: 000d b933 d45c ...3.\.. 0040: 0050: 0060: .. 12:15:44.765199 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 acc7 0201 0600 .C.D.7.. 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. 12:15:44.766913 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 ca31 0201 0600 .C.D.7.1 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. ARP request and answer: 12:15:45.063894 arp who-has alix.fritz.box tell 192.168.0.81 : 0001 0800 0604 0001 000d b933 d45c c0a8 ...3.\.. 0010: 0051 c0a8 002c .Q., 0020: .. 12:15:45.063957 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30 : 0001 0800 0604 0002 000d b913 3c30 c0a8 <0.. 0010: 002c 000d b933 d45c c0a8 0051 .,...3.\...Q 0020: .. TFTP pxeboot requests: 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ "pxe
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 11:05 schrieb Peer Janssen: > Am 28.09.2016 um 10:50 schrieb Solène Rapenne: >> Le 2016-09-28 10:21, Peer Janssen a écrit : >>> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly >>> connected to an alix.3x box serving dhcp and tftp. >>> alix.3x (Server): >>> >>> # tftp localhost >>> tftp> get pxeboot >>> Received 81965 bytes in 0.1 seconds >>> tftp> >>> >> Can you try the LAN ip address instead of localhost ? >> Maybe it's a firewall issue or tftp not listening on the lan interface > Works fine: > $ # on a linux box: > $ # after switching the cable an vr0 of alix server from alix target to > network switch where linux box is connected: > > $ tftp 192.168.0.44 > tftp> get pxeboot > Received 81965 bytes in 1.3 seconds > tftp> Looking at the tcpdump, I noticed this: unsuccessful tftp requests from alix target: 09:44:54.290322 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot" 09:45:04.454216 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot" successful tftp request from linux system: 10:54:07.685813 arp who-has alix.fritz.box tell 10:54:07.685910 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30 10:54:07.686004 .55726 > alix.fritz.box.tftp: 19 RRQ "pxeboot" (DF) 10:54:07.698624 .55726 > alix.fritz.box.24979: udp 4 (DF) 10:54:07.705934 .55726 > alix.fritz.box.24979: udp 4 (DF) [...] So the request seems to be constructed in different ways. This goes beyond what tftpd man page says about tftpd's options. Indeed, it looks like there aren't any tftpd options for this kind of variation at all, so it seems to me at this time that a pxeboot of such an alix.2d13 target is currently not possible with OpenBSD 6.0's tftpd. Unless I missed something somewhere, of course. Peer -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 10:50 schrieb Solène Rapenne: > Le 2016-09-28 10:21, Peer Janssen a écrit : >> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly >> connected to an alix.3x box serving dhcp and tftp. >> alix.3x (Server): >> >> # tftp localhost >> tftp> get pxeboot >> Received 81965 bytes in 0.1 seconds >> tftp> >> > > Can you try the LAN ip address instead of localhost ? > Maybe it's a firewall issue or tftp not listening on the lan interface Works fine: # ifconfig urtwn0 | grep inet inet 192.168.0.45 netmask 0xff00 broadcast 192.168.0.255 # ifconfig vr0 | grep inet inet 192.168.0.44 netmask 0xff00 broadcast 192.168.0.255 $ # on a linux box: $ # via wifi ssh link to the alix server: $ tftp alix.fritz.box tftp> status Connected to alix.fritz.box. Mode: netascii Verbose: off Tracing: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds tftp> get pxeboot Received 81965 bytes in 1.9 seconds tftp> $ md5sum pxeboot 6d0075598b6672a06dda44498ab7d663 pxeboot $ # after switching the cable an vr0 of alix server from alix target to network switch where linux box is connected: $ tftp 192.168.0.44 tftp> get pxeboot Received 81965 bytes in 1.3 seconds tftp> $ md5sum pxeboot #the second file which has overwritten the one from the first try 6d0075598b6672a06dda44498ab7d663 pxeboot # # back on alix server: # md5 /tftpboot/pxeboot MD5 (/tftpboot/pxeboot) = 6d0075598b6672a06dda44498ab7d663 # md5 /usr/mdec/pxeboot MD5 (/usr/mdec/pxeboot) = 6d0075598b6672a06dda44498ab7d663 So everything is in order regarding these connection / firewall / binding to interface aspects. There is no firewall between the alix.3x server and the alix.2d13 target, it's just one cable. -- Peer Janssen - p...@pjk.de
tfdpd doesn't deliver pxeboot file
S 15538/16/63 Log C/H/S 974/255/63 LBA Intel UNDI, PXE-2.0 (build 082) Copyright (C) 1997,1998,1999 Intel Corporation VIA Rhine III Management Adapter v2.43 (2005/12/15) CLIENT MAC ADDR: 00 0D B9 33 D4 5C CLIENT IP: 192.168.0.81 MASK: 255.255.255.0 DHCP IP: 192.168.0.44 GATEWAY IP: 192.168.0.44 PXE-E32: TFTP open timeout PXE-E32: TFTP open timeout PXE-E32: TFTP open timeout PXE-M0F: Exiting Intel PXE ROM. => So the target: - has newest BIOS - gets a lease - get's the necessary arp replies - asks the tftpd for the file - it's there - tftp works - but the file pxeboot is not delivered. No I don't know what to do next. I tried to experiment with putting "/pxeboot" in the dhcpd.conf options instead of "pxeboot" (the docs are not clear which one is necessary for a file in tftpboot chroot dir), but this kind of change only got me to this kind of strange tftpd console logs: tftpd: 192.168.0.81: read request for '/pxeboo' and later even, although the name in dhcpd.conf was indeed "pxeboot": tftpd: 192.168.0.81: read request for 'pxeboo' which strangly persisted some while even across killing and restarting of dhcpd and powercycling the target. Which might be a hint to some tftpd uninitialized buffer problem (or so). Peer -- Peer Janssen - p...@pjk.de
Re: serial input line not working
Am 22.09.2016 um 04:00 schrieb Theo de Raadt:
>> Am 22.09.2016 um 00:23 schrieb Theo de Raadt:
>>>> But on that alix box, nothing seems to arrive at the serial line. I
>>>> tried all of these (the were in 0 t o5):
>>>>
>>>> # cu -d -l ttyC -s
>>>> 9600
>>>>
>>>> Connected to /dev/ttyC (speed 9600)
>>> Well, because that is one of the virtual console / screen
>>> device. You want to use tty00.
>> Thank you. Now I get this error:
>>
>> # cu -d -l tty00 -s 9600
>> cu: open("/dev/tty00"): Device not configured
>
> Use cua00
>
> Look -- did you read the manual page?
>
>
> -l line
>Specify the line to use. Either of the forms like cua00 or
>/dev/cua00 are permitted. The default is /dev/cua00. See
cua(4)
>for information on terminal devices. Users in group ``dialer''
are
>permitted to use cua(4) devices by default.
>
>
> Did you then read follow the breadcrumps to read cua(4)
>
> ?
>
>> I didn't find how to configure this/a device. Tried /etc/remote,
>> /etc/ttys, many man pages, Absolute OpenBSD, read about line disciplines
>> (but didn't find hot to configure them), etc. Also, from 5.8 on tip is
>> not there any more, guess it was merged with cu or so. Or are there
>> (more) framework change with doc lagging behind?
>> Anyway -- any hints?
>>
>> If I understood ttys correctly, I can attach my serial logger software
>> (instead of getty) directly to tty00 (once I know how to configure it),
>> so that when the box boots, it automatically starts logging, and if the
>> process disappears, it restarts it. Right?
> It seems you did all that, but didn't read the manual pages.
Oh yes, I did. That's what I started with (but didn't tell so in my
first mail).
Then you sent me on the tty00 way and I tried to figure that out (and
learned certain things, like that tty and cua are kind of pairs for
rx/tx, but didn't get into the detailed details how it's attached where
internally, etc.), but to no avail.
> In fact, what you want is entirely the defaults:
>
># cu
Sure, it look's like a very standard thing to do, but:
# cu -d -l cua00 -s 9600
cu: open("/dev/cua00"): Device not configured
# cu
cu: open("/dev/cua00"): Device not configured
So I wonder if the device is recognized at all by the kernel when it
starts. Doesn't look like so, unless it's implied with certain devices.
(The dmesg is in my first post.)
Extract of my /etc/ttys (changed it a bit to try out tty00 without getty
getting in the way):
# name getty typestatus comments
#
console "/usr/libexec/getty std.9600" vt220 off secure
ttyC0 "/usr/libexec/getty std.9600" vt220 on secure
ttyC1 "/usr/libexec/getty std.9600" vt220 on secure
ttyC2 "/usr/libexec/getty std.9600" vt220 on secure
ttyC3 "/usr/libexec/getty std.9600" vt220 on secure
ttyC4 "/usr/libexec/getty std.9600" vt220 off secure
ttyC5 "/usr/libexec/getty std.9600" vt220 on secure
ttyC6 "/usr/libexec/getty std.9600" vt220 off secure
ttyC7 "/usr/libexec/getty std.9600" vt220 off secure
ttyC8 "/usr/libexec/getty std.9600" vt220 off secure
ttyC9 "/usr/libexec/getty std.9600" vt220 off secure
ttyCa "/usr/libexec/getty std.9600" vt220 off secure
ttyCb "/usr/libexec/getty std.9600" vt220 off secure
#tty00 "/usr/libexec/getty std.9600" unknown off
tty00 noneunknown off
tty01 "/usr/libexec/getty std.9600" unknown off
tty02 "/usr/libexec/getty std.9600" unknown off
tty03 "/usr/libexec/getty std.9600" unknown off
tty04 "/usr/libexec/getty std.9600" unknown off
I also tried console:
# cu -d -l console -s 9600
Connected to /dev/console (speed 9600)
Seems configured at least -- but no data arrives. So still something is
missing.
Maybe some BIOS quirk, who knows.
Maybe someone on this list had a similar problem?
This is a very fresh install, I didn't update but reinstall completely.
Peer
--
Peer Janssen - p...@pjk.de
Re: serial input line not working
Am 22.09.2016 um 00:23 schrieb Theo de Raadt:
>> But on that alix box, nothing seems to arrive at the serial line. I
>> tried all of these (the were in 0 t o5):
>>
>> # cu -d -l ttyC -s
>> 9600
>>
>> Connected to /dev/ttyC (speed 9600)
> Well, because that is one of the virtual console / screen
> device. You want to use tty00.
Thank you. Now I get this error:
# cu -d -l tty00 -s 9600
cu: open("/dev/tty00"): Device not configured
I didn't find how to configure this/a device. Tried /etc/remote,
/etc/ttys, many man pages, Absolute OpenBSD, read about line disciplines
(but didn't find hot to configure them), etc. Also, from 5.8 on tip is
not there any more, guess it was merged with cu or so. Or are there
(more) framework change with doc lagging behind?
Anyway -- any hints?
If I understood ttys correctly, I can attach my serial logger software
(instead of getty) directly to tty00 (once I know how to configure it),
so that when the box boots, it automatically starts logging, and if the
process disappears, it restarts it. Right?
Peer
--
Peer Janssen - p...@pjk.de
serial input line not working
I updated an alix.3c3 box from OpenBSD 4.6 release to 6.0 release
recently via bsd.rd install kernel.
This went very smoothly, except that now I can't get a serial stream via
the DB9 serial connector.
On a linux box, I do indeed receive the (geiger data) lines like these
at a speed of 9600 baud:
#513302 Timestamp: 733348928Delta_Timestamp: 6 Total_Impulses:
39769137Delta_Impulses: 90
so up to the connector at the end of the cable arriving from geiger
interface the data is coming, and in can be read and stored, etc.
But on that alix box, nothing seems to arrive at the serial line. I
tried all of these (the were in 0 t o5):
# cu -d -l ttyC -s
9600
Connected to /dev/ttyC (speed 9600)
Result: no data at all arrives. I don't see what went wrong.
Peer
# dmesg
OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 259207168 (247MB)
avail mem = 241590272 (230MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/15/07, BIOS32 rev. 0 @ 0xfaf90
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/144 (7 entries)
pcibios0: bad IRQ table checksum
pcibios0: PCI BIOS has 7 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 5 10 11
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 0xc8000/0xa800 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:0d:b9:13:3c:30
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
maxtmp0 at iic0 addr 0x4c: lm86
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11,
CS5536 AC97
ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
audio0 at auglx0
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbdprobe: reset response 0xfa
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (0e0478eff5b1b08d.a) swap on wd0b dump on wd0b
--
Peer Janssen - p...@pjk.de
Trust chain: Trying to check certificates
(1) The pkg_add man page sais that digitally signed packages are checked against authorities in /etc/ssl/pkgca.pem. I didn't find this pkgca.pem at said place, although pkg_add is indeed installed. I suppose checking of digitally signed packages will not be possible without these certificates. So where will that pkgca.pem come from? And how is it constituted? mozilla has a CA policy, but I doubt it really works, since rogue CAs already did bad things (to people) via mozilla's CAs. How are things done in OpenBSD? (2) What I found in /etc/ssl was a cert.pem which apparently contained CAs. Some question: Where did it come from? How was it constituted by the OpenBSD team? Is there some kind of CA policy? (3) Displaying that certificate file with openssl x509 -noout -in cert.pem -text [or -issuer or -subject] yielded data of ONE certificate. However, with less cert.pem it's quickly obvious that the file contains lots of certificates from different CAs. This seems quite strange to me. Not even a warning, nothing which tells that the file contains many certificates. There does not seem to be an option to list all the certificates in such a cert.pem file. Of course I can grep the somewhat cluttered fields. But shouldn't it be easy to list the CAs contained in such file? In fact, that cert.pem is a keyring. Which commands exist to examine such a keyring? Generally speaking (not especially on OpenBSD!), I find it difficult to check certificates. I did this exercise on a linux box and found hundrets of certificates in different places. The tools seem to be more or less useful to create certificates from data, but not at all for easily getting an overview of where all the trust they represent goes. It's useful to build a hierarchical system, but not to clearly show it, and how it works, to the user. This seems bad to me. Peer
SHA file missing on CD1 of OpenBSD 5.5
Hi, I'm writing this - in order to provide some feedback about my user experience (before it even started, that is), - because others might find a modicum of help here if they happen to stumble on the same issue, - in order to suggest a check for completeness for building the CD sets, - and maybe someone might want to supply a bit of data I'm still missing, e.g. a CD hash to cross-check. So, I'm trying to establish a clean and uninterrupted trail of trust (integrity-wise) from Alice the OpenBSD devs to the OpenBSD 5.5 CD set I recently bought in a bookshop in a big german city. This proves surprisingly difficult. I tried to check the CDs in person with one of the devs in that city, but he was not available at that moment (that would have been best solution, a second channel besides all this web machinery), so I tried other venues. The OpenBSD 5.5 web page provides a build key (no idea what kind of format it's in) and the web site strongly recommends checking the CD beforehand (just what I'm trying to do) using the signify tool, but since I have to somehow bootstap OpenBSD, I didn't have that tool nor any other means of verification, e.g. a md5sum, sha256sum or so of the CD is not provided on the website (that would have helped the bootstrapping process). (With hindsight, I could have manually scripted some SHA check for the OpenBSD hash file format.) I found a gpg signed tarball http://www.fefe.de/signify/ from a porter who is publicly known, rather well integrated in the web of trust GPG style via public keyservers (a similar chain of keysigning-trust could not be established from Theo to said dev, for instance because their keys are relatively unsigned in comparison) and/but who does not exactly seem to like OpenBSD, a tarball to build signify on linux (so he helps the project anyway), which I got to work after resolving a compiling issue. -lcrypto was missing: /usr/bin/ld: cannot find -lcrypto collect2: error: ld returned 1 exit status make: *** [signify] Fehler 1 but after some research an: $ sudo apt-get install libssl-dev the somewhat incompletely ported signify compiled and I was ready to verify files on the CDs. Most of the files I verified were reassuringly OK, but there was one issue: One file named SHA verified FAILED because the file listed and hashed in the SHA256.sig of the checked directory is missing on the CD. So now there is some rest of a doubt if the CD is legit or not or if this is a just a minor production error. Maybe this is the best I can hope for for the moment, because the public signing infrastructure in OpenBSD is not yet fully established, and I can live with that. If anybody else wants to verify CD1 of the OpenBSD 5.5 CD set against mine, here are the hashs I got from that CD: $ time dd if=/dev/sr0 | sha256sum 1071464+0 Datensätze ein 1071464+0 Datensätze aus 548589568 Bytes (549 MB) kopiert, 484,533 s, 1,1 MB/s 338c0f72bc55bcf6462c3bf09df88a5c5c0fb4479d12383002b72bd077e90e15 - real8m4.546s user0m17.800s sys 0m8.580s $ time dd if=/dev/sr0 | md5sum 1071464+0 Datensätze ein 1071464+0 Datensätze aus faa38e4af64facbb22b372275d042f7a - 548589568 Bytes (549 MB) kopiert, 486,959 s, 1,1 MB/s real8m7.095s user0m6.308s sys 0m11.460s Of course, I'd appreciate if anybody from the team could verify these, because the chain of trust from the OpenBSD devs to my CD1 is still not exactly established with strictness. I just checked the i386 part of CD1 with signify so far, the minimum in order to install. So now I'm somewhat excited to install and dive more into that distro and discover more of it. Thanks for working so hard! I took a look at the libReSSL comments ... hilarious ! Peer
Re: where to order now ?
Is there another way to buy those cool wireframe-puffy stickers, than from kd85? I need something to cover my 'new' laptop. :-( This is something I am curious about as well, new laptops look bare without Puffy on the lid I guess Wim would be more than happy to sell his stock of stickers and T-Shirts, and especially those who believe in his sincerity, and others who might be interested in selling these items, might want to extend a hand, buying off his products, to help him rebuild lost trust, depending of course on how he will spend future proceeds of his OpenBSD related sales. As far as I am concerned, he did indeed in a certain session help me getting into and getting startet with the system and some technical details of it, so I cannot affirm that he didn't do anything to promote OpenBSD. Promotion is not only developing, but also, well, promotion; there are complete businesses around that concept to help projects grow, so I don't see why his stickers and T-shirts would have been completely useless to the project (which cannot be reduced to the financial side). They create questions and discussions, so they spread awareness about the project's existence. What anybody does do constructively should not be depreciated. Of course, generally speaking, engagements (contractual or otherwise) should always be honored, otherwise society and economy just cannot function. I don't know the details of agreements and what happened behind the scenes of the new-user-view I captured, but I know that anybody might (whithout bad intend, that is) miscalculate public interest in a product, be inexperienced in appreciating the need of accountability, have different views of how the better world he wants to create should look like, the necessary degree of formalisation of procedures, err in the appreciation of the degree of project-relatedness of his actions, the optimal management of his personal time, etc., add to that events and desired direction of your personal life, family, The Crisis(tm), etc., and many undesirable things can happen to anybody. Of course, I understand Theos side, he gave a lot of infos in these threads, while Wim seems to be absorbed by something at the moment. Interestingly, securing a system needs unflagging acute awareness of what comes in and what of it you want to keep or reject (it's a bit what our belly does when we eat, and what our mind should always do when we learn anything; so that poisons can't slip in). This attitude shows in how he manages this situation (and his life indeed), so we see extremely clear expressions of his views and how he wants to proceed. Some more emotion-oriented people find this rude, but if they stick to the facts, I'm sure they will calm down a lot. (Of course, personal flaws could likewise express themselves in a project.) It also should not be forgotten that there could be attack vectors to the project as a whole, one aspect of which is public perception of trust, honesty and reliability, and he obviously cares about that. The complete picture doesn't seem to be known publicly (and doesn't necessarily need to be) and not even individually to anybody, so nobody should'n rush to conclusions and add unnecessary hardships to any side. I noticed worrying signs that the situation could go out of hand in a way that some might really regret later what they said and caused to each other. As long as there is no complete and also personal reconciliation -- by dialogue and necessary action taken --, this is not solved. (It might take some time and doesn't need to be public.) On a more general note, I'd like to say that even if any of my brothers (e.g. every human being) at times fails -- and this happens to everybody -- , small or big-time, he will always be my brother. Everybody has to do his own part, his own self-improvement, and we also need to support each other, whatever happens. We are just one humanity. Some allow themselves to look down to others, but this is never justified; they can never know for sure that they wouldn't have done worse if they had been in the other one's life and situation. Take care Peer
Missing security announcements
Hi! I subscribed to security-announce a long time ago and thought I would receive information about security annoucements, but contrary to what is stated on http://openbsd.org/mail.html: security-announce - Security announcements. This low volume list receives OpenBSD security advisories and pointers to security patches as they become available., as is easily verifyable here: http://www.sigmasoft.com/~openbsd/archives/html/openbsd-security-announce/ together with: http://openbsd.org/errata44.html, the patches are not announced. If the stated annoucement process via mailing list is unreliable or untimely, I'd think it's useless, and with it that mailing list. Regards Peer
