On 08/14/2014 06:44 AM, Gioacchino Mazzurco wrote:
 On Thursday 14 August 2014 04:46:27 Gui Iribarren wrote:
 On 12/08/14 08:48, Gioacchino Mazzurco wrote:
 On Monday 11 August 2014 22:33:31 Gui Iribarren wrote:
 The good things is that hardware detection module will take care of
 hardware quirks while protos can be more hardware agnostic :)

 I'm not entirely happy with having a package called "lime-hwd-eth1-wan"

 This will probably evolve into an option like "respect openwrt wan"

 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.

 lime-hwd-eth1-wan does nothing on wdr3600 / wdr4300 because there is no eth1 
 ;)

  * having a way to easily assign "wan" function to custom ports,
 qualifies as a *feature* / wishlist, something that openwrt does not
 offer currently.

 yep

 a solution can be

 lime-hwd-eth1-wan ->
lime-hwd-respect-openwrt-wan + lime-proto-wan

 this would solve 3500/3600/4300 and a lot of other boards wan problem

 and i'm even more puzzled with "lime-hwd-tl-wdr3600" - are we going to
 have such packages for many other boards out there?

 We will have packages for boards that have specific quirks, tl-
 wdr3600/4300/4310 for example doesn't associate with clients on radio0 if
 there is an adhoc interface builded on top of it, this behavior has
 reproduced indepentently by me, Ilario and Pau

 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.

 We can remove that parts if we can confirm that adhoc+ap works without quirks 
 on that device but doing tests that have also some time duration

 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

 It's strange both images compiled by me and from Pau seems not affected by the 
 bug

 i think we can combine both approaches, like you suggested: make the
 "wan" proto respect
"openwrt" wan on firstboot,

 No, the wan proto should not take care if it is first boot or not, who should 
 care of that is lime-hwd-respect-openwrt-wan 

 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.

 I think the same on this

 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.

 hwd already do this, it flag as autogenerated=true lime.* section generated by 
 it, if the user edit the section should set autogenerated=false so hwd will 
 not touch that section anymore

 so, if i flash a tl-wdr3600, after firstboot /etc/config/lime will have
 config net eth0.2
  list protocols 'wan'
  autogenerated=true

 while if i flash a tl-wdr3500, i will get a /etc/config/lime with
 config net eth1
  list protocols 'wan'
  autogenerated=true

 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

 you should also put autogenerated=false sol lime-hwd know that was touched by 
 user and will not edit it

 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.

 The idea is not to reimplement the whole logic ;)

 But to have a way to avoid quirks that some boards have and that openwrt 
 doesn't take in account because it's default configuration is simpler that the 
 one from lime

 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

 I believe it deserves more than that because we need to talk on future
 evolution of hardware detection, at moment it is limited to avoid specific
 hardware quirks, but I was thinking in something like a capability system
 but we need to talk about this, I have some doubt on doing this via
 mumble, i believe we need some other talking night like in La Responsable
 some time ago
 Then come! spring will start here in about a month :D

 in the meantime, i think a mumble meeting definitely can't hurt,

 Of course ;)

 what
 about next week? say, tuesday
2014/08/14 at 13pm UTC like last time

 you mean 2014/08/19 ? how much days haven't you sleeped ? :p

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

Dev mailing list
Dev@lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev