Re: Selling things through the mailing list allowed? I have compatible THIN CLIENTS for Firewall / Router appliance use Available

2018-08-29 Thread Bogdan Kulbida
I love it! Damn f.. asshole! Get him out of here!

On Wed, Aug 29, 2018 at 21:09 Theo de Raadt  wrote:

> Jacqueline Jolicoeur  wrote:
>
> > > Finally, whether intended or not, your intention to try to SELL
> > > something on this list is extraordinarily rude. Move on and go learn
> > > about this on your own. The Internet is filled with useful information.
> > > The mailing list archives also have a tremendous amount of useful info.
> >
> > Asking permission, while at the same time, performing the act.
> >
> > "Wrote a song about it. Like to hear it? Here it goes." - Calhoun Tubbs
>
> May I call people trying to sell things on misc assholes?  The guy
> trying to sell stuff on misc is an asshole. Oh sorry, I'm sorry I called
> an asshole an asshole.
>
> Right?
>
> --
---
Best regards,
Bogdan Kulbida
Founder and CEO, Konstankino LLC 
+1.802.793.8295


Re: Selling things through the mailing list allowed? I have compatible THIN CLIENTS for Firewall / Router appliance use Available

2018-08-29 Thread Theo de Raadt
Jacqueline Jolicoeur  wrote:

> > Finally, whether intended or not, your intention to try to SELL
> > something on this list is extraordinarily rude. Move on and go learn
> > about this on your own. The Internet is filled with useful information.
> > The mailing list archives also have a tremendous amount of useful info.
> 
> Asking permission, while at the same time, performing the act.
> 
> "Wrote a song about it. Like to hear it? Here it goes." - Calhoun Tubbs

May I call people trying to sell things on misc assholes?  The guy
trying to sell stuff on misc is an asshole. Oh sorry, I'm sorry I called
an asshole an asshole.

Right?



Re: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios

2018-08-29 Thread Arnaud BRAND

I stand corrected. Chris, you are right. My humble apologies.

The boot.conf file had wrong file encoding.
boot tftp:/bsd.rd was used, but not the stty and set tty com0 bits 
before.

This resulted into exactly what you described.

I could double check the same behavior on the USB key AMD64 boot (where 
my tests at 3AM where obviously wrong).
At some point in time I guess that I forgot to type theses instructions 
and just draw the wrong conclusions.


Regarding the DHCP issues with iPXE, they have been fixed in the latest 
version of the BIOS (4.8.0.3).

I didn't find it in the changelog, but it works properly now.

So, thank you Chris for your help, and sorry again.

I won't make the same mistake twice and rush things, time to go to bed 
:-)


'night everyone


Le 2018-08-30 01:38, Arnaud BRAND a écrit :

Sorry, no. If you forget this, the board won't reboot, it just won't
show what it is doing.
Also, this was done (set in the tftp boot.conf).
I can replicate at will just by swapping between i386 and amd64
pxeboot and bsd.rd files on the tftp server, without touching anything
else (leaving boot.conf and random.seed alone).

-- Message d'origine --
De: "Chris Cappuccio" 
À: "Arnaud BRAND" 
Cc : misc@openbsd.org
Envoyé : 30/08/2018 01:25:13
Objet : Re: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated
in the bios


This sounds exactly like what happens when you don't do this at the
boot> prompt:

stty com0 115220
set tty com0

Arnaud BRAND [arnaud.brand--o...@tib.cc] wrote:

Good evening list,

I recently bought a PCEngine APU4B4 
https://www.pcengines.ch/apu4b4.htm

AMD GX-412TC, 1 GHz quad Jaguar core / 64 bit and AES-NI / 4GB RAM

I had absolutely no problem booting and installing i386 OpenBSD 6.3 
and

snapshots over PXE.
With the AMD64 version, it wouldn't boot, it crashed immeditely after 
the

"entry point at 0x1000158" line and rebooted.

I found Neels' page (http://hofmeyr.de/OpenBSD%20on%20APU4/,  BTW 
thanks

Neels) who had no problem installing AMD64 from USB.
So I tried that, both with 6.3 and snapshot, but it ended the same.
To be precise, the "8" at the end of the "entry point at" line never 
shows

up.
The reboot/reset occurs after the 5 character.

I was beginning to think that my APU was broken, but decided to try 
again,

this time disabling the PXE capability in the bios.
It worked immediately (like usual with OpenBSD).

So, long story short, AMD64 kernels won't boot on APU4B4 when PXE 
boot is

enabled in the BIOS.

I don't know if there's anything to fix in OpenBSD as the embedded 
iPXE

seems a bit buggy.
I reckon this might be the cause of the problem.

For people who experience difficulties wiht PXE booting (i386), try 
the

following :
- break out to iPXE shell
- run "dhcp" until iPXE picks up an address
- and then resume PXE booting process by typing "autoboot"


Arnaud






Re: Can't Log In, New Installation

2018-08-29 Thread Jacqueline Jolicoeur
> How can I log in or bypass the login prompt?

https://www.openbsd.org/faq/faq8.html#LostPW



Re: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios

2018-08-29 Thread Arnaud BRAND
Sorry, no. If you forget this, the board won't reboot, it just won't 
show what it is doing.

Also, this was done (set in the tftp boot.conf).
I can replicate at will just by swapping between i386 and amd64 pxeboot 
and bsd.rd files on the tftp server, without touching anything else 
(leaving boot.conf and random.seed alone).


-- Message d'origine --
De: "Chris Cappuccio" 
À: "Arnaud BRAND" 
Cc : misc@openbsd.org
Envoyé : 30/08/2018 01:25:13
Objet : Re: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in 
the bios



This sounds exactly like what happens when you don't do this at the
boot> prompt:

stty com0 115220
set tty com0

Arnaud BRAND [arnaud.brand--o...@tib.cc] wrote:

Good evening list,

I recently bought a PCEngine APU4B4 
https://www.pcengines.ch/apu4b4.htm

AMD GX-412TC, 1 GHz quad Jaguar core / 64 bit and AES-NI / 4GB RAM

I had absolutely no problem booting and installing i386 OpenBSD 6.3 
and

snapshots over PXE.
With the AMD64 version, it wouldn't boot, it crashed immeditely after 
the

"entry point at 0x1000158" line and rebooted.

I found Neels' page (http://hofmeyr.de/OpenBSD%20on%20APU4/,  BTW 
thanks

Neels) who had no problem installing AMD64 from USB.
So I tried that, both with 6.3 and snapshot, but it ended the same.
To be precise, the "8" at the end of the "entry point at" line never 
shows

up.
The reboot/reset occurs after the 5 character.

I was beginning to think that my APU was broken, but decided to try 
again,

this time disabling the PXE capability in the bios.
It worked immediately (like usual with OpenBSD).

So, long story short, AMD64 kernels won't boot on APU4B4 when PXE boot 
is

enabled in the BIOS.

I don't know if there's anything to fix in OpenBSD as the embedded 
iPXE

seems a bit buggy.
I reckon this might be the cause of the problem.

For people who experience difficulties wiht PXE booting (i386), try 
the

following :
- break out to iPXE shell
- run "dhcp" until iPXE picks up an address
- and then resume PXE booting process by typing "autoboot"


Arnaud






Re: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios

2018-08-29 Thread Chris Cappuccio
Chris Cappuccio [ch...@nmedia.net] wrote:
> This sounds exactly like what happens when you don't do this at the
> boot> prompt:
> 
> stty com0 115220

stty com0 115200 of course



Re: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios

2018-08-29 Thread Chris Cappuccio
This sounds exactly like what happens when you don't do this at the
boot> prompt:

stty com0 115220
set tty com0

Arnaud BRAND [arnaud.brand--o...@tib.cc] wrote:
> Good evening list,
> 
> I recently bought a PCEngine APU4B4 https://www.pcengines.ch/apu4b4.htm
> AMD GX-412TC, 1 GHz quad Jaguar core / 64 bit and AES-NI / 4GB RAM
> 
> I had absolutely no problem booting and installing i386 OpenBSD 6.3 and
> snapshots over PXE.
> With the AMD64 version, it wouldn't boot, it crashed immeditely after the
> "entry point at 0x1000158" line and rebooted.
> 
> I found Neels' page (http://hofmeyr.de/OpenBSD%20on%20APU4/,  BTW thanks
> Neels) who had no problem installing AMD64 from USB.
> So I tried that, both with 6.3 and snapshot, but it ended the same.
> To be precise, the "8" at the end of the "entry point at" line never shows
> up.
> The reboot/reset occurs after the 5 character.
> 
> I was beginning to think that my APU was broken, but decided to try again,
> this time disabling the PXE capability in the bios.
> It worked immediately (like usual with OpenBSD).
> 
> So, long story short, AMD64 kernels won't boot on APU4B4 when PXE boot is
> enabled in the BIOS.
> 
> I don't know if there's anything to fix in OpenBSD as the embedded iPXE
> seems a bit buggy.
> I reckon this might be the cause of the problem.
> 
> For people who experience difficulties wiht PXE booting (i386), try the
> following :
> - break out to iPXE shell
> - run "dhcp" until iPXE picks up an address
> - and then resume PXE booting process by typing "autoboot"
> 
> 
> Arnaud



Re: Can't Log In, New Installation

2018-08-29 Thread Gianguido Sorà
Try the "root" user.

The password should be the one you selected during the setup process.


On Thu, Aug 30, 2018, 1:15 AM Heaven Hodges  wrote:

> I'm a new OpenBSD user. I've installed it as a guest OS in gnome-boxes
> (host OS is Debian Stretch). I chose to not create a user account, but I
> did input a password. When OpenBSD starts up, I'm presented with a login
> prompt. I have no idea what the login is. How can I log in or bypass the
> login prompt?
>
> --
> Thank you for your time.
>
>


Can't Log In, New Installation

2018-08-29 Thread Heaven Hodges
I'm a new OpenBSD user. I've installed it as a guest OS in gnome-boxes 
(host OS is Debian Stretch). I chose to not create a user account, but I 
did input a password. When OpenBSD starts up, I'm presented with a login 
prompt. I have no idea what the login is. How can I log in or bypass the 
login prompt?


