Pinebook Pro: "ping: sendmsg: Operation not permitted"

Hi guys,

Relatively new EOS user on a Pinebook Pro.

I went to use my laptop one day and found I couldn’t connect, even though it showed me connected to the AP. I figured it was something wrong with my new phone’s hotspot and tried it again on the wifi at home. Same thing.

When I attempt to ping, I get:

PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Port Unreachable
ping: sendmsg: Operation not permitted

I get the same thing trying to ping the AP (1.21) or (cloudeflare DNS web server).
I’m not able to connect with http with curl of w3m, but the route looks correct as far as I can tell, and I do have an ip.

This all just started out of the blue.

nmap isn’t able to find a single thing, either.

Output of ip address, ip route, and inxi are here:


I tried booting into a fresh SD card image, running arch-chroot on the internal eMMC, and doing a pacman -Syyu, and that didn’t help any.

First, I tried to reinstall most packages with pacman -s $(cat file-with-package-names), but that didn’t seem to help as well.

Try disabling your firewall to test if the issue is related to that.

sudo systemctl stop firewalld

No change, unfortunately.
I even ran iptables --list, and it showed all three policies as ACCEPT with no rules.

Do you have a VPN installed? If so, check the killswitch has not been left enabled (even if the VPN is not running).

Ooo, good call, although I don’t think mullvad cli has a killswitch (or at least I haven’t enabled one), but I’ll check it tonight.

Check this post here:

The way they use (or do not use) the term “killswitch” is a little different than most VPNs in my experience, but in your case you may need to turn off the “Always require VPN” setting.

Always require VPN

The “always require VPN” setting in the app is regularly misunderstood as the kill switch. This is not the case. The “always require VPN” setting only changes whether or not the disconnected state should allow traffic to flow freely or to block it. The disconnected state is not active during intermittent network issues or server changes, when a kill switch would normally be operating.

The intended use case for this setting is when the user want to only switch between no internet connectivity at all and using VPN. With this setting active, the device can never communicate with the internet outside of a VPN tunnel.

Unfortunately, that wasn’t it:

Script started on 2023-08-28 19:27:59-05:00 [TERM="foot" TTY="/dev/pts/0" COLUMNS="156" LINES="35"]
67%, discharging, 4.8 hours remaining, 7.2 total                                                                                 (Running script on Wayland)
~ $ sudo iptables -l
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
~ $ mullvad status
Blocked: Failure to generate tunnel parameters: Failure to select a matching tunnel relay
sudo ullvad status
Blocked: Failure to generate tunnel parameters: Failure to select a matching tunnel relay
~ $ mullvad lockdown-mode get
Network traffic will be allowed when the VPN is disconnected
~ $ 

Script done on 2023-08-28 19:29:17-05:00 [COMMAND_EXIT_CODE="0"]

Are you able to connect to the VPN?

Ok, I think it was mullvad.
mullvad connect gives me no text output and a return code 0 (and same error message when I issue mullvad status), but mullvad disconnect restored everything.

WEIRD! I guess I need to reinstall mullvad?? Or something else broke it?


Ok, DUH, I figured it out.

I had to disconnect/disable all devices from my mullvad account a few days back because there were too many old ones still logged in. Mullvad was set up to autoconnect, at which point it just got stuck because its authentication was no longer valid. Re-logged in and bob’s your uncle.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.