Re: IKED and encapsulated peers
On Mon, Oct 05, 2015 at 07:52:28PM BST, Jason Tubnor wrote: > On 5 October 2015 at 22:00, Jason Tubnor wrote: > > > > > Solved! > > > > > > I have attached a man 5 iked.conf patch that clears up an example used in > > the man page. > > > > The gz diff was stripped by demime, here is the flat text patch file. > > Cheers, > > Jason. > > [demime 1.01d removed an attachment of type application/octet-stream which > had a name of iked.conf.5.patch] > Jason, The only OpenBSD mailing list which permits attachments is ports@[0]. On all the other ones demime strips *any* kind of attachments from emails sent there. It is customary to include patches or config files in-line. Regards, Raf [0] http://www.openbsd.org/mail.html
Re: requesting help working around boot failures with supermicro atom board
On Mon, Oct 05, 2015 at 01:18:53PM -0400, dewey.hyl...@gmail.com wrote: > unfortunately, not on my end. i have hopes that mike larkin may find something > when he gets a chance to look, but i am past the limit of my capabilities and > supermicro support has discontinued responding to me. their last suggestion > was > to switch to linux or windows, and their last message was of the "we'll get > back to you" variety. > I had thought this was acpi related earlier (before we realized that disabling lm* fixes it). So I have no news here, as I don't think the solution is going to be found in the AML. The lm(4) sensor is probably getting wedged somehow, which is causing the bios to think the machine is too hot on reboot. Even though it's not. I don't know a lot about the lm(4) driver so I don't think I'll be able to help much here. One of the things I do know about it is that sometimes you don't actually even have a real lm(4), and that it's simulated by some other component or even SMM. Maybe the manufacturer did a poor job. Shrug. Sorry, I'm out of ideas. Maybe someone else can debug it for you. -ml > so on a related note, i'm on the hunt for something which can replace this > board's functionality without breaking the bank. something not supported by > supermicro, as this is a brand new board and they seem to be unwilling to > provide support anyway. remote kvm/power is the sole purpose for choosing this > supermicro device in the first place. i have plenty much more expensive and > more powerful supermicro devices at customer sites which do not show this > issue - but their non-support of this brand-new motherboard shows me that they > are not who i want to be relying on. > > - On Oct 5, 2015, at 12:08 PM, Sonic sonicsm...@gmail.com wrote: > > Any progress on this issue? > > On Thu, Sep 17, 2015 at 1:26 PM, Mike Larkin wrote: > > On Thu, Sep 17, 2015 at 12:40:12PM +, Dewey Hylton wrote: > >> Dewey Hylton gmail.com> writes: > >> > >> > > >> > Mike Larkin azathoth.net> writes: > >> > > >> > > > >> > > On Tue, Sep 15, 2015 at 07:16:40PM +, Dewey Hylton wrote: > >> > > > Dewey Hylton gmail.com> writes: > >> > > > > >> > > > > > >> > > > > Mike Larkin azathoth.net> writes: > >> > > > > >> > > > > > acpidump please. > >> > >> > motherboard: supermicro x7spe-hf-d525 rev 1.0 > >> > bios: 1.2b > >> > > >> > at the end of this link is an archive containing acpidump output for all > >> > three acpi settings in the bios (1.0, 2.0, 3.0). > >> > > >> > https://goo.gl/tWGL6C > >> > > >> > i apologize for the somewhat hidden link; gmane wouldn't allow me to post > >> > the full link because it's greater than 80 characters. > >> > > >> > please let me know if i can help in any way; i honestly know nothing > >> > about > >> > acpi but am willing to learn or assist otherwise if it means > >> > understanding > >> > and potentially fixing this issue. > >> > >> i was able to export the DSDT files into something human-readable. while i > >> don't really understand much of what i'm seeing in the resulting text > >> files, > >> diff shows that the differences between the three acpi versions are > >> nonexistent. i have no idea about the other files, of which there are > >> several. > >> > >> Mike, does the acpidump output help at all? if not, am i simply at the > >> point > >> where this hardware is not compatible with OpenBSD? > >> > > > > Haven't had a chance to look at it yet. > > > > -ml
Re: requesting help working around boot failures with supermicro atom board
On Tue, Sep 15, 2015 at 02:45:02AM +, Dewey Hylton wrote: > Mark Kettenis xs4all.nl> writes: > > > > > > # sysctl -a|grep 'sensors.*temp' > > > hw.sensors.cpu0.temp0=30.00 degC > > > hw.sensors.lm1.temp0=0.00 degC > > > hw.sensors.lm1.temp1=14.00 degC > > > hw.sensors.lm1.temp2=14.00 degC > > > # reboot > > > > > > BEEEP! > > > > Oh that is interesting. Can you try disabling the lm(4) driver in > > your kernel? You can do: > > > > # config -ef /bsd > > ... > > ukc> disable lm > > 254 lm0 disabled > > 255 lm* disabled > > 256 lm* disabled > > ukc> quit > > Saving modified kernel. > > # reboot > > > > That reboot will probably still hang. But it'd be interesting to see > > if any subsequent reboots work better. > > *this* interests me, and was basically what i was asking in the original > post - except i had no idea what might need to be disabled. one step at a > time, it's been interesting the things that have popped up. > > still no idea whether this has anything to do with the seemingly > openbsd-only issue, but ... > > i made this change, booted the new kernel, ran 'cksum /dev/mem' a bunch of > times in hopes of raising the temperature somewhat (did get to 36C, which is > higher than in my previous tests). then i rebooted, and the box came back up > without incident. > > so i'm going to run through this several times with reboots in every 20 > minutes or so and see if it survives the night. > Based on this and my previous email, my recommendation would be to disable lm(4) on this particular machine.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
On 2015-10-06, Theo de Raadt wrote: >> Wait, sorry - so the disklabel tool says that the c partition starts at >> offset 0 , that's logical indeed as data always starts at offset 0. >> >> By some reason, the disklabel tool however doesn't want partitions on the >> first 64 sectors (console dump below), i.e. on the first 32KB (why?). > > Modern disks are showing up with sector sizes > 512 bytes. This is an > alignment strategy, to future proof things. Flash memory in particular has large erase blocks (it's not possible to erase less than this amount in one go, so to modify data on the device involves read+erase+write of often as much as 256-512K. The larger alignment increases the chance of filesystem blocks aligning with these (if a filesystem block spans over two erase blocks, that's a lot of extra data to erase+rewrite when you might only be making a very small change). Some OS are going further than 64x 512-byte sectors in their default partition alignment - 2048 (1MB) seems pretty common now. This isn't likely to be noticeable on decent SSDs which have a lot more software in the way of access to the flash media, it's more likely to be seen on the relatively simple media like cheap CF/SD cards/USB sticks. https://en.wikipedia.org/wiki/Flash_memory http://electronics.stackexchange.com/questions/125228/why-does-nand-erase-only-at-block-level-and-not-page-level
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
>On Tue, Oct 6, 2015 at 2:48 PM, Benny Lofgren wrote: >> It is well known and understood since decades what's on these first >> sectors of a) a disk, b) of the BSD usable area and c) of each partition >> (type). I don't think (c) is something commonly known.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
On Tue, Oct 6, 2015 at 2:48 PM, Benny Lofgren wrote: > It is well known and understood since decades what's on these first > sectors of a) a disk, b) of the BSD usable area and c) of each partition > (type). Why are you having trouble accepting that things are the way > they are and that they WORK as they are, if you don't turn everything on > its head? Well, at least they work until you start messing with things > you have not yet had any experience with. The upside is you'll quickly > gain useful experience, of how not to do. :-) I am not seeing any trouble accepting that things are the way they are, but am instead seeing an interest in understanding the way things are. And, I'm learning from the relevant details posted here. Are you really seeing something different from me? Thanks, -- Raul
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
There were also some excellent diagrams generated the last time this came up for discussion: https://marc.info/?l=openbsd-misc&m=141520160709490&w=2 FWIW. Brian
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
On 2015-10-06 19:25, Mikael wrote: > So then I'll just learn that sector 80 and up are "safe" for "user data", > and it's up to all users to take care that any non-UFS/swap/RAID partitions > never go below 80. I don't think you can expect swap partitions to honour those first sectors... generally, it i expected that the first partition (by convention 'a' but as you found out yourself not by enforcement) should contain either an ffs(/ffs2) file system or a RAID partition (which in turn contains a label and partitions of its own). Why would you need to reserve space manually? Are you expecting to run something that stores data on raw partitions? I thought that practice more or less died out in the nineties... That said, there are certainly use cases to point BSD partitions in non-standard places, for example if you want to be able to access file systems from another MBR partition that belongs to another bootable system. But that doesn't interfere with the BSD usable area, let alone its precious first sectors. > But how does the behavior of the first added partition by default > overlapping the disklabel "save butts" - > Does this behavior fill any practical function today, and also when the > user (me) makes there be no overlap, could/do I break anything? If you place a 4.2BSD or a RAID partition from the first sector (64) of the BSD usable part of the disk (as limited by the "boundstart" and "boundend" disklabel parameters) you will never get in trouble. Anything else and you need to know more about the system internals to be safe. You ask about saved butts. Just a couple of example scenarios: Consider the option to encasing the partition metadata in the first partition (and again, first physical address-wise, not first partition letter-wise), which is to leave a gap in the beginning: First of all, I'm not even sure the boot code is able to cope with that scenario, but let's say it is. Whenever you want to add a new partition, disklabel will suggest you populate the first free area on your disk - guess where that is going to be... If you wreck your disklabel and have done something non-standard, such as move the first partition from its expected position, you're pretty much in the dark when it comes to actually *find*, not to mention hopefully recover, your partitions. It is well known and understood since decades what's on these first sectors of a) a disk, b) of the BSD usable area and c) of each partition (type). Why are you having trouble accepting that things are the way they are and that they WORK as they are, if you don't turn everything on its head? Well, at least they work until you start messing with things you have not yet had any experience with. The upside is you'll quickly gain useful experience, of how not to do. :-) Regards, /Benny
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
2015-10-07 1:44 GMT+08:00 Mikael : > > Ah sure. > > Perhaps I misunderstood the level of "foolproofness" that the disklabel > tool's autogenerated default value was intended to give - > > Just curious, now that structural things like this are at stake (i.e. some > user making a seemingly reasonable presumption based on the "UI" should > give you partitions where you can really have completely > user-defined/custom stuff based on an expectation that the autogenerated > values guarantee non-overlapping with other partitions or the disk > partition structure itself i.e. the disklabel), what's the motivation for > not increasing the disklabel tool's minimum autogenerated offset value from > 64 to 80? > > The tradeoff would be that the world would lose 8KB per disk, and win the > absence of needing to debug a complete disk crash, that I just underwent. > In all cases, as long as *not* having any partition covering any of the 16 sectors #64 to #79 won't break anything, I feel this is clear & thanks for clarifying!
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
2015-10-07 1:38 GMT+08:00 Ted Unangst : > Mikael wrote: > > 2015-10-07 0:58 GMT+08:00 Ted Unangst : > > > > > > the disklabel is the second sector of the openbsd part of the disk. > > > > > > *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] > OpenBSD > > > > > > so, if you overwrite sector 65, you will overwrite disklabel. normally > the > > > 'a' > > > partition overlaps the disklabel, but you made 'e' first. > > > > > > > Ugh, ok - just to settle this one forever I hope, four brief Q:s: > > > > 1) Does this mean that on an ordinary disk (where the "a" partition is > the > > disk's first partition, and starts at the offset autogenerated as default > > option by the "disklabel" tool), the start of the "a" partition" actually > > overlaps with disklabel-internal data? > > Yes. So, the metadata on a x86 disk will look like: > > |start -- end| > |MBR . somestuff | OpenBSD partition | > | .. | disklabel | > | .. | FFS 'a' | swap 'b' --- | FFS 'd' | > > FFS knows it should not use the first few sectors of a partiton, because > other > things may live there. > > This may not be obvious to start, but if you think about it, these data > structures have to live *somewhere*. If you cannot see reserved space > between > areas of disk, then the reserved space must be somewhere inside those > areas. > Ah sure. Perhaps I misunderstood the level of "foolproofness" that the disklabel tool's autogenerated default value was intended to give - Just curious, now that structural things like this are at stake (i.e. some user making a seemingly reasonable presumption based on the "UI" should give you partitions where you can really have completely user-defined/custom stuff based on an expectation that the autogenerated values guarantee non-overlapping with other partitions or the disk partition structure itself i.e. the disklabel), what's the motivation for not increasing the disklabel tool's minimum autogenerated offset value from 64 to 80? The tradeoff would be that the world would lose 8KB per disk, and win the absence of needing to debug a complete disk crash, that I just underwent.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
Mikael wrote: > 2015-10-07 0:58 GMT+08:00 Ted Unangst : > > > > the disklabel is the second sector of the openbsd part of the disk. > > > > *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] OpenBSD > > > > so, if you overwrite sector 65, you will overwrite disklabel. normally the > > 'a' > > partition overlaps the disklabel, but you made 'e' first. > > > > Ugh, ok - just to settle this one forever I hope, four brief Q:s: > > 1) Does this mean that on an ordinary disk (where the "a" partition is the > disk's first partition, and starts at the offset autogenerated as default > option by the "disklabel" tool), the start of the "a" partition" actually > overlaps with disklabel-internal data? Yes. So, the metadata on a x86 disk will look like: |start -- end| |MBR . somestuff | OpenBSD partition | | .. | disklabel | | .. | FFS 'a' | swap 'b' --- | FFS 'd' | FFS knows it should not use the first few sectors of a partiton, because other things may live there. This may not be obvious to start, but if you think about it, these data structures have to live *somewhere*. If you cannot see reserved space between areas of disk, then the reserved space must be somewhere inside those areas.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
Aha got it. So then I'll just learn that sector 80 and up are "safe" for "user data", and it's up to all users to take care that any non-UFS/swap/RAID partitions never go below 80. But how does the behavior of the first added partition by default overlapping the disklabel "save butts" - Does this behavior fill any practical function today, and also when the user (me) makes there be no overlap, could/do I break anything? Just to really understand the practical impact. 2015-10-07 1:21 GMT+08:00 Theo de Raadt : > > Wait, sorry - so the disklabel tool says that the c partition starts at > > offset 0 , that's logical indeed as data always starts at offset 0. > > > > By some reason, the disklabel tool however doesn't want partitions on the > > first 64 sectors (console dump below), i.e. on the first 32KB (why?). > > Modern disks are showing up with sector sizes > 512 bytes. This is an > alignment strategy, to future proof things.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
2015-10-07 1:14 GMT+08:00 Theo de Raadt : > > > But your fingers don't know it. > > > > > > > > Right, time for fingers to learn. > > > > Will look forward to learn how it "saved many a butt" and what's the > lowest > > "safe" offset (..64 + 8*2 = 81+?..) (if that will actually make sense > when > > understanding the whole thing) through the Q:s in my last post? > > 8K is the smart offset. > Wait, sorry - so the disklabel tool says that the c partition starts at offset 0 , that's logical indeed as data always starts at offset 0. By some reason, the disklabel tool however doesn't want partitions on the first 64 sectors (console dump below), i.e. on the first 32KB (why?). The 8KB you talk about now, is that *in addition* to the first 32KB then, so >40KB i.e all sectors starting with and above 80 are safe? And, does it break anything or otherwise require administrative consideration, that there is no partition covering those 8KB of disklabel data (i.e. "installboot" won't misbehave or alike)? # disklabel -E wd0 Label editor (enter '?' for help at any prompt) > p OpenBSD area: 64-3907024065; size: 3907024001; free: 3907024001 #size offset fstype [fsize bsize cpg] c: 39070291680 unused > a partition: [a] offset: [*64*]
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
> Wait, sorry - so the disklabel tool says that the c partition starts at > offset 0 , that's logical indeed as data always starts at offset 0. > > By some reason, the disklabel tool however doesn't want partitions on the > first 64 sectors (console dump below), i.e. on the first 32KB (why?). Modern disks are showing up with sector sizes > 512 bytes. This is an alignment strategy, to future proof things.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
2015-10-07 1:07 GMT+08:00 Theo de Raadt : > > > Have I (and some others) misunderstood anything about how BSD > disklabelling > > > works? > > > > the disklabel is the second sector of the openbsd part of the disk. > > > > *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] > OpenBSD > > > > so, if you overwrite sector 65, you will overwrite disklabel. normally > the 'a' > > partition overlaps the disklabel, but you made 'e' first. > > The ffs and swap code knows not to touch the first 8K of the disk, for > historic reasons, and this has saved many a butt. I suspect softraid > also does this. > > But your fingers don't know it. > > Right, time for fingers to learn. Will look forward to learn how it "saved many a butt" and what's the lowest "safe" offset (..64 + 8*2 = 81+?..) (if that will actually make sense when understanding the whole thing) through the Q:s in my last post? Very interesting; thanks!
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
> > But your fingers don't know it. > > > > > Right, time for fingers to learn. > > Will look forward to learn how it "saved many a butt" and what's the lowest > "safe" offset (..64 + 8*2 = 81+?..) (if that will actually make sense when > understanding the whole thing) through the Q:s in my last post? 8K is the smart offset.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
2015-10-07 0:58 GMT+08:00 Ted Unangst :
>
> the disklabel is the second sector of the openbsd part of the disk.
>
> *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] OpenBSD
>
> so, if you overwrite sector 65, you will overwrite disklabel. normally the
> 'a'
> partition overlaps the disklabel, but you made 'e' first.
>
Ugh, ok - just to settle this one forever I hope, four brief Q:s:
1) Does this mean that on an ordinary disk (where the "a" partition is the
disk's first partition, and starts at the offset autogenerated as default
option by the "disklabel" tool), the start of the "a" partition" actually
overlaps with disklabel-internal data?
What's the proper approach here - I thought partitions' contents were
expected to be completely separate from disklabel-internal data and was
completely unaware that the "disklabel" tool's default behavior is to
autogenerate offsets (and sizes?) that overlap those.
2) Does this mean that for my partitions never to overlap the disklabel, I
must ensure that they never start at a sector or byte offset lower than a
given one, if so which one?
(Disklabels are constant-size so this is a constant that can be
learned?)
3) Is this some how a feature ("and not a bug") so that some frequently
used tools actually rely on this overlapping between disklabel sectors and
partition-a-sectors, for instance "installboot"?
4) If this is documented anywhere feel free to mention.
Also sorry for the fuss but me and some others found it surprising.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
> > Have I (and some others) misunderstood anything about how BSD disklabelling > > works? > > the disklabel is the second sector of the openbsd part of the disk. > > *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] OpenBSD > > so, if you overwrite sector 65, you will overwrite disklabel. normally the 'a' > partition overlaps the disklabel, but you made 'e' first. The ffs and swap code knows not to touch the first 8K of the disk, for historic reasons, and this has saved many a butt. I suspect softraid also does this. But your fingers don't know it.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
Mikael wrote: > 2015-10-07 0:45 GMT+08:00 Ted Unangst : > > > Mikael wrote: > > > The script below includes extra considerations to see through any kernel > > > caching of the disklabel, by rebooting between every relevant step. > > > > > > "dd if=/dev/srandom of=/dev/rwd0e bs=1024 count=1" does also wipe the > > > disklabel. > > > > > > "dd if=/dev/srandom of=/dev/wd0a bs=1024 count=1" does not wipe the > > > disklabel. > > > > > 16 partitions: > > > #size offset fstype [fsize bsize cpg] > > > a: 390700800016065RAID > > > c: 39070291680 unused > > > e:16001 64RAID > > > > yes, if you overwrite the disklabel (which lives at the start of the disk) > > you > > will wipe it. don't do that. > > > > But.. wd0e is the "e" partition within the BSD disklabel, and that's what I > wrote to (and even if it's not relevant here, also its writes should be > "boundary checked" so they're foolproof in respect of overwriting > extra-partition data)? > > With "dd if=/dev/srandom of=/dev/rwd0*c* bs=1024 count=1" I'd have > understood that I wiped something sensitive, but this is "dd > if=/dev/srandom of=/dev/rwd0*e* bs=1024 count=1"?? > > > Have I (and some others) misunderstood anything about how BSD disklabelling > works? the disklabel is the second sector of the openbsd part of the disk. *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] OpenBSD so, if you overwrite sector 65, you will overwrite disklabel. normally the 'a' partition overlaps the disklabel, but you made 'e' first.
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
2015-10-07 0:45 GMT+08:00 Ted Unangst : > Mikael wrote: > > The script below includes extra considerations to see through any kernel > > caching of the disklabel, by rebooting between every relevant step. > > > > "dd if=/dev/srandom of=/dev/rwd0e bs=1024 count=1" does also wipe the > > disklabel. > > > > "dd if=/dev/srandom of=/dev/wd0a bs=1024 count=1" does not wipe the > > disklabel. > > > 16 partitions: > > #size offset fstype [fsize bsize cpg] > > a: 390700800016065RAID > > c: 39070291680 unused > > e:16001 64RAID > > yes, if you overwrite the disklabel (which lives at the start of the disk) > you > will wipe it. don't do that. > But.. wd0e is the "e" partition within the BSD disklabel, and that's what I wrote to (and even if it's not relevant here, also its writes should be "boundary checked" so they're foolproof in respect of overwriting extra-partition data)? With "dd if=/dev/srandom of=/dev/rwd0*c* bs=1024 count=1" I'd have understood that I wiped something sensitive, but this is "dd if=/dev/srandom of=/dev/rwd0*e* bs=1024 count=1"?? Have I (and some others) misunderstood anything about how BSD disklabelling works?
Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
Mikael wrote: > The script below includes extra considerations to see through any kernel > caching of the disklabel, by rebooting between every relevant step. > > "dd if=/dev/srandom of=/dev/rwd0e bs=1024 count=1" does also wipe the > disklabel. > > "dd if=/dev/srandom of=/dev/wd0a bs=1024 count=1" does not wipe the > disklabel. > 16 partitions: > #size offset fstype [fsize bsize cpg] > a: 390700800016065RAID > c: 39070291680 unused > e:16001 64RAID yes, if you overwrite the disklabel (which lives at the start of the disk) you will wipe it. don't do that.
"dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg
The script below includes extra considerations to see through any kernel caching of the disklabel, by rebooting between every relevant step. "dd if=/dev/srandom of=/dev/rwd0e bs=1024 count=1" does also wipe the disklabel. "dd if=/dev/srandom of=/dev/wd0a bs=1024 count=1" does not wipe the disklabel. Find below 1) Description/how reproduce, and 2) Full console interaction log + dmesg. Did I misunderstand anything or is this a bug? *1) Description/how reproduce* Boot the OBSD 5.7 AMD64 installer in QEMU 2.2. Go into (S) Shell. dd if=/dev/zero of=/dev/wd0c bs=1024 count=102400 fdisk -iy wd0 disklabel wd0 And diskabel correctly shows there's only a c partition i.e. # /dev/rwd0c: [...] 16 partitions: #size offset fstype [fsize bsize cpg] c: 39070291680 unused Reboot (reboot). Go into (S) Shell. Set up the disklabel: disklabel -E /dev/wd0c a e [offset - enter for default] [size: 1M] [type: RAID - the keydisk has type RAID] a a [offset - enter for default] [size - enter for all remaining space] [type - RAID] w q And then check that it's actually written (by "disklabel wd0"), and it is: 16 partitions: #size offset fstype [fsize bsize cpg] a: 390700800016065RAID c: 39070291680 unused e:16001 64RAID Reboot (reboot). Go into (S) Shell, and do: dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1 Now check that the disklabel has integrity, and it has, i.e. "disklabel wd0" shows the same output as above. Reboot (reboot). Go into (S) Shell, and do "disklabel wd0", and the disklabel is now reset! # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: QEMU HARDDISK duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 243201 total sectors: 3907029168 boundstart: 64 boundend: 3907024065 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 39070291680 unused *2) Full console interaction log + dmesg* Marked in bold the parts where I actually change anything. # fdisk wd0 Disk: wd0 geometry: 243201/255/63 [3907029168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] OpenBSD # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: QEMU HARDDISK duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 243201 total sectors: 3907029168 boundstart: 64 boundend: 3907024065 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 39070291680 unused *# dd if=/dev/zero of=/dev/wd0c bs=1024 count=102400* *102400+0 records in* *102400+0 records out* *104857600 bytes transferred in 56.595 secs (1852752 bytes/sec)* *#* *# fdisk -iy wd0* *Writing MBR at offset 0.* # fdisk wd0 Disk: wd0 geometry: 243201/255/63 [3907029168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 243200 254 63 [ 64: 3907024001 ] OpenBSD # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: QEMU HARDDISK duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 243201 total sectors: 3907029168 boundstart: 64 boundend: 3907024065 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 39070291680 unused # reboot syncing disks... done rebooting... (After reboot:) Welcome to the OpenBSD/amd64 5.7 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s # fdisk wd0 Disk: wd0 geometry: 243201/255/63 [3907029168 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0
Re: Is OpenSMTPD worthy of OpenBSD inclusion?
On Tue, Oct 06, 2015 at 02:20:31AM +0300, Kimmo Paasiala wrote:
> On Mon, Oct 5, 2015 at 10:52 PM, Артур Истомин wrote:
> > On Mon, Oct 05, 2015 at 01:07:24PM -0400, STeve Andre' wrote:
> >> The smtpd code is very good.
> >
> > static void
> > filter_tx_io(struct io *io, int evt)
> > {
> > struct filter_session *s = io->arg;
> > size_t len, n;
> > char*data;
> > charbuf[65535];
> >
> >
> > switch (evt) {
> > case IO_DATAIN:
> > data = iobuf_data(&s->ibuf);
> > len = iobuf_len(&s->ibuf);
> > memmove(buf, data, len);
> > buf[len] = 0;
> >
>
> You just validated all the concerns about the quality of OpenSMTPd and
> also the need for peer/code reviews. That is not production quality
> code by any measure.
I mean exactly that. It is sarcasm about "very good code".
Re: Strange network issue during startup
On Tue, Oct 06, 2015 at 08:01 +0200, Alessandro DE LAURENZIS wrote: > Hello Mike, > > Thanks for your feedback, > > On Mon 05/10/2015 16:43, Mike Belopuhov wrote: > > > > Can you please add an "ifconfig -A" invocation to your hostname.trunk0: > > > > trunkproto failover > > trunkport em0 > > trunkport iwn0 > > !/sbin/ifconfig -A >/root/ifconfig.out 2>&1 > > dhcp > > > > And send me the output. > > [snip] > lo0: flags=8049 mtu 32768 > priority: 0 > groups: lo > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet 127.0.0.1 netmask 0xff00 > em0: flags=8b43 mtu > 1500 > lladdr 00:21:86:94:34:8e > priority: 0 > trunk: trunkdev trunk0 > media: Ethernet autoselect (none) > status: no carrier > iwn0: flags=8943 mtu 1500 > lladdr 00:21:86:94:34:8e > priority: 4 > trunk: trunkdev trunk0 > groups: wlan > media: IEEE802.11 autoselect (DS1) > status: no network > ieee80211: nwid wpakey wpaprotos wpa1,wpa2 > wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip > enc0: flags=0<> > priority: 0 > groups: enc > status: active > trunk0: flags=8843 mtu 1500 > lladdr 00:21:86:94:34:8e > priority: 0 > trunk: trunkproto failover > trunkport iwn0 active > trunkport em0 master > groups: trunk egress > media: Ethernet autoselect > status: active > inet 192.168.1.13 netmask 0xff00 broadcast 192.168.1.255 > pflog0: flags=141 mtu 33144 > priority: 0 > groups: pflog > [snip] > > To me, it seems that trunk0 is correctly bound to the wifi and has an IP > address assigned... > Is this from the /root/ifconfig.out? Trunk interface should not have an IP address at this point. How does your /etc/hostname.trunk0 look like right now? > > > > Could you also try to capture the initial output from the dhclient > > or make a photo of the DHCP progress (and failure). > > > > Nothing "special": > > [snip] > DHCPREQUEST on trunk0 to 255.255.255.255 > DHCPREQUEST on trunk0 to 255.255.255.255 > DHCPREQUEST on trunk0 to 255.255.255.255 > DHCPREQUEST on trunk0 to 255.255.255.255 > DHCPREQUEST on trunk0 to 255.255.255.255 > DHCPDISCOVER on trunk0 - interval 1 > DHCPDISCOVER on trunk0 - interval 2 > DHCPDISCOVER on trunk0 - interval 3 > DHCPDISCOVER on trunk0 - interval 8 > DHCPDISCOVER on trunk0 - interval 11 > DHCPDISCOVER on trunk0 - interval 11 > DHCPDISCOVER on trunk0 - interval 14 > DHCPDISCOVER on trunk0 - interval 9 > No acceptable DHCPOFFERS received > Trying recorded lease 192.168.1.13 > bound to 192.168.1.13 - renewal in 21600 seconds. > [snip] > [snip] > bear with me, I need a couple of days to try this; I'll keep you > updated. > Please take your time. > Cheers > > -- > Alessandro DE LAURENZIS > [mailto:just22@gmail.com] > LinkedIn: http://it.linkedin.com/in/delaurenzis
Support for ActivCard, CRYPTOCard and SNK-004 authentication tokens
Hello, We're currently evaluating if we should keep providing support for ActivCard, CRYPTOCard and SNK-004 authentication tokens via login_token(8). If you're a user of "activ", "crypto", "snk" or "token" authentication methods (check your /etc/login.conf), please speak up so that we could estimate a number of active users. If noone speaks up the support for these authentication methods will be removed and won't ship with OpenBSD 5.9. Regards, Mike
Re: Is OpenSMTPD worthy of OpenBSD inclusion?
By now the thread starter should already be well aware that the correct thing would have been to ask for some comforting words the report from the third party code audit was and is going to result in further improvements. And then thank the developers for sharing the audit details, the work done so far and the immediate follow up and best effort to improve it all for the rest who don't have the skill, time or courage to work on a challenging project. Instead he chose to bitch, whine and insult the buddies who try to provide features in trade of more interest and exposure in real usage. It's a call for eyeballs, how much simple can it get, just try to contribute or be supportive, if you can't just shut up, Jason. Sure the OpenSMTPD is worthy of inclusion as it is in base, otherwise it would not be there. What kind of a nonsense question is this, rephrasing the old Confucius saying "be a man about it" does nothing but waste time and asks for a challenge response. Who needs this? Only someone trying to interfere or cause turmoil, so retreat your words or admit you tried causing damage and hope there is way to repair it. As nobody of interest in the internals of the featuritis involved, my best hopes, and certainly the wide groups of users, are the OpenSMTPD project makes it further and this is reassuring enough already.
Re: cu with XMODEM won't transfer file
Hello
On 10/05/15 19:59, Nicholas Marriott wrote:
On Mon, Oct 05, 2015 at 10:07:21AM -0700, Philip Guenther wrote:
On Mon, Oct 5, 2015 at 6:54 AM, Kim Zeitler wrote:
I am trying to transfer a new firmware to a switch using cu(1) with XMODEM
using a USB-to-RS232 adapter and running on -current.
Connection works fine, but for the XMODEM resulting in 'Resource temporarily
unavailable'
$cu -d -l /dev/ttyU0
...
~X
Local file? /tmp/fw.swi
cu: /tmp/fw.swi: Resource temporarily unavailable
Tthe -d option makes cu open the tty with O_NONBLOCK so that it won't
block for carrier; perhaps it should be clearing the flag afterwards?
Hmm, no, it uses libevent, so maybe it should be *always* turning it
on xmodem_{read,write}() updated to use libevent too, or xmodem_send()
updated to explicitly mark it blocking during the transfer.
How about this?
(Not tested as I don't have any serial cables around at the moment :-/)
I have just tested it and can confirm it works great.
Many thanks to you for finding this and providing a patch so quickly.
Cheers Kim
Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.14
diff -u -p -r1.14 command.c
--- command.c 5 Oct 2015 17:53:56 - 1.14
+++ command.c 5 Oct 2015 17:56:14 -
@@ -51,6 +51,7 @@ pipe_command(void)
return;
restore_termios();
+ set_blocking(line_fd, 1);
switch (pid = fork()) {
case -1:
@@ -81,6 +82,7 @@ pipe_command(void)
break;
}
+ set_blocking(line_fd, 0);
set_termios();
}
@@ -102,6 +104,7 @@ connect_command(void)
return;
restore_termios();
+ set_blocking(line_fd, 1);
switch (pid = fork()) {
case -1:
@@ -129,6 +132,7 @@ connect_command(void)
break;
}
+ set_blocking(line_fd, 0);
set_termios();
}
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.22
diff -u -p -r1.22 cu.c
--- cu.c18 May 2015 09:35:05 - 1.22
+++ cu.c5 Oct 2015 17:56:14 -
@@ -186,6 +186,7 @@ main(int argc, char **argv)
NULL);
bufferevent_enable(output_ev, EV_WRITE);
+ set_blocking(line_fd, 0);
line_ev = bufferevent_new(line_fd, line_read, NULL, line_error,
NULL);
bufferevent_enable(line_ev, EV_READ|EV_WRITE);
@@ -209,6 +210,21 @@ signal_event(int fd, short events, void
}
void
+set_blocking(int fd, int state)
+{
+ int mode;
+
+ if ((mode = fcntl(fd, F_GETFL)) == -1)
+ cu_err(1, "fcntl");
+ if (!state)
+ mode |= O_NONBLOCK;
+ else
+ mode &= ~O_NONBLOCK;
+ if (fcntl(fd, F_SETFL, mode) == -1)
+ cu_err(1, "fcntl");
+}
+
+void
set_termios(void)
{
struct termios tio;
@@ -342,7 +358,7 @@ try_remote(const char *host, const char
if (entry != NULL && cgetset(entry) != 0)
cu_errx(1, "cgetset failed");
- error = cgetent(&cp, (char**)paths, (char*)host);
+ error = cgetent(&cp, (char **)paths, (char *)host);
if (error < 0) {
switch (error) {
case -1:
Index: cu.h
===
RCS file: /cvs/src/usr.bin/cu/cu.h,v
retrieving revision 1.6
diff -u -p -r1.6 cu.h
--- cu.h10 Jul 2012 12:47:23 - 1.6
+++ cu.h5 Oct 2015 17:56:14 -
@@ -27,6 +27,7 @@ extern FILE *record_file;
extern struct termios saved_tio;
extern int line_fd;
extern struct bufferevent *line_ev;
+voidset_blocking(int, int);
intset_line(int);
void set_termios(void);
void restore_termios(void);
Index: xmodem.c
===
RCS file: /cvs/src/usr.bin/cu/xmodem.c,v
retrieving revision 1.7
diff -u -p -r1.7 xmodem.c
--- xmodem.c21 Sep 2014 05:29:47 - 1.7
+++ xmodem.c5 Oct 2015 17:56:14 -
@@ -137,8 +137,9 @@ xmodem_send(const char *file)
if (tcsetattr(STDIN_FILENO, TCSAFLUSH, &tio) != 0)
cu_err(1, "tcsetattr");
}
-
+ set_blocking(line_fd, 1);
tcflush(line_fd, TCIFLUSH);
+
if (xmodem_read(&c) != 0)
goto fail;
if (c == XMODEM_C)
@@ -214,6 +215,7 @@ fail:
cu_warn("%s", file);
out:
+ set_blocking(line_fd, 0);
set_termios();
sigaction(SIGINT, &oact, NULL);
Re: vpn from subnet to subnet through a 3rd enpoint?
Em 06-10-2015 10:35, Markus Rosjat escreveu: > as the subject states is it possible to do that ? Yes, it is. > My tunnels working from the 3rd subnet in each of the other 2 subnets > and back from then. I really want to connect from subnet 1 to subnet 2 > over the enpoint in the 3rd subnet. Are you setting up the routes correctly? > > subnet 1 <---> subnet 3 ; works fine > subnet 2 <> subnet 3; works fine > subnet 1 <---| subnet 3 |> subnet 2; isn't working You should send/setup in the subnet 1 a route to subnet 2 using the subnet 3 router as gateway. The same for subnet 2, otherwise the packets won't get back. > > all 3 endpoints running openBSD and ipsec, some advice would be cool I don't know about doing this using ipsec, as I already mentioned, you need configure the routes. There are also PF rules needed, and, if any of the subnets aren't using the OpenBSD as their gateway, you might need some nat. It's worth mentioning that OpenVPN has this functionality with their client-to-client directive. Even them some routing/firewalling is required. Just keep in mind that if these subnets are connected through the internet, making all of them pass through the subnet 2, will slow things down. Cheers, Giancarlo Razzolini
vpn from subnet to subnet through a 3rd enpoint?
Hi there, as the subject states is it possible to do that ? My tunnels working from the 3rd subnet in each of the other 2 subnets and back from then. I really want to connect from subnet 1 to subnet 2 over the enpoint in the 3rd subnet. so subnet 1 <---> subnet 3 ; works fine subnet 2 <> subnet 3; works fine subnet 1 <---| subnet 3 |> subnet 2; isn't working all 3 endpoints running openBSD and ipsec, some advice would be cool :) regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
Re: dd if=/dev/zero of=/dev/mykeydisk; bioctl -k /dev/mykeydisk ... = will use 0x00 as key, or will generate a secure key?
On Tue, Oct 06, 2015 at 08:04:01PM +0800, Mikael wrote: > Aha. So at "-k" time, if there's no key on the keydisk structure already, > it'll make one. So this is how you can use one and the same keydisk for > multiple volumes. Yes. Per volume you need one disklabel partition of type RAID which you pass to the -k option to configure it as key disk. > I guess by "mask key" you mean "stored encryption key" i.e. the whole point > with the keydisk. The mask key on the key disk decrypts the actual data encryption key which is stored (encrypted with the mask key) in the softraid volume. > Is that one generated by bioctl, or does it just take the bytes that happen > to be at those positions already i.e. zeroes?? Of course the key is generated from entropy. Do you really expect us to consider the contents of left-over disk blocks cryptographically secure? > Also how big should a keydrive be? No docs say. That was definitely in my slides, look again ;-) But I admit that slides don't count as docs.
Re: dd if=/dev/zero of=/dev/mykeydisk; bioctl -k /dev/mykeydisk ... = will use 0x00 as key, or will generate a secure key?
2015-10-06 19:54 GMT+08:00 Stefan Sperling : > On Tue, Oct 06, 2015 at 07:32:45PM +0800, Mikael wrote: > > 2015-10-06 19:27 GMT+08:00 Stefan Sperling : > > > Perhaps this will answer your questions: > > > http://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf > > > > > > > That one mentions nothing of what the keydisk is supposed to contain. > > > > Perhaps that was omitted for brevity? > > Indeed, it's not explained in detail. > The mask key is contained in an optional softraid meta data item. > > If no softraid meta date exists (as is the case when you zero the disk) > fresh meta data with a fresh mask key is written to the key disk slice. > > Does that answer your question? > Aha. So at "-k" time, if there's no key on the keydisk structure already, it'll make one. So this is how you can use one and the same keydisk for multiple volumes. I guess by "mask key" you mean "stored encryption key" i.e. the whole point with the keydisk. Is that one generated by bioctl, or does it just take the bytes that happen to be at those positions already i.e. zeroes?? Also how big should a keydrive be? No docs say.
Re: dd if=/dev/zero of=/dev/mykeydisk; bioctl -k /dev/mykeydisk ... = will use 0x00 as key, or will generate a secure key?
On Tue, Oct 06, 2015 at 07:32:45PM +0800, Mikael wrote: > 2015-10-06 19:27 GMT+08:00 Stefan Sperling : > > Perhaps this will answer your questions: > > http://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf > > > > That one mentions nothing of what the keydisk is supposed to contain. > > Perhaps that was omitted for brevity? Indeed, it's not explained in detail. The mask key is contained in an optional softraid meta data item. If no softraid meta date exists (as is the case when you zero the disk) fresh meta data with a fresh mask key is written to the key disk slice. Does that answer your question?
Re: dd if=/dev/zero of=/dev/mykeydisk; bioctl -k /dev/mykeydisk ... = will use 0x00 as key, or will generate a secure key?
2015-10-06 19:25 GMT+08:00 Jiri B : > On Tue, Oct 06, 2015 at 07:17:19PM +0800, Mikael wrote: > > You > > > > 1) Fill your keydisk with zeroes and > > > > 2) Apply "bioctl -k" on it. > > ^^^ this is not exact cmd arg, is it? > > j. > No, exact key argument is bioctl -C force -c C -l thedrive -k keydrive softraid0 , but as I got it that's -k's single intened use anyhow so was kind of implicit? 2015-10-06 19:27 GMT+08:00 Stefan Sperling : > Perhaps this will answer your questions: > http://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf > That one mentions nothing of what the keydisk is supposed to contain. Perhaps that was omitted for brevity?
Re: dd if=/dev/zero of=/dev/mykeydisk; bioctl -k /dev/mykeydisk ... = will use 0x00 as key, or will generate a secure key?
On Tue, Oct 06, 2015 at 07:17:19PM +0800, Mikael wrote: > You > > 1) Fill your keydisk with zeroes and > > 2) Apply "bioctl -k" on it. > > Does this mean your key is now zeroes, meaning completely unsafe, or did > bioctl make a key for you? > > > The keydisk gets some "OPENBSDSR KEYDISK005" header but it says nowhere if > it actually made a key for you. > > If it generates it, then there is no mentioning in the man page of how to > use one keydisk for multiple volumes. Perhaps that means it doesn't > generate it afterall? > > Also it says nowhere how big the keydisk needs to be, and if it's any > benefit of if it's bigger than needed. Perhaps this will answer your questions: http://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf
Re: dd if=/dev/zero of=/dev/mykeydisk; bioctl -k /dev/mykeydisk ... = will use 0x00 as key, or will generate a secure key?
On Tue, Oct 06, 2015 at 07:17:19PM +0800, Mikael wrote: > You > > 1) Fill your keydisk with zeroes and > > 2) Apply "bioctl -k" on it. ^^^ this is not exact cmd arg, is it? j.
dd if=/dev/zero of=/dev/mykeydisk; bioctl -k /dev/mykeydisk ... = will use 0x00 as key, or will generate a secure key?
You 1) Fill your keydisk with zeroes and 2) Apply "bioctl -k" on it. Does this mean your key is now zeroes, meaning completely unsafe, or did bioctl make a key for you? The keydisk gets some "OPENBSDSR KEYDISK005" header but it says nowhere if it actually made a key for you. If it generates it, then there is no mentioning in the man page of how to use one keydisk for multiple volumes. Perhaps that means it doesn't generate it afterall? Also it says nowhere how big the keydisk needs to be, and if it's any benefit of if it's bigger than needed.
pkg question: dnsmasq alternatives?
We have various OpenBSD machines acting as gateways for NAT LANs. We need a handful of services for these, mainly a dhcp server that can do mac-based fixed addressing, dns server that can attach and reverse names associated with these fixed addresses, dns black-holeing, the ability to intercept dns lookups on non-existent domains when the ISP replies with a spam server instead of nx, and PXE/tftp server. We've been using dnsmasq for years since it provides a one-stop-shop for most of the stuff we need, and while we're fairly happy with it, I always like to ask around periodically to see if for any of the stuff we do a better way has come about. So to cut to the chase, does anyone know of and/or have experience with other packages that do the sorts of things dnsmasq does that it might be worth switching to? (We're only looking at packages). One-stop-shop type programs are obviously preferred to managing a bunch of different stuff. Thanks in advance.
Re: OpenBGPd SNMP
On Mon, Oct 05, 2015 at 10:34:01AM +, Stuart Henderson wrote:
> On 2015-10-04, Mike Hammett wrote:
> > Are there any packages out there that expose OpenBGPd or other OpenBSD
> > parameters via SNMP? Would like to check generic health of the system,
> > number of routes, number of peers, number of routes per peer, etc.
>
> System sensors ("sysctl hw.sensors") are exported by snmpd(8) as
> OPENBSD-SENSORS-MIB, this is non-standard but if you spend a little
> time with the standard ENTITY-SENSOR-MIB and its dependency ENTITY-MIB
> you'll soon understand why. (lm_sensor on linux also uses its own MIB
> for this).
>
> There's nothing currently public for bgpd. Bret has a WIP diff though.
>
I'd contacted the author of the original email off-list, but after
much ill-mannered name calling from sthen have mailed the diff
to tech, for those interested in guineaing in the pig fashion.
Fwd: [EdLUG] 5th International LDAP Conference 11-13/11/2015
FYI: 22 peer-reviewed paper programme includes: 3 different async talks Yubikey, OATH-HOTP & OpenID auth talks Samba4 + twin tracked significant practical tutorial day - laptop required (Advanced track with a strong focus on security) - Forwarded message from Edinburgh Linux Users Group - Date: Mon, 5 Oct 2015 20:05:30 +0100 Subject: [EdLUG] LDAPcon Hi, I mentioned this in passing at the monthly meet but LDAPCon is being held in Edinburgh this year (at the Informatics Forum on Crichton St). Full details are available at: http://ldapcon.org/2015/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: Is OpenSMTPD worthy of OpenBSD inclusion?
On 18:47 Mon 05 Oct , Jason A. Donenfeld wrote: > I maintain both distribution packages for it (Gentoo), as well as my > entire infrastructure, which is based on OpenSMTPD. I've "bet the > farm" on the project, so to speak. Oh, so you were that guy who released "stable" ebuild without Berkeley DB support? I vaguely remember I had to ask QA to fix it because you ignored the bug report.
Re: rdomain 0 and dafault route
On Tue, Oct 06, 2015 at 08:58:24AM +0200, Holger Glaess wrote: > hi > > > On Tue, Oct 06, 2015 at 06:49:29AM +0200, Holger Glaess wrote: > >> hi > >> > >> just a simple question > >> > >> how can i setup an kind of "default route" in rdomain 0 > >> to , for example , rdomain 2. > >> > >> i have 3 rdomain > >> > >> the default one > >> one with the internet connection ( rdomain 1 ) > >> one for my wlan ( rdomain 2 ) > >> > >> the routing between wlan to internet is still working( test "route -n -T > >> 2 > >> exec ping 8.8.8.8" ), > >> but if use the wlan client my local ( forward ) dns server in rdomain 0 > >> he diden't got an anser as result that the dns server can not reach > >> any externel dns server. > > > > You need to use pf to move packets between rdomains. Look for the rtable > > keyword. > > > > i try somthing like that for rdomain 0 ( lan_if ) > > pass out on lan_if from any to any rtable 2 ( internet ) nat-to (pppoe0) > or > pass out rdomain from any to any rtable 2 nat-to (pppoe0) > > same with "in" because an simple ping to 8.8.8.8 in ( or on ? ) rdomain 0 > ( direct on the router ) is no working. > > there is no default route at rdomain 0 > You going to need a default route (can point to loopback) because routing decisions are done before pf can move the packet. -- :wq Claudio
Re: Captive portal with OpenBSD as a hostap
On Mon, Oct 5, 2015 at 1:26 PM, laudarch wrote: > I made a custom implementation and a diff to authpf, will share that > later just in case anyone wants it. > > I hope this helps you, it pretty simple > http://bastienceriani.fr/?p=70 > Thanks laudarch ... Very close to what I am searching... I will try your config.
Re: OpenBGPd error /bsd: bgpd(): syscall 105
On 02.10.2015 10:40, Atanas Vladimirov wrote: On 01.10.2015 20:00, Sebastien Marie wrote: On Thu, Oct 01, 2015 at 12:21:33PM -0400, Michael McConville wrote: Atanas Vladimirov wrote: > Snapshot from sep 30 bgpd didn't startup: > Oct 1 08:32:28 ns /bsd: bgpd(28055): syscall 105 > Oct 1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0 > Oct 1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE > Oct 1 08:32:28 ns bgpd[27739]: handle_pollfd: poll fd: No such file or > directory > Oct 1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0 > Oct 1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE control > Oct 1 08:32:28 ns bgpd[27739]: main: Lost connection to SE > Oct 1 08:32:28 ns bgpd[27739]: Lost child: session engine terminated; > signal 9 This looks like a result of the new tame(2)ing. Below are the tame calls that were just added to bgpd, according to Theo's diff. the revision 1.46 of src/sys/kern/kern_tame.c should have corrected the problem. bgpd use IPv6 setsockopts that weren't allowed. Snapshot Thu Oct 1 20:58:20 MDT 2015 This commit [1] fixed the problem. Thanks. [1] http://marc.info/?l=openbsd-cvs&m=144406193609770&w=2
Re: rdomain 0 and dafault route
hi > On Tue, Oct 06, 2015 at 06:49:29AM +0200, Holger Glaess wrote: >> hi >> >> just a simple question >> >> how can i setup an kind of "default route" in rdomain 0 >> to , for example , rdomain 2. >> >> i have 3 rdomain >> >> the default one >> one with the internet connection ( rdomain 1 ) >> one for my wlan ( rdomain 2 ) >> >> the routing between wlan to internet is still working( test "route -n -T >> 2 >> exec ping 8.8.8.8" ), >> but if use the wlan client my local ( forward ) dns server in rdomain 0 >> he diden't got an anser as result that the dns server can not reach >> any externel dns server. > > You need to use pf to move packets between rdomains. Look for the rtable > keyword. > i try somthing like that for rdomain 0 ( lan_if ) pass out on lan_if from any to any rtable 2 ( internet ) nat-to (pppoe0) or pass out rdomain from any to any rtable 2 nat-to (pppoe0) same with "in" because an simple ping to 8.8.8.8 in ( or on ? ) rdomain 0 ( direct on the router ) is no working. there is no default route at rdomain 0 holger > -- > :wq Claudio