--
Thank you for your time.



PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios

2018-08-29 Thread Arnaud BRAND

Good evening list,

I recently bought a PCEngine APU4B4 https://www.pcengines.ch/apu4b4.htm
AMD GX-412TC, 1 GHz quad Jaguar core / 64 bit and AES-NI / 4GB RAM

I had absolutely no problem booting and installing i386 OpenBSD 6.3 and 
snapshots over PXE.
With the AMD64 version, it wouldn't boot, it crashed immeditely after 
the "entry point at 0x1000158" line and rebooted.


I found Neels' page (http://hofmeyr.de/OpenBSD%20on%20APU4/,  BTW thanks 
Neels) who had no problem installing AMD64 from USB.

So I tried that, both with 6.3 and snapshot, but it ended the same.
To be precise, the "8" at the end of the "entry point at" line never 
shows up.

The reboot/reset occurs after the 5 character.

I was beginning to think that my APU was broken, but decided to try 
again, this time disabling the PXE capability in the bios.

It worked immediately (like usual with OpenBSD).

So, long story short, AMD64 kernels won't boot on APU4B4 when PXE boot 
is enabled in the BIOS.


I don't know if there's anything to fix in OpenBSD as the embedded iPXE 
seems a bit buggy.

I reckon this might be the cause of the problem.

For people who experience difficulties wiht PXE booting (i386), try the 
following :

- break out to iPXE shell
- run "dhcp" until iPXE picks up an address
- and then resume PXE booting process by typing "autoboot"


Arnaud



Re: Selling things through the mailing list allowed? I have compatible THIN CLIENTS for Firewall / Router appliance use Available

2018-08-29 Thread Jacqueline Jolicoeur
> Finally, whether intended or not, your intention to try to SELL
> something on this list is extraordinarily rude. Move on and go learn
> about this on your own. The Internet is filled with useful information.
> The mailing list archives also have a tremendous amount of useful info.

Asking permission, while at the same time, performing the act.

"Wrote a song about it. Like to hear it? Here it goes." - Calhoun Tubbs



Re: Selling things through the mailing list allowed? I have compatible THIN CLIENTS for Firewall / Router appliance use Available

2018-08-29 Thread Chris Bennett
On Wed, Aug 29, 2018 at 06:09:39PM +, Z Ero wrote:
> Hi Stuart,
> 
> Thanks for the respectful reply. I am a little bewildered by the
> degree of unwarranted hostility the original post met, but whatever,
> when in Rome... I believe as of now most commercially available small
> business or home LAN routers / WAN gateways are 32 bit MIPS or ARM
> based (as opposed to enterprise, c.f. the 64 bit MIPS Octeon Edge
> Router). I understand your comment about the larger 64 bit address
> space being more secure because it is such a vaster space better able
> to be randomised, but I am not sure how much this really matters
> practically. For example, have journal studies shown that in the real
> world 32 bit routers are actually hacked or 'pwned' at a higher rate
> (after accounting for market share) than 64 bit based machines?
> 

I highly recommend you read the full site at https://www.openbsd.org
If the developers of OpenBSD say something about security, well you
better believe it.
Note: Two, not two thousand, bugs in more than 20 years that have
resulted in remote access being possible.
I sleep very well each night knowing that, unless someone has physically
in person attacked my server, I have no problems.

I also recommend that you pay close attention to the refusal to allow
anyone who is, was or used to be part of the USA to contribute to
anything related to cryptography. Look up and pay attention to all of
the past and continuing attacks on cryptography that the USA continues.

Finally, whether intended or not, your intention to try to SELL
something on this list is extraordinarily rude. Move on and go learn
about this on your own. The Internet is filled with useful information.
The mailing list archives also have a tremendous amount of useful info.

Perhaps reading the source code, which is freely available, deals with
all of these issues. If you can't program C, learn it.

Chris Bennett




Re: DNS (UNBOUND) + PF ISSUE

2018-08-29 Thread Stuart Henderson
On 2018-08-29, NN  wrote:
> Hi,
>
> All is working for me with new ACL Rule:
>
>      access-control: 0.0.0.0/0 allow
>
> Many Thanks Solène Rapenne !
>
> ISSUE is closed.
>
> P.S.
>
> Why opening unbound to the internet is a bad idea ???

Because your resolver *will* be found and quite likely people will send
packets with a bogus source address, causing you to spew crap at the
poor victim whose address was spoofed.

Also they won't care if your upstream bandwidth is flooded.

Turn it off again now and restrict it to your legitimate users' addresses.

People running actual public resolvers open to the world have to put a lot
of work into abuse mitigation.

>     # interface: 188.192.103.156

confirmed!



Re: Has anyone got OpenBSD Arm to run on the Marvel Espresso Bin?

2018-08-29 Thread Z Ero
How about in August? Is it supported now?

Thanks

