Yes, this is the same behavior I noticed. As lime-config is executed in preinit (as a uci-defaults script), it may not configure properly some things. And as the exceptions are not controlled in the code, once something goes wrong the script stops its execution and everything became not configured. This is fixed in the branch "new_init" which right now is merged in the branch "hardware-detection" which is probably the most advanced branch of the current ones. I'll compile right now for this branch and the binaries will be available in the respo. Cheers. El lun 11 ago 2014 20:26:13 CEST, Gui Iribarren escribió: -- ./p4u

On 11/08/14 20:49, Gioacchino Mazzurco wrote: I'm not entirely happy with having a package called "lime-hwd-eth1-wan" and i'm even more puzzled with "lime-hwd-tl-wdr3600" - are we going to have such packages for many other boards out there? it might be just me, but at first sight i get the feeling we're heading in the wrong direction i got wan to work on wdr3600 and wdr3500 as well, without this module, so i'm not entirely sure the problem you're trying to attack i'm not saying the hardware-detection module is a bad idea; instead, i think it makes a lot of sense, but not in these particular solutions :) that can be addressed in a more "upstream" way for what is worth, congratulations on running this succesfully on wdr3x00! if it proves useful right now, i guess we might merge it even if it's not the ideal solution, and try to refactor the code in the future in any case, i think this branch deserves some mumble meeting :D aside from everything, i think it would be very valuable for you to sit down with Frank and guide him to use "git rebase -i" to squash commits into more useful blobs (i.e. unlike 8d14665915 "sintax fix" for example :P ) probably rebasing the whole branch on top of 23289691 as well avoiding those "Merge branch 'develop'..." which won't make much sense when the branch is accepted in develop. cheers and keep up the good work! gui

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

@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

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

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