Missing ip-full on x86 installation?

I'm doing some experiments with OpenWRT on x86 hardware.

Right now my OWRT server is configured like this:

OpenWRT server LAN (10.0.0.1) -> WAN (Fritzbox ISP Router 192.168.1.1) -> REAL WAN.

I also have a Tailscale VPN running on the OpenWRT server, and I wanted to see if I could send WakeOnLan packets from the LAN to a machine on the FritzboxLAN.

Usually when I set this up on other OWRT devices I had use this command to add the device, otherwise, especially when using a VPN, the command could fail:

ip neigh add 192.168.1.102 lladdr samplemacaddress nud permanent dev br-lan

I recently did this for my uncle (on a MT300 mini router) and the command works.
However, when I tried it on my x86 machine I get the error "ip: invalid argument 'add' to 'ip' "

Does this happen because the OWRT installed on the MT300 uses ip-full while the x86 doesn't? If so, what's the syntax for doing the same thing?
If I type "ip help" into the x86 terminal it seems there is no option for adding neighbours (I get this:

ip neigh show|flush [to PREFIX] [dev DEV] [nud STATE]

While it's possible to forward WOL by adding static ARP entries, you're making it a bit hard for yourself, especially when VPNs come into play. Why not have the OpenWrt router itself send the WOL packets to its WAN (the "FritzboxLAN") side? See: etherwake on console, or luci-app-wol on the web interface.

IIRC no default OpenWrt image comes with ip-full, that's always an aftermarket install or a customized image.

1 Like

I was actually using luci-app-wol for the experiments, however in an actual network (for example at home) I like to send the WOL packets from other sources so that I don't have to give access to the router to people that aren't tech savy or that shouldn't have access to the device.
It's also just way more handy to press a button on an app instead of logging into OWRT every time I need to send a packet!

IIRC no default OpenWrt image comes with ip-full, that's always an aftermarket install or a customized image.

Right, I assumed it was present on the stock image but now that you mentioned it I checked on the MT300 where I use Wireguard (unlike the server where I'm now trying things with Tailscale), and it was Wireguard that installed ip-full as a dependency. That mistery is solved!

I'll now try installing it on the x86 machine and see if I can reach stuff on the WAN.

WireGuard does not install ip-full as a dependency, it must have been something else. On that machine, you can try opkg whatdepends ip-full to see what it actually was.

It's needed for luci-proto-wireguard, that's what installed it on the MT300.

The screenshot is from my x86 machine, it's already installed because I added it manually to experiment with the WoL, but otherwise that's how it got on my other router :+1:

Interestingly, and nitpickingly, no, it doesn't, at least not necessarily. wireguard-tools depends on any ip package:

Package: wireguard-tools
Depends: libc, ip, ip, kmod-wireguard

And if you look closely, your screenshot even says "ip-full or ip-tiny"—the latter being the usual package that will be pulled in by the dependency. And neither wireguard-tools nor even wireguard (i.e. kmod-wireguard) itself are installed on your system. Your screenshot only shows that, were wireguard-tools installed, it could make use of the already installed ip-full.

Really, something else must have pulled it into your system. Again, opkg whatdepends ip-full would tell you what on your system actually depends on it. If you care, that is, I don't think it's a great mystery that needs solving. :wink:

There was a misunderstanding, the screen is from the x86 PC, the one that didn't have ip-full. It is now installed because I installed it manually to allow WoL to work properly!

luci-proto-wireguard.is not installed because I was experimenting with Tailscale instead, I just captured a screen with all the dependencies that are needed to show it's where ip-full came from.
On the MT300 router, the one where I inistiallly found that ip-full was already present, it was installed as a dependency of luci-proto-wireguard.

Btw, I found out that WOL works from Tailscale to the 10.0.0.0/24 LAN, but it fails to reach devices on the 192.168.1.0/24 LAN.
It works fine using the WOL utility in OpenWRT, even if it's on the "WAN".
Tomorrow I might try with Wireguard... not that I really need to wake up stuff on a WAN, it's just for science :grin:

luci-proto-wireguard depends on wireguard-tools, wireguard-tools depends on ip, which can be provided by multiple packages including ip-full, but if ip is not present, pulls in the first package that provides ip, which is ip-tiny. I'm really not trying to belabor the point, but if you want to know where ip-full came from, wireguard-tools isn't it.

1 Like

Well, that's weird if ip-tiny is the default one installed by luci-proto-wireguard, because I'm pretty sure I didn't install other packages that depended on ip-full on the MT300.

If I run opkg whatdepends ip-full I get nothing, actual output is:

Root set: ip-full what depends on root set

With opkg status ip-full it says install user installed, while for example wireguard-tools says install ok installed.

I assumed luci-proto-wireguard installed ip-full because I definitely don't remember installing it manually, but the weirdest thing is that I checked the Installed-Time parameter.

wireguard-tools (something definitely installed by luci-proto-wireguard) was intalled at 2025-02-11 21:54:55 UTC
luci-proto-wireguard was installed at 2025-02-11 21:54:59 UTC
ip-full was installed at 2025-02-12 00:15:05 UTC , so AFTER Wireguard.

And adding to the mistery, the supposedly default ip-tiny isn't present :scream:
Now, I might concede that I've installed ip-full without realizing, maybe following some tutorial, but also uninstalling ip-tiny? Nope, that definitely never happened.

I guess it might have been removed because it showed up as a conflicting package with ip-full? I really don't know :neutral_face:
Well, whatever happened, still useful discussions, I learned a lot of new opkg commands.

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