Here it is my proposal for fixing the firewall problem.
If firewall is installed, it does nothing new. But if it is not, it
creates a script to execute the /etc/firewall.user script on each boot.
https://github.com/libre-mesh/lime-packages/commit/e76bc740dfa20dc581a905a4…
It is very simple and works, so we don't need to depend on the whole
firewall shit, I mean thing.
If you like I will merge it to develop.
Cheers.
--
./p4u
Hi all!
I have just pushed the feature/ground-routing branch to our git repo, the good
news is that it is already usable and working, the bad news is that it seems
that openwrt doesn't offer a way to know who switch%d is so it could arbitrary
be eth0 or eth1 depending on the model and seems there is no way to determine
it from software side -_-
what I have done now is assume in the code that swtich$i will be mapped to
eth$i and although it is not true it works on all device i have and on device
we use the most like tl-wdr3x00
what openwrt do is ship a spefic confing for each different device, this config is
manually written by the person who write the support for that device so plain
old boring manual human work...
what we can do is
1) leave stuff as is, so users with "unusual" devices have do do some adjust
after lime-config
2) Introduce some kind of very very hardware specific module like the unpopular
lime-hwd-tl-wdr3600 we had this summer for each device with a "switch map"
readeable by a program
3) Push openwrt developers to implement some kind of mechanism to make switch
map readeable from software side
Hi all!
I have been working on adding support for ground routing in libre-mesh in this
days around winter solstice, today i have done various tests and as they
satisfied me i have merged the work on develop branch, although it is stable
and usable, some buggy switch chip of some router like tl-wdr3500 need some
little (remove Ground routing port from other vlans) configuration tweaking
after lime autoconfiguration, while for example the tl-wdr3600 works out of the
box
Moreover ground routing works also with CPE that doesn't have an integrated
switch like e ubnt-bullet :)
Debugging/Patches/Feedback are all welcome
https://github.com/libre-mesh/lime-packages/commit/03202c811e3d3a208a28b35b…
Today I have compiled and installed the last libre-mesh develop branch
with the last openwrt-trunk. Congratulations to everyone! It worked fine
almost out-of-the-box. The next points are my thoughts/questions
regarding the current state of lime:
1) The firewall problem is not yet fixed, so raw images which does not
include the firewall packet are not properly working.
2) Last OpenWRT/trunk does not have the iptables nat module
(CONFIG_PACKAGE_kmod-ipt-nat) by default enabled (WTF?), so it should be
added as dependency for lime-system. May be also related with the
default strip kernel/libraries options (which comes enabled).
3) Would be nice to write the current options (even if they are the
default ones) to /etc/config/lime once the lime-config script is
executed. So it should 1) use the options specified in the file 2) fill
the non-specified options. Then in the config file you got a picture of
the current whole system configuration, when you upgrade the node these
options are preserved and the node is configured in the same exact way
it was before.
4) Is there any way to specify: "do no configure (or ignore) this radio
device" to lime-config?
5) In my tests, when I try to set some parameters for a specific radio
device (i.e only radio1), lime-config crashes. My first thought is that
if there is a specific configuration for radioX, lime-config expect to
find all the needed parameters there. I think it should try to find
first the parameters in the specific configuration and afterwards (if
the parameter does not exist) look in the generic/default wifi
configuration section.
--
./p4u
Hi all!
now adhoc_ssid is parameterizable with %H that will be substituted by hostname
and with %Mn that will be substituted by the n'th byte of the device primary
mac address, if you have personal clones and wanna test the feature just
rebase on top of develop branch
We're having the problem that bmx6 nodes sometime come up on different
subnets.
The interfaces are getting fd66:0066:0066:00XX::/64 IPs, where XX is the
interface index. This means that some nodes are on different subnets, since
they don't all have the same wifi interface index. Is this intentional, and
if so, why? It means that just running "bmx6 dev=wlan0" on each node will
not result in a working mesh where every node can reach every other node on
their bmx6-assigned addresses.
It seems that either the mask should be changed to /56 or the interface
index should be used as the eigth or higher byte instead of the seventh?
Perhaps it would be better to replace the ff:fe inserted into the middle of
the MAC address with the interface index?
Here's the responsible code from
https://github.com/axn/bmx6/blob/master/ip.c:
if (!global_prefix_cfg.mask && !dev->global_prefix_conf_.mask &&
autoconf_prefix_cfg.mask) {
autoIP6 = bmx6AutoEUI64Ip6(dev->if_link->addr, &autoconf_prefix_cfg);
autoIP6.mask = DEF_AUTO_IP6_DEVMASK;
autoIP6.ip.s6_addr[6] = DEF_AUTO_IP6_BYTE6;
autoIP6.ip.s6_addr[7] = (uint8_t)dev->if_link->index; //different ULAs
for equal MAC addresses!!
}
--
marc/juul
The file /etc/config/lime seems to follow the same reasoning behind many
other projects' default config, that is some commented lines that show
how the conf should look like in the most frequent scenarios.
In lime (branch:release/14.08) the comments are very self-explanatory
but the example is for configuring radio1 and radio2 while 99% of the
devices have radio0 and at most radio1...
I think that should be changed because for a noob user like me it is
misleading to show examples for radio1 and 2, while the radios are
numbered from 0.
What do you think about it?
Hi!
It seems to me that the actual generate_host(...) function doesn't permit to
de user to specify completely it's address on /etc/config/lime, what i see is
that if the user specify as example 10.10.10.10/24 as his ip address the last
nibble get overridden by generate_host(...) function, is this the expected
behavior? If so i would change that giving the user the possibility to specify
completely it's ip address
Cheers!
Hi all!
I remember that guifi.net assigned to libre-mesh an IPv6 subnet bigger then the
one we have for librenet6 so we can do the mapping of assigend ipv4 -> ipv6 i
remember also a wikipage explaining the mechanism, someone remember more
details ?
