Forum Replies Created
I think error -2 is a “no such file or directory” error.
I suspect you are missing the firmware file for your wifi chip, iwlwifi-3160-17.ucode.
These files are usually under stupid licences that do not allow re-distribution, so they are not included in the OS install, and need to be installed afterwards.
I looks like you can get the file you need from here: https://github.com/OpenELEC/iwlwifi-firmware/tree/master/firmware (I just found this with google).
But I’m not sure where in the filesystem you need to put it, possibly under /lib/firmware/
Continuing to talk to myself..
I tried re-imaging the SD card’s non profile partitions, and this made no difference.
For now I have gone back to the x86 system as my router.
I have ordered an Orange Pi and will try again there.
Replying to myself..
I’m now thinking the issue is with the scripts that surround bringing the VPN up.
When I check the log from starting the VPN, it says that interface VPN00 is down.
I logged in to get a shell, and I can’t even run a tcpdump on the interface as “that interface is not up”. When I manually bring it up “ifconfig VPN00 up”, then I can tcpdump and I see the traffic, and it will work. If I restart the VPN it will take the interface down, but not bring it back up again.
I’m wondering if my attempt to restore the profile from the x86 system may have mucked with some scripts causing a mismatch between the Pi image and the x86 install?
I’ve just got back to Canada from a 2 week vacation to Australia and have started looking at this again. With exactly the same config on both systems, only one will have the VPN connect. There must be something different..
I looked in the log files on both systems to compare, after connecting, and attempting to compare. I notice that the OpenVPN versions are very different.
The x86 system which works is running:
OpenVPN 2.4.0 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 4 2017 library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.03
The RPi is running:
OpenVPN 2.3.10 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jan 29 2016 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09
My server/remote system is running:
OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec 1 2014
So I’m beginning to suspect an issue with 2.3.10 armv7l-unknown-linux-gnueabihf.
So I continued fiddling with no success. Doing a sanity check, I moved the x86 box to another LAN IP, and WAN IPs, and changed the VPN config to exactly match the Raspberry Pi.. The VPNs connect with no issues.
I think there’s something funny/broken with the VPN LAN to LAN support in 3.7.1A
I realised I could connect the LAN interface using the WiFi interface on the Pi, rather than VLAN tagging the single port and just use it for my 4 WAN connections (in /29 subnets), in case that was the problem, since it was the only real difference from the x86 system.
I rebooted into the original profile, and I configured things that way from scratch, rather than trying to import the config.
I setup the net balancer and the VPNs exactly the same, exporting and importing the X509 certs etc, and yet the VPN still gets stuck on “connecting to peer”, even though it comes up, and the log file has “Initialization Sequence Completed” at the end.
Now I’m confused as to why it’s not working out that the VPN has connected.
Question: How do you use those Raspberry things as a router? Those have got only one network interface. Do you use USB network card with that?
Or you can use VLAN tags on the single interface, and set them on your switch/AP. I have mine trunked to a Linksys access point, and I configured the WAN and LAN to both be tagged on the port on the Linksys which the Pi is plugged into, with matching tagged interfaces for WAN and LAN.
It appears that Asterisk needs to be compiled with BUILD_NATIVE disabled, as it has been compiled for a CPU which is not compatible with the VIA C3. The issue is that this will be a non optimised binary. Alternatively it could be compiled on/for the C3 CPU.
I saw some issues like that after my NIC (Compaq ThunderLAN dual port) was making the kernel crash and the system reboot, and it caused some corruption to the filesystem due to the unexpected reboots.
I would suggest restoring a recent backup of your profile.
This was happening to me. I had a VGA monitor connected so I would see the kernel crash output. From that I deduced it was being caused by the NIC I had in there, a Compaq ThunderLAN dual port card.
Once I took that NIC out and replaced it with a single port 3Com NIC, it stopped crashing and rebooting.May 26, 2016 at 7:50 pm in reply to: slow openvpn links – don’t use max wan bandwidth available #53570
I realise this is 2 years old..
I did some research into this, and apparently, unless you have pretty beefy boxes on both ends of the VPN, using LZO compression will affect the throughput a lot, and it’s better to not use it..
I also found a large increase in VPN thoughput (from 15Mbit to 30MBit) by configuring my VPN to use AES-128-CBC rather than blowfish, and utilise the VIA padlock hardware encryption in the C3 CPU in my ZS host by adding “–cipher AES-128-CBC –engine padlock” to the VPN configuration (on both ends).