On 3/28/18, Patrick Harper  wrote:
> Armada 3700LP chipset not supported at present.
>
> --
>   Patrick Harper
>   paia...@fastmail.com
>
> On Sun, 25 Mar 2018, at 22:11, Z Ero wrote:
>> If yes is the on board ethernet switch supported? What wifi cards are
>> supported in the miniPCIe slot?
>>
>
>



Re: Selling things through the mailing list allowed? I have compatible THIN CLIENTS for Firewall / Router appliance use Available

2018-08-29 Thread Z Ero
Hi Stuart,

Thanks for the respectful reply. I am a little bewildered by the
degree of unwarranted hostility the original post met, but whatever,
when in Rome... I believe as of now most commercially available small
business or home LAN routers / WAN gateways are 32 bit MIPS or ARM
based (as opposed to enterprise, c.f. the 64 bit MIPS Octeon Edge
Router). I understand your comment about the larger 64 bit address
space being more secure because it is such a vaster space better able
to be randomised, but I am not sure how much this really matters
practically. For example, have journal studies shown that in the real
world 32 bit routers are actually hacked or 'pwned' at a higher rate
(after accounting for market share) than 64 bit based machines?

On 8/28/18, Stuart Henderson  wrote:
> On 2018/08/28 18:21, Z Ero wrote:
>> Hello Stuart,
>>
>> Yes it is correct that the Intel atom is 32 bit i386. Just out of
>> curiosity why would you not recommend it for a router / internet
>> appliance application? Not everybody needs 10G Ethernet or AC wifi on
>> their home or office LAN. Is it a security issue, a performance issue,
>> or a lack of developer attention issue (i.e. there are more eyes /
>> there is more focus on the 64 bit code base than the 32 bit code base
>> at this time)?
>>
>> Here is the Intel info on these N280 processors in these thin clients.
>> https://ark.intel.com/products/41411/Intel-Atom-Processor-N280-512K-Cache-1_66-GHz-667-MHz-FSB
>>
>> If it is a perfomance issue I beg to differ. This machine more than
>> capable for normal LAN use for a home or small business assuming one
>> is not generating massive continuous traffic. Compare to microtik
>> routers, for example. Many if not most routers are 32 bit MIPS based
>> even today. If it is a security issue due to W^X or something about
>> memory / execution protection are there not similar issues on other
>> platforms used in routers such as MIPS or not? If your firewall rules
>> / open ports are prudent shouldn't that prevent remote execution
>> anyway? Is the Atom effected by Meltdown?
>>
>> I use this machine myself as my home router, although I guess maybe
>> that is not saying much because I also use a ten year old Thinkpad as
>> my daily driver machine...kind of stuck in 2008 I guess lol. But I
>> really don't think most home or business applications really need
>> anything more than 1G ethernet or 802.11n wireless it is like 1080p vs
>> 4k in HD TV. At a certain point the marginal returns to increased
>> capability diminish, and diminish at an accelerating rate.
>>
>> Last year I was using a 128mb RAM 200 mhz Soekris based router. I
>> could watch HD Youtube videos on that without issue.
>>
>> Not trying to flame. Just conversing.
>>
>>
>> On 8/28/18, Stuart Henderson  wrote:
>> > On 2018-08-28, Z Ero  wrote:
>> >> I have a bunch (about 50) of atom based HP T5740 thin clients that
>> >> work great as an OpenBSD based VPN gateway, router, firewall, print
>> >> server, wifi or other network appliance.
>> >
>> > Those are i386 (32-bit) only aren't they?
>> >
>> > I think I would not recommend i386 for any new installations
>> > at this point ..
>> >
>> >
>> >
>
> In recent times the Intel compatible architectures have proved to be
> quite high-maintenance. I can't imagine it will have been much fun for
> people working on fixes for the various speculative execution related
> bugs to do that on one architecture let alone porting fixes to a second,
> especially when as time goes on there are fewer really useful x86
> machines that are 32-bit only, and at the same time other architectures
> are getting a lot more interesting with respect to performance.
>
> Security-wise disregarding any other features, the small address space
> is a problem by itself. There's little room for allocation randomness,
> the % of the address space that can be left unmapped is minuscule
> compared to 64-bit architectures.
>
> Ports-wise the small address space is also a problem. Things like browsers
> and rust need various hacks to get them to build at all (rust is now a
> dependency of large parts of the ports tree via librsvg - currently the
> old C version of this is still viable but that won't last). Developers
> of this type of software generally expect cross-compiling from a larger
> architecture for 32-bit systems, which is not how OpenBSD works.
>
> Given the rather limited number of developers working on low-level parts
> of the system I think what remaining interest there is, is going to move
> elsewhere.
>
> For small routers etc with limited packets-per-second flows those
> machines just about work for now, but it's getting tight and I'd rather
> not build anything new on something which is already on borrowed time
> when I can make a fair guess that it's going to need tearing out before
> too much longer.
>
>



Re: BFD Status ?

2018-08-29 Thread Peter Hessler
On 2018 Aug 29 (Wed) at 18:05:50 +0200 (+0200), Arnaud BRAND wrote:
:Hello,
:
:I read Peter's presentation from BSDCan 2016 about BFD on OpenBSD.
:I could not find anything by googling.
:I looked at the codeand it seems to be there, albeit subjected to the BFD
:kernel option.
:
:Does it mean that the feature is not production ready yet ?
:
:How can I try it or help improve it ?
:
:Thanks for your help !
:Arnaud
:

Hi Arnaud

Yes, the BFD feature is not yet production ready.  There is still some
cleanup that needs to happen, and I plan to look at this at the upcoming
hackathon.

-peter


-- 
If you can lead it to water and force it to drink, it isn't a horse.



BFD Status ?

2018-08-29 Thread Arnaud BRAND

Hello,

I read Peter's presentation from BSDCan 2016 about BFD on OpenBSD.
I could not find anything by googling.
I looked at the codeand it seems to be there, albeit subjected to the 
BFD kernel option.


Does it mean that the feature is not production ready yet ?

How can I try it or help improve it ?

Thanks for your help !
Arnaud



Re: sbcl vs uvm

2018-08-29 Thread Manuel Giraud
Gregor Best  writes:

> that looks like a stack space exhaustion. I've had something similar
> while compiling
> OCaml's merlin package. I solved it with the brutest of forces by adding
>
> :stacksize=infinity:\

Thank you for the hint but this does not work for sbcl (w/ thread)
compilation. AFAIU, for each thread sbcl mmap a rather big area (about
5MB) as MAP_STACK. Don't know if it is usual?
-- 
Manuel Giraud



Re: DNS (UNBOUND) + PF ISSUE

2018-08-29 Thread NN

Hi,

All is working for me with new ACL Rule:

    access-control: 0.0.0.0/0 allow

Many Thanks Solène Rapenne !

ISSUE is closed.

P.S.

Why opening unbound to the internet is a bad idea ???

Thx.

On 08/29/18 12:51, Solène Rapenne wrote:

Le 2018-08-29 12:41, NN a écrit :

Hi,

many thanks for your quick answer,
I try to  use your PF rule, and got the same answer from my DNS:

    ...
    >> WARNING: recursion requested but not available
    ...

I need the DNS request RULE's for my PF
Any ideas?

BR
deface


On 08/29/18 12:34, Arnaud BRAND wrote:

Le 2018-08-29 11:57, NN a écrit :

*Hi all,*

*Its my first topic here =)
*

