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'
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
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 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?
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.
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.