Re: Topics for revised PF and networking tutorial
Tue, 11 Apr 2017 15:31:57 -0500 "Adam Thompson"> > > Plus, this year it appears that Peter is co-delivering the seminar > > > with Massimiliano Stucchi from RIPE, so it will presumably cover > > > a lot of IPv6 topics as well, which are poorly represented in > > > existing materials and yet increasingly relevant. > > > > > Tue, 11 Apr 2017 10:30:35 +1000 > > And for those of us who cannot attend, hopefully it will be on > > video. > > I can't say with 100% certainty, but it's unlikely. The tutorials > are not typically recorded. Hi Adam, bytevolcano, misc@, This is very sad to hear, everyone loves these sessions and always asks. If you can not attend, if you're poor (or from an underdeveloped region) if you're an enthusiast without company / employment sponsorship, or any other sort of financial coverage for the expenses, you're left cold out. As an example of what to expect you can see some old tutorial recordings from the 2014 EuroBSDcon held in Sofia, Bulgaria. These are invaluable: https://va.ludost.net/files/eurobsdcon/2014/Pirin/01.Thursday/ https://va.ludost.net/files/eurobsdcon/2014/Pirin/02.Friday/ And if the video recordings of BSDCan are not available, or can not have the tutorial sessions we hope the new https://2017.eurobsdcon.org/ will. It is the live meetings that make the conferences magical for attendees, then video recordings are precious for the wider community, and history. It is most certain the presenters would love to see the sessions online. When there is a will, there is a way: all other reasons are meaningless. Congratulations on the OpenBSD 6.1 release, just in time for April 12th, [https://en.wikipedia.org/wiki/International_Day_of_Human_Space_Flight]. Kind regards, Anton Lazarov > (Among other things, AFAIK the people who do the recording are only > present for the conference itself.) There's also the matter of the > tutorials not necessarily being covered by the same broadcast > license (hmm, I wonder if Henning will consent this year?). I don't > have anything to do with any of those parts of the conference, so I > can't speak to the details. > > The slides and material are sometimes - not always - made available > afterward, and that depends on the individual presenters. Max is > working for RIPE - which makes large amounts of their material > available for free - and Peter historically makes his material > available online for free, so I therefore have at least moderate > hopes that they'll be able to find a way to sort out the copyright > issues and get the slides put up somewhere. > > -Adam
Re: OpenBSD as a non-routing access point
> I'm not certain but I suspect you're athn address is outside your routers > subnet. > No, they’re both on 192.168.77.x
Driver support for WLE600vx/802.11ac
Hello, I am putting together a PCengines machine, and I need some clarification about support in OpenBSD for the WLE600vx wifi card. This card claims to support 802.11a/b/g/n/ac and uses the Qualcomm Atheros QCA9882 chipset. According to PCengines, the card requires the ath10k driver, which I am unable to find in the OpenBSD manual. My understanding is that OpenBSD does not currently support 802.11ac; only the 802.11n standard. Is this correct? Assuming that this is correct, if I were to install the WLE600vx, can I use it in "n" mode with OpenBSD until "ac" support is implemented, or is the card altogether unsupported? Thanks very much, N
Re: OpenBSD as a non-routing access point
Sent from my iPhone On Apr 11, 2017, at 9:55 PM, Jordonwrote: >> >> rcctl enable dhcrelay >> rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your routers address" >> rcctl start dhcrelay >> >> and possibly add -d (log to stderr) to see what its doing. >> > > Thank you! That got it working! So why is that necessary? Doesnt the bridge just forward everything? Or are DHCP requests broadcasts that dont get forwarded? > > Jordon I'm not certain but I suspect you're athn address is outside your routers subnet.
Re: OpenBSD as a non-routing access point
> rcctl enable dhcrelay > rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your routers address" > rcctl start dhcrelay > > and possibly add -d (log to stderr) to see what its doing. > Thank you! That got it working! So why is that necessary? Doesnt the bridge just forward everything? Or are DHCP requests broadcasts that dont get forwarded? Jordon
manpath
I just wanted to thank Ingo for the work with man, etc. The new man.conf is so much nicer! Thanks, edgar
Re: OpenBSD as a non-routing access point
On 04/11/17 20:13, Jordon wrote: What is your dhcpd.conf and have you verified it's running? There is none - the OpenBSD machine that I am trying to turn into an access point is not the DHCP server or router in my network. With bridging enabled, shouldn’t DHCP requests just be forwarded to the wired network, where the actual router/DHCP server will see it and respond? Jordon try: rcctl enable dhcrelay rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your routers address" rcctl start dhcrelay and possibly add -d (log to stderr) to see what its doing.
Re: OpenBSD as a non-routing access point
> What is your dhcpd.conf and have you verified it's running? > There is none - the OpenBSD machine that I am trying to turn into an access point is not the DHCP server or router in my network. With bridging enabled, shouldn’t DHCP requests just be forwarded to the wired network, where the actual router/DHCP server will see it and respond? Jordon
Re: OpenBSD as a non-routing access point
Sent from my iPhone > On Apr 11, 2017, at 8:04 PM, Jordonwrote: > > Ok, lets try this again… > > I got the 9280 installed. My configs are like this: > > My interfaces are configured like this: > > /etc/hostname.re0 > dhcp > > /ets/hostname.athn0 > media autoselect mode 11n media opt host ap chan 1 > nwid testytesterson > wpakey testingx > inet 192.168.77.253 255.255.255.0 > > /etc/hostname.bridge0 > add athn0 > add re0 > up > > I also set the net.inet.ip.forwarding sysctl to 1 > > From a different machine, if I ping 192.168.77.253, it responds. If I unplug > the network cable going to the OpenBSD box (to re0), the pings stop > responding. If I reconnect the cable, they start up again. However, if I try > to connect a wireless device, I think it connects, but it doesnt pull an IP > address. Seems to me that with ip.forwarding enabled and the bridge in place, > DHCP requests should be forwarded through. Am I missing something? > > Jordon What is your dhcpd.conf and have you verified it's running?
Re: OpenBSD as a non-routing access point
Ok, lets try this again… I got the 9280 installed. My configs are like this: My interfaces are configured like this: /etc/hostname.re0 dhcp /ets/hostname.athn0 media autoselect mode 11n media opt host ap chan 1 nwid testytesterson wpakey testingx inet 192.168.77.253 255.255.255.0 /etc/hostname.bridge0 add athn0 add re0 up I also set the net.inet.ip.forwarding sysctl to 1 >From a different machine, if I ping 192.168.77.253, it responds. If I unplug the network cable going to the OpenBSD box (to re0), the pings stop responding. If I reconnect the cable, they start up again. However, if I try to connect a wireless device, I think it connects, but it doesnt pull an IP address. Seems to me that with ip.forwarding enabled and the bridge in place, DHCP requests should be forwarded through. Am I missing something? Jordon
pkg_add on OpenBSD 6.1, fresh install
I have done a fresh install of 6.1 (downloaded it today, from ftp.openbsd.org/pub/OpenBSD/6.1/amd64 as the file install61.fs (I live in Edmonton, Alberta, that's why I use the source ftp)) and was trying to install some packages... When I type in pkg_add -v http://ftp.openbsd.org/%m/joe (as an example), pkg_add reports joe not found. If instead I do pkg_add -v http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/joe, it works. Admittedly, I am running this from the root login... am I doing something wrong? Anathae
Adding default IPv6 route fails on 6.1
Hello everyone. After upgrading to 6.1 about an hour ago, I noticed that I didn't have an IPv6 connection anymore. I use dhcpcd over a pppoe session, which worked fine in 6.0-stable. The problem seems to be a failure to add a default inet6 route on the pppoe device. I see this error in the dmesg console log: "add net default: gateway fe80::: No route to host" Did I miss something in the changelog, or is this a bug? Here's the contents of my hostname.pppoe0: [sven@puffy ~]$ cat /etc/hostname.pppoe0 description "pppoe session over vlan6" inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \ pppoedev vlan6 authproto pap \ authname 'kennyloggins' authkey 'dangerzone!' dest 0.0.0.1 inet6 eui64 !/sbin/route add default -ifp pppoe 0.0.0.1 !/sbin/route add -inet6 default -ifp pppoe0 fe80::
Re: Topics for revised PF and networking tutorial
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On > Behalf Of bytevolc...@safe-mail.net > Sent: April 10, 2017 19:31 > > > Plus, this year it appears that Peter is co-delivering the seminar > > with Massimiliano Stucchi from RIPE, so it will presumably cover a lot > > of IPv6 topics as well, which are poorly represented in existing > > materials and yet increasingly relevant. > > And for those of us who cannot attend, hopefully it will be on video. I can't say with 100% certainty, but it's unlikely. The tutorials are not typically recorded. (Among other things, AFAIK the people who do the recording are only present for the conference itself.) There's also the matter of the tutorials not necessarily being covered by the same broadcast license (hmm, I wonder if Henning will consent this year?). I don't have anything to do with any of those parts of the conference, so I can't speak to the details. The slides and material are sometimes - not always - made available afterward, and that depends on the individual presenters. Max is working for RIPE - which makes large amounts of their material available for free - and Peter historically makes his material available online for free, so I therefore have at least moderate hopes that they'll be able to find a way to sort out the copyright issues and get the slides put up somewhere. -Adam
Re: Little bump in the upgrade path
On Tue, Apr 11, 2017 at 11:00:44AM -0400, trondd wrote: > Just FYI: > > I upgraded 6.0 to 6.1 and /etc/installurl was populated with: > https://ftp4.usa.openbsd.org/pub/OpenBSD/6.1 > > (as is my mirror) > > But when running pkg_add -u to upgrade, it searched > http://ftp4.usa.openbsd.org/pub/OpenBSD/6.1/6.1 for packages. > > Chopped the 6.1 out of installurl to fix. > > Tim. > Fixed. Thanks for reporting. -- -=[rpe]=-
Little bump in the upgrade path
Just FYI: I upgraded 6.0 to 6.1 and /etc/installurl was populated with: https://ftp4.usa.openbsd.org/pub/OpenBSD/6.1 (as is my mirror) But when running pkg_add -u to upgrade, it searched http://ftp4.usa.openbsd.org/pub/OpenBSD/6.1/6.1 for packages. Chopped the 6.1 out of installurl to fix. Tim.
OpenIKED and Windows 10 Client
Hi there, I try to get iked working with a windows 10 client but it seems windows 10 isnt going to work with the certificates I created and installed. so far I did: - followed the OpenIKED howto to get my openbsd box set up ikev2 "win" passive ipcomp esp \ from 0.0.0.0/0 to 10.10.10.0/24 \ local 192.168.0.73 peer any \ srcid 192.168.0.73 \ tag IKED - added the pf rules - created a client cert with the ip address of the client as FQDN (because the cert with the client machine name didnt worked) - I started iked in debug mode with some verbosity (added the output below) Is it even possible to get it to work for win 10 with the given howto or do I need to add something else? I think the problem is with the windows site because it tells me there is no certificate to be found. I added the certificate to local machine store -> own certificates (at least in the german UI is no personal folder) if someone like to see the debug output . start debug output -- ikev2_recv: IKE_SA_INIT request from initiator 192.168.0.72:500 to 192.168.0.73:500 policy 'win' id 0, 616 bytes ikev2_recv: ispi 0xb76efcd4402276ed rspi 0x ikev2_policy2id: srcid IPV4/192.168.0.73 length 8 ikev2_pld_parse: header ispi 0xb76efcd4402276ed rspi 0x nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 616 response 0 ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 256 ikev2_pld_sa: more than one proposal specified ikev2_pld_sa: more 2 reserved 0 length 40 proposal #1 protoid IKE spisize 0 xforms 4 spi 0 ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024 ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 136 ikev2_pld_ke: dh group MODP_1024 reserved 0 c97aca74 9caa3cbb 70f6eb31 c55e8687 b41431ec 5550e6b8 1233795f 247be2a8 f17eb8fc 67560aa7 e0131fa3 edb43993 95a321aa e39c39f5 e40306d7 098ff42e 3ef6e79f 7f0a5c30 8b2cd031 4980a9f4 339b6518 107a9733 1ae169dd ea421996 d07651db 65ef1a91 b04fc991 e31379c0 18fc4a5c 26c87981 81c54dbb f7c8d223 ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 52 dca1e1cf 770662d4 77cfc0d4 a35c3685 5d2a59a4 1aeac0cc 6ee900b7 1505ad22 75956bde caa6bed9 a70601f9 e3b0b1e1 ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28 ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP 4dd57bae f055f8d8 9a347ca0 7a22f663 992117c8 ikev2_nat_detection: peer source 0xb76efcd4402276ed 0x 192.168.0.72:500 4dd57bae f055f8d8 9a347ca0 7a22f663 992117c8 ikev2_pld_payloads: payload NOTIFY nextpayload VENDOR critical 0x00 length 28 ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP fe055aee aa293f41 af77541d a89ff4b0 126306ef ikev2_nat_detection: peer destination 0xb76efcd4402276ed 0x 192.168.0.73:500 fe055aee aa293f41 af77541d a89ff4b0 126306ef ikev2_pld_payloads: payload VENDOR nextpayload VENDOR critical 0x00 length 24 1e2b5169 05991c7d 7c96fcbf b587e461 0009 ikev2_pld_payloads: payload VENDOR nextpayload VENDOR critical 0x00 length 20 fb1de3cd f341b7ea 16b7e5be 0855f120 ikev2_pld_payloads: payload VENDOR nextpayload VENDOR critical 0x00 length 20 26244d38 eddb61b3 172a36e3 d0cfb819 ikev2_pld_payloads: payload VENDOR nextpayload NONE critical 0x00 length 24 01528bbb c0069612 1849ab9a 1c5b2a51 0002 sa_state: INIT -> SA_INIT ikev2_match_proposals: xform 1 <-> 1 (10): ENCR 3DES (keylength 0 <-> 0) ikev2_match_proposals: xform 1 <-> 1 (4): INTEGR HMAC_SHA1_96 (keylength 0 <-> 0) ikev2_match_proposals: xform 1 <-> 1 (2): PRF HMAC_SHA1 (keylength 0 <-> 0) ikev2_match_proposals: xform 1 <-> 1 (5): DH MODP_1024 (keylength 0 <-> 0) ikev2_sa_negotiate: score 21 ikev2_sa_negotiate: score 10: ENCR 3DES ikev2_sa_negotiate: score 2: PRF HMAC_SHA1 ikev2_sa_negotiate: score 4: INTEGR HMAC_SHA1_96 ikev2_sa_negotiate: score 5: DH MODP_1024 sa_stateok: SA_INIT flags 0x, require 0x sa_stateflags: 0x -> 0x0020 sa (required 0x ) ikev2_sa_keys: SKEYSEED with 20 bytes 5ba80078 e765d093 dbe64f3f 27681da3 5a08771e ikev2_sa_keys: S with 96 bytes dca1e1cf 770662d4 77cfc0d4 a35c3685 5d2a59a4 1aeac0cc 6ee900b7 1505ad22 75956bde caa6bed9 a70601f9 e3b0b1e1 36b9b513 2ecbd6f8 a8d0fbee 9fd4722c 161f2c1f adb72626 4b04d05a 1caaf322 b76efcd4 402276ed 3031dda0 cca39594 ikev2_prfplus: T1 with 20 bytes d1b97d70 91d8868c 72c4c28c abc1d900 22164363 ikev2_prfplus: T2 with 20 bytes b36dbd6f 32c602e5 df8172d7 7f86d2f1 d2709260 ikev2_prfplus: T3 with 20 bytes 8086e540 a1c6e0b5 ac31ae5f 33ce6e99 54f8c64f ikev2_prfplus: T4 with 20 bytes 0e9fed35 b812d76b 261f8b70 40dec377 3a84f431 ikev2_prfplus: T5 with 20 bytes b4a1bac2 8c82df78 fcec5523 0ea7d837 3830a842