Re: network config question

[Stuart Henderson]

On 2015-09-25, patrick keshishian  wrote:
> On 9/24/15, Kapetanakis Giannis  wrote:
>> On 24/09/15 22:41, patrick keshishian wrote:
>>> Hi,
>>>
>>> I'm pretty sure I'm over-thinking this, so I thought I'd step back and
>>> see if I can get some hints as how this sort of a set-up is done
>>> "properly" by pros.
>>>
>>>
>>> Say, existing set up:
>>>
>>> [internet] -- [pf] -- [ public-ip-net/24 ]
>>>
>>>
>>> Want to add/connect a private 192.168.0/24 to existing [
>>> public-ip-net/24]:
>>>
>>> ... [ public-ip-net/24] -?- [ obsd box ] -- [ 192.168.0/24 ]
>>>
>>>
>>> Goals:
>>> 1. Hosts in both networks "talk" with one another freely.
>>> e.g., hosts in existing network see hosts in to-be-added 192
>>> network, as they are; i.e., not NAT-ed. And vice versa.
>>> 2. Hosts in 192.168.0/24 have access to the internet through
>>> the same/existing gateway.
>>>
>>>
>>> I lack some knowledge wrt to the subject, where I think, I am
>>> filling the "holes" with, possibly, far too complicated ideas.
>>>
>>> Appreciate any and all help offered.
>>>
>>> Thanks,
>>> --patrick
>>
>> First of all you don't need a second obsd/pf router for this.
>>
>> Either put the private network on a secondary ip on the same
>> vlan/interface as the public
>> or use a new vlan/interface for the private network.
>>
>> pf can be tuned to fit you filtering needs.
>>
>> Do the nat on [pf] box only for packets going out on its egress interface.
>
> Thanks Daniel and Kapetanakis for replies.
>
> I read some on vlans (as I knew next to nothing about them).
> I think I'm still not completely clear on how they would work,
> unless vlan-capable switch is used, which the current set-up lacks;
> The only reference I found, which explicitly states this, is M. Lucas's
> book ("Absolute OpenBSD...").
>
> --patrick
>
>

vlan-tagged packets can be transferred OK through most unmanaged
switches, so if you have two machines with vlans specifically
configured on them, they're usually able to talk to each other.
Obviously with this setup there's no way to restrict which ports
are used for each vlan, and all endpoints wanting to use a vlan
need to handle the tags themselves.

But you don't need that at all, as Giannis points out you can
have an address from both subnets configured on the same interface.

There's obviously no guarantee of separation between the two
networks with either of these methods - by reconfiguring a host
it would be able to directly access hosts from the other subnet -
but as you say you want to allow full access between them anyway,
it's an easy way to do this without extra NICs.

wifi profiles in hostname.if

[Chris Lobkowicz]

Good day, I am curious if there is the possibility of adding/using multiple
profiles or network entries, much like ~/.ssh/config ?

eg:

In /etc/hostname.iwn0

nwid primary
wpakey key
dhcp

​nwid ​secondary
wpakey key
dhcp


Is this possible? I would imagine that wrapping some sort of
identifiers/formatting around the network information would be required,
much like the ssh/config parameters.

Net primary {
  nwid primary
  wpakey key
  dhcp
}
Net secondary {
  nwid secondary
  wpakey key
  dhcp
}


The manpage of hostname.if(5) does not specifically mention/allow for this.



My work-around for this is to have all my locations/ap's use the same nwid
where possible. And where not, just use # comments in my hostname.if files
and just manually edit the appropriate entries in/out, and rerun
/etc/netstart.

Is it possible to bake this in, rather than going down the wpa_supplicant
path as others have done? Or am I getting my hopes up for the sake of being
lazy?

Thanks
Chris

Re: inteldrm errors on latest amd64 snap

[Joe Gidi]

FWIW, a kernel compiled from a fresh checkout of -current produces the
same error and behavior, though the line number changes:

inteldrm0: msiWARNING !power_domains->domain_use_count[domain] failed at
../../../../dev/pci/drm/i915/intel_pm.c:5358

On Sat, September 26, 2015 11:16 am, Joe Gidi wrote:
> I think I just hit some more fallout of the recent inteldrm code update.
>

-- 
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: wifi profiles in hostname.if

[Marc Peters]

