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.
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.
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.
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
It's not just wan, we need a way to work around boards specific quirks without
modifying general code that usually fix a board and break another, returning to
wan problem, the way you got wan working was not configurable, so if the user
would use it as lan instead of wan she had to edit directly /etc/config/network
and not /etc/config/lime that is not what we want...
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.
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, what
about next week? say, tuesday 2014/08/14 at 13pm UTC like last time
cheers!
Cheers!