Re: Installer sucks ! (Re: OpenBSD on VMware ESXi)
The web console copy/paste functionnality is a VMWare limitation. I don't think it ever worked. It think would require the console to emulate/simulate key presses depending on what is pasted and somehow assuming what the VM keymap is. I didn't try to install 6.5 on ESXI yet, but I definitely installed 6.4. On a lot of ESXi versions from 5.5 to 6.7. So you could try to install 6.4 to see if you have the same problems ? Never experienced your problems, although I experienced some strange behaviors with disklabeling (if I remember well sometimes it couldn't install the bootloader or wouldn't boot after install). They were resolved by : - dropping to the shell at the start of the install - fdisk -i - return to the install and proceed normally Never tried to install a custom label on ESXi, but did it sucessfully on virtualbox with 6.5 without any issue (not even needed to fdisk -i). What ESXi version are you running ? What disk controller are you showing to OpenBSD ? AB Le 2019-05-23 12:17, Roderick a écrit : On Thu, 23 May 2019, Otto Moerbeek wrote: You must be doing something wrong. Since it installer surely leats you use a custom label. But since you are not showgin waht you did and you start insulting remarks, you won't get much help. Excuse me, although my words was not flowers, they were no insult. And there was no intention to insult, but it is realy nerving to deal with this web console. I cannot even do "copy and paste" in it for showing what I did. That is why I described it. It is sure a bug there. As said: it is not my previous experience with OpenBSD. There is sure a bug there: (1) if you installed a label before, the installer does not offer it to you. (2) it changes the "custom label" you write in the process. Really changes it. That can never be something else than a bug. (3) "disklabel -E /dev/sd0" puts alway cpg=1. The installer in the autoinstall puts numbers like 10277, 16384. Rodrigo
Re: icmp6_reflect misbehaviour ?
Le 2018-11-28 21:33, Martin Pieuchot a écrit : On 28/11/18(Wed) 17:48, Stuart Henderson wrote: On 2018-11-27, Arnaud BRAND wrote: > Good evening everyone, > > I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. > > Long story short : > - IPv6 routes are propagated using OSPFv3 > - so they are installed with link-local gateways in the fib > - ICMPv6 "time exceeded" packets are generated with link-local source > address > - these packets are not to be routed so they do not get past the next > hop > - the endpoint never receives the "time exceeded packets" > > This of course is only true if the router generating the icmp packet is > not the endpoint, but only a hop in the path. > > I checked the code (or at least tried to). > It seems like it's in function icmp6_reflect in file icmp6.c at lines > 1144/1147. > > This code (if I understood it correctly) : > - fetches the route to the destination > - gets the interface source address for this route > - uses it as the source for the generated IP packet > > As my routes are installed with link-local addresses by OSPFv3, I get a > generated packet with a link local source-address. > The problem is when the destination is not on the local subnet : the > generated packet is unroutable and never makes it to its destination > > Would it be better to try to find another address on the interface that > is not link local if the destination address isn't on the interface > subnets ? That could be a solution. But if you do that, why don't you attach the routes to a routable address in the first place? Why is ospfd(8) not doing that? I'm not 100% sure, but afaik that's standard behavior for ospf6d. At least that's what I have seen on the few different brands I've worked with so far. The old thread contains more information imho, so I'm gonna revive it.
Re: icmp6_reflect misbehaviour ?
Le 2018-11-28 18:48, Stuart Henderson a écrit : On 2018-11-27, Arnaud BRAND wrote: Good evening everyone, I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. Long story short : - IPv6 routes are propagated using OSPFv3 - so they are installed with link-local gateways in the fib - ICMPv6 "time exceeded" packets are generated with link-local source address - these packets are not to be routed so they do not get past the next hop - the endpoint never receives the "time exceeded packets" This of course is only true if the router generating the icmp packet is not the endpoint, but only a hop in the path. I checked the code (or at least tried to). It seems like it's in function icmp6_reflect in file icmp6.c at lines 1144/1147. This code (if I understood it correctly) : - fetches the route to the destination - gets the interface source address for this route - uses it as the source for the generated IP packet As my routes are installed with link-local addresses by OSPFv3, I get a generated packet with a link local source-address. The problem is when the destination is not on the local subnet : the generated packet is unroutable and never makes it to its destination Would it be better to try to find another address on the interface that is not link local if the destination address isn't on the interface subnets ? Sadly, I can't provide a patch, sorry, I'm not that skilled in OpenBSD. I thought of a pf trickery like : pass out quick inet6 proto icmp6 from fe80::/10 to any icmp6-type timex nat-to lo1 but that won't work because the generated packet itself will be matching a state and this rule won't even be evaluated. Does anyone have an idea how I could get these icmp6 packets to reach their destination ? Thanks for your help ! Arnaud Known problem, no known workaround. I tried hard to find a way to do this with PF but I don't think there is one. bluhm@ pointed out "pf with IPv6 link-local addresses does not work properly. I think it cannot parse the %if suffixes. The KAME hack scope id is not handled" in my previous thread on this (https://marc.info/?t=15387538651=1=2). Thanks Stuart ! God, I can't understand how I missed this one. What are you guys using as a search engine to find theses messages ? I was looking at adding a call to in6_ifawithscope() after line 1144 in icmp6_reflect. Sadly I had no time to do it/test it today. Don't you reckon this would/could work ?
icmp6_reflect misbehaviour ?
Good evening everyone, I am stuck with a IPv6 traceroute problem in an OSPFv3 environment. Long story short : - IPv6 routes are propagated using OSPFv3 - so they are installed with link-local gateways in the fib - ICMPv6 "time exceeded" packets are generated with link-local source address - these packets are not to be routed so they do not get past the next hop - the endpoint never receives the "time exceeded packets" This of course is only true if the router generating the icmp packet is not the endpoint, but only a hop in the path. I checked the code (or at least tried to). It seems like it's in function icmp6_reflect in file icmp6.c at lines 1144/1147. This code (if I understood it correctly) : - fetches the route to the destination - gets the interface source address for this route - uses it as the source for the generated IP packet As my routes are installed with link-local addresses by OSPFv3, I get a generated packet with a link local source-address. The problem is when the destination is not on the local subnet : the generated packet is unroutable and never makes it to its destination Would it be better to try to find another address on the interface that is not link local if the destination address isn't on the interface subnets ? Sadly, I can't provide a patch, sorry, I'm not that skilled in OpenBSD. I thought of a pf trickery like : pass out quick inet6 proto icmp6 from fe80::/10 to any icmp6-type timex nat-to lo1 but that won't work because the generated packet itself will be matching a state and this rule won't even be evaluated. Does anyone have an idea how I could get these icmp6 packets to reach their destination ? Thanks for your help ! Arnaud
Re: OpenBGPD set nexthop blackhole qualify question
Auto answering myself because the answer was alrady in the mailling lists : Just set nexthop=127.0.0.1 on the neighbor, then you can blackhole. https://misc.openbsd.narkive.com/7jcjKEkQ/openbgpd-match-clause-with-multihop-bgp-session Le 2018-11-23 16:16, Arnaud BRAND a écrit : Hi misc@ readers, I have a question regarding the "set nexthop blackhole" nexthop qualification in OpenBGPD 6.4 stable. It looks like I have to add "nexthop qualify via default" in order for the blackholed route to make it from the rib to the fib. I understand this is standard behaviour for normal BGP nexthop qualification, but is this mandatory/normal/expected for blackholed prefixes too ? I would have thought that since I am blackholing the prefix there's nothing to qualify for anyway. Thanks for your help and tremendous work ! Have a nice day ! Arnaud
OpenBGPD set nexthop blackhole qualify question
Hi misc@ readers, I have a question regarding the "set nexthop blackhole" nexthop qualification in OpenBGPD 6.4 stable. It looks like I have to add "nexthop qualify via default" in order for the blackholed route to make it from the rib to the fib. I understand this is standard behaviour for normal BGP nexthop qualification, but is this mandatory/normal/expected for blackholed prefixes too ? I would have thought that since I am blackholing the prefix there's nothing to qualify for anyway. Thanks for your help and tremendous work ! Have a nice day ! Arnaud
Re: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios
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: PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios
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
PCEngines APU4B4 doesn't boot AMD64 when PXE is activated in the bios
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
BFD Status ?
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: DNS (UNBOUND) + PF ISSUE
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