On 09/26/15 15:44, Chris Lobkowicz wrote:
> Good day, I am curious if there is the possibility of adding/using multiple
> profiles or network entries, much like ~/.ssh/config ?
> 

I use the scripts provided by afresh1@. They're available at
https://gist.github.com/afresh1/7149844


Marc

> eg:
> 
> In /etc/hostname.iwn0
> 
> nwid primary
> wpakey key
> dhcp
> 
> ​nwid ​secondary
> wpakey key
> dhcp
> 
> 
> Is this possible? I would imagine that wrapping some sort of
> identifiers/formatting around the network information would be required,
> much like the ssh/config parameters.
> 
> Net primary {
>   nwid primary
>   wpakey key
>   dhcp
> }
> Net secondary {
>   nwid secondary
>   wpakey key
>   dhcp
> }
> 
> 
> The manpage of hostname.if(5) does not specifically mention/allow for this.
> 
> 
> 
> My work-around for this is to have all my locations/ap's use the same nwid
> where possible. And where not, just use # comments in my hostname.if files
> and just manually edit the appropriate entries in/out, and rerun
> /etc/netstart.
> 
> Is it possible to bake this in, rather than going down the wpa_supplicant
> path as others have done? Or am I getting my hopes up for the sake of being
> lazy?
> 
> Thanks
> Chris

Re: OpenBSD parts in Toyota Highlander

[Delan Azabani]

Care to post an external link to the image? This list uses demime.

Re: OpenBSD parts in Toyota Highlander

[Predrag Punosevac]

Damn! Not only OpenBSD runs my computers at work and at home now the
secret is out. OpenBSD runs in my Highlander and Sienna. What is next?
Carnegie Mellon University elevators run OpenBSD too? 

Predrag

P.S. I would hope that Toyota corporation will at least match my monthly
contribution to OpenBSD foundation for every vehicle it sells which uses
OpenBSD.

OpenBSD parts in Toyota Highlander

[Chad Dougherty]

As seen in the software information screens on my brother in-law's 
Toyota Highlander.

 -Chad

[demime 1.01d removed an attachment of type image/jpeg which had a name of 
WP_20150830_007.jpg]

Re: OpenBSD parts in Toyota Highlander

[Chad Dougherty]

Oh right, demime.  Try this:
http://1drv.ms/1MQ73pA

Note the "Damien Millet" and "minidrot.org" typos ;)

-Chad

-Original Message-
From: "Delan Azabani" 
Sent: ‎9/‎26/‎2015 11:01
To: "Chad Dougherty" 
Cc: "misc@openbsd.org" 
Subject: Re: OpenBSD parts in Toyota Highlander

Care to post an external link to the image? This list uses demime.

Re: OpenBSD parts in Toyota Highlander

[Todd C. Miller]

On Sat, 26 Sep 2015 12:51:27 -0600, Diana Eichert wrote:

> Todd's is most likely sudo

That's probably strlcpy/strlcat.

 - todd

Re: wifi profiles in hostname.if

[Steve Dee]

On Sat, Sep 26, 2015 at 10:00 AM Stefan Sperling  wrote:

> On Sat, Sep 26, 2015 at 07:44:45AM -0600, Chris Lobkowicz wrote:
> > Good day, I am curious if there is the possibility of adding/using
> multiple
> > profiles or network entries, much like ~/.ssh/config ?
> >
> > eg:
> >
> > In /etc/hostname.iwn0
> >
> > nwid primary
> > wpakey key
> > dhcp
> >
> > ???nwid ???secondary
> > wpakey key
> > dhcp
> >
> >
> > Is this possible? I would imagine that wrapping some sort of
> > identifiers/formatting around the network information would be required,
> > much like the ssh/config parameters.
> >
> > Net primary {
> >   nwid primary
> >   wpakey key
> >   dhcp
> > }
> > Net secondary {
> >   nwid secondary
> >   wpakey key
> >   dhcp
> > }
> >
> >
> > The manpage of hostname.if(5) does not specifically mention/allow for
> this.
> >
> >
> >
> > My work-around for this is to have all my locations/ap's use the same
> nwid
> > where possible. And where not, just use # comments in my hostname.if
> files
> > and just manually edit the appropriate entries in/out, and rerun
> > /etc/netstart.
> >
> > Is it possible to bake this in, rather than going down the wpa_supplicant
> > path as others have done? Or am I getting my hopes up for the sake of
> being
> > lazy?
> >
> > Thanks
> > Chris
>
> Various people have written various scripts.
>

