I've built an Openwrt kernel for Rambutan board (repo: https://github.com/8devices/openwrt-8devices rambutan). I installed kmod-batman-adv and batctl. My problem is that when I add my IP address for the batman interface, Openwrt doesn't accept my IP address and it's never added to my interface. what I need to chose is an IP address simply in range 242.x.y.z. I can see that batctl is running and it works with other ip addresses like 10.x.y.z or 172.x.y.z. but not with my desired ip.
Is this a bug in the kernel or the ip it is an reserved address?
here is my network settings:
config interface 'mesh'
option mtu '1560'
option proto 'batadv'
option mesh 'bat0'
config interface 'bat'
option ifname 'bat0'
option proto 'static'
option ipaddr '242.67.10.15'
option netmask '255.0.0.0'
option mtu '1500'
option ipv6 '0'
Thanks very much
I cannot explain why it is failing, but the whole 240.0.0.0/4 block is "reserved for future uses", and should not be used.
I have vague memories that the mentioned reserved block is (or was) "disabled" by the Linux kernel.
Why did you choose that range?
Actually I'm already using this ip range (242.x.y.z) on lede-openwrt in carambola 2 board.
I can't figure out why it's like this
the kernel version on Rambutan is 4.1.23
At least in my opinion, there is plenty of address space in the common Class A, B, and C private address spaces. Using those would remove one potential problem.
OpenWrt is presently on Linux 4.14 or 4.19 for most devices. Linux 4.1 hasn't been updated in a long time and 4.1.23 is pretty obsolete at this point
commit 54419e3efcd6 (tag: v4.1.23)
Author: Sasha Levin <redacted>
Date: Sat Apr 23 16:46:56 2016 -0400
Thanks for your reply.
but this is what I got from 8devices repository for Rambutan. How can I choose the newer kernel version before building it?
It looks like it is directly supported by OpenWrt, though there doesn't seem to be a device page
and, if you're adventurous
master (without LuCI pre-installed)
Edit: Looks like it is supported by the ar71xx target at this time. Still waiting on project review and merge of the ath79 NAND PR that would be required to port it to the current, ath79 target.
It's reserved for future addressing modes. That means: unicast, multicast, broadcast, etc. IP addressing is not valid on that space.
Not blocked, but definitely not configured to be recognized for normal addressing.
It's interesting that I can add the IP using ip commnad ´ip add add 242.0.0.0/8 dev bat0` but on the /etc/config /network it's not possible to set the IP. Could this be an uci error?
cause it has a wide IP range
Not wider than 10.0.0.0/8...
yes but we are using that ip range for another interface
The point is that you should not be using that range. If you manage to make it work, and do not affect others, good for you. But I would not expect much support around here if it does not work.
On the other hand, many devices will implement the same filters you encountered: for example, Windows boxes might refuse an IP address in that range when issued by a DHCP server.
What about a subnet from 172.16.0.0/16? 65k addresses should be enough.
How many hosts do you need to accommodate in each range? It seems highly unlikely that you actually need 16M addresses. I would seriously consider reallocating your address schemes with more reasonable subnets.