*Please help me investigate DNS+PF issue. **
*

*I have 2 VM on OpenBSD 6.3:*

*    VM#1 - Router with PF, IP:192.168.50.1*

*    VM#2 - DNS (as unbound), IP:192.168.50.2**
*

*here is my pf.conf on VM#1:*

    int_if="{ vether0 re0 }"
    set block-policy drop
    set loginterface egress
    set skip on lo0
    match in all scrub (no-df random-id max-mss 1440)
    match out on egress inet from !(egress:network) to any nat-to 
(egress:0)

    pass out quick inet
    pass in on $int_if inet
    pass in on egress inet proto { tcp, udp } from any to (egress)
port 53 rdr-to 192.168.50.2

*I try to check how my Unbound DNS VM#2 working: *

*# dig @192.168.50.1 google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @192.168.50.1 google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2704
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, 
ADDITIONAL: 0


    ;; QUESTION SECTION:
    ;google.com.    IN  A

    ;; ANSWER SECTION:
    google.com. 299 IN  A 172.217.21.110

    ;; Query time: 35 msec
    ;; SERVER: 192.168.50.1#53(192.168.178.100)
    ;; WHEN: Wed Aug 29 11:35:57 2018
    ;; MSG SIZE  rcvd: 44

*Looks good. But if I try to do it out of my local net ... with:*

*# dig @external_IP google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @external_IP google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24861
    ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available <<<   <<<   
<<< ???


    ;; SERVER: external_IP#53
    ;; WHEN: Wed Aug 29 11:30:50 2018
    ;; MSG SIZE  rcvd: 12

*I think that my PF config is wrong. Please help to investigate my 
issue.*


*P.S: unbound.conf is here ...*

server:
    # interface: 188.192.103.156
    interface: 192.168.50.1
    interface: 127.0.0.1
    interface: ::1
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    access-control: ::1 allow
    access-control: 192.168.1.0/24 allow
    access-control: 192.168.50.0/24 allow
    access-control: 192.168.178.0/24 allow
    do-not-query-localhost: no
    hide-identity: yes
    hide-version: yes
    port: 53

remote-control:
    control-enable: yes
    control-use-cert: no
    control-interface: /var/run/unbound.sock

forward-zone:
    name: "."
    forward-addr: 192.168.178.1 # fritz.box
    forward-addr: 8.8.8.8 # google.com
    forward-addr: 2001:4860:4860:: # google.com v6
    forward-first: yes # try direct if forwarder fails

Sorry for my English,

BR

deface


Eh... something's off in your configs.
You wrote:
 DNS (as unbound), IP:192.168.50.2
But unbound.conf contains :
 interface: 192.168.50.1
May be it's not used and redirected to 127.0.0.1 ?

Anyway, are you trying to match DNS requests origintaing from the 
inside network and going to public DNS through egress and then 
redirecting these requests to unbound ?