My own solution for this is here:

https://github.com/mrdomino/autonet

It relies on a config.h mapping bssids / nwids to filenames in a
/etc/hostname.d directory. So you just write each config in a file like
/etc/hostname.d/., and autonet picks one to symlink to
/etc/hostname. based on the results of a scan, then defers to
netstart to bring up the network.

I've been using this daily since February. By now I've ironed out most bugs
in autonet proper, although netpref-new could still use a bit of polish.
I'd love to have more users to catch more edge cases.

I have a call to autonet in /etc/apm/resume, and another in /etc/rc (a
patch for the latter comes with the repo). I only ever have to run it
manually when I'm adding a new network.



> There is no built-in solution yet. Ideally, the wireless layer itself
> would provide some help with supporting this. E.g. via support for
> roaming, remembering networks that have been used, or other useful
> features. But at present it does not. From my point of view we don't
> have a very clear plan yet. There are various ideas floating around,
> though.
>

I'd be into something like that! That said, I think it's really awesome
that autonet is even possible on OpenBSD -- I believe that the equivalent
program in, say, Linux would be significantly more complicated.


> BTW this discussion comes up at +/- every hackathon I'm attending.
> It's not just you ;-)

5.8 Snap from Sep 24

[Leonardo Santagostini]

Hi @misc, just tested on my hardware this snap, and im very excited to get
X working again.

As soon as i can get the logs out from my pen drive (test install on
pendrive) i will submit then.

Thanks for your effort. Just wondering how to get dual booten with Win10 =)

Regards/Saludos.-

Leonardo Santagostini

Re: dig and DNSSEC

[Christian Weisgerber]

On 2015-09-26, "Todd C. Miller"  wrote:

>> As Unbound/nsd are in base now, perhaps it could be easier to get
>> drill in and drop dig ?
>
> That's a great idea.  We'd need to add nslookup(1) and host(1)
> wrappers though.

Vitaly Magerya wrote a ldns-based host(1):
http://hg.tx97.net/ldns-host

Imported by FreeBSD:
https://svnweb.freebsd.org/base/head/contrib/ldns-host/

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: wifi profiles in hostname.if

[Stefan Sperling]

On Sat, Sep 26, 2015 at 07:44:45AM -0600, Chris Lobkowicz wrote:
> Good day, I am curious if there is the possibility of adding/using multiple
> profiles or network entries, much like ~/.ssh/config ?
> 
> eg:
> 
> In /etc/hostname.iwn0
> 
> nwid primary
> wpakey key
> dhcp
> 
> ???nwid ???secondary
> wpakey key
> dhcp
> 
> 
> Is this possible? I would imagine that wrapping some sort of
> identifiers/formatting around the network information would be required,
> much like the ssh/config parameters.
> 
> Net primary {
>   nwid primary
>   wpakey key
>   dhcp
> }
> Net secondary {
>   nwid secondary
>   wpakey key
>   dhcp
> }
> 
> 
> The manpage of hostname.if(5) does not specifically mention/allow for this.
> 
> 
> 
> My work-around for this is to have all my locations/ap's use the same nwid
> where possible. And where not, just use # comments in my hostname.if files
> and just manually edit the appropriate entries in/out, and rerun
> /etc/netstart.
> 
> Is it possible to bake this in, rather than going down the wpa_supplicant
> path as others have done? Or am I getting my hopes up for the sake of being
> lazy?
> 
> Thanks
> Chris

Various people have written various scripts.

There is no built-in solution yet. Ideally, the wireless layer itself
would provide some help with supporting this. E.g. via support for
roaming, remembering networks that have been used, or other useful
features. But at present it does not. From my point of view we don't
have a very clear plan yet. There are various ideas floating around,
though.

BTW this discussion comes up at +/- every hackathon I'm attending.
It's not just you ;-)

inteldrm errors on latest amd64 snap

[Joe Gidi]

I think I just hit some more fallout of the recent inteldrm code update.

Running the latest available amd64 snapshot on my Dell Precision T1650
(Intel HD Graphics P4000), the drm code apparently fails to initialize
properly. I get this error in dmesg:

inteldrm0: msiWARNING !power_domains->domain_use_count[domain] failed at
../../../../dev/pci/drm/i915/intel_pm.c:5344

And at the end of the boot process I end up with a black screen instead of
the xdm login window. Disabling inteldrm in UKC prevents X from starting.

Full dmesg follows:

OpenBSD 5.8-current (GENERIC.MP) #1378: Thu Sep 24 20:47:17 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8454504448 (8062MB)
avail mem = 8194170880 (7814MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec350 (88 entries)
bios0: vendor Dell Inc. version "A19" date 04/21/2015
bios0: Dell Inc. Precision T1650
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR ASF! SLIC
acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) P0P1(S4) USB1(S3)
USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4)
PXSX(S4) RP02(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz, 3193.25 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz, 3192.75 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz, 3192.75 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz, 3192.75 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus -1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD01
acpivout1 at acpivideo0: DD02
acpivout2 at acpivideo0: DD03
acpivout3 at acpivideo0: DD04
acpivout4 at acpivideo0: DD05
acpivout5 at acpivideo0: DD06
acpivout6 at acpivideo0: DD07
acpivout7 at acpivideo0: DD08

Re: dig and DNSSEC

[Todd C. Miller]

On Sat, 26 Sep 2015 22:03:50 +0200, Denis Fondras wrote:

> As Unbound/nsd are in base now, perhaps it could be easier to get
> drill in and drop dig ?

That's a great idea.  We'd need to add nslookup(1) and host(1)
wrappers though.

 - todd

IPSEC with Juniper SRX220

[Alexandre Westfahl]

Hi,

I have trouble configuring ipsec with my sokeris 6501 (OBSD 5.7) with a
carrier router (Juniper).
SA seems to work well, I see packets going out on em0 and also see them on
enc0. However, the other side said nothing come but they also see SA
working and can see traffic going out.

There may be explanation for this situation:

   - I have another IPSEC tunnel on same public IP (both on em0/enc0)
   - the carrier IPs seems to be on same network so OBSD may be lost with it


*network*
dmz network (DDD.EEE.FFF.0/28)  <--(AAA.BBB.CCC.192)-->Internet<--(
GGG.HHH.III.150)-->  server (GGG.HHH.III.149)



*ipsec.conf:*
//working ipsec tunnel
ike passive esp from {192.168.10.0/24, 192.168.11.0/24 192.168.12.0/24} to
192.168.1.0/24 \
local AAA.BBB.CCC.192 \
main auth hmac-sha1 enc 3des group modp1024 lifetime 28800 \
quick auth hmac-sha1 enc aes-256 group none lifetime 28800 \
srcid "gtfwpo192" dstid "pojimusho169" \
psk secret

//carrier ipsec (not working)
ike esp from DDD.EEE.FFF.0/28 to GGG.HHH.III.149/32 \
local AAA.BBB.CCC.192 peer GGG.HHH.III.150 \
main auth hmac-sha1 enc aes group modp1024 lifetime 86400 \
quick auth hmac-sha2-256 enc aes group none lifetime 86400 \
srcid "AAA.BBB.CCC.192"   dstid "GGG.HHH.III.150" \
psk secret2


I tried to enable or disable PF and use super permissive rules but nothing
change.

Do you have some ideas on what it could be?

Thanks by advance!

Re: OpenBSD parts in Toyota Highlander

[Diana Eichert]

On Sat, 26 Sep 2015, Chad Dougherty wrote:


Oh right, demime.  Try this:
http://1drv.ms/1MQ73pA

Note the "Damien Millet" and "minidrot.org" typos ;)

   -Chad


now that just makes me want to h/w hack into a co-workers new FJ.

Todd's is most likely sudo
Damien's is most likely openssh related
Angelos's is most likey ipsec related

diana

Re: dig and DNSSEC

[Denis Fondras]

> dig and nslookup will remain in base.  Go look in our tree at the contortions
> required to keep them there, since ISC has created a mess of their own 
> libraries
> and makes the 800 lines of nslookup and 7000 lines of dig use them.  Hold your
> nose when you look, ok?
> 

As Unbound/nsd are in base now, perhaps it could be easier to get drill in and
drop dig ?