Re: dhclient vio0 -> Segmentation fault
On Thu, Apr 4, 2019, at 1:19 AM, Greg Steuck wrote: > April 2 snapshot misbehaves badly on Google Compute Engine. > > # dmesg | head > OpenBSD 6.5 (GENERIC.MP) #839: Tue Apr 2 20:38:19 MDT 2019 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > # dhclient -v -d vio0 > vio0: DHCPDISCOVER - interval 1 > vio0: DHCPOFFER from 169.254.169.254 (42:01:0a:80:00:01) > Segmentation fault > # ls -l /sbin/dhclient I don't think this is confined to Google Compute Engine. I just upgraded my ThinkPad T430s to the April 2 snapshot, and I have a similar experience when setting up both wired and wireless connections (em0 and iwn0) using DHCP. My dhclient also segfaults after receiving DHCPOFFER from the local Verizon FIOS router. Sorry for the lack of dmesg, but I'm typing this from my phone. -- Matthew Graybosch https://www.matthewgraybosch.com "Out of order? Even in the future nothing works."
Re: Broken links on http://www.openiked.org/
Thanks, I’m afk this weekend but I’ll take care afterwards. Reyk > Am 05.04.2019 um 19:24 schrieb Alex Naumov : > > Hey, > > it seems openiked.org is not maintained well. > 1. Copyright is just until 2015. > 2. There are some broken links on it: links to "CD's" and "Posters". > 3. Old links-format for man.openbsd.org is used. > > Cheers, > Alex
Broken links on http://www.openiked.org/
Hey, it seems openiked.org is not maintained well. 1. Copyright is just until 2015. 2. There are some broken links on it: links to "CD's" and "Posters". 3. Old links-format for man.openbsd.org is used. Cheers, Alex
Re: Add current rtable to PS1
Pierre - thanks again, this is hugely helpful! I just wanted to add to this for everyone here, plus for (perhaps my own) future Google search reference: In order to get KSH to evaluate the "id -R" each time I had to use single quotes. When using double-quotes id -R is evaluated only once, and then PS1 is set to 0 by default and stays that way. PS1=(rtable 0)... The single quotes preserves the literal $(id -R) and so it's being evaluated every single time the prompt is displayed. So in my .profile I have: export PS1='(rtable $(id -R)) [\u@\h]:\w\\$ ' Then if I switch rdomains using: "doas /sbin/route -T42 exec /bin/ksh" My prompt looks like: (rtable 42) [henry@openbsd]:~$ And for a bonus, here's a little script I put together that I use to easily switch between routing domains: https://gitlab.com/hbonath/openbsd-routing-context It simply runs a new elevated shell in the specified rtable e.g.: doas routing-table 42 would run a root shell in rtable 42. -Henry On Tue, Apr 2, 2019 at 5:07 PM Pierre Emeriaud wrote: > Le mar. 2 avr. 2019 à 23:00, Henry Bonath a écrit : > > > > Hello, > > Does anyone have any suggestions as to how to add the current rtable to > the > > $PS1 prompt? > > > > I tend to flip back and forth between routing domains and tend to lose > track > > of which rdomain I am currently using. > > > > I've been attempting an approach by trying to run 'ps -aux -o rtable' > > and using some grep/cut-fu but I am not happy with the results. > > > > Perhaps there is something simpler that I am missing? > > Yes, `id -R` "Display the routing table of the current process": > > PS1="[\u@$\h:\w](rdomain$(id -R))\$ " >
Re: doas.conf and GUI applications
On Fri, Apr 05, 2019 at 10:10:52AM -0400, Bruno Dantas wrote: There are a handful of GUI applications (file manager, text editor, terminal emulator) that I go back and forth between running as regular user and running with doas root. […] Running GUI applications as root is a bad idea in general. OpenBSD is an OS that emphasizes privilege separation for programs that actually need root access. I think its users should also try to minimize the amount of code they run with administrative privileges. Particularly, why would you want to run a terminal emulator as root? Just launch it without admin privileges and use doas in the shell. This way the terminal and the shell run with your user's privileges. Also, if you need to edit files in /etc, do it with a minimal editor from the base system, like vi, not with a full-blown GUI application. I personally prefer neovim for editing my files, but I trust vi more when I edit system files. As for file management, there shouldn't be a need to manage files outside your home. Just mount (with doas) your USB stick to a sub-dir in your home, and your user should be granted access to its files. If there is need to move around system files, say in /etc, use doas with the CLI tools from base: cp, mv, rm etc. This is the Unix way. I realize right-clicking a program and choosing "Run as admin" might be second nature to Windows users, but it's a nasty habit.
Re: Is anyone able to use certificates with openbsd iked/ikev2 and Apple iOS (iphone)?
On 04/05, Michael Lam wrote: Are you able to have 2 clients connected at the same time? When I tried that (I am using mschap) whenever the 2nd client connects the 1st one's traffic will not go through anymore (it stays connected but no traffic can go through). I've noticed that, if my 2 ikedv2 clients are on the same network using NAT and private IPs, instead of having their own public IPs, that they kick each other off when either of them connects to my remote ikedv2 server. At least last time I tried, on OpenBSD 6.3 I think. Both clients and server are running OpenBSD. Searching the interwebs led me to think maybe IPSEC and NAT-T don't support that scenario...the flows say to send all the packets to the NATted network's public IP, but maybe the NATted network router doesn't know where to send it to after that, or rather, only can handle one such connection at a time, so, whenever a new one is started, the old one gets stomped. Anyhoo, I don't know what I'm talking about, my usage of OpenBSD has only helped me get from complete ignorance of this stuff to slightly less ignorant, so, take all this with a grain of salt. :)
Re: doas.conf and GUI applications
> This is the Unix way. Thank you, Dumitru. All excellent points. Bad habits from imposed-Windows-at-work die hard, even for a Unix and OpenBSD lover. I will try to follow your advice. In the meantime, at least doas is now configured so that applications don't go berserk when I have relapses. OpenBSD has helped me learn better ways of doing almost everything. That's the main reason I use it, even above the security benefits.
Re: Is anyone able to use certificates with openbsd iked/ikev2 and Apple iOS (iphone)?
On Fri, Apr 05, 2019 at 01:45:19PM +, Michael Lam said unto me: > > Are you able to have 2 clients connected at the same time? When I tried > that (I am using mschap) whenever the 2nd client connects the 1st one's > traffic will not go through anymore (it stays connected but no traffic > can go through). Yes. In general I have 3 static site-to-site tunnels with specific flows (running GRE on top), and then typically 1 but have had 3 simultaneous connections hitting the roadwarrior policy. All of the tunnels are using rsa certificate authentication with FQDN ids. --Matt -- Matthew Ernisse m...@going-flying.com http://www.going-flying.com/
doas.conf and GUI applications
There are a handful of GUI applications (file manager, text editor,
terminal emulator) that I go back and forth between running as regular
user and running with doas root.
All these applications were exhibiting unexpected behaviors:
1. Random crashes at launch (https://tinyurl.com/y6k34ol3)
2. Confusion regarding effective user (https://tinyurl.com/y33rc84o)
3. Inability to "remember" user configuration settings
4. Config files in ~/.config "mysteriously" becoming owned by root
After much toil, I figured out that all four issues were related and
were due to my misuse of doas. In case it saves someone some trouble,
here is the summary of the problem and solution, worded in a way that
can be copy/pasted into /etc/examples/doas.conf and/or faq10.html:
--
This /etc/doas.conf works as expected for most CLI applications
(specifically, those that either don't have configuration files or else
have a single root-owned configuration living outside of /home):
permit nopass keepenv bob
However, most GUI applications (more specifically, any application that
saves configuration settings in /home/someuser/somewhere) need the HOME
environmental variable to be that of the effective user. Some GUI
applications rely on the USER variable to determine the effective user.
In addition, in order for GUI applications to access the graphical
environment, they need XAUTHORITY to be that of the logged-in user.
Something like this in /etc/doas.conf should work well for both CLI and
GUI applications:
permit nopass keepenv setenv { USER=root HOME=/root \
XAUTHORITY=/home/bob/.Xauthority } bob
--
Re: Is anyone able to use certificates with openbsd iked/ikev2 and Apple iOS (iphone)?
Are you able to have 2 clients connected at the same time? When I tried that (I am using mschap) whenever the 2nd client connects the 1st one's traffic will not go through anymore (it stays connected but no traffic can go through). I raised this a month ago but seems to have no response. Still trying my luck. > On 5 Apr 2019, at 9:39 AM, Matthew Ernisse wrote: > > I have not tried ECDSA, however I've had iOS and macOS devices > running with iked since it came into OpenBSD using certificate auth > with RSA 2048 certs and a RSA 4096 CA. > > I just recently wrote a blog post on it, it includes a general overview > of how I did it and a fragment of my .mobileconfig and iked.conf. > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.going-flying.com%2Fblog%2Fprotecting-my-macos-and-ios-devices-with-an-openbsd-vpn.htmldata=02%7C01%7C%7C675601333aaa494427c508d6b9c79949%7C84df9e7fe9f640afb435%7C1%7C0%7C636900664254709962sdata=uIBgD24uPOMi6qRmTNOzrYPjdx87Fny1jzlyX5CSI%2B4%3Dreserved=0 > > My VPN endpoint is currently running: > OpenBSD 6.4 (GENERIC) #7: Thu Feb 28 18:10:07 CET 2019 >r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > --Matt > > >> On Apr 4, 2019, at 20:08, Tim Stewart wrote: >> >> Hi Ted, >> >> On 6/2/18 12:26 PM, Theodore Wynnychenko wrote: >>> Hello >>> Last year (before about 3/27/2017 when "Add support for RFC4754 (ECDSA) and >>> RFC7427 authentication" diff was committed to current), I had set up and had >>> been able to connect iOS devices (iphone/ipad) to OpenBSD's iked, and have >>> ikev2 >>> VPN's happen, almost as if by, magic. >>> Authentication was accomplished using certificates signed by a local >>> authority >>> and then distributed to the iOS devices. >>> Since 3/27/17, this has not been working. I sent a couple of emails about >>> this >>> last year (the initial one: >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarc.info%2F%3Fl%3Dopenbsd-bugs%26m%3D149706080419488%26w%3D2data=02%7C01%7C%7C675601333aaa494427c508d6b9c79949%7C84df9e7fe9f640afb435%7C1%7C0%7C636900664254709962sdata=uJr1HNzvBSGIIzxR4CxW3ZuMyksW9B9mD%2BI4PBdUSs4%3Dreserved=0). >>> Over the last year, I have tried many things. Even though I don't know >>> anything >>> about programming (or C), I tried making little changes to the iked source, >>> all >>> without success. (Is that any surprise? No. I was amazed at times that my >>> changes even resulted in a program that would actually start up and run.) >>> I have tried creating several different CA's and certificates, using various >>> different algorithms (ECDSA and RSA, with varying key lengths), all without >>> success. For example, I just tried creating a CA and certificates with >>> ECDSA384/SHA2-384; I distribute those to the iOS device (which supports >>> them), >>> but, iked will not accept them and create a tunnel. >>> In iked.conf, if I don't explicitly state something like "ecdsa384" as the >>> authentication method (and, this requires having a local copy of the public >>> key >>> on the openbsd machine), iked falls back to rfc7427 for authentication, but >>> it >>> appears that iOS does not support this (yet?). >>> I have been downgrading iked to a version before the 3/27/17 (every time I >>> update -current), and this still allows my old certificates to work. But, >>> that >>> doesn't seem sustainable. >>> I have no idea how to proceed? >>> Has anyone been able to get -current (or at least, a snapshot after 3/27/17) >>> version of iked to work with any iOS devices using certificates >>> successfully? >>> If so, I would really appreciate some advice on how it can be done. >>> Thanks >>> Ted >> >> Last night I tried to set up my iPad for the first time and ran into a >> similar issue. Today I remembered writing a patch for a similar issue after >> RFC7427 was added: >> >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarc.info%2F%3Fl%3Dopenbsd-tech%26m%3D149499973130985data=02%7C01%7C%7C675601333aaa494427c508d6b9c79949%7C84df9e7fe9f640afb435%7C1%7C0%7C636900664254709962sdata=HjDwiJ%2BqxTq%2BeddEPECY1HXTp68V2xoqJI7pnlzrDDc%3Dreserved=0 >> >> After applying this, and adding the `rsa' ikeauth parameter to the policy, >> the iPad successfully connected. >> >> Can you try applying that patch and see if it resolves your issue? If it >> also works for you, I'll reply on that thread and see if anyone wants to >> opine on the patch. >> >> -TimS >> >> -- >> Tim Stewart >> t...@stoo.org >> >
Re: Is anyone able to use certificates with openbsd iked/ikev2 and Apple iOS (iphone)?
I have not tried ECDSA, however I've had iOS and macOS devices running with iked since it came into OpenBSD using certificate auth with RSA 2048 certs and a RSA 4096 CA. I just recently wrote a blog post on it, it includes a general overview of how I did it and a fragment of my .mobileconfig and iked.conf. https://www.going-flying.com/blog/protecting-my-macos-and-ios-devices-with-an-openbsd-vpn.html My VPN endpoint is currently running: OpenBSD 6.4 (GENERIC) #7: Thu Feb 28 18:10:07 CET 2019 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC --Matt > On Apr 4, 2019, at 20:08, Tim Stewart wrote: > > Hi Ted, > > On 6/2/18 12:26 PM, Theodore Wynnychenko wrote: >> Hello >> Last year (before about 3/27/2017 when "Add support for RFC4754 (ECDSA) and >> RFC7427 authentication" diff was committed to current), I had set up and had >> been able to connect iOS devices (iphone/ipad) to OpenBSD's iked, and have >> ikev2 >> VPN's happen, almost as if by, magic. >> Authentication was accomplished using certificates signed by a local >> authority >> and then distributed to the iOS devices. >> Since 3/27/17, this has not been working. I sent a couple of emails about >> this >> last year (the initial one: >> https://marc.info/?l=openbsd-bugs=149706080419488=2). >> Over the last year, I have tried many things. Even though I don't know >> anything >> about programming (or C), I tried making little changes to the iked source, >> all >> without success. (Is that any surprise? No. I was amazed at times that my >> changes even resulted in a program that would actually start up and run.) >> I have tried creating several different CA's and certificates, using various >> different algorithms (ECDSA and RSA, with varying key lengths), all without >> success. For example, I just tried creating a CA and certificates with >> ECDSA384/SHA2-384; I distribute those to the iOS device (which supports >> them), >> but, iked will not accept them and create a tunnel. >> In iked.conf, if I don't explicitly state something like "ecdsa384" as the >> authentication method (and, this requires having a local copy of the public >> key >> on the openbsd machine), iked falls back to rfc7427 for authentication, but >> it >> appears that iOS does not support this (yet?). >> I have been downgrading iked to a version before the 3/27/17 (every time I >> update -current), and this still allows my old certificates to work. But, >> that >> doesn't seem sustainable. >> I have no idea how to proceed? >> Has anyone been able to get -current (or at least, a snapshot after 3/27/17) >> version of iked to work with any iOS devices using certificates successfully? >> If so, I would really appreciate some advice on how it can be done. >> Thanks >> Ted > > Last night I tried to set up my iPad for the first time and ran into a > similar issue. Today I remembered writing a patch for a similar issue after > RFC7427 was added: > > https://marc.info/?l=openbsd-tech=149499973130985 > > After applying this, and adding the `rsa' ikeauth parameter to the policy, > the iPad successfully connected. > > Can you try applying that patch and see if it resolves your issue? If it > also works for you, I'll reply on that thread and see if anyone wants to > opine on the patch. > > -TimS > > -- > Tim Stewart > t...@stoo.org >
Re: Viewing SFP diagnostic data in OpenBSD ?
On 05.04.19 02:54, David Gwynne wrote: > you have em(4) with sfp? yepp, e.g. in the following appliances : http://www.lannerinc.com/network-appliances/x86-rackmount-network-appliances/?option=com_content=article=1683:nca-4210=25:rackmount There are 2 SFP slots onboard and we are also using the optional module on the right side of the appliance but not as RJ-45, but with 8x 1 GigE SFP. Whereas the 10 GigE Modules we are using in some setups, are already ix. Here's an example of the chipsets you may find (all *Fibre interfaces are the SFP capable interface and the others are the RJ45 ones): em0 at pci2 dev 0 function 0 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:52 em1 at pci2 dev 0 function 1 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:53 em2 at pci2 dev 0 function 2 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:54 em3 at pci2 dev 0 function 3 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:55 em4 at pci3 dev 0 function 0 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:56 em5 at pci3 dev 0 function 1 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:57 em6 at pci3 dev 0 function 2 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:58 em7 at pci3 dev 0 function 3 "Intel I350 Fiber" rev 0x01: msi, address 00:90:0b:4e:0e:59 em8 at pci5 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:90:0b:68:30:4e em9 at pci6 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:90:0b:68:30:4f em10 at pci7 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:90:0b:68:30:50 em11 at pci8 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:90:0b:68:30:51 em12 at pci9 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:90:0b:68:30:52 em13 at pci10 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:90:0b:68:30:53 em14 at pci11 dev 0 function 0 "Intel I210 Fiber" rev 0x03: msi, address 00:90:0b:68:30:54 em15 at pci12 dev 0 function 0 "Intel I210 Fiber" rev 0x03: msi, address 00:90:0b:68:30:55 Cheers, Marco
