https://openwrt.org/playground/faq/cannot_satisfy_dependencies
1 Like
Ok, if that's safe for strongswan, I'll give it a try. Usually, I assume that there is a reason for such dependencies, which is why I don't just directly force an install anyhow.
When installing a snapshot, you generally have to install the packages you need that day, as there is a new build every day. The safest would be to either build your own images or reinstall with the packages you need from a new snapshot.
2 Likes
You might want to look at Wireguard as another option. It's a new lightweight VPN that is in the repos (wireguard and luci-app-wireguard).
1 Like
I actually had thought about Wireguard, first. However, my firewall is pfsense, and there is no sufficiently reliable working Wireguard implementation for that platform (BSD/pfsense), yet. So I switched my plans to ipsec.
2 Likes
@jeff: This looks like a pretty good advice, as I just ran into a similar dependency problem trying to install openvpn.
I guess I can't just use the image linked in the wiki (for ar750, not ar750s) to get a stable release, but still have to go with a snapshot?
AR750 and AR750S are different devices.
BTW, the current snapshot builds require GPIO 7 to be "manually" raised to get USB power. Literally working on that right now.
+&gpio {
+ usb_power {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "usb-power";
+ };
+};
+
&pcie {
status = "okay";
};
It can also be done through the export facility of /sys/class/gpio -- let me know if you need to do that before I've got the patch done and accepted.
root@OpenWrt:~# cd /sys/class/gpio/
root@OpenWrt:/sys/class/gpio# ls
export gpiochip0 unexport
root@OpenWrt:/sys/class/gpio# echo 7 > export
root@OpenWrt:/sys/class/gpio# cd gpio7
root@OpenWrt:/sys/devices/platform/ahb/ahb:apb/18040000.gpio/gpiochip0/gpio/gpio7# ls
active_low device direction edge subsystem uevent value
root@OpenWrt:/sys/devices/platform/ahb/ahb:apb/18040000.gpio/gpiochip0/gpio/gpio7# echo out > direction
root@OpenWrt:/sys/devices/platform/ahb/ahb:apb/18040000.gpio/gpiochip0/gpio/gpio7# echo 0 > active_low
root@OpenWrt:/sys/devices/platform/ahb/ahb:apb/18040000.gpio/gpiochip0/gpio/gpio7# echo 1 > value
Thanks, don't need USB power right now.
The extra ath10k firmware install for 5ghz wifi also still works, and openvpn and strongswan now install without error.
I just hope I now have all the packages I need. 
1 Like
Have fun! I’ve got two with me on travel right now, one running GL.iNet firmware, the other connected to serial while working on spi-nand.
Hi folks
I am considering getting this router, and reading through the thread have a simple question. I think I understand the fact that there are issues currently with the NAND flash that are being worked on.
Is there a working image using the NOR flash? Anything i need to look out for?
I'm OK using the unit with 16MB only, as I am a light user and road warrior. I can wait for the NAND thing to get fixed, but really like the look of this unit. I'm replacing my old dlink dir-510L...
I’ve got it running on NAND on OpenWrt with ath79 and Linux 4.19. Waiting on some tests on the GL-AR300M with early production NAND so I can submit upstream.
I’m very happy with the GL-AR750S and it is a trusted companion on business travel for me. I run the GL.iNet firmware on that one (basically 18.06.1 plus NAND drivers, a great UI, and travel-friendly packages)
1 Like
Thanks @jeff, so you'd recommend running stock / OEM firmware for now until the NAND patches are ready and accepted upstream? I'm a bit of a tinkerer - know just a little more than enough to be dangerous, comfortable on the command line and researching to troubleshoot. This thread and loading custom modules/drivers though stretches me 
Now if only I could find one of these for sale in Canada...
Amazon US has them.
The one I travel with is bone-stock GL.iNet v3 firmware, latest testing as of a month ago.
Well, there's another one I was traveling with, but it's out of its case and looks a bit like Medusa with all the wires running out of it 
At least the TSA or seat mates on a 14-hour flight as I pounded on drivers didn't think it dangerous.
What would I run myself? On the road, I'll probably stick with GL.iNet firmware. It just works for me in all the situations I've been in. Right now it's based on 18.06.1 (last I checked) and GL.iNet maintains an extensive repo, both their own packages as well as the "standard" ones for OpenWrt.
1 Like
Nice thanks, keeping banging away on those patches I ordered mine from US Amazon - we pay dearly for the shipping despite being on Prime though 
1 Like
Cleaning up the patch sequence now and hopefully fixed the detection of Paragon NAND (older GL-AR300M units). I’ll need to get the Paragon patch through Linux MTD approval, then can submit the OpenWrt patches. I’m hoping a couple weeks for the process, but timing with Linux is likely to be the driver.
1 Like
Hi Jeff,
recently i've ordered few pieces of this little beast (AR750S). May i ask if you can run it on ordinary power-bank (it says 6W but i had good surprise on little esp8266 boards how much more power they suck on certain operations - tx burst - then they freeze up).
Another question if the stock firmware can accommodate mesh packages like batman-adv and wpad-mesh-openssl or i should flash a raw openwrt before messing with meshing?
cheers, lev
GL.iNet firmware is effectively 18.06.1 with GL.iNet packages for VPN/repeater and GUI on top of it, so it should work as well as any 18.06 device (and configure the same way, if you're using batman-adv, which changed configuration approach in early 2019).
Should run fine on a decent 5 V power pack -- I'd figure 500 mA idle, 1 A active for a rough guess at run time.
ath79 support under review and buildable from the branch offering the PR
I manually edited all the 38 files for SPI-NAND support for the AR750
It compiled ok, but before I flash it I wanted to ask question.
│ │ Target System (Atheros AR7xxx/AR9xxx) ---> │ │
│ │ Subtarget (Generic) ---> │ │
│ │ Target Profile (GL.iNet GL-AR750S) --->
I this the right selection, because when I select in subtarget "nand" the ar750s is not available as target profile.
Do I have to select somewhere else "Nand"
What would be the name of the firmware.
Just want to make sure before I do something stupid flashing the device
Or is there a better way to get your code as manually editing. I'm not that familiar with GitHub.
You can clone the repo from https://github.com/jeffsf/openwrt and check out the ath79-nand-pr branch or download a patch from the PR and apply it to your own branch. My repo, since the subject of a PR, only gets "bumped" when the patches fail to apply. It's pretty recent, but not tightly tracking master. I'd go with the clone approach or downloading and applying the patches rather than hand editing.
There should be two options under ath79 (not ar71xx) > NAND
- GL-AR750S NOR -- can be flashed from existing NOR installs, NAND-aware kernel, files on NOR
- GL-AR750S NOR/NAND -- can be flashed from existing NAND kernels, or the above, files on NAND
(ar71xx is a deprecated target)
@jeff
I cloned your repo and it worked perfect.
I downloaded the .zip file
added the feeds
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
I also see you have the cifsd module and the cifsd-tools already included in your code. I want to try this out as well.
Thanks for all the good work. Let's hope your code will be included in the main code of OpenWrt soon.
2 Likes