If so, I think you might want to add this rule :
pass in on $int_if inet proto { tcp, udp } from !$UNBOUND_SERVER to 
any  port 53 rdr-to $UNBOUND_SERVER




you have to allow your IP in unbound.conf, look at your rules:

 access-control: 0.0.0.0/0 refuse
 access-control: 127.0.0.0/8 allow
 access-control: ::0/0 refuse
 access-control: ::1 allow
 access-control: 192.168.1.0/24 allow
 access-control: 192.168.50.0/24 allow
 access-control: 192.168.178.0/24 allow

if you are not in the last 3 ranges specified, you won't be allowed
to make a request.

Note: Opening unbound to the internet is a bad idea.





Re: DNS (UNBOUND) + PF ISSUE

2018-08-29 Thread Arnaud BRAND

Le 2018-08-29 11:57, NN a écrit :

*Hi all,*

*Its my first topic here =)
*

*Please help me investigate DNS+PF issue. **
*

*I have 2 VM on OpenBSD 6.3:*

*    VM#1 - Router with PF, IP:192.168.50.1*

*    VM#2 - DNS (as unbound), IP:192.168.50.2**
*

*here is my pf.conf on VM#1:*

    int_if="{ vether0 re0 }"
    set block-policy drop
    set loginterface egress
    set skip on lo0
    match in all scrub (no-df random-id max-mss 1440)
    match out on egress inet from !(egress:network) to any nat-to 
(egress:0)

    pass out quick inet
    pass in on $int_if inet
    pass in on egress inet proto { tcp, udp } from any to (egress)
port 53 rdr-to 192.168.50.2

*I try to check how my Unbound DNS VM#2 working: *

*# dig @192.168.50.1 google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @192.168.50.1 google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2704
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 
0


    ;; QUESTION SECTION:
    ;google.com.    IN  A

    ;; ANSWER SECTION:
    google.com. 299 IN  A 172.217.21.110

    ;; Query time: 35 msec
    ;; SERVER: 192.168.50.1#53(192.168.178.100)
    ;; WHEN: Wed Aug 29 11:35:57 2018
    ;; MSG SIZE  rcvd: 44

*Looks good. But if I try to do it out of my local net ... with:*

*# dig @external_IP google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @external_IP google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24861
    ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available <<<   <<<   <<< 
???


    ;; SERVER: external_IP#53
    ;; WHEN: Wed Aug 29 11:30:50 2018
    ;; MSG SIZE  rcvd: 12

*I think that my PF config is wrong. Please help to investigate my 
issue.*


*P.S: unbound.conf is here ...*

server:
    # interface: 188.192.103.156
    interface: 192.168.50.1
    interface: 127.0.0.1
    interface: ::1
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    access-control: ::1 allow
    access-control: 192.168.1.0/24 allow
    access-control: 192.168.50.0/24 allow
    access-control: 192.168.178.0/24 allow
    do-not-query-localhost: no
    hide-identity: yes
    hide-version: yes
    port: 53

remote-control:
    control-enable: yes
    control-use-cert: no
    control-interface: /var/run/unbound.sock

forward-zone:
    name: "."
    forward-addr: 192.168.178.1 # fritz.box
    forward-addr: 8.8.8.8 # google.com
    forward-addr: 2001:4860:4860:: # google.com v6
    forward-first: yes # try direct if forwarder fails

Sorry for my English,

BR

deface


Eh... something's off in your configs.
You wrote:
 DNS (as unbound), IP:192.168.50.2
But unbound.conf contains :
 interface: 192.168.50.1
May be it's not used and redirected to 127.0.0.1 ?

Anyway, are you trying to match DNS requests origintaing from the inside 
network and going to public DNS through egress and then redirecting 
these requests to unbound ?

If so, I think you might want to add this rule :
pass in on $int_if inet proto { tcp, udp } from !$UNBOUND_SERVER to any  
port 53 rdr-to $UNBOUND_SERVER




Re: sbcl vs uvm

2018-08-29 Thread Gregor Best
Hi Manuel,

> [...]
> trap [sbcl]46252/177072 type 6: sp 2f76e78b8 not inside 2f74f8000-2f76e8000
> [...]

that looks like a stack space exhaustion. I've had something similar while 
compiling
OCaml's merlin package. I solved it with the brutest of forces by adding

:stacksize=infinity:\

to the limits for `staff` in my `/etc/login.conf`. Some more fine tuned stack 
size
should do the trick just as well.

-- 
Gregor



Re: DNS (UNBOUND) + PF ISSUE

2018-08-29 Thread Solène Rapenne

Le 2018-08-29 12:41, NN a écrit :

Hi,

many thanks for your quick answer,
I try to  use your PF rule, and got the same answer from my DNS:

    ...
    >> WARNING: recursion requested but not available
    ...

I need the DNS request RULE's for my PF
Any ideas?

BR
deface


On 08/29/18 12:34, Arnaud BRAND wrote:

Le 2018-08-29 11:57, NN a écrit :

*Hi all,*

*Its my first topic here =)
*

*Please help me investigate DNS+PF issue. **
*

