Arch Linux User Repository

In case of changes/updates to ppp, you will need to re-run chmod -v u+s /usr/sbin/pppd.

The new client (10.3.0) is completely different than the previous version and does not seem to work yet (even if you do use their questionable install.sh). Therefore, I won't update this package yet until I get it to work.

Hello! Since few days ago, I am not able to use netextender. I thought it would be because pppd updates but I already tried adding the suggested permissions, reverting it back and applying it again. The file has the following: .rwsr-xr-x 432k root 27 Dec 2023 /usr/sbin/pppd

In logs I see the following error: [general error 30319] ERROR: Could not sent SIGTERM to pppd or stop WireGuard failed: Permission denied (13)

Any suggestion?

Thanks in advance

@alexleach

YES. I've recently realised it's doing this. Following the logs it is a NetExtender issue and nothing to do with PPPD.

The only way i could work out how to fix it was to use the systemd-resolved drop-in file replacement (https://wiki.archlinux.org/title/Systemd-resolved#Manually) - but this would break whenever not connected to VPN, so the systemd config file has to be created in /etc/ppp (or wherever), then create a bash file in /etc/ppp/ip-up.d/ that moves the file from /etc/ppp/{your_systemd-resolved.conf} to /etc/systemd/resolved.conf.d/.

Make sure to remember to make the bash file executable.

Then a cleanup file that does the opposite of the above must be added to /etc/ppp/ip-down.d/

The real fix for this is with NetExtender to properly make use of systemd.

The hook is a great idea! Although I think it's better to add the hook to /etc/, /etc/pacman.d/hooks/update-ppp-permissions.hook.

The ppp permissions break regularly enough that I've started using a pacman hook at /usr/share/libalpm/hooks/update-ppp-permissions.hook with the contents:

[Trigger]
Type = Package
Operation = Upgrade
Target = ppp

[Action]
Description = Updating permissions for pppd...
When = PostTransaction
Exec = /usr/bin/chmod -v u+s /usr/sbin/pppd

Hello, I have an issue with netextender where it doesn't play nice with /etc/resolv.conf, when it is managed by systemd-resolved.

The latter package requires that /etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf. However, when netextender connects to my VPN, it will overwrite /etc/resolv.conf and replace it with a standalone file. After disconnecting from the VPN, sometimes a static version of /etc/resolv.conf remains, and systemd-resolved doesn't work to resolve .local mDNS addresses. (Typically, I've just tested now, and the symlink was restored, but it contained the additional nameservers and search domains for my VPN, so DNS stopped working).

This is a bit of a nuisance, as the company domain ends in .local, which conflicts with mDNS of course, and when systemd-resolved is not managing DNS lookups, mDNS doesn't work on my LAN, and I can't cast any audio or video to my chromecast(s). I've wasted much time trying to figure out why I was unable to cast A/V from my PC, and I've pinned it down to the SSL VPN messing around with /etc/resolv.conf.

Has anyone else come across this issue and have any suggestions for making netextender (or is it pppd?) play nicer with systemd-resolved? I'll probably open a support ticket with SonicWall on this, would that be the best place to report this?

Thanks and kind regards, Alex

@lovesponge Looking at the install file, the way it checks is as follows:

if [[ "`uname -m`" =~ '64' ]]
then
    echo "Yes, 64-bit"
else
    echo "No, 32-bit"
fi

Run this in your shell to check if it works.

Confirmed issue with 64bit installer. Not sure what's causing it: --- SonicWALL NetExtender 10.2.826 Installer --- ERROR: This copy of NetExtender is intended for 32-bit systems. Please install a copy of the 64-bit version of NetExtender

-> Found NetExtender.Linux-10.2.826.x86_64.tgz -> Found general-product-agreemen

So it's definitely downloading the '64bit' version but it doesn't work for some reason. Not sure if this is maintainer fault or sonicwall fault.

@physkets Hi there, I'm using Arch, the problem seems to be in the x64 package, I had removed the 32bit source from PKGBUILD but doesn't change anything.

@gilvbp That's odd. Are you on Arch, or some other distro?
The pkgbuild refers to both 32 bit and 64 bit sources, and makepkg should automatically pick the right one for your system.