Re: gcc: error trying to exec 'cc1': execvp: no such file or directory
On Thu, 19 Nov 2020, Todd C. Miller wrote: On Thu, 19 Nov 2020 22:07:33 +, Roderick wrote: g++, gcc and gcov in /bin are from Apr 13, 2019. The rest are from Oct 5, 2020. That explains your problem. The upgrade would have removed any obsolete /usr/lib/gcc-lib/amd64-unknown-openbsd* directory which the old gcc binaries require. tar tvzf base68.tgz | grep gcc gives nothing. It seems, gcc was removed from i386. That explains the old date of my gcc binary that was never deleted. But that does not explain that /usr/lib/gcc-lib disappeared. I think it was never in the upgrade instructions to delete it. I tested my disk with gsmartcontrol and it is OK. Problems that my gigant root fs could bring are, in my oppinion, only when booting, and they never occur. Rod.
Re: gcc: error trying to exec 'cc1': execvp: no such file or directory
On Nov 20 11:27:46, hru...@gmail.com wrote: > > On Thu, 19 Nov 2020, Todd C. Miller wrote: > > > On Thu, 19 Nov 2020 22:07:33 +, Roderick wrote: > > > > > g++, gcc and gcov in /bin are from Apr 13, 2019. The rest are from > > > Oct 5, 2020. > > > > That explains your problem. The upgrade would have removed any > > obsolete /usr/lib/gcc-lib/amd64-unknown-openbsd* directory which > > the old gcc binaries require. > > tar tvzf base68.tgz | grep gcc The compiler is in the comp68.tgz set. Did you install the comp68.tgz set?
Re: gcc: error trying to exec 'cc1': execvp: no such file or directory
Roderick wrote: > It seems, gcc was removed from i386. That explains the old date of my gcc binary that was never deleted. It took you *6* emails before finally mentioning which platform were on, even after being asked.. i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were obsolete even on your 6.7 install.. i386 has been a default clang arch since OpenBSD /6.2/. https://www.openbsd.org/66.html
Re: gcc: error trying to exec 'cc1': execvp: no such file or directory
On Fri, Nov 20, 2020 at 11:27:46AM +, Roderick wrote: > > On Thu, 19 Nov 2020, Todd C. Miller wrote: > > > On Thu, 19 Nov 2020 22:07:33 +, Roderick wrote: > > > > > g++, gcc and gcov in /bin are from Apr 13, 2019. The rest are from > > > Oct 5, 2020. > > > > That explains your problem. The upgrade would have removed any > > obsolete /usr/lib/gcc-lib/amd64-unknown-openbsd* directory which > > the old gcc binaries require. > > tar tvzf base68.tgz | grep gcc > > gives nothing. It seems, gcc was removed from i386. That explains > the old date of my gcc binary that was never deleted. But that ... It took you *6* emails before finally mentioning which platform you were running, even after being asked.. i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were obsolete even on your 6.7 install.. i386 has been a default clang arch since OpenBSD /6.2/! https://www.openbsd.org/66.html
Re: gcc: error trying to exec 'cc1': execvp: no such file or directory
On Fri, 20 Nov 2020, Bryan Steele wrote: It took you *6* emails before finally mentioning which platform were on, even after being asked.. Yes, excuse me, I answered to Nick Samsung nc10, but not mentioned i386. i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were Your link for 6.8 says: "Disabled gcc in base on armv7 and i386." obsolete even on your 6.7 install.. i386 has been a default clang arch since OpenBSD /6.2/. Clang was default, gcc may be obsolete, but /usr/bin/gcc is till now there, broken. In the upgrade instructions is not mentioned to delete it: https://www.openbsd.org/66.html The man page of gcc-local is till now (6.8) delivered in comp68.tgz Rod.
Re: gcc: error trying to exec 'cc1': execvp: no such file or directory
On Fri, Nov 20, 2020 at 02:02:56PM +, Rodrigo Readi wrote: > > On Fri, 20 Nov 2020, Bryan Steele wrote: > > > It took you *6* emails before finally mentioning which platform were > > on, even after being asked.. > > Yes, excuse me, I answered to Nick Samsung nc10, but not mentioned i386. > > > i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were > > Your link for 6.8 says: "Disabled gcc in base on armv7 and i386." I linked to the 6.6 page, not 6.8. Yes, it was disabled, and henced removed from the distribution sets for i386 (and armv7), but not from the tree as other architectures still use base-gcc. New installs do not include them on i386/armv7, but upgrades do not removed obsolete binaries in general. > > obsolete even on your 6.7 install.. i386 has been a default clang arch > > since OpenBSD /6.2/. > > Clang was default, gcc may be obsolete, but /usr/bin/gcc is till now > there, broken. In the upgrade instructions is not mentioned to delete > it: > > https://www.openbsd.org/66.html > > The man page of gcc-local is till now (6.8) delivered in comp68.tgz The man page is installed on all architectures so that's irrelevant. > Rod.
Re: gcc: error trying to exec 'cc1': execvp: no such file or directory
Den fre 20 nov. 2020 kl 15:09 skrev Roderick : > > obsolete even on your 6.7 install.. i386 has been a default clang arch > > since OpenBSD /6.2/. > > Clang was default, gcc may be obsolete, but /usr/bin/gcc is till now > there, broken. In the upgrade instructions is not mentioned to delete > it: > Regardless of when and how defaults changed, the openbsd system compiler is and was always "cc". Used to be gcc 2, then 3, then 4, then clang and no one had to change anything as long as use cc and not calling gcc/clang directly. The system makes sure the correct stuff is called if you use cc at all times. -- May the most significant bit of your life be positive.
Re: Wrong source address of outgoing ESP packets (IKEv1)
I found a problem! I very sorry. I didn't pay attention to outgoing NAT
rules and tagging outside the internal network.
pass out quick on egress tagged OUT nat-to X.X.X.3
pass in quick on { $prod_if $mgmt_if } from to ! tag OUT
Sorry again. I'm inconsiderate. :(
чт, 19 нояб. 2020 г. в 20:45, Dev Op :
> Hello all!
>
> I'm trying to create an IPSec (IKEv1) tunnel from my router to foreign
> host. I've got FLOWS and SAD records for foreign host, everything might be
> ok but esp packets go from the wrong IP address.
>
> Configuration (sorry I need to hide my real net):
>
> Foreign router:
> Y.Y.Y.Y/24 - foreign network with a public IP addresses:
> .1 - VPN peer
> .2 - Application server
>
> My router:
> bge0: X.X.X.1/28 - external subnet
> carp1: X.X.X.3/28 (master) - meanwhile I have no slave yet
>X.X.X.4/28 - alias for IPSec
> vlan12: 10.0.12.1/24 - internal subnet
>
> # cat /etc/isakmpd/isakmpd.conf
> [General]
> Listen-on=X.X.X.4
> Retransmits=32
> Exchange-max-time=240
> DPD-check-interval=30
> Default-phase-1-lifetime=86400,60:86400
> Default-phase-2-lifetime=86400,60:86400
>
> # cat /etc/ipsec.conf
> ike active esp from 10.0.12.12 to Y.Y.Y.2 local X.X.X.4 peer Y.Y.Y.1 \
> main auth hmac-sha1 enc 3des group modp1024 lifetime 24h \
> quick auth hmac-sha1 enc 3des group none lifetime 8h \
> psk "verysecret"
>
> # ipsecctl -Fd
> # isakmpd -4K
> # ipsecctl -f /etc/ipsec.conf
> # netstat -an | grep -w 500
> udp 0 0 X.X.X.4.500 *.*
>
> # ipsecctl -sa
> FLOWS:
> flow esp in from Y.Y.Y.2 to 10.0.12.12 peer Y.Y.Y.1 srcid X.X.X.4/32 dstid
> Y.Y.Y.1/32 type use
> flow esp out from 10.0.12.12 to Y.Y.Y.2 peer Y.Y.Y.1 srcid X.X.X.4/32
> dstid Y.Y.Y.1/32 type require
>
> SAD:
> esp tunnel from Y.Y.Y.1 to X.X.X.4 spi 0x703bdd15 auth hmac-sha1 enc
> 3des-cbc
> esp tunnel from X.X.X.4 to Y.Y.Y.1 spi 0x9163f209 auth hmac-sha1 enc
> 3des-cbc
>
> Now I try to telnet from internal subnetwork:
> node4# telnet -b 10.0.12.12 Y.Y.Y.2 12000
> Trying Y.Y.Y.2...
> ^C
>
> Now checkout router:
>
> # tcpdump -ni enc0 host Y.Y.Y.1
> tcpdump: listening on enc0, link-type ENC
> 17:19:25.664514 (authentic,confidential): SPI 0x9163f209: 10.0.12.12.41013
> > Y.Y.Y.2.12000: S 3062295815:3062295815(0) win 29200 1440,sackOK,timestamp 2280702669 0,nop,wscale 7> [tos 0x10] (encap)
> 17:19:26.725920 (authentic,confidential): SPI 0x9163f209: 10.0.12.12.41013
> > Y.Y.Y.2.12000: S 3062295815:3062295815(0) win 29200 1440,sackOK,timestamp 2280703730 0,nop,wscale 7> [tos 0x10] (encap)
>
> And things goes crazy if you look at the source address of esp packets:
>
> # tcpdump -ni bge0 host Y.Y.Y.1
> tcpdump: listening on bge0, link-type EN10MB
> 17:19:23.398060 Y.Y.Y.1.500 > X.X.X.4.500: isakmp v1.0 exchange INFO
> encrypted
> cookie: 28259647556726a3->2772360ab1b13794 msgid: f4395193 len: 92
> 17:19:25.664623 X.X.X.3 > Y.Y.Y.1: esp spi 0x9163f209 seq 192 len 92 [tos
> 0x10]
> 17:19:26.725975 X.X.X.3 > Y.Y.Y.1: esp spi 0x9163f209 seq 193 len 92 [tos
> 0x10]
> 17:19:28.414920 X.X.X.4.500 > Y.Y.Y.1.500: isakmp v1.0 exchange INFO
> encrypted
> cookie: 28259647556726a3->2772360ab1b13794 msgid: 167f5770 len: 84
> 17:19:28.418532 Y.Y.Y.1.500 > X.X.X.4.500: isakmp v1.0 exchange INFO
> encrypted
> cookie: 28259647556726a3->2772360ab1b13794 msgid: 00e63d21 len: 92
>
> What I forgot? :( Why does OpenBSD (I guess iksampd) choose the first
> address of the CARP interface, not that I specified for VPN only in case of
> ESP packets? I must admit, that I also have a second VPN connection where
> FLOW works well with tunnel address from the private destination network
> and ESP packets go from right address X.X.X.4 on external interface. I
> think this problem somehow occurs due to a public address which was
> specified by foreign service provider that I have to use in the tunnel.
>
> My packet filter ruleset:
>
> set block-policy drop
> set skip on { lo enc0 }
> ...
> # IPSec
> pass out quick on egress proto udp from X.X.X.4 to port { isakmp,
> ipsec-nat-t }
> pass out quick on egress proto esp from X.X.X.4 to
> pass in quick on egress proto udp from to X.X.X.4 port { isakmp,
> ipsec-nat-t }
> pass in quick on egress proto esp from to X.X.X.4
>
> Thanks for any help.
>
> Regards,
> Den
>
--
С уважением,
Денис
*Это сообщение и любые документы, приложенные к нему, содержат
конфиденциальную информацию. Уведомляем Вас о том, что использование,
копирование, распространение информации, содержащейся в настоящем
сообщении, запрещено.*
Measuring Routing Table Capacity
Hi Misc, I have a device which installed OpenBSD. I want to measure how many routes the routing table can hold? In brief, I want to measure the routing table's capacity. Is there any way to do it? Sent with [ProtonMail](https://protonmail.com) Secure Email.
Advice on using intrusion detection
Is it recommended to run some kind of intrusion detection on an OpenBSD router/firewall? I suspect that any kind of system like Snort or Suricata will give a lot of false positives? Kind regards, Erik
A new race condition in OpenVPN and Unbound services
Hi Misc, Has anybody else noticed a new race condition causing Unbound to fail due to the fact that OpenVPN interface is not available. Since a few releases ago I have this in my rc.conf.local to start openvpn server and unbound openvpn_flags=--config /etc/openvpn/server.conf pkg_scripts=sshguard collectd smartd openvpn sensorsd_flags= snmpd_flags= syslogd_flags="-h" unbound_flags= Previously I was starting OpenVPN server via /etc/hostname.tun0 file up link0 !/usr/local/sbin/openvpn --daemon --config /etc/openvpn/server.conf I noticed this morning after upgrading 2 of my OpenVPN servers that unbound is failing to start because tun0 is not available on time. If I go back to start OpenVPN server from /etc/hostname.tun0 file everything works as expected. Cheers, Predrag