*I have 2 VM on OpenBSD 6.3:*

*    VM#1 - Router with PF, IP:192.168.50.1*

*    VM#2 - DNS (as unbound), IP:192.168.50.2**
*

*here is my pf.conf on VM#1:*

    int_if="{ vether0 re0 }"
    set block-policy drop
    set loginterface egress
    set skip on lo0
    match in all scrub (no-df random-id max-mss 1440)
    match out on egress inet from !(egress:network) to any nat-to 
(egress:0)

    pass out quick inet
    pass in on $int_if inet
    pass in on egress inet proto { tcp, udp } from any to (egress)
port 53 rdr-to 192.168.50.2

*I try to check how my Unbound DNS VM#2 working: *

*# dig @192.168.50.1 google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @192.168.50.1 google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2704
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, 
ADDITIONAL: 0


    ;; QUESTION SECTION:
    ;google.com.    IN  A

    ;; ANSWER SECTION:
    google.com. 299 IN  A 172.217.21.110

    ;; Query time: 35 msec
    ;; SERVER: 192.168.50.1#53(192.168.178.100)
    ;; WHEN: Wed Aug 29 11:35:57 2018
    ;; MSG SIZE  rcvd: 44

*Looks good. But if I try to do it out of my local net ... with:*

*# dig @external_IP google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @external_IP google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24861
    ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available <<<   <<<   <<< 
???


    ;; SERVER: external_IP#53
    ;; WHEN: Wed Aug 29 11:30:50 2018
    ;; MSG SIZE  rcvd: 12

*I think that my PF config is wrong. Please help to investigate my 
issue.*


*P.S: unbound.conf is here ...*

server:
    # interface: 188.192.103.156
    interface: 192.168.50.1
    interface: 127.0.0.1
    interface: ::1
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    access-control: ::1 allow
    access-control: 192.168.1.0/24 allow
    access-control: 192.168.50.0/24 allow
    access-control: 192.168.178.0/24 allow
    do-not-query-localhost: no
    hide-identity: yes
    hide-version: yes
    port: 53

remote-control:
    control-enable: yes
    control-use-cert: no
    control-interface: /var/run/unbound.sock

forward-zone:
    name: "."
    forward-addr: 192.168.178.1 # fritz.box
    forward-addr: 8.8.8.8 # google.com
    forward-addr: 2001:4860:4860:: # google.com v6
    forward-first: yes # try direct if forwarder fails

Sorry for my English,

BR

deface


Eh... something's off in your configs.
You wrote:
 DNS (as unbound), IP:192.168.50.2
But unbound.conf contains :
 interface: 192.168.50.1
May be it's not used and redirected to 127.0.0.1 ?

Anyway, are you trying to match DNS requests origintaing from the 
inside network and going to public DNS through egress and then 
redirecting these requests to unbound ?

If so, I think you might want to add this rule :
pass in on $int_if inet proto { tcp, udp } from !$UNBOUND_SERVER to 
any  port 53 rdr-to $UNBOUND_SERVER




you have to allow your IP in unbound.conf, look at your rules:

 access-control: 0.0.0.0/0 refuse
 access-control: 127.0.0.0/8 allow
 access-control: ::0/0 refuse
 access-control: ::1 allow
 access-control: 192.168.1.0/24 allow
 access-control: 192.168.50.0/24 allow
 access-control: 192.168.178.0/24 allow

if you are not in the last 3 ranges specified, you won't be allowed
to make a request.

Note: Opening unbound to the internet is a bad idea.



Re: DNS (UNBOUND) + PF ISSUE

2018-08-29 Thread NN

Hi,

many thanks for your quick answer,
I try to  use your PF rule, and got the same answer from my DNS:

    ...
    >> WARNING: recursion requested but not available
    ...

I need the DNS request RULE's for my PF
Any ideas?

BR
deface


On 08/29/18 12:34, Arnaud BRAND wrote:

Le 2018-08-29 11:57, NN a écrit :

*Hi all,*

*Its my first topic here =)
*

*Please help me investigate DNS+PF issue. **
*

*I have 2 VM on OpenBSD 6.3:*

*    VM#1 - Router with PF, IP:192.168.50.1*

*    VM#2 - DNS (as unbound), IP:192.168.50.2**
*

*here is my pf.conf on VM#1:*

    int_if="{ vether0 re0 }"
    set block-policy drop
    set loginterface egress
    set skip on lo0
    match in all scrub (no-df random-id max-mss 1440)
    match out on egress inet from !(egress:network) to any nat-to 
(egress:0)

    pass out quick inet
    pass in on $int_if inet
    pass in on egress inet proto { tcp, udp } from any to (egress)
port 53 rdr-to 192.168.50.2

*I try to check how my Unbound DNS VM#2 working: *

*# dig @192.168.50.1 google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @192.168.50.1 google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2704
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;google.com.    IN  A

    ;; ANSWER SECTION:
    google.com. 299 IN  A 172.217.21.110

    ;; Query time: 35 msec
    ;; SERVER: 192.168.50.1#53(192.168.178.100)
    ;; WHEN: Wed Aug 29 11:35:57 2018
    ;; MSG SIZE  rcvd: 44

