I have just pushed latest commits from Frank sandbox bringing the new hardware detection feature to our main repository https://github.com/libre-mesh/lime-packages/commit/4c3835541b4823cbb0936791… Here you can find also some fresh compiled images, together with Frank we tested on tl-wdr3500 today and on tl-wdr3600 yesterday with positive results http://madrid.guifi.net/~gioacchino/openwrt/lime/bin/ar71xx/ The good things is that hardware detection module will take care of hardware quirks while protos can be more hardware agnostic :) Cheers! P.S. feedback is welcomed

In line. On 12/08/14 03:33, Gui Iribarren wrote: In my opinion it would be better to have a single packages (lime-hardware-modules) with a set of options which can be enabled or disabled. Same approach busybox follows (and many others). So from menuconfig you have a single configurable packet where can select the hardwares you want to include. I've not read the code you talking about, but I would say we should avoid putting specific-hardware code in the common/generic code. Something like "if wdr3600" then "blah", is quite dirty. In addition, if you are modifying the general behavior then it is very likely that you broke the compatibility with some other hardware. I think the Gio/Frank approach is quite good. I agree with you here. Cheers ;) -- ./p4u

On 12/08/14 08:48, Gioacchino Mazzurco wrote: as it stands now, it actually covers *less* cases than my approach :) + TITLE:=Configure eth1 as wan interface if present in wdr3600 / wdr4300, there's no eth1, but openwrt correctly configures eth0.2 as wan by default. in my point of view: * having a broken wan port on devices that (with vanilla openwrt) normally have a working wan port, qualifies as a *bug* / regression on our part (over what openwrt offers). * having a way to easily assign "wan" function to custom ports, qualifies as a *feature* / wishlist, something that openwrt does not offer currently. i have not encountered that bug (i'm writing with a tl-wdr3600 next to my arm). Asked pau about the steps to reproduce it or the symptoms, and he said he's not sure it's still a problem on current builds. i agree my approach was not configurable, since that wasn't my point (cf. the bullets above). I thought configurability was a wishlist feature, and I wanted to fix the bug. I like the "wan" proto idea, but in it's current implementation, it adds configurability, but regresses to the bug, so i think it's a bad tradeoff :P i think we can combine both approaches, like you suggested: make the "wan" proto respect "openwrt" wan on firstboot, and after that allow the user to modify the /etc/config/lime abstraction and have that propagated on-demand into the lower layer /etc/config/network. in other words, make lime-config behave differently if it's running on firstboot or afterwards: * on firstboot, it will kinda "look" at what openwrt configured (see what interfaces set as lan, wan, wifi, etc), and create an /etc/config/lime that respects and reflects that firstboot (upstream-aligned) state. * on every other run afterwards, it will no longer respect what's set outside of /etc/config/lime, instead enforcing it's own "view" of what the config should be. so, if i flash a tl-wdr3600, after firstboot /etc/config/lime will have config net eth0.2 list protocols 'wan' while if i flash a tl-wdr3500, i will get a /etc/config/lime with config net eth1 list protocols 'wan' and afterwards, i can touch that "config net" section to turn that port into something else, or assign proto wan to other port, or whatever, and run lime-config again, which will (only then) overwrite /etc/config/network to put it simple, i think on firstboot we must respect as much as possible openwrt default config, if we want to run on as much hardware as possible. we will never outsmart openwrt devs in terms of board compatibility. in concrete terms, i'm talking about this: http://pastebin.com/24MEx5V0 respecting what that file produces on firstboot is not hard, but trying to reimplement all that logic in "our" scripts will definitely be unmanageable. Then come! spring will start here in about a month :D in the meantime, i think a mumble meeting definitely can't hurt, what about next week? say, tuesday 2014/08/14 at 13pm UTC like last time cheers!

On 08/14/2014 06:44 AM, Gioacchino Mazzurco wrote: I've been sharing my thoughts on this matter with gui but had no time to write on the list. I'm ok with 2014/08/19 at 13pm UTC for the mumble meeting. I also think it would be really good to meet in person as Gio proposed, and spring or summer time in Argentina would be a good time. I'd prefer summer, when I hope I'll be more used to dealing with our life with Amélie Gioia around :) Just a thought: maybe some GSoC money (+ some guifi/confine whatever money) could be used to fly you guys here... you should also consider if there would be some academic value in the trip if your universities have agreements with the Universidad Nacional de Córdoba (it is very plausible for it's one of the oldest Universities in Latin America). We work with them regularly and our community networks are connected to their campus. Cheers, Nico

here we go: I tried the new binaries: The new binaries from downloads.libre-mesh.org, has a strange behaviour to reach it. There is no way to connect to it after sysupgrade (no telnet, ssh, web). I had to failsafe it, and it looked like there is nothing about LiMe. I tried directly the ones from gio. gioacchino’s has LiMe. I had to make firstboot, in order to get a correct ip address. (maybe I didn’t waited enough). No web interface, once connected to telnet in order to set passwd, it refuses all types of connection (web, ssh, telnet). Wifi and Ethernet fine! If you want me to make more tests, tonight could be possible. Take in account that I did these experiments in a hurry. On Aug 12, 2014, at 1:49 AM, Gioacchino Mazzurco <gio(a)eigenlab.org> wrote:

eureka, now everything is fine, Btw, if somebody has a fix for my other issue I tried to plug an external wifi (AR9271) because the 703n (with or without ext. antenna) has a really poor range. I got everything installed (ath9-htc), however nothing happens on wifi detect. Any ideas? Pau said that usb device has some issues, so maybe, I won’t be able to get it working, about 1 week remaining for the thesis ;-) On Aug 12, 2014, at 11:51 AM, Gioacchino Mazzurco <gmazzurco89(a)gmail.com> wrote:

On 12/08/14 17:22, Max Schmit wrote: i have to advise against using usb dongles for anything other than client mode. adhoc is at best unstable and hard to debug, and while AP mode works reasonably stable, it suffers (along with adhoc mode) from a 7-station limit inherent to the firmware design. add to that kernel oopses on plugging and unplugging, and you'll understand why we (or at least me) have ceased wasting time into supporting dongles. :( cheers! gui

@Max You are right, last commits in lime-packages made the firmware image increase a bit and it does not fit anymore in the fucking 4MB flash. I've enabled the options for stripping not needed libraries and now it looks like it fits in 3.5MB. So, in some minutes you will have new images in downloads.libre-mesh.org. Please, test and report! :) PS: this firmware image have lime-full which means also webui On 12/08/14 11:42, Max Schmit wrote: -- ./p4u