Re: Problem with SSD on Marvell 88SE9230 (Supermicro X9SBAA)
Christoph Viethen [open...@aixplosive.net] wrote:
> Hello,
>
> on my little X9SBAA mainboard, I'm faced with a strange phenomenon. I've got
> two SATA drives at hand, one SSD, the other a regular mechanical harddisk.
> As long as I connect the SSD to a PCI card (with VIA VT6421 chipset), I can
> nicely boot from it (or use it in any other way, for that matter).
>
> But as soon as the SSD is connected to any of the on-board SATA ports (which
> are wired to the 88SE9230), I'm getting error messages during bootup of
> OpenBSD:
>
> "ahci0: failed to stop port, cannot softreset"
>
A variation of this problem (evident on Intel chipsets and various SSDs) was
solved for some cases here:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/ahci.c.diff?r1=1.13&r2=1.14
That was based on Dragonfly's commit:
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/f2dba7003b2add226b3999a41a99fd278cc5a26f
(which is a port of the OpenBSD ahci driver)
Perhaps this is a long shot, but maybe your combination of controller and SSD
require more time to sort out thier business. You could try editing
/usr/src/sys/dev/ic/ahci.c to achieve this,
change this is around line 1443:
if (retries == 0) {
retries = 1;
goto retry;
}
to:
if (retries <= 5) {
retries++;
goto retry;
}
Compile a new kernel, see if it helps?
Re: i386 packages - snapshot 23/12/2015
On Thu, Dec 24, 2015 at 4:24 PM, Stuart Henderson wrote: > On 2015-12-24, soko.tica wrote: > > Hello, > > > > I've succesfully installed today the latest i386 snapshot on a usb flash > > disk (on amd64 box), but the packages (e.g. links+, xfe ) report > unresolved > > dependencies and bad major. This is strange, since it is supposed that > > older packages run on fresh -current install. > > It's normal that this happens from time to time with snapshots after a > library update, it takes time to build packages, sign them and get them > out to the mirrors. > > If you want to avoid this, watch source-changes and hold off on updating > for a couple of days after a shared-library bump in base or X (commits > involving shlib_version files). Increase "couple of days" in relation > to the machine speed for slower arches. > > Additionally, packages go through bulk builds before committing to the ports tree. This might also cause a mismatch in the library versions. So the bottom line is: the packages can be out of sync, try again later...
Re: i386 packages - snapshot 23/12/2015
On Thu, Dec 24, 2015 at 10:48 PM, Amit Kulkarni wrote: > > > On Thu, Dec 24, 2015 at 4:24 PM, Stuart Henderson > wrote: > >> On 2015-12-24, soko.tica wrote: >> > Hello, >> > >> > I've succesfully installed today the latest i386 snapshot on a usb flash >> > disk (on amd64 box), but the packages (e.g. links+, xfe ) report >> unresolved >> > dependencies and bad major. This is strange, since it is supposed that >> > older packages run on fresh -current install. >> >> It's normal that this happens from time to time with snapshots after a >> library update, it takes time to build packages, sign them and get them >> out to the mirrors. >> >> If you want to avoid this, watch source-changes and hold off on updating >> for a couple of days after a shared-library bump in base or X (commits >> involving shlib_version files). Increase "couple of days" in relation >> to the machine speed for slower arches. >> >> > Additionally, packages go through bulk builds before committing to the > ports tree. This might also cause a mismatch in the library versions. So > the bottom line is: the packages can be out of sync, try again later... > > Ugh, that wasn't worded properly. Proposed diffs of new versions of ports, which might break other ports, are also built, in a bulk build. This might cause mismatches...
Re: if I were to make a pkg-add diff
>I wanna make a c program that checks for a PKG_PATH that exists and >connects to a workable link for pkg_add(). and I wanna build a rocket ship...
Re: Boot loader uses INT 13h [WAS BIOS call fallback]
What would a "malicious application of hypervisor" look like? How would that be different from a "malicious application of hardware"? Generally speaking, we're talking "grey boxes" here, I imagine. And, I guess, I'd expect either unwanted internet traffic or unwanted radio traffic. Detection of either is probably better done with specialized hardware than with introspective software? But maybe you had some other form of maliciousness in mind? Thanks, -- Raul
Re: tmux scrollback from OSX terminal on macbooks
try entering copy mode ( ctrl-b [ with default keybindings) before scrolling. -d > On Dec 23, 2015, at 6:25 PM, Paolo Aglialoro wrote: > > Hi, > > working remotely on openbsd from OSX terminal has always had the > inconvenience that on macbooks there is no proper PgUp or PgDn key and that > they must be substituted by Fn+Up or Fn+Dn combinations, which, when > coupled with Shift key, usually do not work. > > Recently I found that using iTerm2 I can easily configure the keys so that > Shift+Fn+Up/Dn do obtain the wanted effect within a normal terminal session > :) > > Nevertheless, also with iTerm2 (does anybody else have experiences with > it?), the problem remains in tmux, because Ctrl+B and then Fn+Up/Dn does > not lead to the desired effect. Is this due to tmux or what? When tmux is > detached scrollback returns to correct functioning.
Re: if I were to make a pkg-add diff
I wanna make a c program that checks for a PKG_PATH that exists and connects to a workable link for pkg_add(). If you ever upgraded using http mirrors on the install disk, it offers list# which links directly to numbered mirrors. It would likely ease the initial startup for whomever uses it while not burdening anybody that has already properly configured their system for pkg_add. Most notably, there won't be any JavaScript text-based GUI. ;) On 12/24/15, Ingo Schwarze wrote: > Hi, > > pkg_add(1) is about the hardest program in base to get patches into, > even for experienced developers who know what they are doing, even > if the patches are of reasonable quality and well thought out. > Almost all of my own attempts at improving it led to nowhere, with > very few exceptions for very simple fixes of the most obvious bugs, > and even those exceptions were almost never easy to bring to fruition. > I say that after having committed more than 2.000 times in very > diverse parts of OpenBSD. pkg_add(1) is very hard and no place at > all for beginners. > > The responsible developer is both chronically overworked and very > picky about keeping the structure of the program in a particular > style, and that style is *extremely* unsusual and extremely hard > to read, understand, and maintain. I'm saying that as someone who > has been doing professional, object-oriented Perl programming in > the software industry for more than half a decade. > > So Luke, don't bother submitting patches to pkg_add(1). Don't > bother doing *anything* in a sloppy way for OpenBSD, that would be > nothing but a waste of time. We expect very careful work even for > the smallest suggestions. What you are thinking about is ridiculously > high over your head. > > Besides, you are not making any sense whatsoever. You probably > shouldn't try to submit any patches whatsoever, but instead try to > acquire basic skills using the system in simple ways and expressing > your thoughts clearly. > > Yours, > Ingo > -- -Luke
Re: manpage typo / poll(2)
On Thu, Dec 24, 2015 at 11:56:07PM +0100, d.l...@openmailbox.org wrote: > On 2015-12-24 23:49, Michael McConville wrote: > >d.l...@openmailbox.org wrote: > >>hi, i think this is a bug/typo in the poll(2) example: FD_SET > >>becomes two arguments. > >> You are right. Patch committed, thanks!
Problem with SSD on Marvell 88SE9230 (Supermicro X9SBAA)
Hello, on my little X9SBAA mainboard, I'm faced with a strange phenomenon. I've got two SATA drives at hand, one SSD, the other a regular mechanical harddisk. As long as I connect the SSD to a PCI card (with VIA VT6421 chipset), I can nicely boot from it (or use it in any other way, for that matter). But as soon as the SSD is connected to any of the on-board SATA ports (which are wired to the 88SE9230), I'm getting error messages during bootup of OpenBSD: "ahci0: failed to stop port, cannot softreset" The SSD remains inaccessible then, so during the bootup procedure, the kernel will ask for an alternative root device at some point (see output "B" below). Both disks contain basic installations of OpenBSD-current (installed onto them with a different machine), yesterday's snapshot. (I had seen the same phenomenon with 5.8-stable, so I thought it was more useful to try -current in the hope that the problem might have been fixed already.) Different attempts at booting OpenBSD on the X9SBAA board were made, as follows - a few lines of output from each of those are given (didn't want to spam this list with the entire dmesgs for the different cases). Case A: connect only the mechanical harddisk to on-board ports of X9SBAA, and then boot from it: OpenBSD 5.9-beta (GENERIC.MP) #1773: Wed Dec 23 01:42:40 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8556261376 (8159MB) avail mem = 8292818944 (7908MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9510 (23 entries) bios0: vendor American Megatrends Inc. version "1.1" date 04/29/2014 bios0: Supermicro X9SBAA [...] ahci0 at pci1 dev 0 function 0 "Marvell 88SE9230 AHCI" rev 0x10: msi, AHCI 1.2 ahci0: port 0: 6.0Gb/s ahci0: port 7: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.5000c5006c893eda sd0: 476940MB, 512 bytes/sector, 976773168 sectors uk0 at scsibus1 targ 7 lun 0: ATAPI 3/processor removable ppb1 at pci0 dev 2 function 0 "Intel Atom S1200 PCIE" rev 0x02 pci2 at ppb1 bus 2 [...] scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (178aae26ff9619d9.a) swap on sd0b dump on sd0b Automatic boot in progress: starting file system checks. /dev/sd0a (178aae26ff9619d9.a): file system is clean; not checking /dev/sd0k (178aae26ff9619d9.k): file system is clean; not checking /dev/sd0d (178aae26ff9619d9.d): file system is clean; not checking [etc...] So everything goes through without problems. Case B: Use the SSD instead of the mechanical harddisk on one of the internal ports, and try to boot from it: [Normal bootup messages like above, up to this point:] ahci0 at pci1 dev 0 function 0 "Marvell 88SE9230 AHCI" rev 0x10: msi, AHCI 1.2 ahci0: port 0: 6.0Gb/s ahci0: port 7: 1.5Gb/s scsibus1 at ahci0: 32 targets ahci0: failed to stop port, cannot softreset ahci0: failed to stop port, cannot softreset ahci0: failed to stop port, cannot softreset ahci0: failed to stop port, cannot softreset ppb1 at pci0 dev 2 function 0 "Intel Atom S1200 PCIE" rev 0x02 pci2 at ppb1 bus 2 [bootup seems to continue a little further then - note that neither sd0 nor uk0 were found in this case] scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root device: ? use one of: exit em0 em1 root device: [here we're basically lost] Case C: Connect the SSD to a VIA SATA card (in the PCI slot) - machine boots up nicely: [...] pci4 at ppb3 bus 4 pciide0 at pci4 dev 0 function 0 "VIA VT6421 SATA" rev 0x50: DMA pciide0: using apic 2 int 21 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 190782MB, 390721968 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 ppb4 at pci0 dev 4 function 0 "Intel Atom S1200 PCIE" rev 0x02 pci5 at ppb4 bus 5 [...] scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on wd0a (1e7b990af4950623.a) swap on wd0b dump on wd0b Automatic boot in progress: starting file system checks. /dev/wd0a (1e7b990af4950623.a): file system is clean; not checking /dev/wd0k (1e7b990af4950623.k): file system is clean; not checking /dev/wd0d (1e7b990af4950623.d): file system is clean; not checking [etc...] Now, I would really like to figure out why that Marvell thing is acting up while the SSD is connected to it. I've tried running other OSes on this board, among them FreeBSD, and they all boot without problems from the SSD. But then again, why use other OSes when there's OpenBSD? It would be really brilliant if it were possible to do away with the extra PCI board and run the SSD right from the on-board controller. To be honest, I'm unsure where to even start debugging this, but I'm open for suggestions. (Maybe make funky #defines when compiling the kernel to turn on extra debugging, or maybe try to downgrade the conn
Re: if I were to make a pkg-add diff
Luke Small wrote: > Assuming i could do it: If I were to make a sloppy perl-based pkg-add > program that used c and the installer code to (re)set the PKG-PATH > environment variable using the "http" settings that are available for > installing the modules from mirrors, if I made changes to it to > request a change to the environment variable and possibly alter a > .profile if either the PKG-PATH doesn't exist, or a connection to the > mirror takes too long, would the openbsd devs accept the diff? Quality diffs that fix problems are welcome.
Re: if I were to make a pkg-add diff
Hi, pkg_add(1) is about the hardest program in base to get patches into, even for experienced developers who know what they are doing, even if the patches are of reasonable quality and well thought out. Almost all of my own attempts at improving it led to nowhere, with very few exceptions for very simple fixes of the most obvious bugs, and even those exceptions were almost never easy to bring to fruition. I say that after having committed more than 2.000 times in very diverse parts of OpenBSD. pkg_add(1) is very hard and no place at all for beginners. The responsible developer is both chronically overworked and very picky about keeping the structure of the program in a particular style, and that style is *extremely* unsusual and extremely hard to read, understand, and maintain. I'm saying that as someone who has been doing professional, object-oriented Perl programming in the software industry for more than half a decade. So Luke, don't bother submitting patches to pkg_add(1). Don't bother doing *anything* in a sloppy way for OpenBSD, that would be nothing but a waste of time. We expect very careful work even for the smallest suggestions. What you are thinking about is ridiculously high over your head. Besides, you are not making any sense whatsoever. You probably shouldn't try to submit any patches whatsoever, but instead try to acquire basic skills using the system in simple ways and expressing your thoughts clearly. Yours, Ingo
if I were to make a pkg-add diff
I can't type underscore on this device. Assuming i could do it: If I were to make a sloppy perl-based pkg-add program that used c and the installer code to (re)set the PKG-PATH environment variable using the "http" settings that are available for installing the modules from mirrors, if I made changes to it to request a change to the environment variable and possibly alter a .profile if either the PKG-PATH doesn't exist, or a connection to the mirror takes too long, would the openbsd devs accept the diff? Theoretically, it wouldn't act much differently than the existing installer code, except it would be on pkg-add after the system has been installed. -- -Luke
Re: manpage typo / poll(2)
On 2015-12-24 23:49, Michael McConville wrote: d.l...@openmailbox.org wrote: hi, i think this is a bug/typo in the poll(2) example: FD_SET becomes two arguments. [demime 1.01d removed an attachment of type text/x-diff which had a name of mypatch.diff] Your attachment got stripped. It's easiest just to include it at the bottom of your message. sorry, hope it's now working. === RCS file: /cvs/src/lib/libc/sys/poll.2,v retrieving revision 1.31 diff -u -p -r1.31 poll.2 --- poll.2 3 Mar 2015 01:13:41 - 1.31 +++ poll.2 24 Dec 2015 22:34:58 - @@ -266,7 +266,7 @@ int nready; timeout.tv_sec = 60; timeout.tv_usec = 0; FD_ZERO(&readfds); -FD_SET(STDIN_FILENO); +FD_SET(STDIN_FILENO, &readfds); nready = select(STDIN_FILENO + 1, &readfds, NULL, NULL, &timeout); if (nready == -1) err(1, "select");
Re: manpage typo / poll(2)
d.l...@openmailbox.org wrote: > hi, i think this is a bug/typo in the poll(2) example: FD_SET > becomes two arguments. > > [demime 1.01d removed an attachment of type text/x-diff which had a name of > mypatch.diff] Your attachment got stripped. It's easiest just to include it at the bottom of your message.
manpage typo / poll(2)
hi, i think this is a bug/typo in the poll(2) example: FD_SET becomes two arguments. [demime 1.01d removed an attachment of type text/x-diff which had a name of mypatch.diff]
manpage typo / poll(2) attachment
gah, sorry, crap those webmailers. === RCS file: /cvs/src/lib/libc/sys/poll.2,v retrieving revision 1.31 diff -u -p -r1.31 poll.2 --- poll.2 3 Mar 2015 01:13:41 - 1.31 +++ poll.2 24 Dec 2015 22:34:58 - @@ -266,7 +266,7 @@ int nready; timeout.tv_sec = 60; timeout.tv_usec = 0; FD_ZERO(&readfds); -FD_SET(STDIN_FILENO); +FD_SET(STDIN_FILENO, &readfds); nready = select(STDIN_FILENO + 1, &readfds, NULL, NULL, &timeout); if (nready == -1) err(1, "select");
Re: i386 packages - snapshot 23/12/2015
On 2015-12-24, soko.tica wrote: > Hello, > > I've succesfully installed today the latest i386 snapshot on a usb flash > disk (on amd64 box), but the packages (e.g. links+, xfe ) report unresolved > dependencies and bad major. This is strange, since it is supposed that > older packages run on fresh -current install. It's normal that this happens from time to time with snapshots after a library update, it takes time to build packages, sign them and get them out to the mirrors. If you want to avoid this, watch source-changes and hold off on updating for a couple of days after a shared-library bump in base or X (commits involving shlib_version files). Increase "couple of days" in relation to the machine speed for slower arches.
Re: text-mode gui
> Merry Xmas everyone. I want Santa to take over the project :) > We already get the gifts in may and november ;)
Re: text-mode gui
Merry Xmas everyone. I want Santa to take over the project :) Sent from my BlackBerry 10 smartphone. Original Message From: Christer Solskogen Sent: Thursday 24 December 2015 23:45 To: misc Subject: Re: text-mode gui On Tue, Dec 22, 2015 at 10:00 PM, Theo de Raadt wrote: >> But I still maintain that putting an option in the installer to create >> softraid crypto volumes automatically just dumbs down OpenBSD >> unnecessarily, and encourages people to be lazy instead of learning how >> to use the system to it's full potential. > > It's great that you have an opinion. > > Unfortunately it is the wrong opinion. > I want to have a opinion too! I want Theo to rewrite the installer in java. That would fit my needs! -- chs, using sarcasm.
Re: Boot loader uses INT 13h [WAS BIOS call fallback]
>>Returning back to the discussion where I suggested it would be nice to
>>build OS kernels that would fail deliberately when virtualized to close
>>off that class of malware, especially on the new Intel Skylake chips
>>that have fixed so many virtualization bugs that they can (reportedly)
>>run VT inside VT and nest virtualization so efficiently you can
>>virtualize ridiculous numbers of VMs even inside each other, with so
>>little overhead and few virtualization artifacts that they are nearly
>>undetectable when virtualized.
>There are at least two issues here.
>
>First, some of us *want* to run OpenBSD in a virtualised environment, so
there would have to be multiple code paths/sysctl to deal with this. Also,
what you're asking for is very x86 specific.
These days, I would guess more stuff runs virtualized than not.
A kernel compile/build time configuration would be sufficient here. Yes, and
even more specific than that, I am concerned about the latest Skylake
generation x86 and follow ons - earlier processors have readily documented
bugs that can be used to identify hypervisors. (and these can be used
independently of the specific brand of hypervisor)
>
>Second, it is simply not true that virtualisation is nearly undetectable.
This is of course a moving target, but I'd be amazed if close examination of
processor features made a VM undetectable. Mostly VMs go out of their way to
let >the guest OS know they're running in a VM, so paravirtual drivers can be
used.
>
Since we are talking about malicious applications of hypervisors, and
virtualization features, we can assume that a specialized hypervisor backdoor,
will probably try to not be so blatant and may not be as easy to detect as a
garden variety VM. A small hypervisor, that limits its scope to interfering
with only a few specific functions would not leave so many artifacts to
detect, in effect passing through most functionality to the real hardware.
(see example below)
>The virtualised hardware has a passing relation to actual hardware. Taking
the easy way out, insist on any server hardware being based on Nehalem or
later chipsets, and you'd immediately block the use of Xen, KVM, and >probably
most other VMs. Until reasonably recently, a Xen HVM domU features a modern
(post pentium 3) processor attached to a 440BX chipset. This is, of course,
non existent in the real world. There are many, many other >quirks that
identify VMs, they do not make a serious effort to hide their presence.
This is a lot of hand waving ("many") without actual details. Xen, bhyve and
lots of other, ahem, simpler, VM systems have unique documented quirks (how's
that for understatement). I'm concerned mostly about the more complex and less
quirky and fingerprintable HyperV, VMware, or derivatives thereof with the
identification APIs removed or disabled, but primarily the threat lurks in
unknown small, specialized hypervisors which might have a very small footprint
to identify. Ideally I'm looking for something that will work across all
hypervisors, to detect virtualization generically instead of VM implementation
specific quirks or tricks and even better if it works across multiple
chipsets, but as stated above I am primarily concerned with the latest
generation of x86 chips where the principal threat lies, as a long set of VM
and chipset specific checks sounds like an ugly to maintain mess (see tricks
below). I concede this may not be possible but we won't know until looking for
such.
Here is an example of a small, difficult to detect custom hypervisor (though
this one is used for defensive purposes) and a pretty cool research paper
which also discusses things relevant to this topic:
http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/WillemsCarsten/diss.pd
f
Some approaches:
Timing loops have always been suggested as a first idea, but in practice are
unwieldy and inaccurate. Network packet timing has also been suggested, but
again I don't know if these approaches will work anymore in new high
efficiency virtualization. Other folks have suggested looking for memory
layout anomalies introduced by virtualization. This seems to me to hold the
most promise.
For reference I include below some documented tricks to identify common VMs.
These tricks in the end are crap. They are just signatures for a snapshot of a
moving target and would not really be useful for defense. I am hoping someone
might have some other clever ideas, and that looking at the list below might
stimulate some creativity. Memory layout integrity seems to me to be the only
avenue that may be feasible right now, but maybe someone else has some other
approach that hasn't been considered yet, as there are a lot of smart folks
here.
Cheers,
--dr
Tricks (but not much treats)
Ed Skoudis and Tom Liston enumerated many VM detection tools and some
anti-anti-VM techniques in their now quite dated 2006 paper:
http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf
Re: text-mode gui
On Tue, Dec 22, 2015 at 10:00 PM, Theo de Raadt wrote: >> But I still maintain that putting an option in the installer to create >> softraid crypto volumes automatically just dumbs down OpenBSD >> unnecessarily, and encourages people to be lazy instead of learning how >> to use the system to it's full potential. > > It's great that you have an opinion. > > Unfortunately it is the wrong opinion. > I want to have a opinion too! I want Theo to rewrite the installer in java. That would fit my needs! -- chs, using sarcasm.
Re: i386 packages - snapshot 23/12/2015
On 12/24/15 16:45, soko.tica wrote: I've succesfully installed today the latest i386 snapshot on a usb flash disk (on amd64 box), but the packages (e.g. links+, xfe ) report unresolved dependencies and bad major. This is strange, since it is supposed that older packages run on fresh -current install. Check whether you have the exact libraries referencend in those messages anywhere. My guess is that you hit a point right after a version bump and the new snapshot only has newer libraries. Either I messed something or there is something wrong with the snapshot. Not necessarily. Give it a few hours and try again. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
i386 packages - snapshot 23/12/2015
Hello, I've succesfully installed today the latest i386 snapshot on a usb flash disk (on amd64 box), but the packages (e.g. links+, xfe ) report unresolved dependencies and bad major. This is strange, since it is supposed that older packages run on fresh -current install. Either I messed something or there is something wrong with the snapshot. Regards
Bug in network stack on 2015/12/19 snapshot?
Hello,
These days I'm playing with npppd trying to setup a nice VPN gateway for
windows users. I managed to have a simple working configuration that
authenticates users in a local file (later on, I'll try with RADIUS).
With the configuration listed below, I can successfully connect a Win7
client to OpenBSD 5.8 and I can ping the tun IP from the Win7 host.
If I try that same configuration on the snapshot from 2015/12/19 the npppd
daemon enters on a strange case and I cannot kill it anymore with ^C when I
started it in foreground (npppd -d -f ...)
Note that the configuration works with pppx & pipex, but failed with tun.
Any advice is welcome :)
Here are the configurations:
l2tp58:/etc # ifconfig em0
em0: flags=8843 mtu 1500
lladdr 08:00:27:c8:6d:77
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.1.108 netmask 0xff00 broadcast 172.16.1.255
l2tp58:/etc # cat /etc/ipsec.conf
ip_pub="172.16.1.108"
PSK="test123123"
ike passive esp transport proto udp from $ip_pub to any port 1701 \
main auth hmac-md5 enc 3des group modp2048 \
quick auth hmac-md5 enc 3des \
psk $PSK
ike passive esp transport proto udp from $ip_pub to any port 1701 \
main auth hmac-sha enc aes group modp2048 \
quick auth hmac-sha enc aes \
psk $PSK
ike passive esp transport proto udp from $ip_pub to any port 1701 \
main auth hmac-md5 enc 3des group modp1024 \
quick auth hmac-md5 enc 3des \
psk $PSK
ike passive esp transport proto udp from $ip_pub to any port 1701 \
main auth hmac-md5 enc aes group modp1024 \
quick auth hmac-md5 enc 3des \
psk $PSK
l2tp58:/etc # cat npppd/npppd.conf
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 172.16.1.108
l2tp-accept-dialin yes
l2tp-vendor-name "OpenBSD"
authentication-method mschapv2
tcp-mss-adjust yes
pipex no
mppe no
}
ipcp IPCP {
pool-address 10.11.1.2-10.11.1.7
dns-servers 192.168.78.201 192.168.78.202
}
interface tun1 address 10.11.1.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to tun1
l2tp58:/etc # cat sysctl.conf
net.inet.ip.forwarding=1
net.inet.ipcomp.enable=1
net.inet.gre.allow=1
# isakmpd -4K
# ipsecctl -f /etc/ipsec.conf
# npppd -f /etc/npppd/npppd.conf
#
Claer
Re: Ifstated help needed
On 2015-12-24, Timo Myyrä wrote: > Hi, > > I'm trying to use ifstated to switch between my laptops wireless and wired > interface. > Currently it works when I don't have cable plugged in but once I plug in the > cable the ifstated starts to switch between wired and wireless states and > won't > stay in wired state. > > So it seems the em0.link.down condition gets triggered in wired state but why? > The dhclient seems to run so the em0 should have IP and so it should be up. Kill ifstated and watch 'route -n monitor' when you plug in. Does state change more than once e.g. does it go up/down/up during negotiation with the switch? If so, you may need a sleep before re-checking link state. As it stands, I don't think this ifstated.conf is doing anything that you can't do just by running a dhclient on each interface all the time, dhclient already tracks link state itself, multiple priority routes work fine, and you aren't doing anything to alleviate the problem I mentioned in the other thread that does exist with that setup.
Re: Ifstated help needed
Zé Loff writes:
>> On 24/12/2015, at 10:07, Timo Myyrä wrote:
>>
>> Hi,
>>
>> I'm trying to use ifstated to switch between my laptops wireless and wired
>> interface
>
> man trunk
Just switched from using trunk as it won't renew the addresses. And I'd like
to
run the wireless down when I'm not using it to reduce power use.
>
>> Currently it works when I don't have cable plugged in but once I plug in
the
>> cable the ifstated starts to switch between wired and wireless states and
won't
>> stay in wired state.
>>
>> So it seems the em0.link.down condition gets triggered in wired state but
why?
>> The dhclient seems to run so the em0 should have IP and so it should be
up.
>>
>> Timo
>>
>> daemon:
>> Dec 24 10:43:29 phobos ifstated[31262]: changing state to wired
>> Dec 24 10:43:29 phobos dhclient[2004]: iwn0 down; exiting
>> Dec 24 10:43:33 phobos dhclient[22725]: DHCPREQUEST on em0 to
255.255.255.255
>> Dec 24 10:43:33 phobos dhclient[22725]: DHCPACK from 192.168.0.254
(00:1e:ab:0a:a4:a3)
>> Dec 24 10:43:33 phobos dhclient[22725]: bound to 192.168.0.105 -- renewal
in 43200 seconds.
>> Dec 24 10:43:33 phobos ifstated[31262]: changing state to wireless
>> Dec 24 10:43:33 phobos dhclient[5042]: em0 down; exiting
>> Dec 24 10:43:37 phobos dhclient[9581]: DHCPREQUEST on iwn0 to
255.255.255.255
>> Dec 24 10:43:37 phobos dhclient[9581]: DHCPACK from 192.168.0.254
(00:1e:ab:0a:a4:a3)
>> Dec 24 10:43:37 phobos dhclient[9581]: bound to 192.168.0.106 -- renewal in
43200 seconds.
>> Dec 24 10:44:29 phobos dhclient[9921]: DHCPREQUEST on iwn0 to
255.255.255.255
>> Dec 24 10:44:31 phobos findnwid: attached to network TW-EAV510v4A4A3 on
interface iwn0
>> ...
>>
>> ifstated.conf:
>> nwid = '"[[ $(ifconfig iwn0 | sed -n \'/status/s/.*status: //p\') ==
\'active\' ]]" every 2'
>>
>> init-state wired
>>
>> state wireless {
>>init {
>>run "ifconfig em0 down"
>>run "ifconfig iwn0 up"
>>run "dhclient iwn0"
>>}
>>
>># check if we have active wireless network
>># if not, re-check for networks
>>if ! $nwid && em0.link.down
>>run "/usr/local/bin/findnwid iwn0"
>>
>>if em0.link.up
>>set-state wired
>> }
>>
>> state wired {
>>init {
>>run "ifconfig iwn0 down"
>>run "ifconfig em0 up"
>>run "dhclient em0"
>>}
>>
>>if em0.link.down
>>set-state wireless
>> }
Re: Ifstated help needed
> On 24/12/2015, at 10:07, Timo Myyrä wrote:
>
> Hi,
>
> I'm trying to use ifstated to switch between my laptops wireless and wired
> interface
man trunk
> Currently it works when I don't have cable plugged in but once I plug in
the
> cable the ifstated starts to switch between wired and wireless states and
won't
> stay in wired state.
>
> So it seems the em0.link.down condition gets triggered in wired state but
why?
> The dhclient seems to run so the em0 should have IP and so it should be up.
>
> Timo
>
> daemon:
> Dec 24 10:43:29 phobos ifstated[31262]: changing state to wired
> Dec 24 10:43:29 phobos dhclient[2004]: iwn0 down; exiting
> Dec 24 10:43:33 phobos dhclient[22725]: DHCPREQUEST on em0 to
255.255.255.255
> Dec 24 10:43:33 phobos dhclient[22725]: DHCPACK from 192.168.0.254
(00:1e:ab:0a:a4:a3)
> Dec 24 10:43:33 phobos dhclient[22725]: bound to 192.168.0.105 -- renewal in
43200 seconds.
> Dec 24 10:43:33 phobos ifstated[31262]: changing state to wireless
> Dec 24 10:43:33 phobos dhclient[5042]: em0 down; exiting
> Dec 24 10:43:37 phobos dhclient[9581]: DHCPREQUEST on iwn0 to
255.255.255.255
> Dec 24 10:43:37 phobos dhclient[9581]: DHCPACK from 192.168.0.254
(00:1e:ab:0a:a4:a3)
> Dec 24 10:43:37 phobos dhclient[9581]: bound to 192.168.0.106 -- renewal in
43200 seconds.
> Dec 24 10:44:29 phobos dhclient[9921]: DHCPREQUEST on iwn0 to
255.255.255.255
> Dec 24 10:44:31 phobos findnwid: attached to network TW-EAV510v4A4A3 on
interface iwn0
> ...
>
> ifstated.conf:
> nwid = '"[[ $(ifconfig iwn0 | sed -n \'/status/s/.*status: //p\') ==
\'active\' ]]" every 2'
>
> init-state wired
>
> state wireless {
>init {
>run "ifconfig em0 down"
>run "ifconfig iwn0 up"
>run "dhclient iwn0"
>}
>
># check if we have active wireless network
># if not, re-check for networks
>if ! $nwid && em0.link.down
>run "/usr/local/bin/findnwid iwn0"
>
>if em0.link.up
>set-state wired
> }
>
> state wired {
>init {
>run "ifconfig iwn0 down"
>run "ifconfig em0 up"
>run "dhclient em0"
>}
>
>if em0.link.down
>set-state wireless
> }
Ifstated help needed
Hi,
I'm trying to use ifstated to switch between my laptops wireless and wired
interface.
Currently it works when I don't have cable plugged in but once I plug in the
cable the ifstated starts to switch between wired and wireless states and won't
stay in wired state.
So it seems the em0.link.down condition gets triggered in wired state but why?
The dhclient seems to run so the em0 should have IP and so it should be up.
Timo
daemon:
Dec 24 10:43:29 phobos ifstated[31262]: changing state to wired
Dec 24 10:43:29 phobos dhclient[2004]: iwn0 down; exiting
Dec 24 10:43:33 phobos dhclient[22725]: DHCPREQUEST on em0 to 255.255.255.255
Dec 24 10:43:33 phobos dhclient[22725]: DHCPACK from 192.168.0.254
(00:1e:ab:0a:a4:a3)
Dec 24 10:43:33 phobos dhclient[22725]: bound to 192.168.0.105 -- renewal in
43200 seconds.
Dec 24 10:43:33 phobos ifstated[31262]: changing state to wireless
Dec 24 10:43:33 phobos dhclient[5042]: em0 down; exiting
Dec 24 10:43:37 phobos dhclient[9581]: DHCPREQUEST on iwn0 to 255.255.255.255
Dec 24 10:43:37 phobos dhclient[9581]: DHCPACK from 192.168.0.254
(00:1e:ab:0a:a4:a3)
Dec 24 10:43:37 phobos dhclient[9581]: bound to 192.168.0.106 -- renewal in
43200 seconds.
Dec 24 10:44:29 phobos dhclient[9921]: DHCPREQUEST on iwn0 to 255.255.255.255
Dec 24 10:44:31 phobos findnwid: attached to network TW-EAV510v4A4A3 on
interface iwn0
...
ifstated.conf:
nwid = '"[[ $(ifconfig iwn0 | sed -n \'/status/s/.*status: //p\') ==
\'active\' ]]" every 2'
init-state wired
state wireless {
init {
run "ifconfig em0 down"
run "ifconfig iwn0 up"
run "dhclient iwn0"
}
# check if we have active wireless network
# if not, re-check for networks
if ! $nwid && em0.link.down
run "/usr/local/bin/findnwid iwn0"
if em0.link.up
set-state wired
}
state wired {
init {
run "ifconfig iwn0 down"
run "ifconfig em0 up"
run "dhclient em0"
}
if em0.link.down
set-state wireless
}
Re: Boot loader uses INT 13h [WAS BIOS call fallback]
On 24 December 2015 08:00:01 GMT+00:00, Dragos Ruiu wrote: >Returning back to the discussion where I suggested it would be nice to >build >OS kernels that would fail deliberately when virtualized to close off >that >class of malware, especially on the new Intel Skylake chips that have >fixed >so many virtualization bugs that they can (reportedly) run VT inside VT >and >nest virtualization so efficiently you can virtualize ridiculous >numbers of >VMs even inside each other, with so little overhead and few >virtualization >artifacts that they are nearly undetectable when virtualized. There are at least two issues here. First, some of us *want* to run OpenBSD in a virtualised environment, so there would have to be multiple code paths/sysctl to deal with this. Also, what you're asking for is very x86 specific. Second, it is simply not true that virtualisation is nearly undetectable. This is of course a moving target, but I'd be amazed if close examination of processor features made a VM undetectable. Mostly VMs go out of their way to let the guest OS know they're running in a VM, so paravirtual drivers can be used. The virtualised hardware has a passing relation to actual hardware. Taking the easy way out, insist on any server hardware being based on Nehalem or later chipsets, and you'd immediately block the use of Xen, KVM, and probably most other VMs. Until reasonably recently, a Xen HVM domU features a modern (post pentium 3) processor attached to a 440BX chipset. This is, of course, non existent in the real world. There are many, many other quirks that identify VMs, they do not make a serious effort to hide their presence. PK -
Re: tmux scrollback from OSX terminal on macbooks
On Thu, Dec 24, 2015 at 12:25:07AM +0100, Paolo Aglialoro wrote: > Hi, > > working remotely on openbsd from OSX terminal has always had the > inconvenience that on macbooks there is no proper PgUp or PgDn key and that > they must be substituted by Fn+Up or Fn+Dn combinations, which, when > coupled with Shift key, usually do not work. Um, does for me. > Recently I found that using iTerm2 I can easily configure the keys so that > Shift+Fn+Up/Dn do obtain the wanted effect within a normal terminal session > :) > > Nevertheless, also with iTerm2 (does anybody else have experiences with > it?), the problem remains in tmux, because Ctrl+B and then Fn+Up/Dn does > not lead to the desired effect. Is this due to tmux or what? When tmux is > detached scrollback returns to correct functioning. > Works for me on all the systems I use tmux on (not just OpenBSD). I'm also on iTerm2, on a MacBook Air. No special configuration of tmux or iTerm2 done. When you say "desired effect", you mean "scrolling up and down", right? Andreas -- Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Boot loader uses INT 13h [WAS BIOS call fallback]
The right link to PacSec slides (sorry): Mickey's and Jesse's slides from PacSec: http://goo.gl/Rgcwud -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Dragos Ruiu Sent: December 23, 2015 8:24 PM To: 'Tinker' Cc: 'Read, James C' ; 'Theo de Raadt' ; 'OpenBSD general usage list' ; owner-m...@openbsd.org Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback] >On 2015-12-23 10:04, Dragos Ruiu wrote: >> Ok let me short circuit this meta discussion by saying that AFAIK now >> that the new Intel Skylake chips fixed many virtualization bugs > >Curious, where can I read about this, URL? The canonical reference is still (and I looked for better summaries but none are found): http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32 -architectures-optimization-manual.pdf http://goo.gl/Aq59Lm Its dense with info and tough to pull relevants bits out, but some clues are in there. My comments are based on verbal discussions with other non OBSD OS kernel developer, Intel folks who have boasted about running hundreds of VMs efficiently on a single (albeit Xeon) chip, and multiple folks who are doing security audits of different vendor's Virtualization Cores, that have all corroborated this not very well documented info, commenting especially that Intel had pulled back some not so ready for the real world features originally promised but eventually deprecating them in Broadwell (haven't checked the processor errata for details yet), which were now finally working in Skylake. Coincidentally tonight, this seemingly related and interesting new paper by Joanna Rutkowska (@rootkovska) "Intel x86 Considered Harmful" was released which proposes an intriguing security solution that sounds appealing at first, getting rid of all state in laptops - until you realize that doing this is almost impossible. For a counter example we had a great paper at PacSec this year from Intel's Mickey Shkatov and Jesse Michael discussing and enumerating many of the hidden state / firmware / processors in modern architectures that can be attacked and used as springboards including examples of pwnage using this soft, delicate, and unprotected underbelly of our computers. Modern architectures have so many mutable bits and embedded CPUs/PICs/FPGAs etc... that removing (or even locking them) is a task I daresay is beyond our reach at the moment - at least without making the computers nearly useless bricks. For another example, consider things like your keyboard controller, which is probably a National Semiconductor chip with yet another embedded 8051 core, and then some more of those in your mice and keyboards, and USB and other controllers, and so on. As a matter of fact just counting only the 8051 cores alone in a modern PC is so hard you are nearly guaranteed to miss a few on your first cut. Joanna's paper: http://goo.gl/8xhMo8 Mickey's and Jesse's slides from PacSec: http://goo.gl/8xhMo8 Returning back to the discussion where I suggested it would be nice to build OS kernels that would fail deliberately when virtualized to close off that class of malware, especially on the new Intel Skylake chips that have fixed so many virtualization bugs that they can (reportedly) run VT inside VT and nest virtualization so efficiently you can virtualize ridiculous numbers of VMs even inside each other, with so little overhead and few virtualization artifacts that they are nearly undetectable when virtualized. The prevailing attitude that this isn't in scope to worry about - to which I counter that if you don't worry about the overall platform security and just put blinders on to the hard problems, avoiding defensive mitigations for the weak architecture areas then you have already lost the security and integrity of your computers, and you are at the mercy of the sophisticated attackers. They aren't your computers anymore, you are just using them under the graces of what attack teams more advanced than you allow you to do. (bracing) This is an area where Win10 is clearly leading the pack based on the effort I see they are putting into repeatedly auditing all their codebase with smart outside experts and adding interesting new mitigations like wrappering and shimming vulnerable unchecked AMD microcode updates, and other weak hardware parts like USB etc... - and who would have guessed I would be saying that a few years ago! Yes, I put on my Nomex flame retardant suit before typing that sentence suggesting that OpenBSD development might actually take some cues from Windows, heresy I know, on an OpenBSD list. But this is just one person's opinion based on what I've seen, and the people I've talked to. I'll certainly continue to seek this kind of functionality and try to add it to my OpenBSD kernels myself if no-one else has anything useful to add. Bottom line: Sigh. Cheers, --dr P.S. Go ahead and tell me why I'm such an idiot now. But you have the data too, come to your own
