OpenBSD 7.1 and Perl 5.32, Invalid argument on creating socket
Hi guys, I noticed a strange issue which ocurred on one of my machines which always worked prior migration to OpenBSD 7.1. I have a couple of perl script which are basically just sending small stuff via UDP on the LAN. For socket creation Im using IO::Socket::INET, normally I can always give a host as PeerAddr argument - this no longer works. I get "Invalid argument", not sure what's wrong - the IP works - so its about resolving? But the host resolves normally with userland utils and I didn't change it. Im on OpenBSD/octeon for this, but I guess this shouldn't be all to important for this. The script(s) are very trivial, basically the line which causes the issue goes like: my $sock = IO::Socket::INET->new( Proto => 'udp', PeerPort => 1122, PeerAddr => $host, ) or die "Could not create socket: $!\n"; The same script works on other machines, like a local Linux with perl 5.34.1 I dont think this is explicitly about perl or that they changed the behaviour that is not longer possible to give hostnames as PeerAddr. regards, Georg
Re: OpenBSD 7.1 and Perl 5.32, Invalid argument on creating socket
Hi, nevermind - disregard this, it was pebcak afterall. Am Dienstag, dem 17.05.2022 um 12:22 +0200 schrieb Georg Bege: > Hi guys, > > I noticed a strange issue which ocurred on one of my machines which > always worked prior migration to OpenBSD 7.1. > > I have a couple of perl script which are basically just sending small > stuff via UDP on the LAN. > For socket creation Im using IO::Socket::INET, normally I can always > give a host as PeerAddr argument - this no longer works. > > I get "Invalid argument", not sure what's wrong - the IP works - so > its > about resolving? > But the host resolves normally with userland utils and I didn't > change > it. > > Im on OpenBSD/octeon for this, but I guess this shouldn't be all to > important for this. > The script(s) are very trivial, basically the line which causes the > issue goes like: > > my $sock = IO::Socket::INET->new( > Proto => 'udp', > PeerPort => 1122, > PeerAddr => $host, > ) or die "Could not create socket: $!\n"; > > > The same script works on other machines, like a local Linux with perl > 5.34.1 > I dont think this is explicitly about perl or that they changed the > behaviour that is not longer possible to give hostnames as PeerAddr. > > regards, > Georg >
Re: Wireguard IP packets fragmentation issue
hello Stuart, sorry for the delay in replying I think the issue in my ISP corner case case was that clients were natted to Public address pool X while link ips within the ISP network (the ips that might send the ICMP destination unreachable fragmentation needed messages would be natted to a different IP address, so PMTU discovery inbound (behind the NAT) in that case didn't work. ( I think you are right re the possibility of a Catch all NAT being missed for the Private router links also would result in the PMTU Frag needed ICMP messages getting lost) Re: >My preference is to try and set things up as much as possible so that >you don't get PMTU blackholes or have to fragment the tunnel packet, >but also clamp mss so that even if you do hit a blackhole there's no problem. >There are some downsides to clamping MSS but they're relatively small >and it's something done by almost every off-the-shelf home CPE so it's >very very xommon on the internet. Agreed on the above... I see alot of 4G devices / networks clamping the hell out of TCP MSS in the wild also, which can make TCP VPNs (SSTP) TLS etc... VPNS Challenging as you have to clamp the TCP MSS in anticipation of an outer clamp on the TCP MSS some tunnels do Fragment gracefully (if you call doubling packet per second on your VPN device graceful, but performance takes a big hit, in testing even deliberately fragmenting packets (to send full frames (layer2) in tunnels or full packets in tunnels (layer3) ) the benefit of being able to send the full packet over the fragmented tunnel does not in any way increase perf... and the TCP MSS clamping gives the best throughput (in my experience) ... Thanks again, Tom Smyth On Sun 15 May 2022, 21:02 Stuart Henderson, wrote: > On 2022-05-15, Tom Smyth wrote: > > Hi Stuart, > > I have huge regard for you and all you contribute to OpenBSD and the > community > > Im going to clarify what I meant and what my experience with PMTU and > > constrained MTUs behind > > NAT, > > My humble experience is that if we have a constrained MTU behind a NAT > > Path MTU discovery from the server to the client fails because > > > > [website]--- public IP MTU 1500 bytes --[firewall/Nat] > > private network MTU 1492 bytes-client > > > > so while MTU discovery may work outbound...(from client to the website) > > the public website to the public IP has no way to discover the > > constrained PMTU behind the nat... > > There's no reason for this to fail? 1500 byte packet with DF set hits > the firewall/nat box, route lookup, exit MTU is 1492, too big -> surely > it just sends back frag needed? > > Even if you have a nat device with 1500 exit mtu and it then hits 1492 > mtu on another device, similar case but the original frag-needed is > sourced from a private address so it gets natted on the way out. > > There could be some specific cases where things aren't setup to allow > this to work but there's nothing in general to cause it to fail. > > The problem case is when you have router hops on private addresses > where there is *no* nat in the path in which case icmp is generated > from the private address but there's nithing ti translate it, so that > case you do often lose the message due to "no martian" packet filtering. > > > This corner case was discovered when I setup My ISP initially and I > > had not many IP addresses many moons ago > > It would be rare for a client behind a NAT to have a smaller MTU than > > their public IP internet connection. > > > > Is my reasoning and analysis here correct ? > > > > > > Regarding my comment > >> PMTU cannot properly account for underlay restrictions Inside a VPN > > > > what I meant was, that if you set an MTU of 1500 on a VPN Tunnel > interface > > but in sending 1500 Bytes in an IP packet across the tunnel it > > requires a the VPN encapsulated Packet + a Fragment Packet to be sent > > also, (on the underlay interface) > > the Router on the VPN wont sent a Fragment needed IP message to the > > client because the MTU of the Tunnel was not exceeded > > (but the MTU on the underlay was exceeded) > > This depends on the MTU stored in the route table entry used to send > the packet over the vpn. > > With a separate tunnel interface the mtu on that interface and thus the > route table can be set low enough that frag needed is sent. > > With standard flow-based IPsec the route used is normally the default > route with either a standard ethernet MTU or a pppoe MTU. But if there's > another route (route-based IPsec on OS which have this, or a > dummyinterface such as is sometines used in combo with flow-based IPsec, > for example a vether interface with a netmask that covers the "other > side" of the IPsec tunnel as defined in the flow) with a lower MTU set > on that interface, when the packet is attempted to be transmitted it > will again see the lower MTU via the route table and be able to send > frag-needed. > > It's easy to hit the blackhole case with IPsec tunnels *bu
Re: kernel fault after 7.1
23.04.2022 15:47, Stuart Henderson пишет:
On 2022-04-23, kasak wrote:
hello everybody. after upgrading to 7.1 my router started to panic very
often :(( about twice a day.
Please report to b...@openbsd.org, with the information from your mail,
plus dmesg, and an outline of how the machine is configured (what types
of network interface/pseudointerface are involved, a bit about ipsec
config and what software is running, is it iked or isakmpd or static,
is sasyncd running, etc)
This is the information from the screen:
kernel: protection fault trap, code=0
Stopped at ipsp_ids_gc+0xb4 cmpl $0,0x64(%r14)
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
ipsp_ids_gc(0) at ipsp_ids_gc+0xb4
softclock_thread(800022baf260) at softclock_thread+0x13b
and trace frame: 0x0, count: -2
ddb{0}> machine ddbcpu 1
Stopped at x86_ipi_db+0x12: leave
ddb{1}> trace
x86_ipi_db(800022909ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x203
sched_idle(800022909ff0) at sched_idle+0x280
end trace frame: 0x0, count -5
I'm so happy that this bug was fixed so quickly, thank's for all
involved people!
Now I'm using my self compiled 7.1-stable with patches for ipsec, with
no issues for 20 days.
Can I somehow revert kernel to 7.1-release, to make syspatch working?
Re: kernel fault after 7.1
On 2022-05-17, kasak wrote: > Can I somehow revert kernel to 7.1-release, to make syspatch working? Boot bsd.rd and do an 'upgrade' install to 7.1 again. (You can also do this with sysupgrade if you modify the script).
Re: kernel fault after 7.1
> On 18 May 2022, at 01:18, Stuart Henderson wrote: > > On 2022-05-17, kasak wrote: >> Can I somehow revert kernel to 7.1-release, to make syspatch working? > > Boot bsd.rd and do an 'upgrade' install to 7.1 again. (You can also do > this with sysupgrade if you modify the script). > > Or just download bsd.mp kernel from [1], check it with signify(1) and reboot. 1. https://ftp.openbsd.org/pub/OpenBSD/7.1/amd64/
Re: kernel fault after 7.1
On 2022/05/18 01:40, Vitaliy Makkoveev wrote: > > On 18 May 2022, at 01:18, Stuart Henderson > > wrote: > > > > On 2022-05-17, kasak wrote: > >> Can I somehow revert kernel to 7.1-release, to make syspatch working? > > > > Boot bsd.rd and do an 'upgrade' install to 7.1 again. (You can also do > > this with sysupgrade if you modify the script). > > > > > > > Or just download bsd.mp kernel from [1], check it with signify(1) and > reboot. > > 1. https://ftp.openbsd.org/pub/OpenBSD/7.1/amd64/ Doing an 'upgrade' also cleans out any syspatches that were applied before updating the kernel to -stable and gets things into more of a known state (that's why I suggested doing it, even though it's a bit more awkward)
Re: kernel fault after 7.1
18.05.2022 02:28, Stuart Henderson пишет: On 2022/05/18 01:40, Vitaliy Makkoveev wrote: On 18 May 2022, at 01:18, Stuart Henderson wrote: On 2022-05-17, kasak wrote: Can I somehow revert kernel to 7.1-release, to make syspatch working? Boot bsd.rd and do an 'upgrade' install to 7.1 again. (You can also do this with sysupgrade if you modify the script). Or just download bsd.mp kernel from [1], check it with signify(1) and reboot. 1. https://ftp.openbsd.org/pub/OpenBSD/7.1/amd64/ Doing an 'upgrade' also cleans out any syspatches that were applied before updating the kernel to -stable and gets things into more of a known state (that's why I suggested doing it, even though it's a bit more awkward) Worked like a charm! Thanks!