*Looks good. But if I try to do it out of my local net ... with:*

*# dig @external_IP google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @external_IP google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24861
    ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available <<<   <<<   <<< 
???


    ;; SERVER: external_IP#53
    ;; WHEN: Wed Aug 29 11:30:50 2018
    ;; MSG SIZE  rcvd: 12

*I think that my PF config is wrong. Please help to investigate my 
issue.*


*P.S: unbound.conf is here ...*

server:
    # interface: 188.192.103.156
    interface: 192.168.50.1
    interface: 127.0.0.1
    interface: ::1
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    access-control: ::1 allow
    access-control: 192.168.1.0/24 allow
    access-control: 192.168.50.0/24 allow
    access-control: 192.168.178.0/24 allow
    do-not-query-localhost: no
    hide-identity: yes
    hide-version: yes
    port: 53

remote-control:
    control-enable: yes
    control-use-cert: no
    control-interface: /var/run/unbound.sock

forward-zone:
    name: "."
    forward-addr: 192.168.178.1 # fritz.box
    forward-addr: 8.8.8.8 # google.com
    forward-addr: 2001:4860:4860:: # google.com v6
    forward-first: yes # try direct if forwarder fails

Sorry for my English,

BR

deface


Eh... something's off in your configs.
You wrote:
 DNS (as unbound), IP:192.168.50.2
But unbound.conf contains :
 interface: 192.168.50.1
May be it's not used and redirected to 127.0.0.1 ?

Anyway, are you trying to match DNS requests origintaing from the 
inside network and going to public DNS through egress and then 
redirecting these requests to unbound ?

If so, I think you might want to add this rule :
pass in on $int_if inet proto { tcp, udp } from !$UNBOUND_SERVER to 
any  port 53 rdr-to $UNBOUND_SERVER






DNS (UNBOUND) + PF ISSUE

2018-08-29 Thread NN

*Hi all,*

*Its my first topic here =)
*

*Please help me investigate DNS+PF issue. **
*

*I have 2 VM on OpenBSD 6.3:*

*    VM#1 - Router with PF, IP:192.168.50.1*

*    VM#2 - DNS (as unbound), IP:192.168.50.2**
*

*here is my pf.conf on VM#1:*

    int_if="{ vether0 re0 }"
    set block-policy drop
    set loginterface egress
    set skip on lo0
    match in all scrub (no-df random-id max-mss 1440)
    match out on egress inet from !(egress:network) to any nat-to 
(egress:0)

    pass out quick inet
    pass in on $int_if inet
    pass in on egress inet proto { tcp, udp } from any to (egress) port 
53 rdr-to 192.168.50.2


*I try to check how my Unbound DNS VM#2 working: *

*# dig @192.168.50.1 google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @192.168.50.1 google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2704
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;google.com.    IN  A

    ;; ANSWER SECTION:
    google.com. 299 IN  A 172.217.21.110

    ;; Query time: 35 msec
    ;; SERVER: 192.168.50.1#53(192.168.178.100)
    ;; WHEN: Wed Aug 29 11:35:57 2018
    ;; MSG SIZE  rcvd: 44

*Looks good. But if I try to do it out of my local net ... with:*

*# dig @external_IP google.com*

    ; <<>> DiG 9.4.2-P2 <<>> @external_IP google.com
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24861
    ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available <<<   <<<   <<< ???

    ;; SERVER: external_IP#53
    ;; WHEN: Wed Aug 29 11:30:50 2018
    ;; MSG SIZE  rcvd: 12

*I think that my PF config is wrong. Please help to investigate my issue.*

*P.S: unbound.conf is here ...*

server:
    # interface: 188.192.103.156
    interface: 192.168.50.1
    interface: 127.0.0.1
    interface: ::1
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    access-control: ::1 allow
    access-control: 192.168.1.0/24 allow
    access-control: 192.168.50.0/24 allow
    access-control: 192.168.178.0/24 allow
    do-not-query-localhost: no
    hide-identity: yes
    hide-version: yes
    port: 53

remote-control:
    control-enable: yes
    control-use-cert: no
    control-interface: /var/run/unbound.sock

forward-zone:
    name: "."
    forward-addr: 192.168.178.1 # fritz.box
    forward-addr: 8.8.8.8 # google.com
    forward-addr: 2001:4860:4860:: # google.com v6
    forward-first: yes # try direct if forwarder fails

Sorry for my English,

BR

deface




sbcl vs uvm

2018-08-29 Thread Manuel Giraud
Hi,

I used to build current sbcl (common lisp compiler) with threads support
on -current amd64. For maybe 2/3 month, it does not compile anymore. On
sbcl self test for threads, I get the following strange dmesg entry:

trap [sbcl]46252/177072 type 6: sp 2f76e78b8 not inside 2f74f8000-2f76e8000

My question is: should I look for sbcl doing something nasty here or
should I look for a bug in uvm?

(I've cc'ed Josh because he has taken care of upstream patch after the
MAP_STACK introduction)
-- 
Manuel Giraud